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
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
