|
Top-level
 @zimoun The tiny-teensy team that took care of ‘core-updates’ (myself included) did lots of testing, tons of fixing, and put out calls for testing and an advanced notice before the merge. I think it’s the first time this branch is merged with so few problems detected afterwards. The Emacs and Git issues are problematic; apparently they could only be detected through regular use, and perhaps individuals didn’t go that far when testing things on their machine before the merge. 3 comments
@civodul Far from me the idea to complain: what an tireless job by volunteers. Kudos! And for sure, joining the party’s free. :-) As we know, core-updates merges always provides collateral annoyances. And this workflow scales poorly. Nothing new, IMHO. The project’s moving to another workflow using more branches. Good thing, IMHO. How to merge (=test) them? Nothing new – a variant of “Incentives for review”.  @zimoun I agree! If I run into such problems when I am too busy to deal with them, I just roll back and wait for a while. Inversely, when I do have the spare time to beta-tests, I'd be happy to play guinea-pig for important updates before they get merged. I just have no idea how to find out when such testing is needed. |
Gregory's Server
@zimoun So I’m curious what suggestions people might have to avoid issues like the two you mentioned.
@khinsen