On Wednesday 19. February 2014 14.34.51 Frederik Gladhorn wrote: > This is independent of Ossi's proposal and tries to solve a different > problem. > > One of the pain points in this release was the "which sha1 makes it in". > I'd like to propose defining this part as it hopefully solves quite some of > the issues we had. > > So far the procedure is roughly: "whenever whichever merge passes CI around > the cut-off time is in". > > I would like to propose instead that we define a certain time, let's say a > week, where maintainers pick which sha1 in this time frame should be the one > used for branching. > > This means we get a defined sha1 that goes from > dev->stable and stable->release > and no longer chase a moving target (some tip of the branch). > To not overly complicate things for most modules where little changes happen > the release team makes a decision. > In case of a change in the branching system this is still valid in that it > would define the branching point.
I fully support that and I think we should do this in any case. Module maintainers - where present - "deliver" a base sha1 that forms the stabilization branch for the next minor release. Whether that delivery happens within a week or until a certain point in time and what happens afterwards we need to discuss of course :) One immediate advantage of this proposal is that we can keep "dev" always open. We still have to lock down "stable" until the sha1 -> stable merge is through the CI system for all modules. However in the spirit of incremental changes to the project and also in light of the advantages the simple three- naming scheme has, I think we should try this first and see how much "frustration" remains before we re-design the naming scheme itself. Simon _______________________________________________ Releasing mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/releasing
