Dnia czwartek, 24 stycznia 2019 13:33:28 CET Allan Sandfeld Jensen pisze: > On Donnerstag, 24. Januar 2019 13:27:41 CET Jedrzej Nowacki wrote: > > Dnia środa, 23 stycznia 2019 22:04:16 CET Allan Sandfeld Jensen pisze: > > > On Mittwoch, 23. Januar 2019 16:51:10 CET Jedrzej Nowacki wrote: > > > > Proposal in short: let's use cherry-pick mode everywhere. > > > > > > > > All(**) changes would go to dev. From which they would be > > > > automatically > > > > > > > > cherry-picked by a bot to other branches. The decision to which branch > > > > cherry- > > > > > > pick, would be taken based on a tag in the commit message. We > > > > > > > could add a footer that marks the change risk level as in quip-5 > > > > (http://quips-qt-io.herokuapp.com/quip-0005.html), so for example > > > > "dev", > > > > "stable", "LTS". By default everything would be cherry-picked to qt6 > > > > branch > > > > unless "no-future" tag would be given. Of course we can bike-shed > > > > about > > > > the > > > > tag names. > > > > > > I don't see any advantage to this what so ever. The same amount of work > > > and > > refactoring needs to be done, all you have done is made development > > > > more prone to human error, and fixes less likely to reach their intended > > > target, and made getting point releases out on time harder as they need > > > to go through more steps before they have all their patches in. > > > > > > 'Allan > > > > It is hard to answer this because you have forgotten to write why you > > think > > that development would be more error prone or fixes less likely to reach > > > the destination or more steps would be involved in releasing. So I will > > try > > shooting in the dark :-) > > > > The current merging strategy involves couple of people, one merge master > > and a > > random reviewer that looks at conflicts if there are any. Usually it is > > > not even close to quality level we have for single patches in which we > > have > > more reviewers and gerrit shows the real diff. In practice we assume that > > no conflicts == good merge. > > > > Fixes are less likely to hit target branches, true, but only if nobody > > cares. > > Mark that a fix can magically disappear during broken mere, nobody > > > will see it. The proposed solution allows at least track such cases. > > > > Releases branches already use cherry-pick mode so from that perspective > > there > > is no big changes, the only one is the origin branch from which the > > > cherry- pick should happen. > > Yeah, this was no the best of comments on the issue. But I believe I wrote > my objections elsewhere: > - Cherry-picks are more error prone in git than merges and requires manual > intervention more frequently
Yes, they are in some ways, I think I managed to not hide them in the proposal. I believe that the load distribution, the fact that more people can handle issues, reduction in bus factor, ability to solve problems in parallel with a significantly smaller context/scope and transparency of the process overweight the risks. In addition we may write tooling, that helps us to detect problems, like for example gerrit change hanging in a limbo for too long, because all of the data would be there. > - Even if we accept the always and instantly cherry-pick model, there is no > reason to push to dev, continuing to push to the same branches as now could > achieve all the same things with less room for error (because where it is > supposed to be merged to is both implicit and unambigious) I mentioned that before. Cherry-picking from stable to dev means that in case of an error we have a regression. In my opinion it is worse, then accidentally not having a fix for something that was broken forever in an older branch. > - By having all commits go to the same branch you make that branch > overloaded, and will break our CI even more than it already is. I will answer that in other part of thread, as I believe it deserve a subtopic on it's own. > - I don't see making it harder to fix bugs in the stable branch as a > benefit. Why harder? Conflicts rate is more or less the same, they will be just resolved by a different person. So I wouldn't call it harder just the maintenance cost would be more visible / moved to the author. Cheers, Jędrek _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
