Re: (seemingly) declinging bug report numbers

2012-10-14 Thread Tollef Fog Heen 
]] Christoph Anton Mitterer 


[...]

> In the case of *buntu... well to be honest I don't really see a reason
> unless someone wanted to create a company behind his distro, which
> wasn't possible with Debian.

Do you remember the sorry state of, for instance hotplugging of devices
and the utterly poor integration with desktops back in 2004 when Ubuntu
first started?  It was a _huge_ step forward.

> And IMHO, making it more "desktop/user" friendly (actually I don't think
> that Debian would be not) would have also been possible in Debian
> itself.

I don't think it would be possible to make some of the
large-scale-across-the-board changes that Ubuntu does, in Debian.  We're
a lot of people, we have a culture of discussing every change in every
detail and in practice people feel like they can rightfully block other
people's work.  We're also generally unable to choose a single solution
and prefer to say «both» rather than A or B.

[...]

> That's a tricky question... ask yourself what RMS would probably answer.

I use RMS as a guide in the same way that a boat captain would use a
lighthouse.  It's good to know where it is, but you generally don't want
to find yourself in the same spot.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


--
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/87ehl0tgbm@xoog.err.no

Re: (seemingly) declinging bug report numbers

2012-10-14 Thread Russ Allbery 
Christoph Anton Mitterer  writes:

> When Debian takes software from upstreams, it's majorly a case of making
> a collection (of course with adaptions).

> When a derivative take Debian, it's - compared to single software - more
> like forking it.

Except it's not, because that's not what Ubuntu does.  Most of the
packages are imported into Ubuntu unmodified.  Among those that are
modified, most of the modifications are exactly the minor changes that
Debian makes to upstream, and Ubuntu folks are generally quite happy to
drop the patch when possible.

I've both been upstream for software packaged in Debian and the Debian
packager of software imported into Ubuntu, and the experiences are very
similar.

> In the case of *buntu... well to be honest I don't really see a reason
> unless someone wanted to create a company behind his distro, which
> wasn't possible with Debian.

Ubuntu has a much different release cycle, a different set of goals in
terms of what packages to focus on and what bugs have to be fixed, and a
different default desktop environment, all of which would be extremely
difficult to do in Debian directly, and would at least have involved a
vast amount of discussion.

-- 
Russ Allbery (r...@debian.org)   


-- 
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/877gqscoqo@windlord.stanford.edu

Re: (seemingly) declinging bug report numbers

2012-10-14 Thread Christoph Anton Mitterer 
On Sat, 2012-10-13 at 20:35 +0200, Wouter Verhelst wrote:
> No. However, Debian is an upstream to many other distributions, just as
> upstream developers are to us.
Don't think that's true.

When Debian takes software from upstreams, it's majorly a case of making
a collection (of course with adaptions).


When a derivative take Debian, it's - compared to single software - more
like forking it.


Now forks can have benefits for (free) software, but they also can have
disadvantages, especially if there's no good reason for forking.

Some of Debian's forks may do so because they want to add modifications
which they wouldn't get into Debian easily. E.g. for policy/DFSG
reasons...
I guess that's ok,... but one can already question whether it wouldn't
be better if it was tried to bring these changes into a state where they
fit the quality of Debian.

Some of course are special ones like rescue disks or so... no problem
with them.

In the case of *buntu... well to be honest I don't really see a reason
unless someone wanted to create a company behind his distro, which
wasn't possible with Debian.
And IMHO, making it more "desktop/user" friendly (actually I don't think
that Debian would be not) would have also been possible in Debian
itself.


> On the whole, commercial entities cooperate better with other commercial
> entities than they do with volunteer organizations, just as much as
> volunteer organizations cooperate better with other volunteer
> organizations instead of other commercial entities.
That's true... but wrt Ubuntu it sounds rather like an excuse, because
many projects show that it's well possible to build up commercial
support without making a fork.


> I don't think Debian is losing ground to Ubuntu.
Well we'll see... I'm quite sceptical... and truly hope I'm wrong and
people can look back in some years and laugh what that Mitterer jerk
wrote about ;)


> If anything, Ubuntu is
> gaining ground on non-free software. You can't be angry about that.
That's a tricky question... ask yourself what RMS would probably answer.

Making opensource more open for proprietary stuff is sometimes simply
necessary... but this may ultimately also become a big threat for the
free software world, namely then when that non-free stuff plays such an
important role that we couldn't get rid of it anymore.

When you followed that recent discussion on lkml, where some Nvidia guys
wanted to remove GPL from some kernel source files (for their evil
deeds ;) )... you may see what I'm thinking about.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

2012-10-14 Thread Christoph Anton Mitterer 
On Fri, 2012-10-12 at 16:52 -0400, Michael Gilbert wrote:
> On Fri, Oct 12, 2012 at 4:45 PM, Christoph Anton Mitterer wrote:
> > I wasn't talking about such an impossible task,... but there speaks
> > nothing against relatively easy things,... like securing all of our
> > package repository infrastructure by strong algos (as we already did)...
> > and trying to prevent higher level attacks, like downgrade attacks.

