> -----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. Regards Kai _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
