On Wed, Sep 24, 2014 at 3:41 PM, Adam Williamson <adamwill@xxxxxxxxxxxxxxxxx> 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
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
