Re: removal instead of orphaning?
2016-08-28 02:22 gregor herrmann:
On Sat, 27 Aug 2016 11:40:03 +0200, Paul Gevers wrote:
On 26-08-16 23:40, Julien Cristau wrote:
> off the top of my head:
> - it's wasting time of anyone doing QA work
> - it's wasting time of any user who looks for a piece of software to
> do
> $stuff and gets to eliminate all the noise from unmaintained
> probably-broken cruft
These were indeed the two items I was mostly thinking of. I felt the
pain of the first item last year with the dh-python migration at
Debconf.
Speaking about [perl, in my case] transitions, in my experience
orphaned packages are less annyoing (I can just do a QA upload, where
I can fix whatever I want) than
officially-maintained-but-de-facto-neglected packages where I do
minimal NMUs, and then again next year, and then again the year
afterwards, etc.
(I know, the answer to that is salvaging^Winvolving MIA and getting
the packages orphaned; I just wanted to point out that orphaned
packages are not that much of a burden in all cases.)
I completely agree with this.
Sometimes there's the feeling from many people (including MIA team) that
reporting possibly inactive people and expecting MIA to follow the
procedures is a way of "harassing them out of the project". I
understand that, specially people working on the MIA team, they can feel
sometimes like an "evicting squad", and the people being pinged by MIA
might feel "pushed" or "on risk of eviction".
However, I think that it's quite important from the point of view of
Quality Assurance processes to detect such cases and strip packages of
inactive maintainers (not necessarily remove people from DM/DD
positions) precisely for the reason that Gregor explains here.
In that way, people working on a wide range of packages that they don't
particularly care about (e.g. porters, people helping with transitions,
RC bugfixing in BSPs or during the freezes, contributors or DMs which
need sponsoring, or people just wanting to fix a particular problem)
will have a much better time doing QA uploads [2] than following the NMU
processes, thus are more likely to fix things, thus increasing overall
quality.
So, as Gregor, I also believe that orphaned packages are much better [1]
than the many other packages maintained by NMUs for years, which are in
that state because they're not orphaned by the maintainers and nobody
cares to change the situation.
I think that one measure to improve the current situation is that, for
the people doing NMUs, to orphan the package when the number of NMUs
exceeds for example 3 or 5 in a row, or 1 year since the oldest NMU not
acked by the maintainers and there are bugs or reasons requiring new
intervention. (Exceptions can apply if there are specific reasons to
avoid to do that, e.g. keep packages as part of a team). With this,
future NMUs will be QA uploads.
If there's a general agreement that this is a good thing, and somehow
becomes part of the NMU process or similar guidelines [2], it would help
to avoid conflicts.
There is also the additional advantage that, when they're maintained by
QA and neglected, it's easier to get them removed from the archive as
well (the original purpose of the first post of the thread).
Cheers.
[1] A different question is that orphaned packages also tend to not get
many upstream updates (specially if they require transitions) unless
they block somebody's way (RC bugs, blocking a transition of another
package, etc); but officially-maintained-but-de-facto-neglected
packages are not better in that front either.
[2] I think that I see recommended somewhere that I cannot find right
now, but it is not "officially" endorsed or not general practice, as
far as I know.
--
Manuel A. Fernandez Montecelo <manuel.montezelo@gmail.com>
Reply to: