On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote:
> * So, the first question is: should I spend my time on getting these
> packages back to testing so they would be a part of the next release? Or
> should I spend my time on other RC bugs fixing which will help release
> stretch faster?
IMHO, ponder popcon, you're personal feeling on what the package is, the
actual issue, and then see what's better. Though I believe that if they
arrived at this point they are not worth much of your time, but of
course that's entirely up to you!
[reflowing]
> 1 was "should
> be orphaned, though we don't have a standard method to orphan team
> packages".
> 1 was "why are you asking me, I am only an uploader,
> the package is team maintained" even though that person was the only
> actual uploader (since 2002 till 2012).
sigh.
Yes, we don't have a standard method.
But if the team *is* the uploader (as often is the case), then there is
only so much you can do. Probably before orphaning you can email the
team ML, but of course contacting the single uploader (that is the
de-facto maintainer), before writing to a public ML that you are
proposing to wrestle a package out of the uploader only seems nice?
> 1 was "I will move to a team" and I answered "a package needs a
> human maintainer".
sigh².
> I've sent the list of my pings to the MIA team.
Thanks. You've already received a reply from us.
> * So: is it a real problem that there are packages that should be marked
> as orphaned but they aren't? Should we spend any effort on marking more
> orphaned packages? If yes, how should we do that?
There surely are a lot of packages that are de-facto orphaned around
here.
Thorsten Alteholz writes on his blog about adopting orphaned packages
(http://blog.alteholz.eu/2016/11/my-debian-activities-in-october-2016/),
and as he noticed the number of orphaned packages is steadily
increasing. We're now at 1007 packages as of yesterday wnpp report
https://lists.debian.org/debian-devel/2016/12/msg00023.html
(I wonder if we have any graph?)
Since the MIA team restarted their efforts earlier this year the number
of orphaned packages has been increasing, I'm not sure if that's for the
worse of the better, but it did...
> * Also: what should we do with packages that are marked as team-maintained
> but are really orphaned?
I suggest: contact uploaders to check if they are fine, then contact
team and seek ack, then file the bug (this is assuming they reply, if
they don't, then it's harder).
> When fixing the RC bugs I always looked through other bugs in the same
> package and applied trivial patches to the packaging. I've added
> debian/source/format where it was missing. In some cases I've completely
> replaced the packaging with 4-line d/rules. In at least two cases I fixed
> empty -dbgsym packages.
I did such things too, and even received thanks, regardless of the fact
that NMUs are not supposed to do any of that.
> * So, the final question: how much time should pass since the last
> maintainer upload (since removal from testing, since the first still
> unfixed RC bug, how many NMUs should exist since the last maintainer
> upload) to be able to just do a QA upload (without changing the Maintainer
> field as it's prohibited on the https://wiki.debian.org/Teams/MIA page)
> instead of finely-crafting minimal diffs and fixing only things allowed by
> devref 5.11.1?
We discussed several times internally in the MIA team during the year
how to just "declare" a maintainer gone based on the current state
(last upload, gpg key ok, number of RCs, number of NMUs, etc), but the
consensus has been that it's just plain hard/impossible to give an
appropriate answer good for all cases. We shall discuss this again at
DebConf instead.
And: you're suggesting to do a QA upload without changing maintainer
field? That seems ridiculous to me: QA uploads are uploads where
maintainer is QA, right? You're suggesting to change the meaning to
"big NMU", basically? Let's just call them NMU.
--
regards,
Mattia Rizzolo
GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`.
more about me: https://mapreri.org : :' :
Launchpad user: https://launchpad.net/~mapreri `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia `-
Attachment:
signature.asc
Description: PGP signature