On Wed, 2016-12-07 at 06:21 +0100, Kevin Kofler wrote: > Kamil Paral wrote: > > This serves as a nice example why we need to tweak how Rawhide works if we > > want people actually running on it. > > And why do we need that? Rawhide is a place to do development, not a rolling > release distro. > > > So, we either need: > > a) updates-testing for Rawhide - e.g. with auto-push even with 0 karma > > after 3 days, doesn't matter, it would still allow us to prevent many of > > these issues > > or > > b) decouple building and submitting to Rawhide - because the idea that > > everything and anything built is immediately part of the release seems > > very broken to me. > > Those proposals will both slow down development to a crawl and prevent us > from doing our packaging work. > > > At least if we want people to use it. If we want just a huge repo of > > frequently broken bleeding edge packages, yes, that's exactly what we > > have. > > The latter is exactly what you get when you do actual development. The > former is a totally impractical illusion. I quote, from https://fedoraproject.org/wiki/Releases/Rawhide : "Rawhide has the following Goals: To allow package maintainers to integrate the newest *usable* versions of their packages into Fedora. To allow advanced users access to the newest *usable* packages in a rolling manner." Emphasis is original, not mine. More to the point: it is entirely awful for the quality of Fedora as a whole if Rawhide is allowed to be completely broken for substantial periods of time - and this *did* make Rawhide completely broken. Just about any package set besides minimal could not be installed or updated. Several release-blocking deliverables entirely failed to compose. This isn't 2005 any more. It's not OK for us to go for weeks without Rawhide working, then finally clean it all up a week before the Alpha release and try to figure out where we stand. We have mechanisms now which make it a reasonable goal to keep Rawhide working. As long as we actually pay attention, they make it very easy to pinpoint breakage and fix it much more easily than before. But if we just let things be completely broken, all that goes away: we've no idea if half the rest of the distro is broken if we can't get to the point of testing it because of bugs like this. Keeping a baseline level of fundamental working-ness lets us test in much more depth and identify breakages *as they happen* and fix them rapidly. Refusing to revert changes like this and instead insisting that their consequences be fixed live, while the distro fails to work or build properly for the entire time until that's done, is just a crappy way to do things. We have the capability to do better, thus we should. -- 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
