On Thu, Dec 8, 2016 at 6:59 PM, Matthew Miller <mattdm(a)fedoraproject.org> 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
* maintaining the high level of QA we have for releases (or, you
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
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
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
> 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
> Fedora Project Leader
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org