subject:"\[SUMMARY\/PROPOSAL\] Orphaning another maintainer's packages"

Hi Lucas,

As you know I agree with you on most aspects.

On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
   I find third-party reviews
   and ACKs a good way to reinforce the feeling that the orphaning is the
   right thing to do.

Absolutely.

   Note that it's often users who detect unmaintained
   software. With the ACK-based process, it's possible for a user to
   initiate the process.

Yes, the users help is welcome.

   For simple  obvious cases, waiting for a month
   is a bit annoying when someone is willing and ready to take over
   maintenance. it's important to use contributors motivation while it's
   high.

I agree to not demand a delay for the reason you gave.

 
 But anyway, I would not oppose adding something such as:
   If you followed all the steps above, waited for a month, did not
   receive enough ACKs, but nobody NACKed, you can still proceed.

I join Steve L. with wanting a consensus, so the package can be orphaned only
when there are sufficient ACKs.  I expect the cc to debian-qa to draw
sufficient attention from DDs, so I don't expect any problem with this.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026060942.gf10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - without objection versus requiring ACKs

On Thu, Oct 25, 2012 at 09:06:34AM -0400, Scott Kitterman wrote:
 Why not start with a without objection standard and see how it works?

The without objection approach would require a reasonable delay for people to
raise objections (some say two months).  The ACK/NACK approach allows to reach
a consensus in a shorter time, so that for obvious cases the salvaging can
proceed without pointless delay.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026061813.gg10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay

On Thu, Oct 25, 2012 at 02:50:46PM +0100, Ian Jackson wrote:
 I'm also not that keen on the idea that the outcome is to orphan the
 package.

Orphaning the package it not the final outcome.  The goal is to get packages
salvaged.  See the two activities explained here:
http://lists.debian.org/debian-devel/2012/10/msg00261.html

 The salvager should surely be adding themselves as an Uploader.

If the package is not orphaned, then the maintainer and salvager can agree on
that.  If the package is orphaned, the salvager can adopt the package (ITA).

   3. Wait for objections

For how long ? The proposal includes collecting ACKs so that any pointless
delay can be skipped, resulting in the package being salvaged sooner.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026062506.gh10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - getting orphaned packages marked as such

On Thu, Oct 25, 2012 at 04:20:43PM +0200, Thibaut Paumard wrote:
 If someone notices that a package is in need of greater attention, but
 cannot commit to attending it themselves, it's important that the
 packages is marked at least as needing help.
 
 I understand the entire point here is to mark packages which are
 effectively abandoned as orphaned, so that others can see them in the
 wnpp news for instance.
 
 It's certainly better if a new foster maintainer can be found for the
 package right away, but it should IMHO not be mandatory. Prospective
 maintainers, those that want to help Debian but don't know were to
 start, will be able to adopt an orphaned package, but not to salvage
 one in most cases.
 
 Take it as a three body encounter:
  - a package with no effective maintainer;
  - a developer who notices the problem;
  - a prospective maintainer.

I fully agree with all the above with s/developer/person/.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026063112.gi10...@master.debian.org

[SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay

2012-10-26 Thread vangelis mouhtsis


Hi,
I'm wondering, before a package will be orphaned is it possible/
needful the owner to ask for help or to express the reasons?

Regards
gnugr

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - only for obvious cases

On Thu, Oct 25, 2012 at 03:52:36PM +0100, Ian Jackson wrote:
 Whether a package is in need of greater attention is not a hard and
 fast objective thing.  It's to a large part subjective.  Perhaps the
 maintainer thinks it's more or less fine, or at least low enough
 priority that the problems are tolerable.

I agree that not every case will be obvious.  When a package has clearly not
been maintained for several years, then it is easy to find three ACKs, so that
the package can be marked as orphaned.  When the maintainer thinks that the
package is more or less fine and doesn't want to put the package up for
adoption, then the ITO procedure should not forcibly orphan the package.

The proposal written by Lucas is, in my opinion, sufficiently clear to address
only the obvious cases.

 It's one thing to say this package is in need of attention which I am
 prepared to commit to providing.  It's quite another to say this
 package is in need of attention but I'm not going to do anything other
 than say it's a problem.

It is, in my opinion, also useful to identify problems even without solving the
problems.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026063849.gj10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote:
 Gergely Nagy alger...@balabit.hu wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  Whether a package is in need of greater attention is not a hard and
  fast objective thing.  It's to a large part subjective.  Perhaps the
  maintainer thinks it's more or less fine, or at least low enough
  priority that the problems are tolerable.
 
 Then the maintainer has many options, including but not limited to
 NACK-ing the ITO. One has a lot of possibilities even before it comes
 to
 filing an ITO.
 
 AIUI, with the current proposal, as long as three DDs think it should be
 orphaned, the maintainer's objection is irrelevant.

I would send a NACK because the maintainer objects, and I trust other DDs
subscribed to debian-qa to do the same.  The ITO procedure is not meant to
replace the TC handling conflicts.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026064655.gk10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - liberal NMUs

On Thu, Oct 25, 2012 at 03:09:55PM -0400, Michael Gilbert wrote:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.

Lucas' proposal discussed in this thread is about adding a lightweight
procedure to mark obviously unmaintained packages as orphaned.  If you want
NMUs to be more liberal, then please write a proposal for modifying the NMU
procedure and feel free to discuss it in a separate thread.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026065601.gl10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - sponsoring

On Thu, Oct 25, 2012 at 10:05:40PM +, Jean-Michel Vourgère wrote:
 When fixing non important bugs, or improving the package quality, like
 switching to format 3 source, arranging the rules file, and so on, I fear
 it will be very difficult to find a sponsor for these nmus.
 
 Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these
 cases. After it's done, one can work on more radical changes, that are more
 likely to get sponsored.
 
 I find it sad to see patches hanging for years in the bug tracker.

I fully agree with the above.

I occasionally sponsor packages.  I don't sponsor NMU packages when they
contain changes that don't conform to the NMU procedure.  I understand that it
is difficult for non-DDs to salvage packages via NMUs.  I prefer that an
unmaintained package is simply orphaned, so that the non-DD can adopt the
package with full maintainership.  Much easier to sponsor.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026071211.gm10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Gergely Nagy

Steve Langasek vor...@debian.org writes:

   No, it makes the process based on *consensus*, which is a minimum
   requirement.

  It also means that the salvager has to do more work.

 I expect the cc to debian-qa to draw sufficient DD's attention.  And the
 ACKs are about agreeing on marking a package as orphaned.  That's the easy
 part.

 The salvaging part goes via the existing ITA procedure.  That's the hard
 part.

 Exactly.  Anyone who can't be bothered to find N other DDs to agree with him
 that a package should be orphaned (for some value of N = 3 - as far as I'm
 concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering
 themselves a candidate for maintaining the package anyway.

I am then unfit to maintain any package, since I would not be willing to
do more than CC -qa@ by the time it comes to an ITO, to draw
attention.

If I get no answer to that, no acks, no nothing (and similar things did
happen in the past, perhaps not on -qa, but I have mails on -devel@ and
-release@ unanswered, or complained about months later after the fact),
I would not want to go out of my way to find consensus. I take no
replies (within a reasonable timeframe) as not caring, as silent
agreement.

By the time -qa@ is mailed, the salvager had to do enough visible work
to draw attention to the eventual ITO, so mailing -qa@ should be enough,
whether that gets the salvager any acks or not. In case of no acks, it
is *NOT* the salvagers fault that noone cares, and therefore it is not
the salvager who should be punished with more gruntwork, either.

I don't really see the point of requiring consensus if there are *zero*
replies to an ITO CC'd to -qa@ for, say, 2-3 weeks.

On a similar note, the original proposal did not mention how much time
needs to pass before the salvager can proceed, after getting a
majority. THAT too, needs a timeout, and if it does, why would it hurt
to bake in a worst-case scenario with no acks or nacks? (I can accept
defaulting to no too, after a timeout, as long as there's one. I would
find the result pointless and silly, but at least it puts an end to it,
which the current proposal doesn't.)

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87haphy8ql@luthien.mhp

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Thomas Goirand


On 10/26/2012 01:09 PM, Bart Martens wrote:
I expect the cc to debian-qa to draw sufficient DD's attention. And 
the ACKs are about agreeing on marking a package as orphaned. That's 
the easy part. The salvaging part goes via the existing ITA procedure. 
That's the hard part. Regards, Bart Martens 


Could anyone explain what broken thing we are trying to fix?

- Is the current process of orphaning broken? (if so: why?)
- Is there too many hijacks?
- Not enough salvage?

And more importantly:
- What do you expect the new procedure will do? What's the goal?

I have re-read Lucas Nussbaum original post, and I didn't find
any information about the above.

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508a45d3.8070...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Gergely Nagy

Bart Martens ba...@debian.org writes:

  I think that sufficient DDs will review the ITOs.  Note that most work is
  already done by the ITO submitter.  Sponsoring a package at mentors 
  (review
  other peoples work) is, in my opinion, much more work than reading an ITO 
  and
  sending an ACK.
 
 On the other hand, ACKing an ITO is much more responsibility, becasue
 it's not only about a package, but about taking over a package too.

 No, it is not.  See the two activities explained here:
 http://lists.debian.org/debian-devel/2012/10/msg00261.html

It is still more responsibility than sponsoring, whether you orphan or
take over the package, because you're not just introducing a new package
or a new version as with sponsoring, you're not just doing an NMU, but
you're taking away something from someone. This latter part is what - in
my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
NMUs.

 An
 ITO will also contain quite a lot of info about previous attempts at
 updating the package - that's not simple to review either. It is less
 technical too, which can be off-putting to some.

 No, an ITO should just enumerate the reasons why the package should be marked
 as orphaned.

And the reasons why the package should be orphaned overlaps quite a bit
with previous attempts at getting the package fixed/updated/whatever by
other means.

If there were no previous attempts, then the package should not be
considered for ITO.

  As said elsewhere in the thread, the process needs to be easy and
  efficient. Hunting ACKs is neither easy, nor efficient.
 
  The proposed text is quite easy, in my opinion.
 
 Indeed, it is. Partly because as far as I understand it, it only
 recommends a 3/1 majority, and does not demand it. That's perfectly
 fine.

 I guess it's a recommendation because it would go in developers-reference.
 That doesn't mean that it would be OK to randomly orphan packages ignoring the
 recommended procedure in developers-reference.

I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
I never said otherwise. I merely said that *waiting* for ACK/NACK
replies should have a timeout, and if no response arrives within a
reasonable amount of time, we should default to allowing the salvager to
proceed.

That is all. Without the timeout, we have a hole in the system: how long
do you have to wait for replies? When is majority reached? As soon as
3/0? What if that happens within 10 minutes, and a NACK would come on
the 15th? If waiting for majority does have a timeout, what happens if
there are no replies for one reason or the other?

These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,
and default to yes in case of no replies, on the grounds that mistakes
can be corrected, and we should be civilised enough to not flame the
salvager to crisp if that happens (since it was us who failed to give
him feedback in the first place - punishment shall be on us, not the
salvager).

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d305y88b@luthien.mhp

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal

On Fri, Oct 26, 2012 at 04:12:03PM +0800, Thomas Goirand wrote:
 On 10/26/2012 01:09 PM, Bart Martens wrote:
 I expect the cc to debian-qa to draw sufficient DD's attention.
 And the ACKs are about agreeing on marking a package as orphaned.
 That's the easy part. The salvaging part goes via the existing ITA
 procedure. That's the hard part.
 
 Could anyone explain what broken thing we are trying to fix?
 
 - Is the current process of orphaning broken? (if so: why?)
 - Is there too many hijacks?
 - Not enough salvage?
 
 And more importantly:
 - What do you expect the new procedure will do? What's the goal?

People interested in salvaging an unmaintained package are discouraged by the
current procedures.  The new procedure is meant to add a lightweight procedure
to mark unmaintained packages as orphaned, so that anyone interested can adopt
them without needless delay.  Basically the goal is to increase speed in
getting packages salvaged.

 I have re-read Lucas Nussbaum original post, and I didn't find
 any information about the above.

Some aspects were discussed earlier in different threads than this one.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026090720.ga23...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - need for ACKs, default no orphaning

On Fri, Oct 26, 2012 at 09:59:16AM +0200, Gergely Nagy wrote:
 Bart Martens ba...@debian.org writes:
 
   I think that sufficient DDs will review the ITOs.  Note that most work is
   already done by the ITO submitter.  Sponsoring a package at mentors 
   (review
   other peoples work) is, in my opinion, much more work than reading an 
   ITO and
   sending an ACK.
  
  On the other hand, ACKing an ITO is much more responsibility, becasue
  it's not only about a package, but about taking over a package too.
 
  No, it is not.  See the two activities explained here:
  http://lists.debian.org/debian-devel/2012/10/msg00261.html
 
 It is still more responsibility than sponsoring, whether you orphan or
 take over the package, because you're not just introducing a new package
 or a new version as with sponsoring, you're not just doing an NMU, but
 you're taking away something from someone. This latter part is what - in
 my opinion - makes ACKing an ITO a much bigger thing than sponsoring or
 NMUs.

When a package has clearly not been maintained for years, then marking it as
orphaned doesn't take away something from someone.

I agree that there is some responsibility involved.  But the work is easy.  In
obvious cases sufficient ACKs will be collected in no time.  When there is
doubt, a NACK is appropriate.  I trust DDs to be responsible with this.

 
  An
  ITO will also contain quite a lot of info about previous attempts at
  updating the package - that's not simple to review either. It is less
  technical too, which can be off-putting to some.
 
  No, an ITO should just enumerate the reasons why the package should be 
  marked
  as orphaned.
 
 And the reasons why the package should be orphaned overlaps quite a bit
 with previous attempts at getting the package fixed/updated/whatever by
 other means.
 
 If there were no previous attempts, then the package should not be
 considered for ITO.

Marking a clearly unmaintained package as orphaned is useful regardless of
previous attempts to update it.

 
   As said elsewhere in the thread, the process needs to be easy and
   efficient. Hunting ACKs is neither easy, nor efficient.
  
   The proposed text is quite easy, in my opinion.
  
  Indeed, it is. Partly because as far as I understand it, it only
  recommends a 3/1 majority, and does not demand it. That's perfectly
  fine.
 
  I guess it's a recommendation because it would go in developers-reference.
  That doesn't mean that it would be OK to randomly orphan packages ignoring 
  the
  recommended procedure in developers-reference.
 
 I never said ignoring the recommended procedure. CC-ing -qa@ is a must,
 I never said otherwise. I merely said that *waiting* for ACK/NACK
 replies should have a timeout, and if no response arrives within a
 reasonable amount of time, we should default to allowing the salvager to
 proceed.
 
 That is all.

I'm with Steve L. on this.  Without sufficient ACKs, no orphaning.

 Without the timeout, we have a hole in the system: how long
 do you have to wait for replies? When is majority reached? As soon as
 3/0? What if that happens within 10 minutes, and a NACK would come on
 the 15th? If waiting for majority does have a timeout, what happens if
 there are no replies for one reason or the other?

Collecting ACKs is useful to avoid needless delay to wait for possible
objections.  It is, in my opinion, OK to conclude the ITO with three ACKs,
without further delay.  If nobody sends ACKs nor NACKs then something went
probably wrong with the cc to debian-qa.

 These I'd love to see clarified. Personally, I'd go with 2-3 weeks tops,

I prefer no delay in the text, but I have no strong opinion on this.

 and default to yes in case of no replies,

Without sufficient ACKs, no orphaning.  My opinion on that is quite strong.

 on the grounds that mistakes
 can be corrected, and we should be civilised enough to not flame the
 salvager to crisp if that happens (since it was us who failed to give
 him feedback in the first place - punishment shall be on us, not the
 salvager).

Of course, the maintainer can re-adopt his/her package during the time it is
orphaned.  But if someone else already has retitled the O to ITA, then in
general that person should be allowed to continue.  Of course, all involved
parties can still talk and agree on something else.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026093548.gb23...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - no ACKs nor NACKs, timeout, defaulting to no

On Fri, Oct 26, 2012 at 09:48:18AM +0200, Gergely Nagy wrote:
 why would it hurt
 to bake in a worst-case scenario with no acks or nacks? (I can accept
 defaulting to no too, after a timeout, as long as there's one. I would
 find the result pointless and silly, but at least it puts an end to it,
 which the current proposal doesn't.)

I would not object against including this in the text.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026094407.gc23...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay

2012-10-26 Thread Thibaut Paumard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 26/10/2012 08:35, vangelis mouhtsis a écrit :
 Hi, I'm wondering, before a package will be orphaned is it
 possible/ needful the owner to ask for help or to express the
 reasons?
 
 Regards gnugr

http://www.debian.org/devel/wnpp/
Look for RFH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQinm/AAoJEJOUU0jg3ChA09wQAIsS1aQf81ela8jA73azBwrN
DoDxzYGyNQQBtv1X5h3S7lYvLk4mXLs+JnkDfrI4gzdsE/3j8yw8wA6c9YjLMnMo
qqPZwZ6Pv1Cvv7CQ02qAJujbqjoftwOn6vCtIPPKLJ7gzJrFIDoAqhRfCjdLPwB3
hpR9wvi3P9kCvCWKZgCZTwOymFIM7Oeie07bVhI55MSC925msG5Bg5Iy77EjppIl
LmwW3WWY+x7ut1nkwNjkhs6dHWGOKjPh1louetEmqEng97FXUCFS/WiTUEz3QN7D
qxSIA4QkTnSHpbwY8zvt4jBOHT+PCfc8yQ2omjwoFK4YvgUiuFRSHFP1rueHSjSZ
LSvM/n+Oaxw9wgpcmeDedTabk1bO9Dy2NcP+rQsICV0OimioxMqTeHT8wXW4mAAt
mSbMuu393CxJ2xs2kBTRFCmWxqYJu6vTUEyZstc9W7ZdISBGGnYHMghcixtQejEM
5Zlv/oN6BQKMP9h0fk/Rmfx9HEaobqzvrXktd3vlLZOwdihyD38ZwaHB/YoTya7d
Zaq8kcb1PRTDqM3j4hZE9ZmNzyB3JUuEWDiaBT/LOmIydXbPug3UBzvBb5ecJ0LG
cYhnxLNPAExPXGwsAx6yid1YVnz44CquW4ou5Wdcs7qw1PRYPqCkXtvDA1kBopH+
jG1s2GLVU9UPgBE+VZiv
=x9xl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508a79bf.7080...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

2012-10-26 Thread Thibaut Paumard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 26/10/2012 08:46, Bart Martens a écrit :
 On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote:
 Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current
 proposal, as long as three DDs think it should be orphaned, the
 maintainer's objection is irrelevant.
 
 I would send a NACK because the maintainer objects, and I trust
 other DDs subscribed to debian-qa to do the same.  The ITO
 procedure is not meant to replace the TC handling conflicts.
 

So why not agree now that the maintainer can veto the process?

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQinr/AAoJEJOUU0jg3ChAJ74P/3i8/IHIS1HN/IRdldsQUEa8
sJvW/hRd2iXrPmwLCkxP0ng0XmiG8GZ8JjYo7esYWbU2omgJhZ/XxlOKeePHQJfA
RQ5ifYq1kZFZT+5xpkwqlhtQ+MBbTuMSRYmDsEgyjnwoEQGLrjCld/+Q4SJA5EQo
DvGgFOd3gvz0SpJa8Tp9wDfr8bXezEJs8iTBiGCnihs4n+Qfhjc7aHrAEUenOzuh
ZWnEmpbByF79jHYuor403Lu9TPwrCklVxZ69qKhSHJlDVTUDoC2H8MxZcLyJwYqJ
KmmwQMYFi8mf210WPw/OpJ9mDYR+VbCWA4zFaoq91rFoxsmIVn0Z8upFFQVyr4fZ
DnxKBxeOjBC25hb5301v67cZOYC6x+izfHY9oPHuzPCPkinybk1ak0KpsIX5vXTU
jCy4xCt3Uu1RnJBl0f215RpyKxcGx8Nh67t0GjjyfP72ZrfM9LluwzZRGXyixCJU
ujnZZZ5+VSzqsXGYAQW9UU1ME9ap4yLJ6jXYsX0AEuzF0y6XT7iHLQ2c3nHGWlgv
fk7Gl7+23lxOs1VbWgbiHwhyRLp/F0BAD+eUjtnAYWGPFpFrp/FV6JkOosTmL4kM
yUfBjTIhGlp9uPcYO9hikyRXkvp0P1lDE1GMe0Ng8gCUfymBFu6r5O3ENkZ2q2Ii
B2UFYpy1as6N4BykeEr5
=2BdK
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508a7aff.3020...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - without objection versus requiring ACKs

2012-10-26 Thread Scott Kitterman



Bart Martens ba...@debian.org wrote:

On Thu, Oct 25, 2012 at 09:06:34AM -0400, Scott Kitterman wrote:
 Why not start with a without objection standard and see how it
works?

The without objection approach would require a reasonable delay for
people to
raise objections (some say two months).  The ACK/NACK approach allows
to reach
a consensus in a shorter time, so that for obvious cases the salvaging
can
proceed without pointless delay.

No.  Changing 3:1 ACK/NACK to 3 (or some other number) ACKS and no objections 
imposes no such constraint.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/89ce141c-80d9-4e5f-b73b-2089677f2...@email.android.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

2012-10-26 Thread Scott Kitterman



Bart Martens ba...@debian.org wrote:

On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote:
 Gergely Nagy alger...@balabit.hu wrote:
 Ian Jackson ijack...@chiark.greenend.org.uk writes:
  Whether a package is in need of greater attention is not a hard
and
  fast objective thing.  It's to a large part subjective.  Perhaps
the
  maintainer thinks it's more or less fine, or at least low enough
  priority that the problems are tolerable.
 
 Then the maintainer has many options, including but not limited to
 NACK-ing the ITO. One has a lot of possibilities even before it
comes
 to
 filing an ITO.
 
 AIUI, with the current proposal, as long as three DDs think it should
be
 orphaned, the maintainer's objection is irrelevant.

I would send a NACK because the maintainer objects, and I trust other
DDs
subscribed to debian-qa to do the same.  The ITO procedure is not meant
to
replace the TC handling conflicts.

But as written, it does.   It should be changed.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/99822e4d-662e-4589-ae72-5a017906b...@email.android.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Nikolaus Rath

Russ Allbery r...@debian.org writes:
 Michael Gilbert michael.s.gilb...@gmail.com writes:
 On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:

 Okay, well, I guess I return to my previous statement, then.  I don't
 think your proposed solution will work for the more common cases.

 I respect your opinion, so I'm just curious which part do you believe
 won't work in common cases?  It's just applying existing NMU rules with
 a little more liberalism to increase activity in under-maintained
 packages, so I personally can't see where it would break down.

 Well, that's what I was trying to get at: I think your method puts too
 many barriers in the way of someone who wants to take over an effectively
 abandoned package.  It also requires *more* skill than adopting the
 package would otherwise, since you have to be good enough at Debian
 packaging to make minimal chnages within some arbitrary packaging scheme.
 In other words, it requires as much or more skill than doing NMUs, whereas
 adopting a traditionally orphaned package is much easier.

Very much agree. I am much more likely to work on a neglected package if
I can use the tools that I'm familiar with from my own packages. The
prospect of having to reverse engineer the packaging before I can make
any useful changes is very discouraging.

I am *not* a DD, so I think I'm qualified to say that if the goal of the
proposal is to attract new contributors to help with existing packages,
being allowed to change the packaging style is crucial.


Best,

   -Nikolaus

-- 
 »Time flies like an arrow, fruit flies like a Banana.«

  PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6  02CF A9AD B7F8 AE4E 425C


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uglcqzq@inspiron.ap.columbia.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote:
 Le 26/10/2012 08:46, Bart Martens a écrit :
  On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote:
  Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current
  proposal, as long as three DDs think it should be orphaned, the
  maintainer's objection is irrelevant.
  
  I would send a NACK because the maintainer objects, and I trust
  other DDs subscribed to debian-qa to do the same.  The ITO
  procedure is not meant to replace the TC handling conflicts.
  
 
 So why not agree now that the maintainer can veto the process?

Because this would raise the question how long should we wait for the
maintainer to object or to remain silent.  In obvious cases, for example when
the package has clearly not been maintained for years, then three ACKs from DDs
should be sufficient to orphan the package, so that the package can be salvaged
quickly, without pointless delay.  In less obvious cases, for example when the
maintainer objects, I trust the DDs to send NACKs to the ITO, so that the
package is not orphaned forcibly.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026134025.ga17...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

2012-10-26 Thread Scott Kitterman

On Friday, October 26, 2012 01:40:26 PM Bart Martens wrote:
 On Fri, Oct 26, 2012 at 01:58:55PM +0200, Thibaut Paumard wrote:
  Le 26/10/2012 08:46, Bart Martens a écrit :
   On Thu, Oct 25, 2012 at 12:45:21PM -0400, Scott Kitterman wrote:
   Gergely Nagy alger...@balabit.hu wrote: AIUI, with the current
   proposal, as long as three DDs think it should be orphaned, the
   maintainer's objection is irrelevant.
   
   I would send a NACK because the maintainer objects, and I trust
   other DDs subscribed to debian-qa to do the same.  The ITO
   procedure is not meant to replace the TC handling conflicts.
  
  So why not agree now that the maintainer can veto the process?
 
 Because this would raise the question how long should we wait for the
 maintainer to object or to remain silent.  In obvious cases, for example
 when the package has clearly not been maintained for years, then three ACKs
 from DDs should be sufficient to orphan the package, so that the package
 can be salvaged quickly, without pointless delay.  In less obvious cases,
 for example when the maintainer objects, I trust the DDs to send NACKs to
 the ITO, so that the package is not orphaned forcibly.

It seems like an obvious bug in the proposal that I don't understand the 
resistance to fixing.  Rather than trust is won't be a problem, why not fix the 
bug and change it to if there are NACKs, it's a dispute for the tech ctte?

Scott K


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5609089.6aMmCRQnhL@scott-latitude-e6320

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - full maintainer without restrictions

On Fri, Oct 26, 2012 at 09:17:13AM -0400, Nikolaus Rath wrote:
 Russ Allbery r...@debian.org writes:
  Well, that's what I was trying to get at: I think your method puts too
  many barriers in the way of someone who wants to take over an effectively
  abandoned package.  It also requires *more* skill than adopting the
  package would otherwise, since you have to be good enough at Debian
  packaging to make minimal chnages within some arbitrary packaging scheme.
  In other words, it requires as much or more skill than doing NMUs, whereas
  adopting a traditionally orphaned package is much easier.
 
 Very much agree. I am much more likely to work on a neglected package if
 I can use the tools that I'm familiar with from my own packages. The
 prospect of having to reverse engineer the packaging before I can make
 any useful changes is very discouraging.
 
 I am *not* a DD, so I think I'm qualified to say that if the goal of the
 proposal is to attract new contributors to help with existing packages,
 being allowed to change the packaging style is crucial.

I strongly agree with what Russ Allbery and Nikolaus Rath wrote above.  When a
package is clearly not maintained, then it should be orphaned, so that a new
contributor can become full package maintainer without any restrictions on the
allowed changes.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026135454.gb17...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Ian Jackson

Russ Allbery writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 I think orphaned packages are one of our best opportunities to attract new
 developers, rather than serving as an additional obligation for existing
 developers.  [etc.]

Thanks for that excellent analysis.  You have convinced me that the
salvaging process should countenance orphaning packages, as well as
(or perhaps instead of) allowing a different maintainer to take them
over.

I still think that the right standard is no objection rather than
collecting some explicit number of acks.  In particular I don't think
any number of acks ought to override a nack from the existing
maintainer.

And if we're allowing any single nack to stop it, then I don't see
what requiring ack(s) buys us.  It would force the salvager to make
explicit their criticisms of the package and hence the maintainer.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20618.41869.34617.514...@chiark.greenend.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - skipping pointless delay

2012-10-26 Thread Ian Jackson

Bart Martens writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages - skipping pointless delay):
 On Thu, Oct 25, 2012 at 02:50:46PM +0100, Ian Jackson wrote:
3. Wait for objections
 
 For how long ? The proposal includes collecting ACKs so that any pointless
 delay can be skipped, resulting in the package being salvaged sooner.

I was thinking some weeks.

I do think this delay is essential, not pointless.  It is there to
allow a maintainer who wishes to resist the orphaning to do so.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20618.42165.454144.292...@chiark.greenend.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Michael Gilbert

On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
 On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
 I think this is where language is important.  In my opinion, the term
 adoption will continue to mean taking on full responsibility for a
 package as its new maintainer.  The term salvage, in my opinion, we
 can define as a process for becoming a co-maintainer on a package with
 a long-term possibility of becoming its maintainer.

 This is an unhelpful redefinition of the term.  The term salvage was
 introduced to *mean* orphaning/adopting a package when the maintainer is no
 longer fulfilling their responsibilities.

Why do we need two different terms defined as the exact same thing?
In other words, if both salvaging and orphaning mean the same thing,
then what's the point of salvaging?

In my opinion salvaging (under the above definition) is something that
would be able to happen a lot sooner than orphaning because it is
initial a co-mainainter process, rather than a maintainer replacement
process.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MNYTDBqy6do+=flacn+srnvzfhosbbj3inou4qdad5...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - goal

2012-10-26 Thread Thomas Goirand


On 10/26/2012 05:07 PM, Bart Martens wrote:

People interested in salvaging an unmaintained package are discouraged by the
current procedures.  The new procedure is meant to add a lightweight procedure
to mark unmaintained packages as orphaned, so that anyone interested can adopt
them without needless delay.  Basically the goal is to increase speed in
getting packages salvaged.


Thanks, this is much more clear now.

After more thoughts, I probably agree such a proposal.

Probably, Steve Langasek is right in that it shouldn't be such a big deal
to find few DDs to vote for the salvaging...

And if I understand well, this procedure is *on top* of what we have
currently for orphaning anyway (eg: QA team orphaning MIA maintainers,
and the tech. commity), right?

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/508ae1de.4080...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react

2012-10-26 Thread Dmitry Smirnov

On Fri, 26 Oct 2012 16:56:02 Bart Martens wrote:
 On Fri, Oct 26, 2012 at 08:06:57AM +1100, Dmitry Smirnov wrote:
  If bug was unanswered for let's say two months the package is free to
  orphan
 
 Some prefer no delay, some prefer one month, some prefer two months.  I
 originally wanted one month, but I got convinced by others to drop the
 delay.

For merely orphaning minimising delay is not too important because if there is 
an active maintainer ready to adopt the package it is a salvaging procedure.
For example if package is not maintained for years we can certainly wait for a 
month or two before orphaning even though there may be no need to wait that 
long.

 Now my opinion is that I trust the DDs reviewing the ITO to judge
 the package's situation before sending an ACK or NACK.  One possible
 judgement on an ITO can be NACK until 2 months have passed or the
 maintainer has agreed to orphan the package.  Another possible judgement
 on an ITO can be ACK because this package has clearly not been maintained
 for years, so please proceed without further delay.

I'm convinced that acknowledging is ambiguous and unnecessary.
First, what do you expect DDs to acknowledge -- the fact that package needs 
attention (this should be obvious already) or their approval of salvager?

Assuming they're not familiar with salvager's work getting and acknowledgement 
might be as hard as finding a sponsor.

Also this will rely on developers constantly reviewing ITA requests in other 
people's packages.

Most certainly this will increase delay and the complexity of the procedure 
which might work only for popular packages with high visibility.
I think in usual case we can expect no response for salvaging requests.

Also without timed delay acknowledgements may be very unfair if few DDs voted 
for salvaging and therefore salvager got a green light without waiting for 
possible objections.

Michael Gilbert's proposal to start salvaging with NMUs makes more sense as it 
allows to proceed gently and demonstrate motivation and willingness to work on 
the package. From non-DD prospective couple of successful NMUs will confirm 
salvaging intent and capacity better than random ACKs.

Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201210270747.48293.only...@member.fsf.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - maintainer's objection

2012-10-26 Thread Dmitry Smirnov

On Sat, 27 Oct 2012 00:40:26 Bart Martens wrote:
  So why not agree now that the maintainer can veto the process?
 
 Because this would raise the question how long should we wait for the
 maintainer to object or to remain silent.  In obvious cases, for example
 when the package has clearly not been maintained for years, then three
 ACKs from DDs should be sufficient to orphan the package, so that the
 package can be salvaged quickly, without pointless delay.  In less obvious
 cases, for example when the maintainer objects, I trust the DDs to send
 NACKs to the ITO, so that the package is not orphaned forcibly.
 
I recognise fundamental injustice here. If you expect ACKs then objections 
should be allowed as well but there might be unlikely situation when salvaging 
proceed after few ACKs without waiting for any further objections.
I fear of conflicts it may create.

Any form of agreement require fair amount of time for all parties to respond.

If the matter cannot wait one can use NMU during transition of package 
ownership. This is in harmony with what Michael Gilbert proposed.

In clear case when waiting is impossible without hurting the package state,  
DDs can take over without delays and take responsibility for future issues 
with maintainer.

In any case we want salvaging to be documented in corresponding bug report.

Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201210270800.17329.only...@member.fsf.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Dmitry Smirnov

On Sat, 27 Oct 2012 01:51:57 Ian Jackson wrote:
 I still think that the right standard is no objection rather than
 collecting some explicit number of acks.  In particular I don't think
 any number of acks ought to override a nack from the existing
 maintainer.
 

Indeed. I think lack of enough acknowledgements can make process even slower. 
Acknowledgements will require developers to judge on other developer's 
intentions and I'm not sure wherever ACKs meant to approve the fact that 
salvaging is needed or to approve salvager and express trust to her/his 
capacities as maintainer. 
Probably not many people will find this role attractive so we can expect a 
lack of acknowledgements.


 And if we're allowing any single nack to stop it, then I don't see
 what requiring ack(s) buys us.  It would force the salvager to make
 explicit their criticisms of the package and hence the maintainer.

I'm sure salvaging intent can be neutral or positive. It is merely a 
declaration of intent to help maintaining a package. 
When original maintainer is responding it is effectively a co-maintainership 
offer. Only when maintainer is not responding it becomes de-facto a 
declaration of adoption intent (ITA) so perhaps word savlaging is not 
perfect to express the idea.
There is nothing to suggest that salvager has to express any criticism.

As far as I can remember some adoption experiences of mine I was sincerely 
grateful to previous maintainers for their work.

Regards,
Dmitry.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201210270839.54287.only...@member.fsf.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote:
 On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
  On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
  I think this is where language is important.  In my opinion, the term
  adoption will continue to mean taking on full responsibility for a
  package as its new maintainer.  The term salvage, in my opinion, we
  can define as a process for becoming a co-maintainer on a package with
  a long-term possibility of becoming its maintainer.

  This is an unhelpful redefinition of the term.  The term salvage was
  introduced to *mean* orphaning/adopting a package when the maintainer is no
  longer fulfilling their responsibilities.

 Why do we need two different terms defined as the exact same thing?
 In other words, if both salvaging and orphaning mean the same thing,
 then what's the point of salvaging?

They don't mean the same thing.  Maintainers orphan their own packages;
adopters adopt orphaned (or RFAed) packages.  Salvaging is the process of
identifying packages that *should* be orphaned in the *absence* of the
maintainer.

 In my opinion salvaging (under the above definition) is something that
 would be able to happen a lot sooner than orphaning because it is
 initial a co-mainainter process, rather than a maintainer replacement
 process.

Comaintenance is irrelevant to the question at hand.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Michael Gilbert

On Fri, Oct 26, 2012 at 6:06 PM, Steve Langasek vor...@debian.org wrote:
On Fri, Oct 26, 2012 at 03:10:30PM -0400, Michael Gilbert wrote:
On Fri, Oct 26, 2012 at 12:51 AM, Steve Langasek wrote:
On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
I think this is where language is important. In my opinion, the term
adoption will continue to mean taking on full responsibility for a
package as its new maintainer. The term salvage, in my opinion, we
can define as a process for becoming a co-maintainer on a package with
a long-term possibility of becoming its maintainer.

This is an unhelpful redefinition of the term. The term salvage was
introduced to *mean* orphaning/adopting a package when the maintainer is no
longer fulfilling their responsibilities.

Why do we need two different terms defined as the exact same thing?
In other words, if both salvaging and orphaning mean the same thing,
then what's the point of salvaging?

They don't mean the same thing. Maintainers orphan their own packages;
adopters adopt orphaned (or RFAed) packages. Salvaging is the process of
identifying packages that *should* be orphaned in the *absence* of the
maintainer.

We already orphan packages without the maintainer's consent, and it's
already called orphaning.

Salvaging is still undefined; until we come to consensus on its
definition. Some vague notion of the idea was started at debconf, and
we should be willing to be open to discussing the best definition that
achieves the most optimum result. If we limit the scope of our
thinking, then we box ourselves into a much smaller and likely less
optimum set of solutions.

So let's keep the term's definition open for debate.

In my opinion salvaging (under the above definition) is something that
would be able to happen a lot sooner than orphaning because it is
initial a co-mainainter process, rather than a maintainer replacement
process.

Comaintenance is irrelevant to the question at hand.

Again, co-maintenance is a proposed solution to the question at hand,
so it is quite apropos to the discussion. There is now vast evidence
within the archive that co-maintained packages tend to be much
healthier than strongly maintained ones. This adds an additional
avenue for becoming a co-maintainer while injecting health into often
neglected parts of the archive.

Wrapping up, I'd like to state my concern about how we continue to
allow a certain culture of strong voices to effectively limit the
scope of discussions. This isn't how a meritocracy should work. I've
developed a solution, shown that it works, and now I would like to
document it to make it available to help others as a guide in similar
situations. Criticism from those that haven't demonstrated their own
solutions should fail in a real meritocracy.

Best wishes,
Mike

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=MN+uaGrAsSvPjs5bMt_ty4FBr=fsh+6++03jo-wnrr...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote:

 We already orphan packages without the maintainer's consent, and it's
 already called orphaning.

 Salvaging is still undefined

No, it is not.  The definition was clear from the first use of the term.
Stop trying to redefine it.

 So let's keep the term's definition open for debate.

Or, find something useful to do with yourself instead.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Michael Gilbert

On Fri, Oct 26, 2012 at 8:19 PM, Steve Langasek wrote:
 On Fri, Oct 26, 2012 at 07:33:27PM -0400, Michael Gilbert wrote:

 We already orphan packages without the maintainer's consent, and it's
 already called orphaning.

 Salvaging is still undefined

 No, it is not.  The definition was clear from the first use of the term.
 Stop trying to redefine it.

 So let's keep the term's definition open for debate.

 Or, find something useful to do with yourself instead.

This is an unkind insult.  I am defending my dissertation on Monday,
so I have more than enough to do right now.  That's something quite
important to me, and I am taking time away from that to make a
passionate case for something else that I believe in.  I've also spent
a reasonable amount of time on Debian over the past few weeks, but I
prefer humility, so I won't drone on about that.

Anyway, deployment of an abusive ad hominem is generally seen as a
concession of the argument to the opposing side of the discussion, so
I think that puts a rather sour note and an end to this particularly
unproductive sub-thread.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MM+SgEwoJ2frbt7N=6vpffkxrto84o8st822oxx3p-...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Hi Zack,

On Tue, Oct 23, 2012 at 11:19:34PM +0200, Stefano Zacchiroli wrote:
 On Tue, Oct 23, 2012 at 05:19:37PM +, Sune Vuorela wrote:
  1) report a bug 'should this package be orphaned?' against the package
  with a more or less defalut templated text and a serious severity
  2) sleep 4*7*24*3600
  3) if bug silent, orphan it (and maybe adopt it)

 According to the interpretation I suggested in [1], this is actually the
 degenerate case of the proposal that is being discusses. If no-one ACKs
 --- which IMHO is what would happen by default anyhow in quite a number
 of cases --- and if the interested person chooses to sleep 4*7*24*3600,
 your point (3) will be the natural conclusion.

 [1]: https://lists.debian.org/debian-devel/2012/10/msg00471.html

 Otherwise stated, the proposal is *exactly* what you're proposing, plus
 some consensus-based best practice to deal with the missing else
 branch of your point (3).

 I'm convinced that else branch will be quite uncommon (unless
 mandated, see below), and that ACKs/NACKs are just a different way of
 putting what already happens when we discuss on a mailing list the
 salvation of a package.

 But you could either have the unsupervised if branch, or what Steve
 suggests in https://lists.debian.org/debian-devel/2012/10/msg00475.html
 i.e. maintainers explicitly looking for ACKs to support their action as
 a requirement to complete the procedure. It has its merits (e.g. a
 surefire extra review layer). But if you consider ACKs as votes, as
 Scott put it, and you see that as bad, you won't accept this.

 So, can people comment on Steve's proposal?

 Similarly, Steve: can you comment on the criticism of voting on
 packages, why don't you see it as a problem?

