Re: [gentoo-dev] Adding slot and subslot deps to others' packages

[Jeroen Roovers]

On Sun, 2 Mar 2014 12:32:05 -0500
Mike Gilbert <floppym@g.o> wrote:

> On Sun, Mar 2, 2014 at 10:45 AM, Jeroen Roovers <jer@g.o>
> wrote:
> > On Sun, 2 Mar 2014 09:37:22 +0100
> > Michał Górny <mgorny@g.o> wrote:
> >
> >> Few months ago I have written a small FAQ on how to use slots
> >> and subslots for library dependencies properly [1]. However, today
> >> I see that most of the developers didn't care to properly update
> >> their packages and when I introduced binary compatibility slot in
> >> libgcrypt, I had my hands full of work fixing the mess for a
> >> single package.
> >
> > How about you file a tracker bug report for each library package,
> > and then file bug reports per package using that dependency
> > blocking the tracker bug?
> >
>
> That is certainly the conservative way to handle this, and it seems
> like a lot more work.

Not managing the migration is apparently a lot of work, since the work
isn't being done "voluntarily". Managing the migration might seem like a
lot of work, but at least it allows you to track progress properly and
tick off finished tasks, while in the mean time everyone involved gets
informed, and perhaps gets their bugs fixed for them quicker.

> This seems like a QA project. Perhaps we could get the QA team to make
> a couple for decisions?

Wow, that would make it a *lot* of work.

> Firstly, do you agree that we should migrate library dependencies as
> mgorny has described?

There is no agreement on whether it should even be done?

> Secondly, can we grant developers the license to make these changes
> outside of the normal "file-a-bug" workflow as an efficiency measure?

People handling the sub-SLOT migration for dev-libs/libgcrypt would
probably know better what they are doing than the package maintainers,
so I see no reason for QA to "grant licenses".

> If there are any reasonable objections (besides maintainer
> territorial-ism), of course the QA team should consider them.

That's back to the "agreement" bit, I guess.

Honestly, setting up a tracker and blocking it with bugs about packages
which someones-sub-SLOT-checking-script has vetted to be involved could
be done in less than a day (for the hundred or so packages that depend
on dev-libs/libgcrypt). It doesn't need some QA team to study in depth
-- it needs a couple of volunteers to do the checks and file the bug
reports.


     jer