On Thu, Dec 8, 2016 at 6: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 > * not being on a hamster wheel which routinely bursts into flame Some of the above proposal looks to be creating more hamster wheels not less, by this I mean branching off the branch. What do we gain by this other than more branches to deal with which generally means more work/maintenance, maybe we'd be better tagging to document as opposed to branching. > * maintaining the high level of QA we have for releases (or, you know, > even increasing it) Again more hamster wheels if not done properly (automated CI as opposed to human) but I've not seen any concrete proposal for implementation, again just hand wavy stuff. > * doesn't increase work for packagers How? With more branches it seems like it woudl... would we still keep N+1 releases IE, have a release around for 2 years not 1? > * including time for QA and Rel-Eng to a) breathe and b) invest in > infrastructure Again, with bundled updates every 6 months you're still releasing and potentially with major desktop/virt rebases (and no doubt docker too) I don't see how this is actually close to your reality so Id like to see more solid detail on this rather than hand wavy bullet points. > * 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 I think that needs to be two separate points as I don't see them directly linked. > 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
