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

» Linux Archive

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


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian Development

 
 
LinkBack Thread Tools
 
Old 10-11-2012, 09:44 AM
Charles Plessy
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

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

Hi Bart,

here are some comments.

- It would be more straight to the point to submit an "Intend To Salvage" (ITS) and
focus on such takeovers, because merly orphaning the package does not guarantee
that it will be actively maintained.

- You may clarify that the bug is to be reported to the package, not to the
wnpp pseudo-package.

- How about requesting that the explanation contains the plans for future work on
the package ?

- I am not found of the voting procedure, and would rather propose to follow a
similar process as for the modification of the Policy and the Developers
Reference, where at least three DDs need to indicate that, in their conclusion,
a consensus has been reached. I think that if a package is orphaned with for
instance a 16:3 majority, it indicates a problem rather than a consensus. Also
if the maintainer opposes, this shows lack of consensus and a vote can only
aggravate the situation.

- For response delay, it think that one month after the bug is opened would be
a good compromise. It also makes the deadline more predictable, as opposed
to voting or counting consensus assessments. We can not use private
information such as vacation flag of the LDAP database in public bug records,
so we must assume that the maintainer may not be available. This said perhaps
we can request that DDs must not post ITS on pacakges where the maintainer has
declared being on vacation in the LDAP ?

- Lastly, how about an expiration date ? If we all agree on a one-month delay
for the maintainer's response, we can also use it as an expiration date. If
within a month there is no reaction of the maintainer, but on the other hand
the proposer does not manage to attract support or even positive comments, then
it either signals unwritten problems, or it asks the question whether the package
should really stay in Debian.

Cheers,

--
Charles Plessy
Tsurumi, Kanagawa, Japan


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121011094453.GB27691@falafel.plessy.net">http://lists.debian.org/20121011094453.GB27691@falafel.plessy.net
 
Old 10-11-2012, 01:14 PM
Scott Kitterman
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Thursday, October 11, 2012 06:44:53 PM Charles Plessy wrote:
...
> - I am not found of the voting procedure, and would rather propose to
> follow a similar process as for the modification of the Policy and the
> Developers Reference, where at least three DDs need to indicate that, in
> their conclusion, a consensus has been reached. I think that if a package
> is orphaned with for instance a 16:3 majority, it indicates a problem
> rather than a consensus. Also if the maintainer opposes, this shows lack
> of consensus and a vote can only aggravate the situation.
...

I am also concerned with this. I think it should either be unanimous or there
is a dispute the tech ctte should resolve. I don't think we should introduce
voting on the quality of other DD's package maintenance.

Scott K


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/7338961.iqtWnx2jL2@scott-latitude-e6320
 
Old 10-11-2012, 10:18 PM
Sam Hartman
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

For myself, I'd feel a lot more comfortable with DDs seconding than DMs
seconding.

In my mind, when you sign up to be a DM, you're signing up to do a good
job of maintaining one or more packages.

In my mind a part of the additional commitment in agreeing to be a DD is
to think about the broader issues of the project, for example, the
social implications of your decision, to try and help build Debian as a
community and team.
I think that broader view is important when doing something that is
likely to have social consequences like an ITO.

So, I would prefer DD seconds to DM seconds.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 0000013a51e8b51f-2190865a-4871-43ec-a362-56efe361e561-000000@email.amazonses.com">http://lists.debian.org/0000013a51e8b51f-2190865a-4871-43ec-a362-56efe361e561-000000@email.amazonses.com
 