Voting implies that the majority rules.  I am certainly not in favor of
any sort of voting mechanism where we tally those in favor and those against
orphaning the package.  The standard I expect to see applied here is
*consensus*, not voting.

A lone voice in the wilderness, with no one saying either yay or nay, is not
a consensus.

20 DDs saying the package should be orphaned, and the maintainer saying it
shouldn't (or some other DD saying it shouldn't), is not a consensus.

We should not need a heavyweight process here at all.  It seems that some of
the participants in this discussion are unaware that some of us are
subscribed to debian-qa specifically *for* dealing with questions of
unmaintained packages (MIA, salvaging, or coordination of QA uploads).  The
only real requirements for such a process are:

 - Make an appropriate effort to notify the maintainer of your concern
 - Make the rest of Debian aware of your plans in the designated public
   forum
 - Get some (small) number of your peers to agree via public review that
   this is the correct course of action for the package in question
 - Wait a reasonable amount of time for objections
 - If consensus is not reached, refer to the TC

And if my frustration is showing through in this thread, it's because *I am
not proposing a new process*.  This was the process that was used for
*years* via debian-qa.  But, evidently because this process was never
adequately codified in the developer's reference, here we are now having a
long, drawn-out discussion not only about reinventing the wheel but also
about what we should define a wheel to be, and entertaining solutions in
search of a problem from people who have never used that existing and proven
process.


It is not going to be hard to get the necessary handful of acks when
following an appropriate process, nor is it hard to wait a fixed period to
give time for any nacks to arrive before taking action on a package to be
salvaged.  A package salvage is NOT an urgent matter, ever.  Urgent matters
should be dealt with by NMU.  Salvaging is for longer-term questions of
maintainership, and where maintainership is concerned we should be duly
respectful of the existing maintainer's committment to Debian instead of
enacting a buggy process that allows for a maintainer to come back from a
vacation/hospital stay/computer outage to find her package has been
rewritten without so much as a thank you.  If you really intend to commit to
maintaining the package for the foreseeable future, you can bloody well sit
on your hands for a month and wait for the maintainer to react first.


So in sum, I'm broadly in favor of Lucas's patch, except:

 - A single nack is evidence of a lack of consensus.  If consensus can't be
   achieved, it should be referred to the TC instead of making a political
   mess of things for the rest of the project.
 - There does need to be a mandatory minimum waiting period.  This process
   is going to be seen as blessed via the devref; we should not be
   blessing a process with an obvious bug that permits abuse by a DD and
   three of her friends pulling off a hostile takeover of a package before
   anybody has a chance to say no.  Even though such an act *can* be
   appealed to the TC, we

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 09:58:54PM +0100, Ben Hutchings wrote:
 On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote:
 [...]
  All the pings in the world won't help if you are sending them via
  a path that discards them.  I know several large US ISPs that automatically
  reject what they consider SPAM without the customer's knowledge.  If
  the sender of the ping is on a SPAM list for one of them, the ping
  will never get to the maintainer, and *no one* will know.
  (From personal experience I can tell you mail from the Debian list addresses
  does get caught in these SPAM filters and no, the ISPs won't change the
  policy.)

 Given that Debian lists are 'open' and haven't always had good spam
 filtering, it is not too surprising that they are sometimes treated
 as spam sources.

 In general, anything that needs to reach the maintainer(s) of a
 specific package should not be sent to the maintainer address, not to
 some general mailing list.  (The maintainer address may itself be a
 mailing list, but if the maintainer(s) no longer read mail sent to it
 then that's a further reason to orphan/salvage the package!)

I strongly recommend that such mails always be sent via the BTS.  This
ensures that the mail follows the same path as bug mail, and avoids getting
tripped up on filtering bugs that don't actually impact the maintainers
ability to carry out their responsibilities as maintainer.

I.e.: maintainers don't have a responsibility to reply to private mails.
They do have a responsibility to act on bug reports.  So if you send it via
the BTS, and the maintainer claims afterwards that they didn't receive the
mail, it's clear where the responsibility lies.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote:
 On 10/25/2012 02:48 AM, Steve Langasek wrote:
 On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote:
 I remember when I started a thread about 6 months ago,
 willing to take over maintainership of a clearly unmaintained
 package (since then, all other packages of this maintainer
 have been orphaned...). It (unwillingly) created a huge thread
 about when and when not taking over a maintainer, with some
 of the thread participant having no clue what so ever if the old
 maintainer was still alive or not.
 Do you also remember WHY it created a huge thread?

 It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS
 ASSENT.

 What? Could you explain what I did? Silence from who? The old maintainer?
 Other DDs reading the list?

  So, if nobody objects within the next following 2 or 3 days, and if Jack
  doesn't show up and oppose to this procedure, we'll do that.

https://lists.debian.org/debian-devel/2012/05/msg01362.html

That's equating silence with assent.

Perhaps that wasn't what you intended, but that is what you said, and that
was a factor in the resulting blow-up.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Fri, Oct 26, 2012 at 06:24:24PM -0700, Steve Langasek wrote:
 So in sum, I'm broadly in favor of Lucas's patch, except:
 
  - A single nack is evidence of a lack of consensus.  If consensus can't be
achieved, it should be referred to the TC instead of making a political
mess of things for the rest of the project.

I fully agree with that.

  - There does need to be a mandatory minimum waiting period.  This process
is going to be seen as blessed via the devref; we should not be
blessing a process with an obvious bug that permits abuse by a DD and
three of her friends pulling off a hostile takeover of a package before
anybody has a chance to say no.  Even though such an act *can* be
appealed to the TC, we shouldn't put ourselves in the situation that it
has to be.

I won't object to adding a mandatory minimum waiting period, although in
some obvious cases it will lead to a pointless delay.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121027041826.ga5...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-26 Thread Uoti Urpala

Steve Langasek wrote:
 On Thu, Oct 25, 2012 at 05:17:10PM +0800, Thomas Goirand wrote:
  On 10/25/2012 02:48 AM, Steve Langasek wrote:
  On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote:
  I remember when I started a thread about 6 months ago,
  willing to take over maintainership of a clearly unmaintained
  package (since then, all other packages of this maintainer
  have been orphaned...). It (unwillingly) created a huge thread
  about when and when not taking over a maintainer, with some
  of the thread participant having no clue what so ever if the old
  maintainer was still alive or not.
  Do you also remember WHY it created a huge thread?
 
  It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS
  ASSENT.

This claim seems to be false.

  What? Could you explain what I did? Silence from who? The old maintainer?
  Other DDs reading the list?
 
   So, if nobody objects within the next following 2 or 3 days, and if Jack
   doesn't show up and oppose to this procedure, we'll do that.
 
 https://lists.debian.org/debian-devel/2012/05/msg01362.html
 
 That's equating silence with assent.
 
 Perhaps that wasn't what you intended, but that is what you said, and that
 was a factor in the resulting blow-up.

The mail also talked about we and us (eg: the PKG-PHP Pear team).
That implies he already had the support of someone else, and they could
have sent ACKs if needed (but there was no need to, as he wanted to know
whether anyone opposed; the number of me toos didn't matter). None of
the mails starting the discussion questioned whether the number of
people in favor was sufficient.



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1351312739.10719.19.camel@glyph.nonexistent.invalid

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Игорь Пашев

2012/10/25 Steve Langasek vor...@debian.org

  It may just mean you've managed to send
 your request to the wrong place


As I see, almost all debian guys are so courteous that they point to the
right place.

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Thibaut Paumard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 25/10/2012 01:51, Steve Langasek a écrit :
 On Thu, Oct 25, 2012 at 08:38:19AM +0900, Charles Plessy wrote:
 Le Wed, Oct 24, 2012 at 09:46:08PM +, Clint Adams a écrit :
 On Wed, Oct 24, 2012 at 11:48:12AM -0700, Steve Langasek
 wrote:
 Silence is not assent.  That thread blew up because you
 proposed a *broken*
 
 No, silence is an indication that you don't deserve any
 decision-making power.
 
 while in general one can not make interpretation for silence, in
 this particular case, I think that the absence of any reaction to
 the proposition to orphan a package is actualy a clear
 demonstration that the package is orphan.
 
 No.  We're talking here about silence *from the entire Debian
 developer community* in response to a call for orphaning.  That
 says nothing about whether the package is orphaned.  It may just
 mean you've managed to send your request to the wrong place (or
 gotten it stuck in a mail queue somewhere).
 

Hi Community,

Is there anyone here who would actually bother (n)acking if I were to
propose orphaning, say, yorick-cubeview (assuming it was not one of
mine)? If I were to suddenly disappear from the scene, I 'd be quite
happy if just one DD would care enough to orphan it for me, not to
mention  adopting...

Besides, orphaning is just a stage in the lifetime of a package. It's
not like it will need to see a shrink for the rest of its life to deal
with abandonment issues. The *original* maintainer can very easily
adopt it back, the same day or the next month.

So yes, I say long silence from the entire community *including the
package maintainer(s)* probably means it's safer to orphan the package
than not. I would probably send a few pings during the one month
period though. I would also be careful during vacation periods,
especially if the maintainer is not a DD and therefore can not easily
announce VAC.

Regards, Thibaut.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQiO90AAoJEJOUU0jg3ChAEJoP/0fchAceVsgMfZ0Zwo1ixzYk
jPwXegTtxDGOBJ2ZrYJPYNRNv6I8pjDo4w64yK7kswgf4i3ryfuS7smHTobySETH
EMuOkS5CV2c4Ljo9icKZmygkgo5rcMcx6OGbURkz0EcnaPHIglAssi8FkZ734aL7
uMPDX+ASyGFcBoY/D/5rRBErEQLDa5c2kSgqr7C4sWLP/ddF4Vsw0lUBGnmtkbJ3
JUKKI82H8JhMqeERIys75Oq1jMXC+ZXikbUJWP2Z7sKVHjTAFD5HvbK1uQh6J/l/
6siKZdnfwb6KyrATQUld6wdwUwZVttP5XPq6PK+YTO0tUUrntEDYAcDWUkyD6cy8
huXZc3dmOOF1Ns8fDFTxUgHPg9OHtH17U2bRSletPhEIYdKS82/vyLis+3WEpd6c
3sIXS3nibroFlcN12JtHtMaVuaZkG2F4AbDkvOFOETV326QlUvrKZf0dYMiIWNK4
5boErI4Pp7VceOvKv1WYlXPEzPyd1v8AFnMao8ZbYKB/jXLkdmIgRCO2JI6yPHT7
DqWOXaJK1AlZN51ojtePwkqp6S0rFJ/eAH7hNtYljFwePcYu2xjokTflt3rX7CDk
WJFpW7lkhm3l3H9jHnF7wDXVsWhv1QBCukp0kB8kzw+vwOaOzSxyDFoIYRB93+3s
tsXfoBTij5KATcz/Cy/m
=zPJe
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/5088ef74.8050...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Lucas Nussbaum

On 24/10/12 at 08:17 -0400, Scott Kitterman wrote:
 That could work either way.  If you're in such a rush to build consensus you 
 could change 3/1 ACK/NACK ratio to without objection (objections  result in 
 disputes resolved by the tech ctte) and have a +1 from me.
 
 The problem is that once in place these rules are rather harder to change.  
 While you have in mind a certain set of packages this rule should be applied 
 to, there's nothing preventing it from being applied in incorrect cases.
 
 The popularity contest aspect of the current rule creates a risk that 
 maintainers that make unpopular, but technically correct, choices will have 
 their packages orphaned out from under them.

I am quite sure that we will find many DDs (me included) willing to NACK
all proposals of stealing packages from technically-correct, active,
but unpopular maintainers. And you can even drop technically-correct
from my sentence. The goal of this proposal is not to substitute for the
technical committee.

Really, I don't see how a cabal could abuse this recommended procedure without
enough people to stop it noticing.

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025081548.ga1...@xanadu.blop.info

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Lucas Nussbaum

On 23/10/12 at 17:19 +, Sune Vuorela wrote:
 On 2012-10-23, Lucas Nussbaum lu...@lucas-nussbaum.net wrote:
  Hi,
 
  Here is an attempt at summarizing  building a proposal out of the
  Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal
  thread that was started at [1].
 
 Some years ago, people used a much simpler process. Why complicate
 matters?
 
 1) report a bug 'should this package be orphaned?' against the package
 with a more or less defalut templated text and a serious severity
 2) sleep 4*7*24*3600
 3) if bug silent, orphan it (and maybe adopt it)

