On Thu, Dec 08, 2016 at 07:41:13PM +0100, drago01 wrote:
> Which problem are you trying to solve with those proposals?
>From my *other* other mail:
* predictable calendar dates, to help with long-term planning
* not being on a hamster wheel which routinely bursts into flame
* maintaining the high level of QA we have for releases (or, you know,
even increasing it)
* doesn't increase work for packagers
* including time for QA and Rel-Eng to a) breathe and b) invest in
infrastructure
* satisfying upstream projects which depend on us as an early delivery
mechanism to users (GNOME, GCC, glibc, have spoken up before, but not
limited to just those)
* maximum PR and user growth
and just to expand a little bit: although we have a nominal six-month
cycle, the natural tendency seems to be to expand to eigh- or
nine-month cycles. That's not necessarily terrible, except a) it's not
well-aligned with upstreams and b) it makes longer-term planning
difficult because release times are unpredictable year-to-year.
The alternative we just tried was: if one cycle goes over six months,
still target the next one as if it it _hadn't_ - that is, a shorter
"make up" cycle. In this case, we came out with a great release (again,
awesome work everyone), but we didn't have much breathing room (and
ended slipping into the holidays again, with real risk of running into
Christmas/end-of-year. And we certainly didn't have, in that, time for
the teams to work on infrstructure.
So, I'm trying to come up with different ways to do it which still have
the properties above.
--
Matthew Miller
<mattdm@xxxxxxxxxxxxxxxxx>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
