On Tue, 2017-07-18 at 03:37 +0200, Kevin Kofler wrote: > > IMHO, this is a slippery slope eroding the quality of Fedora just because > some people are not willing to wait a week longer for their "fix". The > argument that this steals time from the next cycle is also invalid, because > the obvious answer there is: "Don't Do That Then" – the schedule for the > next release needs to start from the ACTUAL release date of the current > release, NOT the planned release. > > There is at least one user a day asking on #fedora-kde about the Discover > issue that you decided to ignore in violation of the process, This kind of language just isn't helpful. No-one chose to 'ignore' anything 'in violation' of anything. It clearly wasn't 'ignored', since we had about an hour of debate over it. And as ultimately the decision as to whether a bug is a blocker is the preserve of the relevant groups - as the process states - nothing is 'violated' by that decision. > and no doubt > there are many more who don't bother asking and just wipe Fedora and install > Kubuntu or Neon instead. The bug would have been trivial to fix. > > A blocker ought to be a blocker, no matter when it is discovered and how > long it takes to fix. I don't think that re-arguing the concept is a useful thing to do in this thread. All the relevant groups were represented at the meeting and agreed that this *should* be covered in the process documentation. The point of this thread is to agree on the details of the explanation, not to argue over whether this should even be a thing at all. Of course if it somehow becomes evident there's a large number of relevant people who think this was a terrible idea, we can re-consider, but that doesn't seem terribly likely. As the text notes, we have for a *long time* stated that Fedora's release process is not entirely time-based or entirely quality-based, so it's not feasible to hold that we absolutely must hold the release for any criteria violation, no matter how long it might take to fix. That would be too close to an entirely quality-based process. As a side point, I'll note that it is *also* a settled point that desktop teams have a responsibility to help test their own stuff. We produce KDE lives nightly throughout the release cycle. We (QA) create validation events, with all the announcement emails and result tables and associated paraphernalia, at least every two weeks during the release cycle. AFAICS, no-one from the KDE team actually contributed any tests of KDE in the F26 cycle *at all*. As seems to be the trend lately, we have to point out once more that Fedora is supposed to be a *collaborative* project. Declaring that X Must Be Done but not actually being willing to contribute to doing X at all isn't very sustainable for a project like Fedora. We really need the groups responsible for release-blocking parts of the distribution to *help test them*. If KDE is going to continue shipping dozens and dozens and dozens of things by default (including, last I checked, three different things that deal somehow with software installation), it would be nice for the KDE team to help check they all actually *work*. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