Funnily, I was the one that initiated that process (see thread at [1]).
[1] http://lists.debian.org/debian-devel/2007/10/msg00406.html

I used that process for quite a few packages (but not recently). However
I see two problems with it:
- it requires quite a lot of self-confidence. I find third-party reviews
  and ACKs a good way to reinforce the feeling that the orphaning is the
  right thing to do. Note that it's often users who detect unmaintained
  software. With the ACK-based process, it's possible for a user to
  initiate the process. I fear that, if we go for a process without
  third-party reviews, people (esp. users who are not DDs) will lack the
  confidence needed to initiate the process.
- it takes a long time. For simple  obvious cases, waiting for a month
  is a bit annoying when someone is willing and ready to take over
  maintenance. it's important to use contributors motivation while it's
  high.

But anyway, I would not oppose adding something such as:
  If you followed all the steps above, waited for a month, did not
  receive enough ACKs, but nobody NACKed, you can still proceed.

However, so far, it seems that the discussion is split between people
that think it would work, and people that think it would not work.
Maybe we could try for a few months, and if it does not work, fix it?

Lucas


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025081009.ga1...@xanadu.blop.info

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Thomas Goirand


On 10/25/2012 02:48 AM, Steve Langasek wrote:

On Thu, Oct 25, 2012 at 01:57:12AM +0800, Thomas Goirand wrote:

I remember when I started a thread about 6 months ago,
willing to take over maintainership of a clearly unmaintained
package (since then, all other packages of this maintainer
have been orphaned...). It (unwillingly) created a huge thread
about when and when not taking over a maintainer, with some
of the thread participant having no clue what so ever if the old
maintainer was still alive or not.

Do you also remember WHY it created a huge thread?

It created a huge thread BECAUSE YOU HAD PROPOSED TO TREAT SILENCE AS
ASSENT.


What? Could you explain what I did? Silence from who? The old maintainer?
Other DDs reading the list?


That thread blew up because you proposed a *broken*
process for trying to orphan a package that didn't require you to establish
a consensus


Call me stupid, but I don't get it again. Are you saying that I should have
silently taken over maintainership of the package (eg: hijacking it)?

I didn't propose any process, I asked the crowd for anyone to eventually
infirm my view that the maintainer was MIA. It blew up because people
thought I was changing the process, which I was *not*.

Fine, if getting a consensus is too much work for you, feel free to 
refer all maintainer change requests directly to the Technical 
Committee instead. 


I didn't write it was too much work for [me] ...

This type of sentence, is making a caricature of what I wrote and emptying
all my words from any kind of sense. This is *not* going to help in any 
way...


Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50890396.3010...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Thomas Goirand


On 10/25/2012 07:51 AM, Steve Langasek wrote:
No. We're talking here about silence *from the entire Debian developer 
community* in response to a call for orphaning. That says nothing 
about whether the package is orphaned. It may just mean you've managed 
to send your request to the wrong place (or gotten it stuck in a mail 
queue somewhere). 

It would have been wrong if it was the *only* course of action that I did.
Which was not. I mailed the old maintainer, waited for a long time, then
finally asked the QA team to orphan the package, which is what is
currently required. The mail to -devel was just an extra precaution, but
(with all due respect) seeing the kind of reaction like yours, probably,
I shouldn't have do it at all...

Cheers,

Thomas


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50890518.7070...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Steve Langasek vor...@debian.org writes:

 So, what will you do if:
 - previous maintainer goes MIA
 - Somebody wants to hija^W salvage the package and starts the procedure
 - Nobody votes for this to happen...

 Should we then leave the package forever unmaintained?
 I don't think this is reasonable...

 And I don't think this is a realistic scenario.  Why can't you find N other
 DDs who agree with you that the package should be taken over?  This is not a
 high bar.  I don't really have any sympathy for the argument that the entire
 Debian project might decide not to care about the package you're concerned
 about and therefore you need to take matters into your own hands and take it
 over.

Not a high bar, but still far more work than it needs to be. Salvaging
is meant for cases where it is desperately needed, which, I believe, are
quite clear cases. I find it unreasonable to demand ACKs, when one
already went to great lengths to solve the issue without taking over
maintainership.

If there's dispute later, any change can be reverted then, or taken to
the tech-ctte. I do not see any reason to make the process long and
tedious, we should *NOT* punish the salvager for trying to bring a
package back to life. We should make that as easy and painless as
possible, once other options failed.

Would a mistake happen, it can and should be corrected, but that should
be the exception, not the norm. And as such, the process should not
follow the exceptional cases, but the most common ones.

So while I do agree that ACKs/NACKs can be helpful, making them
mandatory would - I believe - be counter productive. If noone cared
enough to respond with neither ACK nor NACK, go ahead. Not voting means
one does not care. It is entirely possible that the vast majority of the
project won't care about a particular package, and that should not be an
obstacle on the path of salvaging it.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ugmbxii.fsf@algernon.balabit

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Steve Langasek vor...@debian.org writes:

 On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  I disagree on this point.  If you can't get anyone to ack that you should 
  go
  ahead with the orphaning, then the system is not working as designed and
  consensus has not been achieved.  It's then incumbent on the person looking
  to orphan the package to rattle the cage and get developers to pay
  attention.

 On the other hand, it is already hard to find people willing to review
 other peoples work. Mandating acks means trusting that there will be
 enough manpower to review something potentially unknown. I can't see
 that happening reliably. It also makes the process a whole lot more
 complicated than it needs to be,

 No, it makes the process based on *consensus*, which is a minimum
 requirement.

It also means that the salvager has to do more work. By the time we get
to salvaging, other means of getting the package fixed/updated have
already been exhausted - that's quite a lot of work already, and by that
time, it should be very clear that salvaging is the way to go forward.

I do agree that the salvager should seek consensus, and should make a
reasonable effort to get some feedback on his/her intention, BUT I would
not make that mandatory (seeking acks - yes; not being able to go
forward until N acks - no), as that will stall the process for far too
long in case of less popular packages (and as far as I see, those less
popular packages would benefit most from the salvaging process).

THAT is what I'm concerned about.

And seriously, if noone ACKs or NACKs a salvaging proposal for an
extended period of time, to me, that means noone cares enough. If noone
cares, noone minds, then I would put my trust behind the developer, to
know what he's doing, and let him proceed. Would a mistake be made, that
can always be corrected.

 which in turn allows the package to suffer unmaintainance longer,
 decreasing the distributions overall quality.

 As said elsewhere in the thread, the process needs to be easy and
 efficient. Hunting ACKs is neither easy, nor efficient.

 The debian-qa list served this purpose fine for *years*.  It's not
 acceptable to use handwavy assertions about manpower to justify an
 antisocial process.

If the debian-qa list continues to serve this purpose well, then there
is no issue: we'll never see the case I'm worried about, and I'll be the
happiest person on earth.

If we do end up in such situations, though...

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqyeaie2.fsf@algernon.balabit

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Bart Martens ba...@debian.org writes:

 On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
 Steve Langasek vor...@debian.org writes:
 
  On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
   4. When/if consensus has been reached, the package can be orphaned by
  retitling and reassigning the ITO bug accordingly.
 
  I fear a bit the situation nobody care enough to comment, being
  interpreted as lack of consensus. But I do think in that case we should
  _eventually_ allow the orphaning to happen (after all 1/0  3/1 ACK/NACK
  /joke).
  Any suggestion on how to word that properly, without adding yet another
  timeout rule carved in stone?
 
  I disagree on this point.  If you can't get anyone to ack that you should 
  go
  ahead with the orphaning, then the system is not working as designed and
  consensus has not been achieved.  It's then incumbent on the person looking
  to orphan the package to rattle the cage and get developers to pay
  attention.
 
 On the other hand, it is already hard to find people willing to review
 other peoples work. Mandating acks means trusting that there will be
 enough manpower to review something potentially unknown. I can't see
 that happening reliably.

 I think that sufficient DDs will review the ITOs.  Note that most work is
 already done by the ITO submitter.  Sponsoring a package at mentors (review
 other peoples work) is, in my opinion, much more work than reading an ITO and
 sending an ACK.

On the other hand, ACKing an ITO is much more responsibility, becasue
it's not only about a package, but about taking over a package too. An
ITO will also contain quite a lot of info about previous attempts at
updating the package - that's not simple to review either. It is less
technical too, which can be off-putting to some.

 It also makes the process a whole lot more
 complicated than it needs to be, which in turn allows the package to
 suffer unmaintainance longer, decreasing the distributions overall
 quality.

 It's not so complicated to find three DDs to agree with the ITO.

Not terribly so, perhaps. But if the salvager has already gone to great
lengths to save a package, pushing even more work on him is not going to
help.

(Mind you, I'm not against the ACK/NACK system, I'm only arguing for
being able to proceed without N acks after a reasonable amount of time.)

 As said elsewhere in the thread, the process needs to be easy and
 efficient. Hunting ACKs is neither easy, nor efficient.

 The proposed text is quite easy, in my opinion.

Indeed, it is. Partly because as far as I understand it, it only
recommends a 3/1 majority, and does not demand it. That's perfectly
fine.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87sj92ahzh.fsf@algernon.balabit

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Andreas Tille

On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
 However, so far, it seems that the discussion is split between people
 that think it would work, and people that think it would not work.
 Maybe we could try for a few months, and if it does not work, fix it?

+1

Kind regards

   Andreas. 

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025125937.gc30...@an3as.eu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Scott Kitterman

On Thursday, October 25, 2012 10:15:48 AM Lucas Nussbaum wrote:
 On 24/10/12 at 08:17 -0400, Scott Kitterman wrote:
  That could work either way.  If you're in such a rush to build consensus
  you could change 3/1 ACK/NACK ratio to without objection (objections 
  result in disputes resolved by the tech ctte) and have a +1 from me.
  
  The problem is that once in place these rules are rather harder to change.
   While you have in mind a certain set of packages this rule should be
  applied to, there's nothing preventing it from being applied in incorrect
  cases.
  
  The popularity contest aspect of the current rule creates a risk that
  maintainers that make unpopular, but technically correct, choices will
  have their packages orphaned out from under them.
 I am quite sure that we will find many DDs (me included) willing to NACK
 all proposals of stealing packages from technically-correct, active,
 but unpopular maintainers. And you can even drop technically-correct
 from my sentence. The goal of this proposal is not to substitute for the
 technical committee.
 
 Really, I don't see how a cabal could abuse this recommended procedure
 without enough people to stop it noticing.

It may not be the goal of this proposal to substitute for the technical 
committee, but, in part, it would.  If there is a 3:1 dispute over if a 
package should be orphaned, this process would take that dispute out of the 
hands of the technical committee because the voting ratio was adequate.

I fundamentally disagree with the idea of a popularity contest over the 
adequacy of package maintenance.  In practice, I think people will very rarely 
object when packages are clearly not maintained, so the practical difference 
between 3:1 ratio and without objection or go to the technical committee is 
not much.  Where I believe it will make a difference is in preventing 
misapplication of this process, particularly trying to resolve social issues 
through a process that is supposed to be technical.

Why not start with a without objection standard and see how it works?  If it 
doesn't work, the consequence would be most work for the technical committee.  
If they complain/can't keep up, then we could look into a voting alternative.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Scott Kitterman writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 Why not start with a without objection standard and see how it
 works?

I absolutely agree with this.

If we adopt a without objection standard then the whole process can
be a lot simpler too.  There is no need for acks if any one nack is
sufficient to stop the process.

I'm also not that keen on the idea that the outcome is to orphan the
package.  The salvager should surely be adding themselves as an
Uploader.

So I would have this process

  1. Package is in the salvager's opinion in need of substantial and
 important attention; maintainer has been inactive on this
 package, and in need of help with it, for some time.
 It doesn't need to be an objective criterion.

  2. Notify various places (-devel and the BTS, at least)

  3. Wait for objections

  4. If no objections, add salvager to Uploaders.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20617.17334.664111.94...@chiark.greenend.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Andreas Tille writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
  However, so far, it seems that the discussion is split between people
  that think it would work, and people that think it would not work.
  Maybe we could try for a few months, and if it does not work, fix it?
 
 +1

