Tirsdag 18. februar 2014 08.37.02 skrev Koehne Kai: > > -----Original Message----- > > From: [email protected] > > > > [...] > > > > > I think it makes more sense to just set a cut off date and time, e.g. > > > tonight and look at the patches that were in at that time. > > > Instead of trying to merge the tip of the respective branch, I would > > > suggest merging the sha1 of the last patch that was in the branch in > > > time. > > > > > > For patches that should be in but that didn't make it through the > > > integration in time, we should imho just re-target the branch that > > > they are then intended for. > > > > That is totally fine with me if we just define the process working like > > this. Any comments from someone else? > > I personally would be happy with > - Freeze on Friday (night). Changes that are not approved by now don't make > it, but approved changes can be staged during the weekend. - Branching on > Monday morning (CET). Changes that didn't make it through CI by now don't > make it. - Some changes might be retargeted to new target branch then, > after consent from the resp. maintainer. > > I'm not sure it's worth it to have any technical enforcement for these > restrictions though. The important thing isn't whether some change 'broke > the rules' and was approved/integrated on Sunday (though the approver > should expect some backslash e.g. when it broke the integration). The > important thing is that we really branch on Monday, and head on to an > alpha. The current situation where everybody has to hold of its patches for > an unknown time, until the merge happened, is unfortunate.
I personally don't care about the timing as such. I just think that agreeing on a sha1 makes more sense than trying to merge the tip of a branch. This also would mean that nobody has to care about "frozen branches" as we had sometimes in the past. Instead as a casual developer I can just keep on pushing to the dev branch (as long as I don't mind waiting for the feature a bit longer). > > Regards > > Kai -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
