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

Attachment: signature.asc
Description: This is a digitally signed message part.

_______________________________________________
Opm mailing list
Opm@opm-project.org
http://opm-project.org/cgi-bin/mailman/listinfo/opm

Reply via email to