I don't think this is a good idea because it may actually restrict
rather than empower.  At the moment much of the stuff in this area is
what you can get away with.  If you can say I asked around and made
sure everyone was aware, and it was clear no-one was objecting then
anyone who comes along later with a grievance is going to get short
shrift from the rest of the project.

Whereas now we're proposing codifying a policy that requires explicit
acks even for unopposed actions.

Ian.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20617.17899.999516.325...@chiark.greenend.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Thibaut Paumard

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Le 25/10/2012 15:50, Ian Jackson a écrit :
 I'm also not that keen on the idea that the outcome is to orphan
 the package.  The salvager should surely be adding themselves as
 an Uploader.

Is that in addition to or instead of orphaning the package?

If someone notices that a package is in need of greater attention, but
cannot commit to attending it themselves, it's important that the
packages is marked at least as needing help.

I understand the entire point here is to mark packages which are
effectively abandoned as orphaned, so that others can see them in the
wnpp news for instance.

It's certainly better if a new foster maintainer can be found for the
package right away, but it should IMHO not be mandatory. Prospective
maintainers, those that want to help Debian but don't know were to
start, will be able to adopt an orphaned package, but not to salvage
one in most cases.

Take it as a three body encounter:
 - a package with no effective maintainer;
 - a developer who notices the problem;
 - a prospective maintainer.

Regards, Thibaut.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJQiUq7AAoJEJOUU0jg3ChAS4sP/0VALbDFBRjSNJR1HNWfwpwx
QPx9PJ55Lms5a9xfMDAM2XL8If0RVV77bl3o39WIEGYSDIhwYtQFhiufCigmcK7w
VZE3rvvWUCoayjswEsbZn0LGzA8oQUe6Q6yVlpg7uiD4V8gHX/MFbULt5JageJ6L
a8N+jzJ+NkXxdwhHg9L1B/3+uNm91+7OxwbhFktk7pI9ZjCuTRYyG7c7NOwpJdTk
K11lec/bpensjcfJB3c9Ba5o7BcButys17GucxY2A1m/CpQLB1SDerfl9ZZEYbqx
Dw7poAbqfUbVxNEYnxHCzAKvJ3Apaiat8IoFB/x9XE3FgK0ItGoVdwQt01s/ui3i
4LVNHMZ1HFQX8wSsLhpc0akOQ+pWBskjakFZqwATCOrexhlhFJRUtn7uKXInEm50
K6q1vHakajFyHFG5qFZAWhZxwtRQG4CUDhFSYjqEokSg1xJFm7ZD+ujUj7SOD0Tc
FlzgYZxTuJlTHE2pbySMKVnPuniwyOW+R6Lkl5kkzZWuiKJ0jaHhDAIcG68CgmHn
wWCjenPVI/9QYtNqPLd/2qxJn6j38q7yUCzIwdDcvcqa7MkRvA/VIM263pG8wiqu
COo8ks522s9bdPL5w9LBBAWyfysoNzzs8HGUgJg3Tz011/SdbKpZxnP/E1GejuBT
6DXRNtjCCOGiYpRD8uhD
=5uyj
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/50894abb.5060...@debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ian Jackson

Thibaut Paumard writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
packages):
 Le 25/10/2012 15:50, Ian Jackson a écrit :
  I'm also not that keen on the idea that the outcome is to orphan
  the package.  The salvager should surely be adding themselves as
  an Uploader.
 
 Is that in addition to or instead of orphaning the package?

Instead.

 If someone notices that a package is in need of greater attention, but
 cannot commit to attending it themselves, it's important that the
 packages is marked at least as needing help.

Well, no, I don't think so.

Whether a package is in need of greater attention is not a hard and
fast objective thing.  It's to a large part subjective.  Perhaps the
maintainer thinks it's more or less fine, or at least low enough
priority that the problems are tolerable.

It's one thing to say this package is in need of attention which I am
prepared to commit to providing.  It's quite another to say this
package is in need of attention but I'm not going to do anything other
than say it's a problem.

Ian.


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20617.21044.799784.199...@chiark.greenend.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Andreas Tille

On Thu, Oct 25, 2012 at 03:00:11PM +0100, Ian Jackson wrote:
 Andreas Tille writes (Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's 
 packages):
  On Thu, Oct 25, 2012 at 10:10:09AM +0200, Lucas Nussbaum wrote:
   However, so far, it seems that the discussion is split between people
   that think it would work, and people that think it would not work.
   Maybe we could try for a few months, and if it does not work, fix it?
  
  +1
 
 I don't think this is a good idea because it may actually restrict
 rather than empower. ...

My +1 was for try for a few months.  We currently have a set of
theories about different options and we should start some experiment
whether one of it is right or will be proven wrong.  I do not think that
we can find out by pure discussion of those different options.

Kind regards

   Andreas.

-- 
http://fam-tille.de


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025145304.gd30...@an3as.eu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Whether a package is in need of greater attention is not a hard and
 fast objective thing.  It's to a large part subjective.  Perhaps the
 maintainer thinks it's more or less fine, or at least low enough
 priority that the problems are tolerable.

Then the maintainer has many options, including but not limited to
NACK-ing the ITO. One has a lot of possibilities even before it comes to
filing an ITO.

 It's one thing to say this package is in need of attention which I am
 prepared to commit to providing.  It's quite another to say this
 package is in need of attention but I'm not going to do anything other
 than say it's a problem.

There is, indeed a difference, but the latter allows someone else
(potentially a non-DD) to take over the package, and make it visible
that the package is in need of a new maintainer. That alone is already a
tremendous improvement compared to papering over the issue.

-- 
|8]


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ehkma8mg.fsf@algernon.balabit

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Scott Kitterman



Gergely Nagy alger...@balabit.hu wrote:

Ian Jackson ijack...@chiark.greenend.org.uk writes:

 Whether a package is in need of greater attention is not a hard and
 fast objective thing.  It's to a large part subjective.  Perhaps the
 maintainer thinks it's more or less fine, or at least low enough
 priority that the problems are tolerable.

Then the maintainer has many options, including but not limited to
NACK-ing the ITO. One has a lot of possibilities even before it comes
to
filing an ITO.

AIUI, with the current proposal, as long as three DDs think it should be 
orphaned, the maintainer's objection is irrelevant.

Scott K


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/73a36e57-0c39-4688-bf88-bc7183ba7...@email.android.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Patrick Ouellette

On Thu, Oct 25, 2012 at 09:51:16AM +0200, Thibaut Paumard wrote:
 
 So yes, I say long silence from the entire community *including the
 package maintainer(s)* probably means it's safer to orphan the package
 than not. I would probably send a few pings during the one month
 period though. I would also be careful during vacation periods,
 especially if the maintainer is not a DD and therefore can not easily
 announce VAC.
 

Can you define in absolute terms what are the vacation periods that
apply to anyone/everyone of all cultures and religious backgrounds in
the world in a way that is acceptable to everyone?

A long silence is defined as how many hours/days/weeks/months/years?

All the pings in the world won't help if you are sending them via
a path that discards them.  I know several large US ISPs that automatically
reject what they consider SPAM without the customer's knowledge.  If
the sender of the ping is on a SPAM list for one of them, the ping
will never get to the maintainer, and *no one* will know.
(From personal experience I can tell you mail from the Debian list addresses
does get caught in these SPAM filters and no, the ISPs won't change the
policy.)

