Dne 27.10.2016 v 13:42 Neal Gompa napsal(a): > 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. I agree that Koji is likely capable, but: 1) Nobody did that so far for whatever reason. 2) What will be the meaning of "rpmlint" failture for example? Should if fail the build? Should it be just informative ... My point is that there is no such thing in Koji yet, but it is already implemented for Bodhi, why not use it. As far as I understand, Bodhi can also provide various other information from Taskotron tasks, why we have them for stable releases and not for Rawhide ... > >> 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. Yes, I would love that ... > 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. We don't have the simpler mechanism for side-tags, we don't have post-build checks in Koji, but we have Bodhi, which allows to gate updates getting from build into some testing/stable repository. > > Another downside is that the "masher" that is used by Bodhi would also > be frequently broken. Frankly, I don't know anything about masher and hence it sounds just as some anoying technical detail to me ;) > 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. > > > I really don't ask for any kind of freeze. I am asking for a way how to make Rawhide more stable and actually without broken dependencies for end users. I am asking for precise control when my packages are ready for Rawhide and that some package is build is not the right measure. And just as a coincidence, Bodhi gives me some additional checks which are not for whatever reason in Koji. And as I said, package maintainers are already used to use Bodhi, so there is virtually nothing new to learn for them. Vít _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
