On Mon, 2016-12-05 at 16:10 -0500, Matthew Miller wrote: > It was by design, though — for a while, when a schedule slipped, we > planned the next schedule as 6 or 7 months from the actual release. > This time, we tried to keep it to October even though the previous > release had slipped, resulting in the short schedule. I'm the person > who pushed for that (because of the value of calendar consistency), > and > I'm now saying it was a mistake. I still think it's a good idea for Workstation. We really need to be seen as the leading GNOME distro: that's what gets GNOME people using Workstation and recommending that other people install it, then those people recommend it... I think it's part of the story behind our recent rise in popularity. Right now we are that leading GNOME distro because we usually follow about 1-2 months behind a GNOME release. It's a huge advantage over, say, Ubuntu, where people complain about needing PPAs to get the latest software and upstream has already moved on to newer versions half a year ago. Right now this is one of our biggest strengths as a distro, and your proposal would throw that away. So there is real serious risk of changing this. Also, if we do one release per year, then I expect most of the Red Hat developers who work on GNOME would start using some unstable copr to get the latest GNOME; this means way fewer developers using and testing the latest release, since it's too stale. (I dunno what I'd do myself, stick around and use a GNOME copr, or try to go improve Tumbleweed...?) I'm even concerned by schedule slippage into June; this is the time of year that I see complaints that Fedora is too old, go install Arch. I'd prefer that we always target early May and November releases for Workstation. I know, the early May is hard for GCC, but GCC isn't our user experience and I'm sure it can wait until the fall releases. A tangential argument is this will hurt our reputation for being a leading-edge distro. Ubuntu would have newer software than us for half the year.... Michael _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
