Hi Pål, On Dienstag, 4. April 2017 13:27:49 CEST you wrote: > > Cut-off date for code changes: Tuesday April 11, 2017. The master branches > > of all modules will be closed for non-trivial, non-regression and non- > > documentation merges after this, i.e., I'll be a jerk and personally > > revert any merged code changes that do not fix serious problems > > thereafter. > I don't know if I understand you correctly here, but I hope you can clarify. > Why can't every module simply make a release 2017-04 that is frozen from > April 11, and then you can simply pick that one, and we can go on doing > development as usual in the master branch? > > It's simple to just update the release and cherry-pick from master if need > be.
that's basically the plan. judging from past experience, there will be some
minor problems that must be fixed before the release and if larger changes are
merged to master during this period, cherry-picking might become a pain.
anyway, if everything works smoothly, the "hard" freeze for master will
only be three days, and the "soft" one only two weeks. also, new PRs can be
opened and existing ones can be worked-on during that period, they should just
not be merged.
> This will also be a lot less invasive (and sane?).
I don't think that this plan is very invasive, and IMO it is certainly less
restrictive than the Linux kernel's development model.
> But I probably misunderstood something.
maybe: my point is simply that you should not press Green from April 12 to
April 15, and you should be careful from April 15 to April 25, i.e., try to
not merge anything that kills cherry-picking.
cheers
Andreas
--
Sacred cows make the tastiest hamburger.
-- Abbie Hoffman
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Opm mailing list [email protected] http://opm-project.org/cgi-bin/mailman/listinfo/opm
