On Thu, 2018-03-08 at 11:24 -0800, Kevin Fenzi wrote: > On 03/08/2018 11:11 AM, Richard Shaw wrote: > > What about making side tags easily available to packagers directly? I could > > build my package that includes an ABI breaking update and rebuild the > > dependencies within that side tag and then submit when everything is > > complete. > > Yes, teaching bodhi about side tag management was one idea talked about. > > Then you would do: > > * get a side tag from bodhi > * build all your stuff, test it, etc. > * CI/automated tests run on it, and if all is ok goes out in the next > rawhide compose. > * If not ok, you could wave the results or build more things/edit the > update until it passes. That would be really nice! There are often cases where a fix or enhancement needs to land in at least two components at once (in our cases usually pykickstart & anaconda and/or blivet & anaconda) and the only "atomic" way of doing that is doing a chainbuild, which, frankly, sucks: - cryptic CLI syntax, no Web UI - totally different process from branched releases - you need to have commit right to all involved packages - no automated tests run on the results whatosoever - no way to tell list inidividual scratchbuilds in the past (AFAIK) So having the option to use Bodhi to group atomic package updates for Rawhide to a Bodho update would be really useful! - consistent with branched Fedora process - no need to be commiter for all packages, just tell the other maintainers to add their new build to the update - tests could be easily hooked to the update - Web UI - ability to see & link people to pending & past updates I might be missing some of the technicalities but this really seems like a win-win solution while keeping the current process in place due to the updates being optional. > > The only downsides to this is that it means more code for bodhi, and > more newrepos for koji. > > kevin > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
