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).
-- Jason
