Re: Bug#895246: gconf: Intent to Adopt

[Gert Wollny]

Am Sonntag, den 13.05.2018, 15:18 -0400 schrieb Jeremy Bicha:
> Respectfully, you are the only one complaining about gconf's
> removal.

I might not have been complaining here, but I'm also not that happy
about some removals, and I don't understand the resistance to let
someone adopt the package. Adrian is obviously dedicated to maintain
the package, and in this (and other cases with gnome2 related packages)
there are no RC bugs or known security problems. 

I have ported two packages away from gconf, but it would be better to
have at least the posibility to read the gconf configuration, to be
able to convert it to a new backend. If only for that keeping gconf for
the next release cycle is a good thing, and thank you, Adrian, for
stepping up to adopt the package.

best,
Gert

 

Re: Bug#895246: gconf: Intent to Adopt

[Jonathan Dowland]

On Sun, May 13, 2018 at 03:18:04PM -0400, Jeremy Bicha wrote:

By the way, I did announce the gconf removal on this list in February.
[1] Respectfully, you are the only one complaining about gconf's
removal.


At least here, or to you, or via a "proper channel". I grumble under my
breath continually about the churn rate of GNOME-related packages and
technologies, and marvel when I can run an old win32 binary flawlessly
on a modern Windows¹ machine.

The standard riposte at this point is "we are all volunteers". And here
we have Adrian volunteering.

¹ Although I was recently disappointed to discover win16 finally stopped
 working with the move to 64 bit.


--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: Bug#895246: gconf: Intent to Adopt

[Jeremy Bicha]

On Sun, May 13, 2018 at 1:54 PM, Adrian Bunk  wrote:
> On Mon, Apr 30, 2018 at 06:47:41PM -0400, Jeremy Bicha wrote:
>> Why? Basically there are only two things left in Buster that depend on
>> gconf: eclipse and pulseaudio.
>
> Plus ~ 50 more in unstable.
>
>> Please be more specific about what software you are interested in that
>> requires gconf and why it can't be ported away from gconf this year.
>
> As I wrote:
>   It is not a good service to our users to rip gconf support
>   out of many packages for buster.
>
> This should be reverted in the packages where it was already done,
> shipping castrated packages in buster where the package in stretch was
> fully functional is not good, especially since there is no problem that
> would make it non-trivial to ship gconf in buster.

I don't think you really addressed my request: Which specific packages
have been removed from Testing solely because of gconf that you
believe should be in Buster and what is the reason they can't be
ported away from gconf this year?

By the way, I did announce the gconf removal on this list in February.
[1] Respectfully, you are the only one complaining about gconf's
removal.

It is not a service to our users to keep old libraries and software
around for additional Debian releases just because someone somewhere
might use some of it for something.

[1] https://lists.debian.org/debian-devel/2018/02/msg00169.html

Thanks,
Jeremy Bicha

Re: Bug#895246: gconf: Intent to Adopt

[Adrian Bunk]

On Mon, Apr 30, 2018 at 06:47:41PM -0400, Jeremy Bicha wrote:
> On Sun, Apr 8, 2018 at 3:19 PM, Adrian Bunk  wrote:
> 
> Sorry for not replying more promptly.
> 
> > I hereby declare my intent to adopt gconf.
> 
> Why? Basically there are only two things left in Buster that depend on
> gconf: eclipse and pulseaudio.

Plus ~ 50 more in unstable.

> pulseaudio is being worked on upstream
> so I expect that to be resolved in time for Buster. Eclipse is a major
> headache as you know.
> 
> Please be more specific about what software you are interested in that
> requires gconf and why it can't be ported away from gconf this year.

As I wrote:
  It is not a good service to our users to rip gconf support
  out of many packages for buster.

This should be reverted in the packages where it was already done, 
shipping castrated packages in buster where the package in stretch was 
fully functional is not good, especially since there is no problem that 
would make it non-trivial to ship gconf in buster.

> Thanks,
> Jeremy Bicha

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

Re: Bug#895246: gconf: Intent to Adopt

[Jeremy Bicha]

