> Did you document your attempts so people willing to help have a point
> to start from?
No, and all the blame for that goes to me.
BTW the same holds for all of my other packages, I'm more than willing
to accept help/co-maintainership.
Thanks for the patch.
Michael
--
Michael Meskes
Michael
On Sun, Dec 04, 2016 at 01:14:42PM +0100, Christoph Biedl wrote:
>...
> To add a few criteria, I'd remove a package from sid only if it
>...
> * has been orphaned for a longer time, say: a year
> So again users of that package had a grace period to ask for work on
> that package.
>...
Two ques
Michael Meskes wrote...
> Sure, but then it would be nice if you'd tried finding out if nobody
> cares. As usual the real world is neither white not black, but some
> shade of gray. The problem with the package is that the new version
> does not build on my system but I lack the time to debug, cou
Emilio Pozuelo Monfort wrote...
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-removals.
> Then if nothing happens in a
> > The question is absolutely valid, but maybe I should rephrase it to
> > "Why
> > are you contacting the uploader only and not the team as well?"
>
> Because it's the first step.
Would have been nice to know. Anyway, I can see your point.
> > > * Also: what should we do with packages that are
On Sat, Dec 03, 2016 at 09:25:11AM +0100, Michael Meskes wrote:
> > human maintainer". 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). I've sent the list of my
> > pings to
On Sat, Dec 03, 2016 at 06:23:17PM +0500, Andrey Rahmatullin wrote:
> > I think we should also have an auto-removals-from-sid[1] (the crowd
> > applauded
> > when I mentioned that in my Debconf talk), which would solve/help your high
> > number of orphaned packages.
> What real problems will this
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I think we should also have an auto-removals-from-sid[1] (the crowd applauded
> when I mentioned that in my Debconf talk), which would solve/help your high
> number of orphaned packages.
What real problems will this solve apa
On Sat, Dec 03, 2016 at 11:42:02AM +0100, Mattia Rizzolo wrote:
> 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?
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-re
On Sat, Dec 03, 2016 at 12:23:17PM +0100, Emilio Pozuelo Monfort wrote:
> I would suggest to come up with some algorithm to determine if a package is
> effectively unmaintained, and implement it in an automatic way that gives
> maintainers prior notice and a chance to react, like we do with auto-re
On 03/12/16 11:42, Mattia Rizzolo wrote:
> On Fri, Dec 02, 2016 at 10:56:07PM +0500, Andrey Rahmatullin wrote:
>> * 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
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 fa
> human maintainer". 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). I've sent the list of my
> pings to
> the MIA team.
I don't like the way you are picturing this. The question
Andrey Rahmatullin writes ("Re: MIA maintainers and RC-buggy packages"):
> On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > Frankly, I would have been tempted to let a lot of those packages slip
> > out of stretch. It depends what they were, of course
On Fri, Dec 02, 2016 at 06:58:55PM +, Ian Jackson wrote:
> > * 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?
>
> No, I think this is a wast
Andrey Rahmatullin writes ("MIA maintainers and RC-buggy packages"):
> * 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?
No,
Hello.
During the last week or two I've spent some time looking through the
packages with RC bugs, mostly those that are removed from testing, have
popcon 100+ and don't have recent activity on the bug report. I skipped
bugs like "depends on obsolete piece of software" or "crashes in some
circumst
18 matches
Mail list logo
