On 25/11/16 21:00, Jason Zaman wrote:
> On Fri, Nov 25, 2016 at 08:27:12PM +1100, Michael Palimaka wrote:
>> On 25/11/16 17:51, Jason Zaman wrote:
>>>> Automation
>>>> ==========
>>>>
>>>> It's easy to forget to check that all the required dependencies are in
>>>> stable before filing a stabilisation test, but this wastes the actioning
>>>> developer's time. I have prepared a bot that repoman checks the list of
>>>> atoms and flags the bug appropriately. This allows easy filtering out of
>>>> broken requests.
>>>
>>> This part would need to take into account DEPENDS ON in the bug too.
>>> When I file my xfce lists I dep on the gnome stable bug since I need
>>> the gtk stuff and if that isnt taken into account, repoman would just
>>> die.
>>
>> The bot will either try its best to take into account bug dependencies,
>> or otherwise just give up and skip such a bug.
>>
>>> I just realized there is another rare issue that we may have to take
>>> into account. Some sets of packages *must* be stablized in lockstep. For
>>> regular sets of packages like eg xfce if you leave off a bunch of the
>>> extras its no big deal.
>>> Eg for SELinux, the policy packages must all be stabilized all at
>>> once because they depend on each other (I think perl is like this too?).
>>>
>>> We would need a way for maintainers to ask for testing without actually
>>> committing. The maintainer can wait till everything is done and commit
>>> everything at once himself. Some flag to make the tatt script skip the
>>> step would be enough I think.
>>
>> Do you have a bug number handy so I can double check how the process
>> normally looks?
>
> SwifT and I both run stable machines so we always just stabilize SELinux
> stuff ourselves so dont have a bug number, no.
>
> its pretty much just:
> cd sec-policy/
> ekeyword amd64 x86 */*-2.20151208-r6.ebuild
> git add .
> repoman full
> repoman commit -m 'sec-policy: Stabilize selinux policy 2.20151208-r6'
>
> every single selinux policy package {,R}DEPENDs on
> =sec-policy/selinux-base-policy-${PVR}
> which in turn deps on
> =sec-policy/selinux-base-${PVR}
> and we always do everything with the same revision at the same time
> otherwise you get lots of weirdness. For us, each arch could be done
> separately (no point tho), the main part is that committing the packages
> in a random order or even alphabetical doesnt really work.
>
> How aware of deps do we want to make such a tool? Having it figure out
> the right order seems like a lot of work. Or we could force the script
> to follow the order defined in the package list and then its up to the
> maintainer. Then also if there is a failure either abort completely or
> continue with the rest that it can (a. la --keep-going).
Most tools I've seen address this by keywording the entire list of
packages first, then doing the commit(s). tatt splits the entire process
into multiple stages (build the package, build revdeps, keyword the
ebuilds, git commit, ...) which can be run individually to maximise
control to the person running it.
That said, not everything needs a fancy tool. Your SELinux process looks
pretty good the way it is.