> Do you have evidence of any of those things?
Well as I said previously, in security one should usually not try to
only take measures against things one can identify as a problem right
now. Especially if there's no considerable disadvantage, then I see no
good reason  for not using the strongest (in this specific example) hash
algorithms available.

Now the argument some people threw in, that debsums should stay at MD5
to already hint that it shouldn't be used for intrusion detection:
- It's much better than to clearly document that this shouldn't be used
in that way (which is already done)... and then use a algo that provides
a good trade off between speed and hash quality (MD5 might be just
that...).
- I still think that one may build up a system using debsums that is
equally secure than what AIDE and friends do. At least I see no reason
speaking against.


> If so, please submit
> bugs, and we will look at fixing them.  Otherwise, speculation gets us
> nowhere and actually wastes time.
Well I had once a discussion (around March this year) here about
blockin/downgrade attacks... which, AFAICS, both are possible in secure
APT right now but there was no real outcome.
Unforunately it seems that people do not take these higher-level attacks
really serious even though the danger they impose is quite high.


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

2012-10-14 Thread Christoph Anton Mitterer 
On Sun, 2012-10-14 at 17:25 +0600, Andrey Rahmatullin wrote:
> """
> debsums is intended primarily as a way of determining what installed files
> have been locally modified by the administrator or damaged by media errors
> and is of limited use as a security tool.
> 
> If you are looking for an integrity checker that can run from safe media,
> do integrity checks on checksum databases and can be easily configured to
> run periodically to warn the admin of changes see other tools such as:
> aide, integrit, samhain, or tripwire.
> """

I never claimed (and already explicitly said that before) that it was
intended to be used for that,... or that I would do or recommend so...
just that people might and that it already happens more or less
(rkhunter has a mode of doing so, IIRC).


Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#690496: ITP: libjs-jstat -- A JavaScript statistical library

2012-10-14 Thread Jeffrin Jose Thalakkottoor 
Package: wnpp
Severity: wishlist
Owner: Jeffrin Jose Thalakkottoor 

* Package name: libjs-jstat
  Version : 1.0.0
  Upstream Author : John Resig 
* URL : http://www.jstat.org/
* License : MIT
  Programming Lang: JavaScript
  Description : A JavaScript statistical library

jStat is a statistical library written in JavaScript that allows you
to perform advanced statistical operations without the need of a
dedicated statistical language


-- 
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/20121014220458.ga7...@debian.jeff

Bug#690489: ITP: libjs-jstat -- A JavaScript statistical library

2012-10-14 Thread Jeffrin Jose Thalakkottoor 
Package: wnpp
Severity: wishlist
Owner: Jeffrin Jose Thalakkottoor 

* Package name: libjs-jstat
  Version : x.y.z
  Upstream Author : Name 
* URL : http://www.example.org/
* License : (GPL, LGPL, BSD, MIT/X, etc.)
  Programming Lang: (C, C++, C#, Perl, Python, etc.)
  Description : A JavaScript statistical library

(Include the long description here.)


-- 
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/20121014201958.ga6...@debian.jeff

Re: Salvaging packages for fun and profit: A proposal

2012-10-14 Thread Stefano Zacchiroli 
[ dropping "hijacking" from the subject, as that's not what this thread
  is about :) ]

On Sun, Oct 14, 2012 at 08:30:26AM +, Bart Martens wrote:
> 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).

Hear hear, the above matches my perception too. There are still some
aspect to be fleshed out, but we seem to agree on the need and, roughly,
on the procedure. Thanks a bunch to Lucas, you, and all the others who
helped keeping this discussion going.  I'm looking forward to a new
draft, for further review and assessment of what remains pending.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#690451: ITP: libmongodbx-class-perl -- Flexible ORM for MongoDB databases

2012-10-14 Thread Dominique Dumont 
Package: wnpp
Owner: Dominique Dumont 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,debian-p...@lists.debian.org

* Package name: libmongodbx-class-perl
  Version : 1.0
  Upstream Author : Ido Perlmuter 
* URL : http://search.cpan.org/dist/MongoDBx-Class/
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Flexible ORM for MongoDB databases

MongoDBx::Class is a flexible object relational mapper (ORM) for
MongoDB databases. Given a schema-like collection of document classes,
MongoDBx::Class expands MongoDB objects (hash-refs in Perl) from the
database into objects of those document classes, and collapses such
objects back to the database.