On Sun, Apr 8, 2018 at 3:19 PM, Adrian Bunk  wrote:

Sorry for not replying more promptly.

> I hereby declare my intent to adopt gconf.

Why? Basically there are only two things left in Buster that depend on
gconf: eclipse and pulseaudio. pulseaudio is being worked on upstream
so I expect that to be resolved in time for Buster. Eclipse is a major
headache as you know.

Please be more specific about what software you are interested in that
requires gconf and why it can't be ported away from gconf this year.

Thanks,
Jeremy Bicha

Re: Bug#895246: gconf: Intent to Adopt

[Simon McVittie]

On Thu, 12 Apr 2018 at 23:12:44 +0300, Adrian Bunk wrote:
> On Mon, Apr 09, 2018 at 04:12:47PM +0100, Simon McVittie wrote:
> > - src:orbit2 (orphaned library needed by gconf)
> > - src:libidl (orphaned library needed by orbit2)
> 
> Where does gconf depend on these?

I thought it did, but that was incorrect. The protocol it uses behind the
scenes was switched from CORBA to D-Bus before upstream maintenance ended.

If someone (you or otherwise) wants to keep libgnome, libgnomeui or
libbonobo* alive, *that* is the dependency tree that would require
orbit2 and libidl (the "Network Object Model" part of the original
expansion of the GNOME acronym).

smcv

Re: Bug#895246: gconf: Intent to Adopt

[Adrian Bunk]

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

Re: Bug#895246: gconf: Intent to Adopt

[Simon McVittie]

(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)
- src:orbit2 (orphaned library needed by gconf)
- src:libidl (orphaned library needed by orbit2)
- various language bindings for gconf

All are equally dead upstream (or more so in some cases) as far as I
can tell.

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

I recently converted gconf's svn repository to git,
, along with a batch of other
svn repositories where the first round of imports via reposurgeon had
failed. Anything else that is currently maintained by the GNOME team
(notably gconf-editor) should be in git too, and that's almost certainly
a better starting point than the svn repositories currently listed in
their Vcs-* fields. I don't think orbit2 and libidl were ever maintained
by pkg-gnome, and they probably did't have a VCS before they were orphaned.

A gnome-team Owner or a salsa sysadmin might be able to move gconf into
another namespace on salsa while leaving redirects behind, if that's
something you'd find useful.

> This is about keeping software that is long dead upstream but
> has reverse dependencies longer on life support.

My concern about keeping packages like gconf in Debian, rather than
removing them, is that keeping significant amounts of unmaintained
software in Debian is an ongoing time- and attention-sink for contributors
doing archive-wide QA, and a distraction for users looking for software
of interest.

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 (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. In the case of gconf,
it's had about 8 years of deprecation. If you keep gconf and its rdeps on
life support until buster, how much do you expect the dependent packages
to have changed by the time we get to the bullseye freeze? If you keep
them going until bullseye, is the situation going to have improved for
bullseye+1? And so on. If the upstream maintainer of some software has
abandoned it, we can keep it alive for a while, but I don't think it's
healthy for Debian to take over for multiple of our release cycles[1].

For users: having a "long tail" of undermaintained software is both
a strength and a weakness. It's a strength because we get to say we
provide a vast amount of software, some of it very specialized. It's
a weakness because it drags down the average level of quality of the
results of a search for packages: if we have (say) two well-maintained
implementations of a particular class of package, we'd probably prefer
users to find only those two in a search, and not find them listed among
multiple poorly-maintained implementations. This requires some
value-judgement/curation, which Debian has historically not been great at.

One way this could perhaps be mitigated is by improving how we mark
deprecated and obsolescent packages, and as a small starting point for
that I've just opened a ftp-master bug to get gconf and gconfmm moved to
oldlibs (I hadn't realised they were still in libs). Better Description
fields might also help, but the sort of libraries that we don't want
new code using are exactly the sort of libraries where rewriting the
Description isn't high on anyone's priorities. Ideally this would have
happened back in 2010 when gconf was deprecated, of course, but
hindsight is always clearer.

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.

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