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