Re: Bug#895246: gconf: Intent to Adopt

On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> (I don't speak for the GNOME team, or for Josselin, who is officially
> this package's maintainer; please don't assume I do.)
> 
> On Sun, 08 Apr 2018 at 22:19:43 +0300, Adrian Bunk wrote:
> > I hereby declare my intent to adopt gconf.
> 
> Thank you for offering to take over this package. Do you also intend
> to adopt these related packages?
> 
> - src:gconf-editor (which depends on gconf and is useless without it;
>   currently maintained by the GNOME team)

Makes sense.

> - src:orbit2 (orphaned library needed by gconf)
> - src:libidl (orphaned library needed by orbit2)

Where does gconf depend on these?

> - various language bindings for gconf

Good point, I haven't yet looked at these.

>...
> Do you use software that relies on gconf yourself/are you able to test it?

Yes.

>...
> For contributors: every time a package that hasn't had upstream
> development for a few years fails to build during a transition, or
> needs fixes for a new architecture, or has RC bugs that someone looks
> at during a BSP, it takes a little bit more of several contributors'
> time and attention

There have been 2 port bringups already this year so far (ia64, riscv64),
and a bigger amount of contributors' time and attention is actually 
wasted for these in cases like #876592 or #887868 where the maintainer
didn't apply a simple FTBFS fix for months.

> (even if the only attention it gets is to look at the
> package, realise it hasn't changed significantly in a decade, and decide
> to prioritize something different). Software that depends on gconf isn't
> *directly* an indication of something terribly bad, but it's reasonably
> well correlated with the dependent software also being unmaintained or
> undermaintained upstream. Each individual package blocking a transition,
> and each individual RC bug, doesn't necessarily take much time and
> attention, but it adds up over time, and I'm concerned that the long
> tail of GNOME-2-based packages might be collectively and cumulatively
> taking more time and attention than it deserves.
>...

The worst-possible outcome is when you force reverse dependencies to 
bundle copies of the libraries, like glademm in aeskulap.

>...
> If we had bikesheds, PPAs or an equivalent of Ubuntu universe, I'd
> suggest moving unmaintained/undermaintained packages to one of those
> to indicate that users shouldn't have the same quality expectations,
> but we don't currently have that facility.

I will begin to take your suggestion seriously after you have managed
to enforce that for ITPs - whatever quality expectations we have should
be enforced there already, usually software does not suddenly become
low-quality after it was shipped in half a dozen Debian releases.

> If, bearing all that in mind, you still think Debian is better with
> gconf than without it, then I'm not going to try to prevent you from
> maintaining it. (Again, I don't speak for the GNOME team.)

Thanks.

>     smcv
>...

cu
Adrian