Old 10-12-2012, 03:01 PM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 11/10/12 at 10:21 +0200, Gergely Nagy wrote:
> Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:
>
> > On 11/10/12 at 05:50 +0000, Bart Martens wrote:
> >> | Anyone can mark a package as orphaned after the following steps have been
> >> | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> >> | explanation of why he/she thinks that the package needs a new maintainer. The
> >> | explanation should cover aspects like how long there was no visible activity,
> >> | whether there are NMUs not yet acknowledged, wheter the package blocks progress
> >> | elsewhere in Debian, release critical bugs, public comments from the maintainer
> >> | revealing lack of interest in the package, ... etc. The bug must have severity
> >> | "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
> >> | submit this "intent to orphan". At least three DDs (not counting the initial
> >> | submitter) second the "intent to orphan" on the same bug report with a cc to
> >> | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
> >> | between ACKers and NACKers.
> >
> >> And the maintainer does not respond within one month after the the third second.
> >
> > I'm not sure about this delay. This procedure should be used for
> > uncontroversial cases, where orphaning is obviously the right choice.
>
> I strongly agree here. A package that's a salvaging candidate has
> already been neglected far too long, requiring another extra month of at
> most NMU-maintainance is counter productive.
>
> A maintainer has many ways to signal in advance that he/she will be
> unable to answer bug reports or mail for a longer period of time
> (including VAC messages on -private, and/or setting a vacation message
> in LDAP), many of which can and should be checked as soon as the
> salvaging process starts, to make sure there's no accidental overlap.
>
> With that done, I do not see the point of waiting an extra month. I
> would, however, put a time limit on the NACKs: one week after 3 ACKs or
> 3/1 majority is reached, the decision's done, and further ACKs/NACKs
> won't be counted. That is, we'd have a time limit on everyones ability
> to contribute to the salvaging process, not just a ticking clock for the
> maintainer.

OK

> > Maybe rephrase that into "Before taking action, it could also be a good
> > idea to wait for comments from the maintainer, especially if he/she is
> > otherwise active in Debian."
>
> I'd rephrase that further, with a s/wait for/seek/, because in my
> opinion, the person wanting to salvage a package should go to great
> lengths to reach the maintainer. Merely waiting when the package is
> obviously neglected sounds like a very passive thing to me.

OK. What is considered "sufficiently seeking for comments" can probably
be decided on a case-by-case basis (i.e., people should not ACK before
the waiting time is considered sufficient by them).

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121012150135.GA26172@xanadu.blop.info">http://lists.debian.org/20121012150135.GA26172@xanadu.blop.info
 
Old 10-12-2012, 03:07 PM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 11/10/12 at 11:27 +0200, Arno Töll wrote:
> Hi,
>
> On 11.10.2012 07:50, Bart Martens wrote:
> >> - the submitter of the "intent to orphan" bug must Cc
> >> debian-qa@lists.debian.org, and file the bug with severity:serious (this
> >> was part of the "criterias" proposal).
> > | Anyone can mark a package as orphaned after the following steps have been
> > | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> > | explanation of why he/she thinks that the package needs a new maintainer.
>
> I don't think "intend to orphan" (ITO) is a good name. First of all, it
> is wrong, because if you file such a bug, you eventually don't want to
> orphan a package, but quite the contrary revive its maintenance.
> Moreover, its name suggests it would be a WNPP bug, which it isn't and
> wouldn't be.

Any ideas of better names?

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

In the process, most of the burden is put on the one requesting the
orphaning. That person has to build a sufficiently strong case that the
package should be orphaned. I don't expect random DDs to deeply
investigate the package themselves, but rather to check the facts put
forward by the requester and then ACK/NACK. That task is sufficiently
lightweight that I think finding 3 DDs will be easy. Plus, the smell of
blood is likely to attract DDs to look into those cases

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

Correct, but addressed by Gergely's proposal in
<87r4p58llk.fsf@algernon.balabit>, I think.

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

Yes, votes must be signed, and it's the responsibility of the
requester to check the signatures.

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121012150726.GB26172@xanadu.blop.info">http://lists.debian.org/20121012150726.GB26172@xanadu.blop.info
 
Old 10-12-2012, 03:08 PM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 11/10/12 at 22:18 +0000, Sam Hartman wrote:
>
> For myself, I'd feel a lot more comfortable with DDs seconding than DMs
> seconding.
>
> In my mind, when you sign up to be a DM, you're signing up to do a good
> job of maintaining one or more packages.
>
> In my mind a part of the additional commitment in agreeing to be a DD is
> to think about the broader issues of the project, for example, the
> social implications of your decision, to try and help build Debian as a
> community and team.
> I think that broader view is important when doing something that is
> likely to have social consequences like an ITO.
>
> So, I would prefer DD seconds to DM seconds.

