On Thu, Oct 27, 2016 at 6:53 AM, Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > Hi all, > > I am thinking, why we don't have enabled Bodhi for Rawhide? I know that > you might think now that I went nut and it is bureaucracy, but let me > explain. > > If I understand it correctly, during several past years, our build > process was more streamlined and we are trying to do the Rawhide > composes in a similar fashion we are doing stable releases. But for some > reason, we are still not using Bodhi for Rawhide and I see no reasons > not to use it. Here are some benefits if we were using Bodhi: > > * One of the nice things which Bodhi does is running several check, such > as depcheck, rpmlint (actually question if we are using rpmlint for > Fedora builds was what triggered this email), etc. On one hand, I'd love > to see these checks running in Koji, but there is no support for them > and I don't even see the support coming. So enabling Bodhi for Rawhide > would give us this opportunity. > As far as I knew, Koji *is* capable of running checks as a post-build task. So it should be possible to do what you want without Bodhi. > It is actually quite interesting, that while most of the development > happens in Rawhide, there is less sanity checks then for the Rawhide, so > if you screw up something in Rawhide, it will get into stable version > and you might not notice until you submit some stable update. > > * From time to time, there is necessary to build some framework, which > consist of several components which must be released together. > Currently, we either temporarily break Rawhide or we are asking for side > tag. But why not use koji for that? Users of stable releases are not > affected by incomplete builds, since the don't reach even the > update-testing without pushing via Bodhi. > > * And probably last think, why the Rawhide should be really exception? > Why we should not use Bodhi if we are using it anywhere else? > Because Bodhi really slows down the process. You're essentially asking for a mechanism to implement a semi-freeze in rawhide so things go out in batches. Perhaps the better answer would be to make it simpler for people to use side-tags for this purpose and have Koji run post-build checks and provide that information. Another downside is that the "masher" that is used by Bodhi would also be frequently broken. I'm doubtful that it could handle the continuous stream of things well at the pace that Rawhide typically goes at. And frankly, broken dependencies are expected from time to time in Rawhide as we are pulling off migrations (like the OpenSSL 1.1 migration going on now, or the migration to rich dependencies for langpacks earlier this year, and so on). > Lets use Bodhi for Rawhide, where the submitted update would immediately > go into Rawhide, unless maintainer wishes some testing period. > > Any comments on this topic? > Some anecdotal evidence here: I also actively participate in Mageia development, and there, we implement a "freeze" process similar to Debian as we prepare to make releases. It drastically slows down the development process, perhaps to a level that is unnecessary. I've spoken to a few other folks about it before, and it's generally agreed that the only times Cauldron (Mageia's equivalent to Rawhide) should be frozen are just before making test composes and just before branching to release. But as it is, it's a major drag for development and discourages people to freely upgrade/fix things. That being said, you're not actually asking for that. You want checks to run on rawhide builds, which I think is a good idea. But I think using Bodhi as the hammer for it might not be the right choice. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
