'Branch freeze policy' and 'Change deadline' naming change proposal

[Christopher]

On Wed, Sep 24, 2014 at 3:41 PM, Adam Williamson <adamwill at fedoraproject.org
> wrote:

> Hi, folks!
>
> I'm currently like two months behind on devel@ - apologies if I've
> missed anything relevant.
>
> A discussion in #anaconda this morning made it clear that folks have
> trouble following our full release cycle, and particularly the various
> kinds of 'freeze' that exist.
>
> So, there is a page named "Branch freeze policy":
>
> https://fedoraproject.org/wiki/Branch_Freeze_Policy
>
> which is marked as deprecated, and hasn't been linked to in the wiki
> Releases/XX/Schedule pages since F18. However, I can't for the life of
> me see any way in which it is in fact inaccurate, and it doesn't seem to
> have been replaced with anything. So far as I can see it still
> accurately describes the process we follow.
>
> AFAICS, the "Branch freeze" kicks in at the point we enable Bodhi on the
> Branched tree, which is usually a couple of weeks after forking it from
> Rawhide. For instance, on the F21 schedule -
> https://fedoraproject.org/wiki/Releases/21/Schedule - "Branch Fedora 21
> from Rawhide" is listed on 2014-07-08. The first 'Fedora 21
> updates-testing' email I have is dated 2014-08-28, so I'd say the
> schedule should have had an extra row, "Branch Freeze", dated
> 2014-08-28. (The period between branching and enabling Bodhi was
> unusually long for F21).
>
> The name "Branch freeze" seems unfortunate to me, however, as it's not
> really a freeze, it's more of a light cooling. I'd suggest we remove the
> 'deprecation' notice, update any details on the page which are no longer
> correct if anyone can see any, and rename it. Ideas:
>
>
That page only describes policy, it doesn't really connect policy to
actions one could take, or offer any explanation about what is actually
"frozen", and is very confusing. What can a package owner do in git? What
shouldn't they do? What about in Bodhi? (For instance, I have a trivial
update to a package sitting in F21 updates-testing, because I'm not sure if
moving it to stable would violate the freeze policy, but perhaps the git
commit it was built from was already an accidental violation of the freeze
policy?)


>
> Branch stabilization
> Branch update policy enforcement
>
> anyone got anything better?
>
> So, the second part of the process which is apparently causing trouble
> is the "Change Deadlines". These, again, seem to be something of a
> misnomer, because the Change Deadlines are the *actual* freezes. The
> problem is exacerbated by the renaming of 'Features' to 'Changes'. If
> you look again at the F21 schedule you'll see that it lists "Change
> Proposals Submission Deadline", "Changes Freeze", some "milestone Change
> Deadlines", and "Accepted Changes 100% Complete" - but those items are
> referring to two entirely *different* things when they use the word
> "Change". This is clearly unfortunate.
>
> Again, I'd recommend a renaming here. If we call the "Branch freeze"
> something else then we can simply call those points the "Alpha Freeze",
> "Beta Freeze" and "Final Freeze", which are the terms used informally in
> any case, and would line up with the "freeze exception policy" which
> determines what stuff can break those freezes.
>
> Along with the renaming I'd like to work over the documentation a bit so
> all the relevant pages link up and sing from the same hymn sheet, but I
> can actually do that right now, orthogonal to the renaming, without
> really needing any review, so I'll just go do it. (I'll post a reply
> explaining what I did in a bit).
>
> Thanks folks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
>
> --
Christopher L Tubbs II
http://gravatar.com/ctubbsii
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20140924/fa641530/attachment.html>