Sounds like you want to implement something like merge trains?[0]

[0]: https://about.gitlab.com/blog/2020/01/30/all-aboard-merge-tr...

Another question I got on this. What do you do with merge conflicts between the branches? Do you then provide the system with patches for the merge conflicts somehow, so that it can resolve them as needed?

E.g. when merging A, B and C. C might have no conflict with master or A but it has a conflict with B. Now for the queuing to work A -> B -> C it will have to know somehow how to patch C to fit on top of B.

Maybe B breaks if it is not working after merged into A, and then the queue becomes A -> C -> B (modified), now B probably needs a patch to merge cleanly on C?

The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts, and doing sidebars as needed where a discussion of the approach was warranted. They would resolve those conflicts in their branch before the PR was submitted. If the conflicts happened between submission and approval then the conflicts would still be resolved on the task branch before merge.

>The developer whose task branch had merge conflicts was responsible for resolving the merge conflicts

But that's exactly my point. The first PR to merge cleanly will determine whether the next PR causes a merge conflict or not. At the time of merging, none of these PRs had a merge conflict.

We often have 10 conflicts between PR admission and approval.

The key is to reduce the number of developers touching a specific section of code, and line up all tickets and hand them over to a single developer (or two).

And yeah, management won't do it. Fred Brooks wrote an entire book about this in 1975 that no one reads today and everyone would certainly ignore if they did read it. Because it tells you the unvarnished truth about the nature of communication and information flow within an organization. Such is the state of things in our industry. Sweet little lies.

> We often have 10 conflicts between PR admission and approval.

I don't think a devops solution can remove those conflicts. At least not all of them.

If you have devs in the same hot-spots of the code, you're going to get conflicts. Maybe refactoring can address some of this core issue.

We call ours the "stage". Merge conflicts are just a "please wait" signal. The way it works is:

  - the stage is always up-to-date with the target branch (so if it updates, we re-merge all topics on top of the new target branch head)
  - topics should pass CI standalone before being staged
  - the stage is first-come first-served, so "later" topics have to wait
  - updating a topic puts it at the end of the line
  - topics should really go through the stage before landing in the target branch

Conflicts (content or logical) will cause a topic to have to wait until the conflicting topic has landed in the target branch before it can participate in the stage. This usually only affects topics working in the same area.

Our library implementing this: https://gitlab.kitware.com/utils/rust-git-topic-stage

However, given your later metric of 10+ conflicts per topic…I suspect your project is still in the "getting off the ground" phase where a stage is awfully heavy process because there aren't "bright line" distinct sections of the code yet. Or your topics are too big. Hard to say.

This is a great solution and while I was at Google I noticed several high commit frequency teams using this strategy. Of course Google had built a bunch of custom tooling and infrastructure around it, so I can’t vouch for how easy it would be to integrate into a different company’s dev workflow, but if there are enough developers to make it worthwhile, then tasking a few developers with setting this up should be a useful allocation of engineer time.

GitLab has this feature.

Not for fast forward merges.

Last time I checked they don't exist in GitHub, but it seems like a really good way to counteract this problem.

Almost there: https://github.blog/changelog/2021-10-27-pull-request-merge-...

To note, we signed up for the beta and got accepted in last week. Haven't turned it on yet though.

Merge trains are the way. They do optimistic testing of the prior branches in the queue so the happy path goes fast.

This one's at the top of my list as well. I will never work for Facebook.

That's mainly because we started exporting most of the wood to North America, creating our own shortage here in Europe. Hence, prices went up here too.

http://www.phptherightway.com/ https://learnxinyminutes.com/docs/php/

I write my SQL as follows:

    SELECT `second_column`,
           `fourth_column`
      FROM `table_name`
     WHERE `first_column` = 'Value'
       AND `third_column` = 3
  ORDER BY `fifth_column` ASC
     LIMIT 1

Well that is cute. I find it odd that the second line of the where clause is on the same level as the where but a neat format otherwise. Tabs or spaces though?

What happens when you need to do something non-trivial? Ie. nested selects, joins or even only some more complex expression in WHERE?

Yes, it is!

http://electron.atom.io/docs/tutorial/windows-store-guide/

No, it really isn't. The worst thing that can happen in programming is my application throwing an error (assuming PHP/Python or similar). That's really nothing compared to when I'm driving a heap of metal at high speeds around the streets together with other people doing the same.

> The worst thing that can happen in programming is my application throwing an error (assuming PHP/Python or similar).

This is not remotely true at all.

Discounting the fact that some programs execute within the "heaps of metal" you speak of. There are also programs and solutions out there that affect millions of individuals, and could absolutely have far-reaching consequences in a "worst case" scenario. E.g. The recent citizen information leaks.

He mentioned "even basic programming", that's what I ran with.

Goddamit, I downvoted you when I meant to upvote. Sorry.

Seems like a good start to a useful project! I'm a bit turned off by the lack of customisation options for the servers though. I would like a bit more options in terms of what gets installed and what not (I don't need Bazaar, Mercurial _AND_ git installed f.e. and I'd like nginx i.o. Apache).

I'll definitely be keeping an eye on the project!

It's an awesome project and I like how it significantly lowers the entry barrier to get into Erlang programming for a lot of people. Personally I just haven't really had the time to play around with it yet but it's definitely on my list of things to try.

Also, I don't get that there seems to be such a divide between the Erlang and Elixir community. It should be much more mingled together imho.

Why not use a real-world example of something you would write a class for? The best tutorials are the ones that teach you things you can actually use. I've never used an Animal or Vehicle class myself. A better example might be to write something like an Article class, and then build out to a very simple and minimal blog?

That's a good point. As a second suggestion, I think I liked Dive Into Python's example of a mp3-file metadata parser, from way back when I learned python

http://www.diveintopython.net/object_oriented_framework/inde...