FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-01-2012, 09:40 AM
Simon McVittie
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 01/10/12 09:51, Thijs Kinkhorst wrote:
> I've had an NMU in the past for a package when I had a little less time,
> but the change was sound and correct. So I didn't bother to make an
> (empty) MU just to acknowledge it - I think that should be OK and not
> 'punished' by taking it as a sign of an unmaintained package.

I think it'd be reasonable to expect a maintainer to follow-up to the
BTS[1] in cases like this, just to say "that change looks fine" (and if
the upload is still in DELAYED, give the non-maintainer a chance to
reschedule it to the 0-day queue), e.g.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607762#19>.

I also think it's reasonable to expect that people checking whether a
package is "effectively unmaintained" should check such bugs for
activity, and treat the NMU as having been acknowledged (in the
non-jargon sense of the word) if the maintainer replied.

S

[1] the same place the non-maintainer (should have) sent the nmudiff:
the bug closed if there was only one, or the new "integrate changes from
NMU 1.2-3" bug otherwise.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 50696506.70100@debian.org">http://lists.debian.org/50696506.70100@debian.org
 
Old 10-01-2012, 09:50 AM
Ian Jackson
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Stefano Zacchiroli writes ("Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal"):
> I just meant that if we encourage to post seconds (which are in fact
> just a form of review of the intention to orphan) on a list such as -qa
> (which is more specific-purpose than, say, -devel), we might end up
> attracting there people who have an interest in doing this sort of
> package quality review. That sounds like a useful side-effect to me. But
> I'm still unsure about the benefits of the seconds principle, though.

It seems to me that when salvaging works well, the existing maintainer
is probably at least semi-active but is embarrassed about the
package or somehow otherwise blocked from working on it.

A successful salvage is then a quiet operation where we take this
burden from the maintainer and they don't have to feel too bad about
it. Hopefully the maintainer, after a few months at least, will be
actually relieved.

I don't think seconding fits well into this. It would encourage
dogpiles and noise. If it achieves anything it will be to make the
maintainer feel worse and perhaps make them stubborn.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20585.26461.670996.413976@chiark.greenend.org.uk"> http://lists.debian.org/20585.26461.670996.413976@chiark.greenend.org.uk
 
Old 10-01-2012, 10:29 AM
Holger Levsen
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi,

On Sonntag, 30. September 2012, Arno Töll wrote:
> * We are effectively ruling out opinions of non-members. That's bizarre,
> since we allow them to maintain (and even "hijack") packages.

