Fork me on GitHub

Phabricator had this as the default


Although this seems way lighter


Bore da pawb welsh_flag


hmmmm... I read that first as 'daft' pull request and wondered what it was facepalm

😂 5

I too love to solve social problems with technology 😛


putting WIP in the title of the PR was far too difficult


Heh. We don't use PRs, just do all work on master and require commits to be non-breaking, but I suspect that would fall down with a more open project and/or something that was more of a monolithic app instead of lots of small microservices


my last project at digital was all trunk-based and it completely confirmed my suspicions about trunk

😅 5

What were those suspicions? I take it you didn't like it? 😉


no, that it's the best way to speed up delivery


Oh cool :) I agree but I’ve tended to find pushback from others outside of our and a few other teams.


we do multi-trunk - a trunk branch for each release cycle, with the general principle that all lower-release trunks should be merged into a higher-release trunk. it generally works pretty nicely, although it does get hairy if a release is delayed for a while for some reason and you consequently have more than one very active trunk


Though thinking about it, the pushback is generally from people who haven’t tried it...


I don’t think there’s any objectively better git workflow; it entirely depends on what is right for the team and how they’re organised and managed. Trunk based dev at scale complects the workflow to force integration at the expense of isolation. I’d say it’s the easiest (not necessarily best) way to speed up delivery in the short term. It’s the singleton pattern from OO as a workflow, which is fine when you only want one system; but if you need many you’ll find people coordinating adhoc outside of the version control system and CI. For example with trunk based dev, how do you integrate large scale changes across many services/repos without shutting down the shop floor? You trade off that capability; which branching workflows enable (with more complex supporting infrastructure).


you feature flag and have a lot of redundant code is what I found


but then once the flags reverse you can prune it all pretty aggressively


I found that the QA effort, the having good test/dev data effort and writing good tests effort went up, but the brainpower required to dev and get code out was an order of magnitude better


> you feature flag :thumbsup: yes you can — but then you need to manage the different sets of flags across services etc. Ultimately you’re moving organisational problems into code and increasing complexity of things to test. Which is totally fine, so long as you’re aware of what you’re doing. Feature toggles often just give the illusion of integration; until you try a combination you thought would work and realise they’re incompatible.


At the end of the day I think mandating any one workflow without consideration is removing tools from your shed. (Not saying anyone here is doing this btw) You can make more subtle trade offs still by combining feature toggles with branches for example.


I think there’s only been one word I disagreed in this conversation and that was the word best 🙂


I should also say we do use feature toggles for this in some of our services… (though we still use branches too). And they can work well, in particular it lets you decomplect notions of merged & integrated. For example one of our customers sponsored a large complex feature. It’s not generalised to everyone else, so feature toggling made sense, as it meant we can pick up cross cutting improvements in particular styling changes etc. However I’m under no illusion that the feature isn’t being tested with some other features yet… some combinations may be assumed to work but untested etc. It’s a JTBD to unpick that, and test combinations of features. We use duct, which is pretty good at this sort of thing… Thinking about it I recon we can probably represent those features in the keyword hierarchy, so we can use that to represent what is expected to work and then test those combinations explicitly.


we’ve had a ready for review tag for years - to indicate readiness — so whilst it’s a nice feature and has a few more protections it feels like it’s an overly specified feature. Main advantage I guess is it encourages more people into better default workflows. We’ll certainly be using it, but I find it hard to believe there weren’t more important features of equivalent complexity to add.


Yeah, we apparently used phabricator back before I joined


Although at the time I think we might have mostly been an svn shop too


isn't Phabricator a PHP groupware for devs product..?


What is groupware


Software for groups that provides a suite of facilites / apps that allow that group to work, so messaging, calendaring, planning, documenting (wiki) etc.


I think so, yeah


I had a colleague in Manila who was keen to move us over to it instead of using Atlassian and Github... $20/seat (up to 50 seats then more for no more $s) seems pricey, but when you add it up... Thing is I really like Clubhouse and I really like Github and I hate Wikis anyway, so I'd rather not have one...


(apart from Wikipedia, that one can stay)


Quick announcement / thank you to you lot - I have hired someone! He signed the contract yesterday and starts on March 4th, so I am excited to soon be un-alone... I am still hiring on the Front End (see #jobs and Functional Works), so if you know of any young / new-to-ClojureScript (age is not a factor) devs who want to change the World for good, please send them in my direction... 😉

👍 35



the first step on the path to you never writing any code 😉


From your mouth to God's(*) ears... 😉 (*clearly I am an atheist, so this is a silly saying)


and thanks 🙂


The wisdom of experience 🙂


Morning, and congrats @maleghast! :)…