On Thu, Mar 29, 2018 at 10:47:50AM +0200, Nicolas Mailhot wrote: > Le 2018-03-28 12:52, Pierre-Yves Chibon a écrit : > > Hi > > > With bodhi: > > - Single package update > > https://pingou.fedorapeople.org/gating_rawhide/GatingRawhide_bodhi.png > > - Multi-packages update > > Not terribly fond of anything that offloads multi-build intellignece > coordination on packagers, forcing everyone that needs multi-build to either > do lots of manual operations, to reinvent its own local tooling, or just > give up on some updates. I am not sure where you're seeing: - lots of manual operations - reinventing its own tooling - giving up on some updates There would be 2 new operation: ask for a new side-tag, ask for it to be merged. These already exists for large rebuilds and need to go via rel-eng while the new tooling would allow self-service. I think we made it clear that we want to get chain-build to work/keep working For the last point, I'm very unclear on where you got this impression. > The correct packager-friendly way to do it is > > eat-this <list of srpms> → ok/nok How is this different from chain-build? > With the tooling chain-building <list of srpms>, automatically applying > boostrap sections when present, automatically rebuilding everything in the > set against the final state of other parts of the set, and applying > integration tests to the end result and not to the intermediary steps. > > And it should not matter if <list of srpms> has a count of one or many. Agreed in theory, in practice having a list of one item allows to simplify things. > Anything that posits list of srpms is a special case I think it's the other way around: single srpm are a special case, they are a sub-case of the multi-srpm which allow taking shortcut. > (that's also a huge defect our the review workflow, unbundle and produce a > clean and maintenable set of packages → lots of review and tooling misery, > keep it all in a single srpm → no problems) One could argue than 1 is always simpler than > 1 so this is intrinsically a state of things. That being said, I think it is a fair critic one we may want to address but I think that's broader than the discussion at hand. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