Pat


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025174752.gb19...@flying-gecko.net

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 9:50 AM, Ian Jackson
ijack...@chiark.greenend.org.uk wrote:
Scott Kitterman writes (Re: [SUMMARY/PROPOSAL] Orphaning another
maintainer's packages):
Why not start with a without objection standard and see how it
works?

I absolutely agree with this.

If we adopt a without objection standard then the whole process can
be a lot simpler too. There is no need for acks if any one nack is
sufficient to stop the process.

I'm also not that keen on the idea that the outcome is to orphan the
package. The salvager should surely be adding themselves as an
Uploader.

So I would have this process

1. Package is in the salvager's opinion in need of substantial and
important attention; maintainer has been inactive on this
package, and in need of help with it, for some time.
It doesn't need to be an objective criterion.

2. Notify various places (-devel and the BTS, at least)

3. Wait for objections

4. If no objections, add salvager to Uploaders.

I would prefer to see even more autonomy for the salvager and less
bugging of various lists (ITPs on -devel are already distracting
enough). With that, I would like to suggest rewriting steps 2-4 as:

2. Salvager uploads liberal (10-day delayed) nmus as needed to bring
the package into a better maintained state.

3. After a period of 3 months of contributing as an nmuer or with
maintainers approval prior to that, salvager is free to add
himself/herself as a package uploader.

4. After 6 more months without contribution from the original
maintainer, the salvager is free at his or her discretion to
remove the original maintainer.

5. The salvager should do his/her best to address original mantainer's
concerns in a manner that would please them, and any unresolvable
conflicts should be deferred to the Technical Committee.

Note that this process was pretty much the one I followed to salvage
wine. Also, the python maintainer Tech Committee decision would have
been much easier if the people complaining had been following this
kind of process where there would have been evidence that their nmus
were contributing to a better package. It eliminates the complaints
without action issue.

Best wishes,
Mike

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=MOC+7rn9jk=xoye_vrycr+ykcmfzyxohdxrreawgqb...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Dmitry Smirnov

On Fri, 26 Oct 2012 06:09:55 Michael Gilbert wrote:
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 
 4.  After 6 more months without contribution from the original
 maintainer, the salvager is free at his or her discretion to
 remove the original maintainer.
 
 5.  The salvager should do his/her best to address original mantainer's
 concerns in a manner that would please them, and any unresolvable
 conflicts should be deferred to the Technical Committee.
 
 Note that this process was pretty much the one I followed to salvage
 wine.  Also, the python maintainer Tech Committee decision would have
 been much easier if the people complaining had been following this
 kind of process where there would have been evidence that their nmus
 were contributing to a better package.  It eliminates the complaints
 without action issue.
 

Thanks Michael, this is clear, straightforward and effective strategy.
I like it. The only question is what to do (and how long to wait) before first 
NMU upload.

Regards,
Dmitry.


signature.asc
Description: This is a digitally signed message part.

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ben Hutchings

On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote:
[...]
 All the pings in the world won't help if you are sending them via
 a path that discards them.  I know several large US ISPs that automatically
 reject what they consider SPAM without the customer's knowledge.  If
 the sender of the ping is on a SPAM list for one of them, the ping
 will never get to the maintainer, and *no one* will know.
 (From personal experience I can tell you mail from the Debian list addresses
 does get caught in these SPAM filters and no, the ISPs won't change the
 policy.)
 
Given that Debian lists are 'open' and haven't always had good spam
filtering, it is not too surprising that they are sometimes treated
as spam sources.

In general, anything that needs to reach the maintainer(s) of a
specific package should not be sent to the maintainer address, not to
some general mailing list.  (The maintainer address may itself be a
mailing list, but if the maintainer(s) no longer read mail sent to it
then that's a further reason to orphan/salvage the package!)

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025205853.gg13...@decadent.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Ben Hutchings

On Thu, Oct 25, 2012 at 09:58:54PM +0100, Ben Hutchings wrote:
 On Thu, Oct 25, 2012 at 01:47:52PM -0400, Patrick Ouellette wrote:
 [...]
  All the pings in the world won't help if you are sending them via
  a path that discards them.  I know several large US ISPs that automatically
  reject what they consider SPAM without the customer's knowledge.  If
  the sender of the ping is on a SPAM list for one of them, the ping
  will never get to the maintainer, and *no one* will know.
  (From personal experience I can tell you mail from the Debian list addresses
  does get caught in these SPAM filters and no, the ISPs won't change the
  policy.)
  
 Given that Debian lists are 'open' and haven't always had good spam
 filtering, it is not too surprising that they are sometimes treated
 as spam sources.
 
 In general, anything that needs to reach the maintainer(s) of a
 specific package should not be sent to the maintainer address, not to

Delete the first 'not'. ;-)

 some general mailing list.  (The maintainer address may itself be a
 mailing list, but if the maintainer(s) no longer read mail sent to it
 then that's a further reason to orphan/salvage the package!)

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
  - Albert Camus


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121025210019.gh13...@decadent.org.uk

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Dmitry Smirnov

I think this proposal is a little bit too complicated and not straightforward 
enough.

Clearly we have two different situations:

  * Maintainer is not active and we want to orphan a particular package.
(just to orphan without adoption)

For this case filing a bug please orphan this package with CC to QA team 
seems reasonable mostly because MIA may be an overkill (what if maintainer 
just don't have enough time with the absence of co-maintainers? Also consider 
the case of prioritising when active maintainer may be working hard on more 
important issues).
Also MIA procedure (if applicable) may take too long -- it is not unusual when 
it takes 6 months or more to complete MIA checks and orphan all packages.

If please orphan this package bug is answered (or closed) by maintainer it 
clarifies the situation immediately.

Obviously anyone can update the bug with objections in which case we need some 
form of consensus to proceed. I would leave the decision to QA team as they 
are handling orphaning anyway.

If bug was unanswered for let's say two months the package is free to orphan 
by QA team. I believe one month won't be enough: maintainer might be without 
connectivity while changing internet providers, attending funeral overseas, 
being on long vacation, on maternity leave, relocating, changing jobs etc. 
Such reasons can easily keep maintainer offline for a month.

This will work if QA team won't hesitate to orphan in obvious cases.



Another (second) situation:

  * Maintainer is not active and somebody intended to take over the package.

I think proposal is addressing this case in order to protect package 
ownership. I believe generally we should trust developers (DDs) and avoid 
unnecessary bureaucracy. If DD is going to snatch the package without waiting, 
asking or following the procedure it would be a case for technical committee 
to investigate.

Practically speaking taking over the package often bypasses orphaning.
Either developers decide between themselves or new maintainer declares (her|
him)self as such.

The question is whenever we want package to be orphaned first, which I believe 
is unnecessary as long as new maintainer publicly announce ITA.

Also I think we should trust DDs to decide how long to wait for maintainer to 
reply. One month seems reasonable but it depends: timing may be important 
before freeze or if package is blocking other packages. Proposal can recommend 
to wait one month, ideally two.

As for DMs or non-members they would have to find sponsor to review their work 
anyway so we don't need a procedure to protect package ownership from 
hijacking by non-DDs.

I like the idea of filing ITA against the package in question. It clearly mark 
the intention to work on the package and notifies the maintainer 
automatically. It doesn't have to be called ITA -- we can call it co-
maintainership intent or whatever.

Consensus 3 to 1 will be only needed if there are any objections but that's 
common sense. In obvious cases a single developer's decision should be just 
enough for adoption.

I believe we're all respect each others work and our intentions are good so we 
need only little clarification how to adopt a package respectfully.
For example I would mention to keep old maintainer in Uploaders unless 
(she/he) agreed to retire from maintenance.

All the best,
Dmitry.


signature.asc
Description: This is a digitally signed message part.

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Jean-Michel Vourgère

On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
 (...)
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 (...)

I feel that would make it quite difficult for a non-DD to salvage a package.

Remember finding a sponsor can be hard.

When fixing non important bugs, or improving the package quality, like
switching to format 3 source, arranging the rules file, and so on, I fear
it will be very difficult to find a sponsor for these nmus.

Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these
cases. After it's done, one can work on more radical changes, that are more
likely to get sponsored.

I find it sad to see patches hanging for years in the bug tracker.

Cheers.

Jean-Michel Vourgère, sponsored only DM


signature.asc
Description: This is a digitally signed message part.

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:05 PM, Jean-Michel Vourgère wrote:
 On Thursday 25 October 2012 19:09:55 Michael Gilbert wrote:
 (...)
 I would prefer to see even more autonomy for the salvager and less
 bugging of various lists (ITPs on -devel are already distracting
 enough).  With that, I would like to suggest rewriting steps 2-4 as:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.
 3.  After a period of 3 months of contributing as an nmuer or with
 maintainers approval prior to that, salvager is free to add
 himself/herself as a package uploader.
 (...)

 I feel that would make it quite difficult for a non-DD to salvage a package.

 Remember finding a sponsor can be hard.

I will make myself available as a salvaging sponsor, and we can add a
tag like SV or something like that to sponsorship-requests to help
salvaging sponsors find packages.  That should significantly lower the
barrier.

 When fixing non important bugs, or improving the package quality, like
 switching to format 3 source, arranging the rules file, and so on, I fear
 it will be very difficult to find a sponsor for these nmus.

That is because those changes are not allowable in an nmu, and that
wouldn't change given any proposal so far anyway.  Those choices are
up to the maintainer and uploaders, not an nmuer.

 Having 3/1 (1/0?) *DD* approving the orphaning will be more easy in these
 cases. After it's done, one can work on more radical changes, that are more
 likely to get sponsored.

That also adds more bureaucracy, and I don't think Debian needs any
more of that.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mn2gufe4jb5dsxdnoj0xw_+q2zbtt9sxpvk65qkage...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:15 PM, Michael Gilbert  wrote:
 When fixing non important bugs, or improving the package quality, like
 switching to format 3 source, arranging the rules file, and so on, I fear
 it will be very difficult to find a sponsor for these nmus.

 That is because those changes are not allowable in an nmu, and that
 wouldn't change given any proposal so far anyway.  Those choices are
 up to the maintainer and uploaders, not an nmuer.

I was a bit unclear here.  Fixing non-important bugs and in fact any
issue in a liberal NMU will be ok.  Changes to packaging style like
source format changes, rearranging rules, etc. will not as is
currently the case (see current NMU rules).

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MOKN0Hzn__9NMh=hp7kikd3apoo1suuo5cesgq9h2c...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Arno Töll

On 25.10.2012 21:09, Michael Gilbert wrote:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.

Please let's not go that road. Mixing-up the concept of a bad maintained
package and the concept of NMUs together does not help. They do not
belong together, and only blur both concepts, so that we only can loose.

You NMU because you aren't the maintainer, that's the Non Maintainer
in Non Maintainer Upload and a fundamental difference. Developer's
reference clearly states for good reasons that the concept of NMU is
house-keeping in someone else's house. It's not your house (yet), so
please respect that. We have too many people already, continuously
ignoring NMU guidelines and are uploading NMUs with cosmetic changes
(e.g. 3.0 conversions) instead. Let's not endorse this.

However, what you are proposing is right that: Make your footprints in
someone else's package first, and find out later if someone complains
loud enough. That's everything but respectful and eventually not going
to help finding a way to head over a package to a new maintainer in a
way which is a not prone to conflicts.


I am not saying you should not NMU packages. People should not be afraid
to NMU - but do it an respectful, minimally invasive way. Do the
cosmetic perfectionist stuff later, when you are the official maintainer.


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



signature.asc
Description: OpenPGP digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 6:50 PM, Arno Töll wrote:
 On 25.10.2012 21:09, Michael Gilbert wrote:
 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  the package into a better maintained state.

 Please let's not go that road. Mixing-up the concept of a bad maintained
 package and the concept of NMUs together does not help. They do not
 belong together, and only blur both concepts, so that we only can loose.

The term better probably led to that interpretation.  By better, I
mean improving the situation in an under-maintained package, not that
the packaging was somehow bad.  That wording can be improved to
clarify that confusion.  How about:

 2.  Salvager uploads liberal (10-day delayed) nmus as needed to bring
  an under-maintained package into a more maintained state.

 You NMU because you aren't the maintainer, that's the Non Maintainer
 in Non Maintainer Upload and a fundamental difference. Developer's
 reference clearly states for good reasons that the concept of NMU is
 house-keeping in someone else's house. It's not your house (yet), so
 please respect that. We have too many people already, continuously
 ignoring NMU guidelines and are uploading NMUs with cosmetic changes
 (e.g. 3.0 conversions) instead. Let's not endorse this.

As I've said many times now, the liberal NMU would not be a license
for packaging style changes.  In fact, no NMU is allowed to make those
changes (the fact that people are doing it is apparently a social
issue, and solutions to those are hard).  It is instead more of a
license to go ahead and fix real issues with the package including new
upstreams.

 However, what you are proposing is right that: Make your footprints in
 someone else's package first, and find out later if someone complains
 loud enough. That's everything but respectful and eventually not going
 to help finding a way to head over a package to a new maintainer in a
 way which is a not prone to conflicts.

That is why the 10-day delay and bug report patch is important.  The
salvager prepares their changes and gives the existing maintainer
those 10 days to review and possibly reject them.  If the maintainer
does reject them, hopefully he does so in a constructive manner
indicating how to prepare an appropriate upload to meet his/her
requirements.

If that process somehow breaks down, only then does the Tech committee
need to get involved.  But at least at that point, there is real
activity that they can judge.

Best wishes,
Mike


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=mp5ve5b3q+kw3r-1crqjq-f6bkrzknjarprhvuobnj...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 As I've said many times now, the liberal NMU would not be a license for
 packaging style changes.  In fact, no NMU is allowed to make those
 changes (the fact that people are doing it is apparently a social issue,
 and solutions to those are hard).  It is instead more of a license to go
 ahead and fix real issues with the package including new upstreams.

I don't think adoption via liberal NMUs will work in the volume that we'd
like because they invert the natural workflow involved in improving a
package.  When I take over an unmaintained or undermaintained package, the
*last* thing I'm going to start with is upgrading it to a new upstream
release.  Usually there are stray patches that have to be analyzed,
usually the workflow is unclear, the tools used are out of date, and the
package structure isn't efficient, all of which will make the process of
updating to a new upstream release tedious, complex, and unnecessarily
difficult and make it even more of a hairball than it usually already is.

The first thing I want to do when adopting is to clean up the package,
modernize the packaging, sort through the patches and figure out which
ones are unnecessary or already merged, and get the package into a
maintainable state.  *Then* I'd update to the latest upstream.

Of course, people's mileage varies, and I have no objection to people
working the way that you describe instead.  But I think it's quite a high
bar to ask of people adopting effectively orphaned packages, so I don't
think it's the right approach to use as our default process.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871ugmw352@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 7:19 PM, Russ Allbery wrote:
 As I've said many times now, the liberal NMU would not be a license for
 packaging style changes.  In fact, no NMU is allowed to make those
 changes (the fact that people are doing it is apparently a social issue,
 and solutions to those are hard).  It is instead more of a license to go
 ahead and fix real issues with the package including new upstreams.

 I don't think adoption via liberal NMUs will work in the volume that we'd
 like because they invert the natural workflow involved in improving a
 package.

I think this is where language is important.  In my opinion, the term
adoption will continue to mean taking on full responsibility for a
package as its new maintainer.  The term salvage, in my opinion, we
can define as a process for becoming a co-maintainer on a package with
a long-term possibility of becoming its maintainer.

For adoption, the existing adoption processes will continue for those
who prefer that approach.  For salvaging, the new procedures will be
available.

 The first thing I want to do when adopting is to clean up the package,
 modernize the packaging, sort through the patches and figure out which
 ones are unnecessary or already merged, and get the package into a
 maintainable state.  *Then* I'd update to the latest upstream.

Again, I think it comes down to language.  If we view salvaging as a
process that is initially meant to help the existing maintainer, then
it makes sense to continue to work with the package as he/she
intended.  When the 3 month clock expires, and the salvager becomes an
uploader, then any change becomes allowable.  It may be that some
salvagers will start out with some more minor work for the 3 months
before becoming an uploader and jumping to a new upstream and at the
same time they change packaging style, but then again some may want
bump upstreams right away, and this process makes it possible for the
person actually doing the work to decide their own fate.  I think
autonomy is incredibly important.

That's what we did with wine, and it was entirely possible although
not as pleasant (for us salvagers) than if we could have redesigned
the packaging style.  We wanted to work as well as we could with the
existing maintainer to avoid conflict arising from changes that would
modify the way things work that he was familiar with.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MMUgQf0JGfTCRioPErQqAvcbgSbgbSCAT8aVOw=+jf...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 Again, I think it comes down to language.  If we view salvaging as a
 process that is initially meant to help the existing maintainer, then it
 makes sense to continue to work with the package as he/she intended.
 When the 3 month clock expires, and the salvager becomes an uploader,
 then any change becomes allowable.  It may be that some salvagers will
 start out with some more minor work for the 3 months before becoming an
 uploader and jumping to a new upstream and at the same time they change
 packaging style, but then again some may want bump upstreams right away,
 and this process makes it possible for the person actually doing the
 work to decide their own fate.  I think autonomy is incredibly
 important.

I certainly have no objection to people doing this, but I'm not sure
that's really what we're discussing here.  I think the thread is more
about the ongoing issue that we seem to have in Debian where the existing
procedure for orphaning packages is perceived as too heavy-weight and we
believe that there are packages that aren't being cared for, aren't
orphaned, and that someone else would work on if the status were clearer.

(I'm not entirely convinced that this is as common as people think; I
think a lot of the largely unmaintained packages are in that state because
no one else is really motivated to do anything with them either.  But it's
certainly the case that the existing process for orphaning feels murky,
ill-defined, and open-ended, which is going to tend to scare away people
who want to be helpful but who don't want to subject someone else to what
can be perceived as a sanction and who don't want to create conflict.)

The process you describe sounds more appropriate for a situation like the
WINE packages were in, where the existing maintainer was overwhelmed but
still wanted to stay deeply involved in the packaging.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87objqun33@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert michael.s.gilb...@gmail.com writes:
 On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:

 I certainly have no objection to people doing this, but I'm not sure
 that's really what we're discussing here.  I think the thread is more
 about the ongoing issue that we seem to have in Debian where the
 existing procedure for orphaning packages is perceived as too
 heavy-weight and we believe that there are packages that aren't being
 cared for, aren't orphaned, and that someone else would work on if the
 status were clearer.

 It is a proposed solution to the above issue, so it is intimately
 apropos to the discussion at hand in my opinion.

Okay, well, I guess I return to my previous statement, then.  I don't
think your proposed solution will work for the more common cases.  It's
certainly fine for people to try it, though, and I don't think it requires
any changes to any procedures for people to do so.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87d306ului@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:
Michael Gilbert writes:
On Thu, Oct 25, 2012 at 7:52 PM, Russ Allbery wrote:

I certainly have no objection to people doing this, but I'm not sure
that's really what we're discussing here. I think the thread is more
about the ongoing issue that we seem to have in Debian where the
existing procedure for orphaning packages is perceived as too
heavy-weight and we believe that there are packages that aren't being
cared for, aren't orphaned, and that someone else would work on if the
status were clearer.

It is a proposed solution to the above issue, so it is intimately
apropos to the discussion at hand in my opinion.

Okay, well, I guess I return to my previous statement, then. I don't
think your proposed solution will work for the more common cases.

I respect your opinion, so I'm just curious which part do you believe
won't work in common cases? It's just applying existing NMU rules
with a little more liberalism to increase activity in under-maintained
packages, so I personally can't see where it would break down.

It's
certainly fine for people to try it, though, and I don't think it requires
any changes to any procedures for people to do so.

A procedure change is important because it empowers salvagers; giving
them a clear set of steps to follow while also giving them the
confidence that their actions are the approved/correct ones; just like
the existing NMU rules. It also makes it clear who is in the right if
the issue does blow up to the Tech Committee.

Best wishes,
Mike

--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CANTw=mmblomn8q9zs9p8foybyhawx35wp0mvydmqu2o67ze...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert michael.s.gilb...@gmail.com writes:
 On Thu, Oct 25, 2012 at 8:18 PM, Russ Allbery wrote:

 Okay, well, I guess I return to my previous statement, then.  I don't
 think your proposed solution will work for the more common cases.

 I respect your opinion, so I'm just curious which part do you believe
 won't work in common cases?  It's just applying existing NMU rules with
 a little more liberalism to increase activity in under-maintained
 packages, so I personally can't see where it would break down.

Well, that's what I was trying to get at: I think your method puts too
many barriers in the way of someone who wants to take over an effectively
abandoned package.  It also requires *more* skill than adopting the
package would otherwise, since you have to be good enough at Debian
packaging to make minimal chnages within some arbitrary packaging scheme.
In other words, it requires as much or more skill than doing NMUs, whereas
adopting a traditionally orphaned package is much easier.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bofquj99@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 9:14 PM, Russ Allbery wrote:
 I respect your opinion, so I'm just curious which part do you believe
 won't work in common cases?  It's just applying existing NMU rules with
 a little more liberalism to increase activity in under-maintained
 packages, so I personally can't see where it would break down.

 Well, that's what I was trying to get at: I think your method puts too
 many barriers in the way of someone who wants to take over an effectively
 abandoned package.  It also requires *more* skill than adopting the
 package would otherwise, since you have to be good enough at Debian
 packaging to make minimal chnages within some arbitrary packaging scheme.
 In other words, it requires as much or more skill than doing NMUs, whereas
 adopting a traditionally orphaned package is much easier.

Don't we expect the same adaptability of anyone trying to become a
co-maintainer of any other package?  Once someone has jumped all the
hurdles to become a DD, at that point, aren't they expected to be of
sufficient caliber and skill to be able to learn quickly and apply
themselves to hard(er) problems?

At one point, there were arguments on -devel against using git for
packages because it increased the learning curve and thus may reduce
potential contributors.  This argument strikes me as quite similar.

I think we have to be able to expect ourselves to be able to adapt and
learn.  If we can't do that, then we really weren't qualified, and we
should get out of the way of those who can.

Best wishes,
Mike


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CANTw=MMkenFta5+bH5o=DkU_Kc554jOb-G=+1a2bbftb9uo...@mail.gmail.com

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

Michael Gilbert mgilb...@debian.org writes:

 Don't we expect the same adaptability of anyone trying to become a
 co-maintainer of any other package?

No, because in the typical comaintenance situation, the other maintainers
will teach the newcomer how to package according to the team standards,
rather than having them have to reverse-engineer the intention behind the
packaging setup.  With an effectively orphaned package, that's unlikely;
usually the current maintainer doesn't have the time to do anything as
time-intensive as mentoring or training.  It's way easier, in general, to
maintain the package yourself than to teach someone else how to do it, so
if they don't have time to maintain the package, they're almost certainly
not going to be able to teach someone else.

 Once someone has jumped all the hurdles to become a DD, at that point,
 aren't they expected to be of sufficient caliber and skill to be able to
 learn quickly and apply themselves to hard(er) problems?

That's not, for me, the point.

One of the problems people are concerned with when looking at the overall
quality of the Debian archive, and on our releasability, is that we tend
to keep adding new packages without taking good care of the ones already
in the archive.  I think this is one of the main motivations for the
persistant discussions of finding a better way to deal with effectively
orphaned packages.  Frequently, people will ask or hope for new
contributors to start by fixing a package already in the archive rather
than adding yet another new package to the archive, or at least do some
combination of both.

I think orphaned packages are one of our best opportunities to attract new
developers, rather than serving as an additional obligation for existing
developers.  If the package is fully orphaned, then the new maintainer
doesn't have to try to fit in with an existing packaging style without
help and explanation, and can experiment (which is how people learn).  A
lot of orphaned or poorly-maintained packages aren't horribly important,
so the new maintainer doesn't have to worry about breaking something
vital, but they still have existing work to start from and don't have the
intimidating problem of starting from scratch.  And often they have a
personal incentive for fixing that package; perhaps it's a relatively
obscure piece of software they personally use, and they were drawn to
contribute to Debian because they wanted to make it better.

Adopting orphaned packages was one of the ways I personally got started in
Debian.

But to take full advantage of that opportunity, we need to do two things.
First, we need to officially orphan packages that are effectively orphaned
but don't officially have that status.  New contributors are unlikely to
want to do that, since they don't want to insult the existing developer
and they don't have any social capital and will be worried about starting
a confrontation.  I think that's where a new orphaning process could fit
in; existing Debian developers who have the social capital to be able to
tell another developer no, really, you're not maintaining your package,
let someone else take a crack at it can get the package into a state
where a newcomer feels safe in taking it over.

And, secondly, the package needs to be in a status where the new developer
can experiment and learn.  While one *can* learn a lot by fitting within
the framework that's already in place, I think that's a learning path best
done as part of an active maintenance team so that one has mentors and
assistance.  Orphaned packages can provide a great source of material for
one's personal experimentation as one learns how to package because one
can make as large or small of changes to the packaging as one wants to
attempt and then see how well the results work without breaking any team
rules or getting in anyone else's way, but also without having to
introduce yet another new package into the archive.

-- 
Russ Allbery (r...@debian.org)   http://www.eyrie.org/~eagle/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87pq46neie@windlord.stanford.edu

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Steve Langasek

On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
 I think this is where language is important.  In my opinion, the term
 adoption will continue to mean taking on full responsibility for a
 package as its new maintainer.  The term salvage, in my opinion, we
 can define as a process for becoming a co-maintainer on a package with
 a long-term possibility of becoming its maintainer.

This is an unhelpful redefinition of the term.  The term salvage was
introduced to *mean* orphaning/adopting a package when the maintainer is no
longer fulfilling their responsibilities.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 01:41:25PM +0200, Gergely Nagy wrote:
 Steve Langasek vor...@debian.org writes:
  On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  Someone wrote:
   I disagree on this point.  If you can't get anyone to ack that you 
   should go
   ahead with the orphaning, then the system is not working as designed and
   consensus has not been achieved.  It's then incumbent on the person 
   looking
   to orphan the package to rattle the cage and get developers to pay
   attention.
 
  On the other hand, it is already hard to find people willing to review
  other peoples work. Mandating acks means trusting that there will be
  enough manpower to review something potentially unknown. I can't see
  that happening reliably. It also makes the process a whole lot more
  complicated than it needs to be,
 
  No, it makes the process based on *consensus*, which is a minimum
  requirement.
 
 It also means that the salvager has to do more work.

I expect the cc to debian-qa to draw sufficient DD's attention.  And the ACKs
are about agreeing on marking a package as orphaned.  That's the easy part.

The salvaging part goes via the existing ITA procedure.  That's the hard part.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026050907.gb10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 01:50:10PM +0200, Gergely Nagy wrote:
 Bart Martens ba...@debian.org writes:
  On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
  Steve Langasek vor...@debian.org writes:
  
   On Tue, Oct 23, 2012 at 02:40:39PM +0200, Stefano Zacchiroli wrote:
4. When/if consensus has been reached, the package can be orphaned by
   retitling and reassigning the ITO bug accordingly.
  
   I fear a bit the situation nobody care enough to comment, being
   interpreted as lack of consensus. But I do think in that case we should
   _eventually_ allow the orphaning to happen (after all 1/0  3/1 ACK/NACK
   /joke).
   Any suggestion on how to word that properly, without adding yet another
   timeout rule carved in stone?
  
   I disagree on this point.  If you can't get anyone to ack that you 
   should go
   ahead with the orphaning, then the system is not working as designed and
   consensus has not been achieved.  It's then incumbent on the person 
   looking
   to orphan the package to rattle the cage and get developers to pay
   attention.
  
  On the other hand, it is already hard to find people willing to review
  other peoples work. Mandating acks means trusting that there will be
  enough manpower to review something potentially unknown. I can't see
  that happening reliably.
 
  I think that sufficient DDs will review the ITOs.  Note that most work is
  already done by the ITO submitter.  Sponsoring a package at mentors (review
  other peoples work) is, in my opinion, much more work than reading an ITO 
  and
  sending an ACK.
 
 On the other hand, ACKing an ITO is much more responsibility, becasue
 it's not only about a package, but about taking over a package too.

No, it is not.  See the two activities explained here:
http://lists.debian.org/debian-devel/2012/10/msg00261.html

 An
 ITO will also contain quite a lot of info about previous attempts at
 updating the package - that's not simple to review either. It is less
 technical too, which can be off-putting to some.

No, an ITO should just enumerate the reasons why the package should be marked
as orphaned.

 (Mind you, I'm not against the ACK/NACK system, I'm only arguing for
 being able to proceed without N acks after a reasonable amount of time.)

OK thanks for clarifying that.  Well, also for clarity, I expect every ITO to
get sufficient ACKs or NACKs (thanks to the cc to debian-qa).

 
  As said elsewhere in the thread, the process needs to be easy and
  efficient. Hunting ACKs is neither easy, nor efficient.
 
  The proposed text is quite easy, in my opinion.
 
 Indeed, it is. Partly because as far as I understand it, it only
 recommends a 3/1 majority, and does not demand it. That's perfectly
 fine.

I guess it's a recommendation because it would go in developers-reference.
That doesn't mean that it would be OK to randomly orphan packages ignoring the
recommended procedure in developers-reference.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026052546.gc10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

On Thu, Oct 25, 2012 at 09:51:12PM -0700, Steve Langasek wrote:
 On Thu, Oct 25, 2012 at 07:45:35PM -0400, Michael Gilbert wrote:
  I think this is where language is important.  In my opinion, the term
  adoption will continue to mean taking on full responsibility for a
  package as its new maintainer.  The term salvage, in my opinion, we
  can define as a process for becoming a co-maintainer on a package with
  a long-term possibility of becoming its maintainer.
 
 This is an unhelpful redefinition of the term.  The term salvage was
 introduced to *mean* orphaning/adopting a package when the maintainer is no
 longer fulfilling their responsibilities.

I agree with Steve on this.  Let's not redefine the term now, since it would
introduce more confusion, and it would not bring us closer to a consensus on
the proposal.

The proposal is about an intent to orphan, which is in obvious cases easy to
find a consensus on.  The real salvaging (the hard work) happens via the
existing ITA procedure.

Regards,

Bart Martens


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121026053726.gd10...@master.debian.org

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages

2012-10-25 Thread Steve Langasek

On Fri, Oct 26, 2012 at 05:09:07AM +, Bart Martens wrote:
 On Thu, Oct 25, 2012 at 01:41:25PM +0200, Gergely Nagy wrote:
  Steve Langasek vor...@debian.org writes:
   On Wed, Oct 24, 2012 at 01:58:16PM +0200, Gergely Nagy wrote:
   Someone wrote:
I disagree on this point.  If you can't get anyone to ack that you 
should go
ahead with the orphaning, then the system is not working as designed 
and
consensus has not been achieved.  It's then incumbent on the person 
looking
to orphan the package to rattle the cage and get developers to pay
attention.
  
   On the other hand, it is already hard to find people willing to review
   other peoples work. Mandating acks means trusting that there will be
   enough manpower to review something potentially unknown. I can't see
   that happening reliably. It also makes the process a whole lot more
   complicated than it needs to be,

   No, it makes the process based on *consensus*, which is a minimum
   requirement.

  It also means that the salvager has to do more work.

 I expect the cc to debian-qa to draw sufficient DD's attention.  And the
 ACKs are about agreeing on marking a package as orphaned.  That's the easy
 part.

 The salvaging part goes via the existing ITA procedure.  That's the hard
 part.

Exactly.  Anyone who can't be bothered to find N other DDs to agree with him
that a package should be orphaned (for some value of N = 3 - as far as I'm
concerned, 1 or 2 acks w/ 0 nacks is sufficient) shouldn't be considering
themselves a candidate for maintaining the package anyway.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: [SUMMARY/PROPOSAL] Orphaning another maintainer's packages - delay for maintainer to react