On Thu, Dec 8, 2016 at 7:59 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > 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 Longer cycles are not necessarily mean no slips. > * not being on a hamster wheel which routinely bursts into flame > [...] > mechanism to users (GNOME, GCC, glibc, have spoken up before, but not > limited to just those) How so? By having less frequent releases we'd be skipping more of them. > * maximum PR and user growth How is less PR (only one event per year) instead of two lead into "maximum PR" ? > > 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. Longer term planning of what exactly? And by whom? Are you talking about fedora's planning or the users? > 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, There is no evidence that we slipped into the holidays because of the shorter cycle (it happens all the time, hence even you wrote "again" ;) ) > So, I'm trying to come up with different ways to do it which still have > the properties above. Well I am trying to understand what you are trying to do before thinking of solutions. I think the 6 months cycle worked pretty well so far so I'd rather only change it for good reasons. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