(Fully agreed.)

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121012150840.GC26172@xanadu.blop.info">http://lists.debian.org/20121012150840.GC26172@xanadu.blop.info
 
Old 10-12-2012, 03:31 PM
Lucas Nussbaum
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On 11/10/12 at 18:44 +0900, Charles Plessy wrote:
> Le Thu, Oct 11, 2012 at 05:50:51AM +0000, Bart Martens a écrit :
> >
> > | Anyone can mark a package as orphaned after the following steps have been
> > | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> > | explanation of why he/she thinks that the package needs a new maintainer. The
> > | explanation should cover aspects like how long there was no visible activity,
> > | whether there are NMUs not yet acknowledged, wheter the package blocks progress
> > | elsewhere in Debian, release critical bugs, public comments from the maintainer
> > | revealing lack of interest in the package, ... etc. The bug must have severity
> > | "serious" and a cc must be sent to the debian-qa mailing list. Anyone can
> > | submit this "intent to orphan". At least three DDs (not counting the initial
> > | submitter) second the "intent to orphan" on the same bug report with a cc to
> > | the maintainer. If some DDs send NACKs instead, then a 3/1 majority is needed
> > | between ACKers and NACKers. And the maintainer does not respond within one
> > | month after the the third second. During this process anyone is welcome to add
> > | comments on the bug.
>
> Hi Bart,
>
> here are some comments.
>
> - It would be more straight to the point to submit an "Intend To Salvage" (ITS) and
> focus on such takeovers, because merly orphaning the package does not guarantee
> that it will be actively maintained.

That makes the assumption that the requester will be able to salvage the
package. I would prefer if we stick to the fact: what's it's about is
orphaning the package.

Note that this procedure could also be used as a lightweight replacement
to the MIA procedure, for example if a maintainer has only one package.
In that case, it would make sense to orphan the package without the
promise to salvage it, simply to reflect the fact that the maintainer is
long gone (that way, people using wnpp-alert will identify the package
as being up for adoption).

> - You may clarify that the bug is to be reported to the package, not to
> the wnpp pseudo-package.

(ack)

> - How about requesting that the explanation contains the plans for future work on
> the package ?

See above.

> - I am not found of the voting procedure, and would rather propose to follow a
> similar process as for the modification of the Policy and the Developers
> Reference, where at least three DDs need to indicate that, in their conclusion,
> a consensus has been reached. I think that if a package is orphaned with for
> instance a 16:3 majority, it indicates a problem rather than a consensus. Also
> if the maintainer opposes, this shows lack of consensus and a vote can only
> aggravate the situation.

It should be outlined that this procedure is a lightweight process that
describes how it's considered acceptable to orphan package in simple and
obvious situations. I personally would NACK all attempts to "steal"
packages from active maintainers, and I'm quite sure that I would not be
the only one. :-) We have a procedure (bring the case to the TC) for
those situations, the problem is that it would not scale to bring
all such simple situations to the TC.

Similarly, when discussions show that the situation is not simple and
obvious, I would be inclined to NACK on the basis that the situation is
sufficiently complex to be brought to the TC. (And again, I'm quite sure it
will be easy to find more DDs agreeing with that, than 3X more DDs
willing to go fast).

> - For response delay, it think that one month after the bug is opened would be
> a good compromise. It also makes the deadline more predictable, as opposed
> to voting or counting consensus assessments.

