On 20 December 2016 at 11:20, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Dec 20, 2016 at 04:48:44PM +0100, Pavel Raiskup wrote: >> I probably lost the context ... what real-world problems are trying to fix? >> Everything which comes to my mind should be solved by better tooling for >> updates-testing testers. > > I've given this in several ways across the thread, but I don't mind > restating. :) > > 1. I believe in the value of releases, for the project and for end > users — as opposed to a "rolling release" system. But major releases > are a lot of work across the project — not just release engineering, > but marketing, ambassadors, design, docs, and others. One possible > way to reduce this is to have major releases less frequently. I want > a cadence that gives us the highest return on effort. Maybe that's > six months — and maybe it isn't. > > 2. I really want releases to come at a known time every year, +/- two > weeks. Keeping to this with six month targets means that if (when!) > we slip, the next release may only have five or four months to bake. > This doesn't seem like it's the ideal for the above — maybe we can > get the engineering processes streamlined enough to make it > comfortable, but there's still the matter of marketing and the rest. > > 3. The modularity initiative will mean that different big chunks of > what we use to compose the OS can update at different speeds and > have different lifecycles. That gives us a lot more flexibility in > the above, and I'd like us to start thinking about what we *want* > to. > I am having a hard time reconciling 2 and 3. We want to have regular releases AND we want them to be whenever we want... this is Quantum Mechanics all over... the release is both a particle and a wave.. and the cat is both alive and dead. The difference is that only one of the two events is 'real' after you have opened the box. Do we end up with a release which is regular? Or do we end up with a release which has different life-cycles? If the answer is 'yes', ok but we will need to be clearer when and how we measure both. > I suggested one release a year as an alternative to the current two per > year. I guess three per year would be possible (but seems counter to > the above); other plans like eight- or nine-month cycles don't have the > fixed-calendar property I'm looking for (and I'm pretty sure no one > wants to go to one every two years). > > The proposals previously in this thread are ideas aimed at presenting > users with an annual release from a marketing/ambassadors/design, etc., > point of view, but also addressing our upstream stakeholders' desire to > have Fedora ship their software fast. (For example, GNOME.) I hoped we > could find ways to make them also reduce release effort for developers, > packagers, releng, and QA, but from the feedback so far people don't > really feel like those particular suggestions do. > The only way I can see that working is that QA, releng, etc only deal with a small part of the OS that the rest of the OS is built from. Everything else above either a sack of potatoes or a well oiled machine but it depends on the group (be it KDE, GNOME, Docker/Atomic/etc, i386/ppc/arm, etc) putting the work into it to make it so. It may make things look like 'second class citizens' but every group has called itself that when it doesn't get its way so it just makes it clearer. -- Stephen J Smoogen. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
