Hi,

Am Sun, Feb 16, 2025 at 05:44:34PM +0100 schrieb наб:
> On Sun, Feb 16, 2025 at 05:29:26PM +0100, Chris Hofstaedtler wrote:
> > On Sun, Feb 16, 2025 at 05:18:39PM +0100, наб wrote:
> > > Quoting the relevant:
> > > > It is recommended to choose between one of the two following schemes:
> > > > 2. Put the mailing list address in the Maintainer field.
> > > >    In the Uploaders field, put the team members who care for the 
> > > > package. 
> > > 
> > > In the packages salvaged into the salvage team we have a choice between:
> > [..]
> > > 3. Maintainer: salvage team
> > > 
> > [..]
> > > 3 is a better fit for what I term dead-end packages
> > >   (ones that truly no-one cares about, with no upstream,
> > >    or no maintainer, or no utility, or otherwise 0 forward motion;
> > >    and with little potential to generate bugs except 1 FTBFS/decade).
> > >   This is most of the salvage team packages.
> > 
> > Why are what you call "dead-end packages" "salvaged" at all? I seem
> > to recall that the salvaging process is for packages you actually
> > want to maintain.

Just to clarify: When I created the Bug of the Day initiative[1] which
is making use of the ITS process a lot (be it in its intended form or
possibly misinterpreting - this might be discussed on a better place) it
was not planed to deal with "dead-end packages" and I personally would
not name the salvaged packages that way.

The intention was to guide newcomers at the example of potentially easy
to fix bugs into the way how bugs can be fixed and by doing so getting
in contact to maintainers who might be happy about some helping hand.

Looking back from my todays knowledge this idea was in two ways naive:
  1. There are no newcomers queuing up at the gates of Debian keen
     on fixing bugs.
  2. The method we selected the bug candidates has lead in most cases
     to maintainers who are de facto MIA.

I'd like to leave it with this statement - a more detailed evaluation of
the whole process is definitely needed and pending.  We should discuss
this at a better place than some "random bug report".

One main reason to pick some package from the list of Bug of the Day set
is its popcon value - so these are also not "dead-end packages" but
packages that have some potential user base and the package deserves
some care.

> Because a more aggressive RM RoQA policy got me yelled at last time
> for making work for the ftpmasters, so I stopped arguing for RMs
> and do Andreas' preferred methodology of salvaging everything.

Just for clarification:  I did not explixitly declared the methodology
of salvaging everything.  I've filed several RoQA bugs as action to some
packages showing up for the Bug of the Day.  I understand the
frustration of наб who received some unfriendly mail as a bummer for his
good intention (I forgot the link - наб if you want to provide it here
that might be enlightening for other readers).

I think the whole process needs some better adjustment and discussion.
Given what we found since about 6 months work its definitely needed that
someone cares for those forgotten packages - which, just to repeat are
definitely packages with high popcon and no "dead-end" at all - and than
there are those who are somehow inbetween.  There are cases where its
really quick-and-simple to create a Git repository, apply some patches
from BTS and upload.  The fact that some developer has sat down to
create a patch should be rewarded in some way and it shows that there
are people who care.
 
> Doing this allows packages that tend to be in a functionally-orphaned
> state to be team-maintained in the long term. This satisfies the salvage
> criteria as I see them and I have an equal interest in every weird
> ancient FTBFS these packages generate.

I confirm that namely наб did a really good job in doing subsequent
uploads in case the first upload might have triggered an issue.  Using
this chance to explicitly thank you for your work here, наб.  So the
salvaged packages are definitely under active maintenance.
 
> This also sets up the packages to be RM ROMed when they do fizzle out.
> But, consolation.
> 
> > If the packages are "dead", RM them.

This is what we try to do.

Kind regards
    Andreas.


[1] 
https://salsa.debian.org/tille/tiny_qa_tools/-/wikis/Tiny-QA-tasks#bug-of-the-day

-- 
https://fam-tille.de

Reply via email to