No, we d/won't allow non-members to hijack packages. We probably will allow
them to salvage packages OTOH. (And that's totally non-bizarre IMHO.)

This is a good example why language is important. And please dont write
"hijack" if you mean _salvage_ or _salvage or high-jack_. Similary like you
won't say "coffee" if you mean water or (water or coffee) ;-p


cheers,
Holger


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 201210011229.01274.holger@layer-acht.org">http://lists.debian.org/201210011229.01274.holger@layer-acht.org
 
Old 10-01-2012, 11:00 AM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Mon, Oct 01, 2012 at 12:29:00PM +0200, Holger Levsen wrote:
> On Sonntag, 30. September 2012, Arno Töll wrote:
> > * We are effectively ruling out opinions of non-members. That's bizarre,
> > since we allow them to maintain (and even "hijack") packages.
>
> No, we d/won't allow non-members to hijack packages. We probably will allow
> them to salvage packages OTOH. (And that's totally non-bizarre IMHO.)

I agree with Holger Levsen on this. And the "seconding" I'm proposing is
obviously to have DDs (maybe also DMs ?) judge between an unwanted hijack and a
welcome salvage.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121001110005.GD3482@master.debian.org">http://lists.debian.org/20121001110005.GD3482@master.debian.org
 
Old 10-10-2012, 10:04 PM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 28/09/12 at 18:48 +0200, Arno Töll wrote:
> Hello,
>
> we may all agree that the maintenance of some (many?) packages in Debian
> is in a unclear situation. There is a transient state, where people are
> interested to bring a package in shape but the strong role of a package
> maintainer in Debian effectively blocks any commitment beyond fixing
> important issues in minimally invasive non-maintainer uploads.
>
> [...]

Hi,

So, reading this thread (which was surprisingly quiet, given the topic),
it seems that everybody agrees that such a procedure would be a good
thing (nobody had fundamental concerns). But now we have two proposed
procedures:
- one which is based on a set of criterias
- one which is based on seconds

It seems that the second[s] one gets slightly more traction, but requires
some minor changes:
- the submitter of the "intent to orphan" bug must Cc
debian-qa@lists.debian.org, and file the bug with severity:serious (this
was part of the "criterias" proposal).
This aims at increasing the publicity of the process, thus avoiding the
"cabal" effect where a group of DDs secretly act together to orphan a
package: everybody can watch the flow of orphanings and react if necessary.

- the number of seconds should probably be tuned a bit. For example, people
could also NACK the proposal to orphan the package. I propose that we wait
until:
+ three DD have ACKed the proposal (not counting the initial submitter)
AND
+ a 3/1 majority is reached between ACKers and NACKers (same as the TC
for overriding developers)

So, how do we move forward?
It seems we need someone to update the proposal, and turn it into a form
suitable for further comments (typically a draft dev-ref patch).

Some ideas:
- the proposal should stress that everybody is welcomed to participate in the
discussion, even if only DDs can ACK/NACK. Specifically, having feedback
from users is always very useful in those discussions.
- the proposal should include a list of criterias the the submitter could
check to reinforce his initial email: the more "proofs" that the package is
a good target, the better. The criterias from Arno's proposal look very
good as a starting point.
- the proposal could stress that the proposed adopter can start working on
the package right away and use NMUs to address open issues.

I don't think that we need something big like a GR to make the process active.
This could probably simply be described as a recommended procedure in dev-ref:
that way, in case of backfire, people following the procedure would have the
backing of a recommended procedure described in a semi-official document.

So, any takers for shaping up an updated proposal? I will probably try to do it
if nobody does it by the end of the month.

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121010220433.GA32486@xanadu.blop.info">http://lists.debian.org/20121010220433.GA32486@xanadu.blop.info
 
Old 10-11-2012, 12:24 AM
Michael Gilbert
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Wed, Oct 10, 2012 at 6:04 PM, Lucas Nussbaum wrote:
> So, reading this thread (which was surprisingly quiet, given the topic),
> it seems that everybody agrees that such a procedure would be a good
> thing (nobody had fundamental concerns). But now we have two proposed
> procedures:
> - one which is based on a set of criterias
> - one which is based on seconds

There is also my proposal:
http://bugs.debian.org/681833

It's not perfect, and I'm open to suggestions and improvements, but I
think it has some important advantages over the above. One is that
piggybacks on existing NMU procedures (so it's not really new, but
refines the existing process). Another is that it is fully
autonomous: whoever has interest to do the work is empowered to just
go ahead and do it. In other words, let the best code win. The third
is that its already been tested in practice: the wine package being
successfully salvaged without instigating any kind of adversarial
reaction by the salvager (myself) and the existing maintainer.

There are some worries in that bug log about too much deference to the
tech committee in case of disputes. That is certainly a valid
concern, but presumably that is one of the tech committees primary
roles, and the goal of that wording is to direct parties in the right
direction toward a resolution in those cases.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/CANTw=MNL76LA8tXgeNgE5TYTuYxVOviCL4H-74qiU5DQTHCs8A@mail.gmail.com
 
Old 10-11-2012, 05:50 AM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi Lucas,

Thanks for coming back on this.

On Thu, Oct 11, 2012 at 12:04:33AM +0200, Lucas Nussbaum wrote:
> On 28/09/12 at 18:48 +0200, Arno Töll wrote:
> > Hello,
> >
> > we may all agree that the maintenance of some (many?) packages in Debian
> > is in a unclear situation. There is a transient state, where people are
> > interested to bring a package in shape but the strong role of a package
> > maintainer in Debian effectively blocks any commitment beyond fixing
> > important issues in minimally invasive non-maintainer uploads.
> >
> > [...]
>
> Hi,
>
> So, reading this thread (which was surprisingly quiet, given the topic),
> it seems that everybody agrees that such a procedure would be a good
> thing (nobody had fundamental concerns). But now we have two proposed
> procedures:
> - one which is based on a set of criterias
> - one which is based on seconds
>
> It seems that the second[s] one gets slightly more traction, but requires
> some minor changes:
> - the submitter of the "intent to orphan" bug must Cc
> debian-qa@lists.debian.org, and file the bug with severity:serious (this
> was part of the "criterias" proposal).
> This aims at increasing the publicity of the process, thus avoiding the
> "cabal" effect where a group of DDs secretly act together to orphan a
> package: everybody can watch the flow of orphanings and react if necessary.

Yes, the cc to debian-qa is a good idea for the reason you described. I'm not
sure about severity:serious but I don't object.

>
> - the number of seconds should probably be tuned a bit. For example, people
> could also NACK the proposal to orphan the package. I propose that we wait
> until:
> + three DD have ACKed the proposal (not counting the initial submitter)
> AND
> + a 3/1 majority is reached between ACKers and NACKers (same as the TC
> for overriding developers)

Yes, including NACKs the way you described is an improvement.

>
> So, how do we move forward?
> It seems we need someone to update the proposal, and turn it into a form
> suitable for further comments

Here's an updated proposal based on the second propsal using criteria from the
first proposal and using some of your newest comments :

| Anyone can mark a package as orphaned after the following steps have been
| completed : Someone submits an "intent to orphan" (ITO) in the bts with an
| explanation of why he/she thinks that the package needs a new maintainer. The
| explanation should cover aspects like how long there was no visible activity,
| whether there are NMUs not yet acknowledged, wheter the package blocks progress
| elsewhere in Debian, release critical bugs, public comments from the maintainer
| revealing lack of interest in the package, ... etc. The bug must have severity
| "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
| submit this "intent to orphan". At least three DDs (not counting the initial
| submitter) second the "intent to orphan" on the same bug report with a cc to
| the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
| between ACKers and NACKers. And the maintainer does not respond within one
| month after the the third second. During this process anyone is welcome to add
| comments on the bug.

> (typically a draft dev-ref patch).

I have not yet done that, but I'm willing to do that once we've reached a
larger consensus on the text.

>
> Some ideas:
> - the proposal should stress that everybody is welcomed to participate in the
> discussion, even if only DDs can ACK/NACK. Specifically, having feedback
> from users is always very useful in those discussions.

I've added that in the updated text above.

> - the proposal should include a list of criterias the the submitter could
> check to reinforce his initial email: the more "proofs" that the package is
> a good target, the better. The criterias from Arno's proposal look very
> good as a starting point.

I have added some of them in the updated text above. I have skipped the part
about the MIA database because I want people without access to the MIA database
to be able to submit an "intent to orphan". The three DDs adding seconds can
still consult the MIA database.

> - the proposal could stress that the proposed adopter can start working on
> the package right away and use NMUs to address open issues.

In my opinion, the NMU procedure already sufficiently describes when an NMU is
appropriate. I suggest to simply follow the existing NMU rules.

>
> I don't think that we need something big like a GR to make the process active.
> This could probably simply be described as a recommended procedure in dev-ref:
> that way, in case of backfire, people following the procedure would have the
> backing of a recommended procedure described in a semi-official document.

I agree that the procedure should at least be included in developers-reference.
I have no strong opinion on whether a GR would be needed.

>
> So, any takers for shaping up an updated proposal? I will probably try to do it
> if nobody does it by the end of the month.

See updated text above. I'm looking forward to a consensus.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121011055051.GB5933@master.debian.org">http://lists.debian.org/20121011055051.GB5933@master.debian.org
 
Old 10-11-2012, 06:20 AM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 11/10/12 at 05:50 +0000, Bart Martens wrote:
> | Anyone can mark a package as orphaned after the following steps have been
> | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> | explanation of why he/she thinks that the package needs a new maintainer. The
> | explanation should cover aspects like how long there was no visible activity,
> | whether there are NMUs not yet acknowledged, wheter the package blocks progress
> | elsewhere in Debian, release critical bugs, public comments from the maintainer
> | revealing lack of interest in the package, ... etc. The bug must have severity
> | "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
> | submit this "intent to orphan". At least three DDs (not counting the initial
> | submitter) second the "intent to orphan" on the same bug report with a cc to
> | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
> | between ACKers and NACKers.

> And the maintainer does not respond within one month after the the third second.

I'm not sure about this delay. This procedure should be used for
uncontroversial cases, where orphaning is obviously the right choice.
If it's not that obvious, of course common sense dictates to wait for
some time to give the maintainer time to comment. But that can also be
achieved by someone NACKing saying "Mmmh, I'm not so sure about that,
there hasn't been any big task awaiting action from the maintainer.
Are you really sure that the maintainer would understand that the
current level of maintenance is suboptimal? Have you tried re-contacting
him?"

Maybe rephrase that into "Before taking action, it could also be a good
idea to wait for comments from the maintainer, especially if he/she is
otherwise active in Debian."

> During this process anyone is welcome to add
> | comments on the bug.

Maybe rephrase into:
During the process, everyone is of course welcomed and encouraged to
contribute to the discussion. Comments from users of the package that
suffer from the level of maintenance are especially useful.

> > - the proposal should include a list of criterias the the submitter could
> > check to reinforce his initial email: the more "proofs" that the package is
> > a good target, the better. The criterias from Arno's proposal look very
> > good as a starting point.
>
> I have added some of them in the updated text above. I have skipped the part
> about the MIA database because I want people without access to the MIA database
> to be able to submit an "intent to orphan". The three DDs adding seconds can
> still consult the MIA database.

I like the fact that this process focuses on *packages* and not on
*maintainers*. This makes thing a lot less confrontational. So I'm fine
with not including MIA in the checklist, since this typically focuses on
the maintainer.

> > - the proposal could stress that the proposed adopter can start working on
> > the package right away and use NMUs to address open issues.
>
> In my opinion, the NMU procedure already sufficiently describes when an NMU is
> appropriate. I suggest to simply follow the existing NMU rules.

OK, fair enough

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121011062036.GA7093@xanadu.blop.info">http://lists.debian.org/20121011062036.GA7093@xanadu.blop.info
 
Old 10-11-2012, 08:21 AM
Gergely Nagy
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:

> On 11/10/12 at 05:50 +0000, Bart Martens wrote:
>> | Anyone can mark a package as orphaned after the following steps have been
>> | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
>> | explanation of why he/she thinks that the package needs a new maintainer. The
>> | explanation should cover aspects like how long there was no visible activity,
>> | whether there are NMUs not yet acknowledged, wheter the package blocks progress
>> | elsewhere in Debian, release critical bugs, public comments from the maintainer
>> | revealing lack of interest in the package, ... etc. The bug must have severity
>> | "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
>> | submit this "intent to orphan". At least three DDs (not counting the initial
>> | submitter) second the "intent to orphan" on the same bug report with a cc to
>> | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
>> | between ACKers and NACKers.
>
>> And the maintainer does not respond within one month after the the third second.
>
> I'm not sure about this delay. This procedure should be used for
> uncontroversial cases, where orphaning is obviously the right choice.

I strongly agree here. A package that's a salvaging candidate has
already been neglected far too long, requiring another extra month of at
most NMU-maintainance is counter productive.

A maintainer has many ways to signal in advance that he/she will be
unable to answer bug reports or mail for a longer period of time
(including VAC messages on -private, and/or setting a vacation message
in LDAP), many of which can and should be checked as soon as the
salvaging process starts, to make sure there's no accidental overlap.

With that done, I do not see the point of waiting an extra month. I
would, however, put a time limit on the NACKs: one week after 3 ACKs or
3/1 majority is reached, the decision's done, and further ACKs/NACKs
won't be counted. That is, we'd have a time limit on everyones ability
to contribute to the salvaging process, not just a ticking clock for the
maintainer.

> Maybe rephrase that into "Before taking action, it could also be a good
> idea to wait for comments from the maintainer, especially if he/she is
> otherwise active in Debian."

I'd rephrase that further, with a s/wait for/seek/, because in my
opinion, the person wanting to salvage a package should go to great
lengths to reach the maintainer. Merely waiting when the package is
obviously neglected sounds like a very passive thing to me.

--
|8]


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/87r4p58llk.fsf@algernon.balabit
 
Old 10-11-2012, 09:27 AM
Arno Töll
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi,

On 11.10.2012 07:50, Bart Martens wrote:
>> - the submitter of the "intent to orphan" bug must Cc
>> debian-qa@lists.debian.org, and file the bug with severity:serious (this
>> was part of the "criterias" proposal).
> | Anyone can mark a package as orphaned after the following steps have been
> | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> | explanation of why he/she thinks that the package needs a new maintainer.

I don't think "intend to orphan" (ITO) is a good name. First of all, it
is wrong, because if you file such a bug, you eventually don't want to
orphan a package, but quite the contrary revive its maintenance.
Moreover, its name suggests it would be a WNPP bug, which it isn't and
wouldn't be.

Aside I welcome Lucas and your initiative to move on with this
discussion. After all, I'm happy with any solution which finds
consensus, but I still don't like the DD seconding for the reasons
outlined before. At very least we could allow DMs to make votes too.
Eventually it's just some key in a keyring which is required to
authenticate people.

Some additional thoughts on the seconding:

* can we really be sure that random developers flying by, care enough
to look into a package they may not care about, inspect its situation
and ack/nack? The whole new mechanism could be bypassed by feedback
timeout. Frankly, many packages which could be salvaged in future are
not on of these which draw much attraction.

* You cannot require a 3:1 majority without giving a time window to
raise objections. The way Bart proposed it in his draft, one couldn't
make sure a 3:1 majority is reached before 75% of *all* developers
agreed for the opened case. I don't think that's desired or realistic.

* How would you validate binding votes on a salvage process? You would
need to require to send signed mails to the list for seconding.
Otherwise we did not win anything over votes allowed by anyone.



--
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D
 

Thread Tools




All times are GMT. The time now is 03:49 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org