MongoDBx::Class takes advantage of the fact that Perl's MongoDB driver
is Moose-based to extend and tweak the driver's behavior, instead of
wrapping it. This means MongoDBx::Class does not define its own
syntax, so you simply use it exactly as you would the MongoDB driver
directly. That said, MongoDBx::Class adds some sugar that enhances and
simplifies the syntax unobtrusively (either use it or don't). Thus, it
is relatively easy to convert your current MongoDB applications to
MongoDBx::Class. A collection in MongoDBx::Class
isa('MongoDB::Collection'), a database in MongoDBx::Class
isa('MongoDB::Database'), etc.

-- 
https://github.com/dod38fr/config-model/ -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/-o-   irc: dod at irc.debian.org


-- 
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/20121014132918.ga9...@gandalf.hd.free.fr

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

2012-10-14 Thread Andrey Rahmatullin 
On Sun, Oct 14, 2012 at 01:14:19PM +0200, Bernhard R. Link wrote:
> > > part at all) will only weaken security. So I think what you say is an
> > > argument for keeping md5sum, so that noone think they can use that
> > > information for security.
> >
> > This argument is based on the incorrect assumption that everyone in the
> > world knows md5 is broken.
> 
> No it is based on the assumption that in that set of people that care
> about security at all but have little enough knowledge of security
> to mix up protection against faulty hardware with protection against
> attackers there is at least one user having heared the meme
> "md5 considered broken" and might combine those half-knowledges to
> the correct result that debsums is not about security against attackers.
> 
> Causing at least one user to not think they could use debsums as protection
> against wilfull file modification by sticking with md5 is (given there are
> no benefits from switching hashes at all) a very strong argument that
> switching hashes for debsums to stick to the hashes it uses.
For the reference: the manpage says:

"""
debsums is intended primarily as a way of determining what installed files
have been locally modified by the administrator or damaged by media errors
and is of limited use as a security tool.

If you are looking for an integrity checker that can run from safe media,
do integrity checks on checksum databases and can be easily configured to
run periodically to warn the admin of changes see other tools such as:
aide, integrit, samhain, or tripwire.
"""

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Debian should move away from MD5 (and at best also from SHA1) (in secure APT and friends)

2012-10-14 Thread Bernhard R. Link 
* Wouter Verhelst  [121013 10:56]:
> On Fri, Oct 12, 2012 at 09:17:32AM +0200, Bernhard R. Link wrote:
> > part at all) will only weaken security. So I think what you say is an
> > argument for keeping md5sum, so that noone think they can use that
> > information for security.
>
> This argument is based on the incorrect assumption that everyone in the
> world knows md5 is broken.

No it is based on the assumption that in that set of people that care
about security at all but have little enough knowledge of security
to mix up protection against faulty hardware with protection against
attackers there is at least one user having heared the meme
"md5 considered broken" and might combine those half-knowledges to
the correct result that debsums is not about security against attackers.

Causing at least one user to not think they could use debsums as protection
against wilfull file modification by sticking with md5 is (given there are
no benefits from switching hashes at all) a very strong argument that
switching hashes for debsums to stick to the hashes it uses.

Bernhard R. Link


-- 
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/20121014111405.ga15...@client.brlink.eu

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

2012-10-14 Thread Bart Martens 
On Thu, Oct 11, 2012 at 10:21:59AM +0200, Gergely Nagy wrote:
> Lucas Nussbaum  writes:
> > 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.

Yep.  See what I wrote about skipping the month delay in obvious cases.

> 
> 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 don't know where to look for such signal for non-DDs.  I think that we should
still allow one month delay in less obvious cases.

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/20121014085853.gi...@master.debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

2012-10-14 Thread Bart Martens 
On Thu, Oct 11, 2012 at 08:20:36AM +0200, Lucas Nussbaum wrote:
> On 11/10/12 at 05:50 +, Bart Martens wrote:
> > 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 agree that in some cases orphaning is obviously the right choice and the
delay would be pointless.  Maybe this can be solved by allowing unanimous
consensus on skipping the delay.  Then the person interested in adopting the
package can proceed without the pointless entire month delay, so without the
risk of loosing interest.  (Someone already brought up this aspect, as far as I
remember.)

> 
> > During this process anyone is welcome to add
> >   |  comments on the bug.
> 
> Maybe rephrase into:
> During the process, everyone is of course welcomed and encouraged to
> contribute to the discussion. Comments from users of the package that
> suffer from the level of maintenance are especially useful.

OK for me.  I usually prefer the shorter text, but I won't object against the
larger text.

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

I fully agree on that, and I have a quite strong opinion on this.  Let's focus
on the package quality, and always be polite/friendly/respectful for the people
involved.

> So I'm fine
> with not including MIA in the checklist, since this typically focuses on
> the maintainer.

OK, I left it out for the practical reason I mentioned, but you're right about
the reason you gave.

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/20121014084825.gh...@master.debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

2012-10-14 Thread Bart Martens 
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...@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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121014083026.gg...@master.debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

2012-10-14 Thread Bart Martens 
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121014073345.gf...@master.debian.org

Re: Hijacking^W^W^W^W^W^WSalvaging packages for fun and profit: A proposal

2012-10-14 Thread Bart Martens 
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-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121014072741.ge...@master.debian.org