(I made my point about delays in another mail, so I'm not replying here)

> We can not use private
> information such as vacation flag of the LDAP database in public bug records,
> so we must assume that the maintainer may not be available. This said perhaps
> we can request that DDs must not post ITS on pacakges where the maintainer has
> declared being on vacation in the LDAP ?

So, we are talking about a case where a maintainer would have been on
VAC for a long enough time to allow a package to become in such a
terrible state that NMUs are no longer sufficient to maintain its
quality at a reasonable level. In that case, I would not consider it
unreasonable to orphan the package. After all, We should prioritize the
distribution's quality higher than the ownership of packages.

> - Lastly, how about an expiration date ? If we all agree on a one-month delay
> for the maintainer's response, we can also use it as an expiration date. If
> within a month there is no reaction of the maintainer, but on the other hand
> the proposer does not manage to attract support or even positive comments, then
> it either signals unwritten problems, or it asks the question whether the package
> should really stay in Debian.

I'm not sure about that. I would prefer if we implemented a simple
procedure first, and then improved it if we find serious problems with
it.

Lucas


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121012153109.GD26172@xanadu.blop.info">http://lists.debian.org/20121012153109.GD26172@xanadu.blop.info
 
Old 10-14-2012, 07:27 AM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

Hi Charles,

On Thu, Oct 11, 2012 at 06:44:53PM +0900, Charles Plessy wrote:
> here are some comments.
>
> - It would be more straight to the point to submit an "Intend To Salvage" (ITS) and
> focus on such takeovers, because merly orphaning the package does not guarantee
> that it will be actively maintained.

I'm with Lucas on this. Lucas wrote : "That makes the assumption that the
requester will be able to salvage the package. I would prefer if we stick to
the fact: what's it's about is orphaning the package."

I see two activities that can be done by different people. One activity is
identifying unmaintained packages. Getting these packages marked as orphaned
makes them more visible as needing a new maintainer. The second activity is
the salvaging process itself. It already exists : it's adopting the package
and bringing the package back in good shape. Anyone interested can choose to
contribute on only one or both activities.

>
> - You may clarify that the bug is to be reported to the package, not to the
> wnpp pseudo-package.

I agree that this would be a useful clarification.

>
> - How about requesting that the explanation contains the plans for future work on
> the package ?

See above, about the two activities.

>
> - I am not found of the voting procedure, and would rather propose to follow a
> similar process as for the modification of the Policy and the Developers
> Reference, where at least three DDs need to indicate that, in their conclusion,
> a consensus has been reached.

I'm OK with following a similar process as for the modification of the Policy
and the Developers Reference.

> I think that if a package is orphaned with for
> instance a 16:3 majority, it indicates a problem rather than a consensus.

I agree. Do you suggest to require an unanimous consensus ? That would be OK
for me.

Actually I would like to get a simple procedure started without too much
discussion on which majority would be needed, because I expect that most cases
will get unanimous consensus anyway.

> Also
> if the maintainer opposes, this shows lack of consensus and a vote can only
> aggravate the situation.

I would allow the maintainer to cancel the ITO simply by closing the ITO bug.
(If the maintainer continues to sit on the package without updating it, we can
still go to the TC.)

>
> - For response delay, it think that one month after the bug is opened would be
> a good compromise.

I agree. Let's use this.

> It also makes the deadline more predictable, as opposed
> to voting or counting consensus assessments. We can not use private
> information such as vacation flag of the LDAP database in public bug records,
> so we must assume that the maintainer may not be available. This said perhaps
> we can request that DDs must not post ITS on pacakges where the maintainer has
> declared being on vacation in the LDAP ?

As I wrote above, I'm OK with following a similar process as for the
modification of the Policy and the Developers Reference. That is in fact a
form of voting, so I'm confused on the part "as opposed to voting or counting
consensus assessments". I would keep the three required seconds from DDs for
the ITO (not ITS, see above about the two activities) who can consult the MIA
database and the information in LDAP to base their decision on.

>
> - Lastly, how about an expiration date ? If we all agree on a one-month delay
> for the maintainer's response, we can also use it as an expiration date. If
> within a month there is no reaction of the maintainer, but on the other hand
> the proposer does not manage to attract support or even positive comments, then
> it either signals unwritten problems, or it asks the question whether the package
> should really stay in Debian.

I'm OK with adding an expiration date or a maximum duration. What maximum
duration do you suggest ? I agree that the expiration would raise the questions
you mentioned, to be looked at package per package.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121014072741.GE856@master.debian.org">http://lists.debian.org/20121014072741.GE856@master.debian.org
 
Old 10-14-2012, 07:33 AM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Thu, Oct 11, 2012 at 09:14:04AM -0400, Scott Kitterman wrote:
> On Thursday, October 11, 2012 06:44:53 PM Charles Plessy wrote:
> ...
> > - I am not found of the voting procedure, and would rather propose to
> > follow a similar process as for the modification of the Policy and the
> > Developers Reference, where at least three DDs need to indicate that, in
> > their conclusion, a consensus has been reached. I think that if a package
> > is orphaned with for instance a 16:3 majority, it indicates a problem
> > rather than a consensus. Also if the maintainer opposes, this shows lack
> > of consensus and a vote can only aggravate the situation.
> ...
>
> I am also concerned with this. I think it should either be unanimous or there
> is a dispute the tech ctte should resolve.

I'm OK with requiring unanimous consensus, and taking it to the TC in other
cases. (I wrote something similar in my previous message.)

> I don't think we should introduce
> voting on the quality of other DD's package maintenance.

Actually I don't see any problem with peer reviews. As long as the quality of
the packages is discussed, with respect for all people involved.

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121014073345.GF856@master.debian.org">http://lists.debian.org/20121014073345.GF856@master.debian.org
 
Old 10-14-2012, 08:30 AM
Bart Martens
 
Default Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

On Thu, Oct 11, 2012 at 11:27:03AM +0200, Arno Töll wrote:
> Hi,
>
> On 11.10.2012 07:50, Bart Martens wrote:
> >> - the submitter of the "intent to orphan" bug must Cc
> >> debian-qa@lists.debian.org, and file the bug with severity:serious (this
> >> was part of the "criterias" proposal).
> > | Anyone can mark a package as orphaned after the following steps have been
> > | completed : Someone submits an "intent to orphan" (ITO) in the bts with an
> > | explanation of why he/she thinks that the package needs a new maintainer.
>
> I don't think "intend to orphan" (ITO) is a good name. First of all, it
> is wrong, because if you file such a bug, you eventually don't want to
> orphan a package, but quite the contrary revive its maintenance.

I explained this here, see the explanation about the "two activities" :
http://lists.debian.org/debian-devel/2012/10/msg00261.html

> Moreover, its name suggests it would be a WNPP bug, which it isn't and
> wouldn't be.

I agree that ITO sounds like a wnpp bug. We could clarify this in the
procedure (as suggested by Charles Plessy), or we could simply make ITO a wnpp
bug. I have no strong opinion on which one to choose.

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

I've read some people objecting against non-DDs voting in this context. I
follow your reasoning that the DMs can be identified with they key, so that
would be no reason to exclude them. I have a slight preference to only count
votes from DDs, but I won't object if there is a consensus to include DMs.

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

In my opinion, yes. I expect the cc's to debian-qa to draw sufficient
attention from DDs to get ack/nack's within reasonable time. At least I would
be one of the DDs regularly looking at these packages.

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

I have no strong opinion on whether an unanimous consensus would be required or
a majority would be sufficient, and which majority that would be.

The time window would be one month after opening the bug (suggestion by Charles
Plessy). I don't expect this to be a problem.

Obviously we don't need "75% of *all* developers" taking part of the voting. I
don't see where this comes from.

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

I remember that someone else also suggested to use signed messages. That's OK
for me.

The good thing is that everyone in this thread so far seems to agree that some
packages in Debian need salvaging by a new maintainer, and that we need a new
practical procedure to enable that. I also see people pooring water in their
wine towards a consensus, so in my opinion this discussion has been
surprisingly constructive so far for the sensitive/controversial subject. I
intend to wait a few more days for additional comments before making a new
updated draft (but anyone, please feel free to make an updated draft without
waiting for me).

Regards,

Bart Martens


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20121014083026.GG856@master.debian.org">http://lists.debian.org/20121014083026.GG856@master.debian.org
 

Thread Tools




All times are GMT. The time now is 12:26 PM.

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