Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Andreas Tille 
On Tue, Oct 30, 2012 at 02:30:20PM +, Ian Jackson wrote:
> 
> Consider the case where a maintainer objects.  In that case you're
> counting in the previous "long waiting" time a period which the
> orphaner probably thinks shows disinterest in the package, but during
> which the maintainer may well feel (for part of the time at least)
> that the package simply didn't need any attention.

I keep on thinking that we are talking about different packages.  If a
maintainer is "simply feels that the packages didn't need any attention"
these are not packages which are for instance:

  - lagging *way* behind upstream (regarding time or version number)
  - leaving open bugs simply unanswered (=do not give any reasons
for not working on a bug)
  - etc.

I do not speak about feelings but measurable facts.

> So I don't think
> counting time-since-last-touched towards the notification period (even
> in the moral sense you're now doing) is reasonable.

I should be more precise:  It is not time-since-last-touched but rather
time-with-reported-problem-but-no-reaction.  I definitely expect a
maintainer to at least respons to a bug report somehow like "I'm willing
to do something in time X but do not have time now bla bla".  If you
find several bugs on a package with no response (assuming reasonable
reports which for instance also might affect a potential orphaner) I
would perfectly include the time-since-last-issue-without-any-reaction
into the waiting time and this is the time X I was talking about (and I
always lived under the impression that we are talking about packages of
this kind.

> Also this argument is a form of "this has been waiting for ages so now
> it is urgent" which I don't really agree with (unless there's an
> actual deadline of course).

I would rather call it a "this has been waiting for ages so you are
obviosely not interested and no harm is done if I take action nowish".
 
> Unless we're having some heavyweight process with multiple pings
> etc. (which we IMO shouldn't) the way the maintainer might first
> discover that someone feels the package needs to be orphaned is by the
> ITO bug.  The maintainer needs to have a good chance to object.

Why should a maintainer who ignored several other bugs should be
astonished about such kind of a bug?

OK, if you want a chance for objection:  Lets add to the procedure an
upload to DELAYED/15 which gives another two weeks time to react.  I
definitely think that somebody who really is in the mood of salvaging
a package and has some momentum should not be delayed a longer time
than two weeks to start with some action.
 
> >   We are not talking about stealing packages right at the first day
> > of a maintainers VAC, right?
> 
> That's not the intent, of course.  But if we invent a new process with
> objective criteria, it needs to be robust against malicious
> interpretation (or indeed careless action which follows the letter of
> the rules).

I did not followed all the mails of this thread but I never had the
impression that the drivers of a simple package salvaging process seemed 
to some extend careless.  I respect my fellow maintainers high enough to
simply assume that they do not do careless action and will deal with the
rules sensible enough that no extra hurdles are needed.

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/20121031070545.gb32...@an3as.eu

Bug#691903: ITP: libcouchbase -- Couchbase protocol library

2012-10-31 Thread Neutron Soutmun 
Package: wnpp
Severity: wishlist
Owner: Neutron Soutmun 

* Package name: libcouchbase
  Version : 2.0.0~beta2
  Upstream Author : Couchbase, Inc. 
* URL : http://www.couchbase.com/develop/c/current
* License : Apache-2.0 
  Programming Lang: C 
  Description : Couchbase protocol library

libcouchbase provides a complete interface to the functionality of
Couchbase Server. It is a callback oriented client library which makes
it very easy to write high performance programs. You could use this
library to save and retrieve data from Couchbase cluster.


signature.asc
Description: Digital signature

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Michael Gilbert 
On Wed, Oct 31, 2012 at 3:05 AM, Andreas Tille  wrote:
>> Unless we're having some heavyweight process with multiple pings
>> etc. (which we IMO shouldn't) the way the maintainer might first
>> discover that someone feels the package needs to be orphaned is by the
>> ITO bug.  The maintainer needs to have a good chance to object.
>
> Why should a maintainer who ignored several other bugs should be
> astonished about such kind of a bug?
>
> OK, if you want a chance for objection:  Lets add to the procedure an
> upload to DELAYED/15 which gives another two weeks time to react.  I
> definitely think that somebody who really is in the mood of salvaging
> a package and has some momentum should not be delayed a longer time
> than two weeks to start with some action.

That is essentially my proposal then.

Maybe we need a DELAYED/30 (or more) queue for orphaning uploads?

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=mpoo1xvbfzymliwfpqems_j5so0wrg0lkubirf253h...@mail.gmail.com

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Bernhard R. Link 
* Andreas Tille  [121031 08:06]:
> > Consider the case where a maintainer objects.  In that case you're
> > counting in the previous "long waiting" time a period which the
> > orphaner probably thinks shows disinterest in the package, but during
> > which the maintainer may well feel (for part of the time at least)
> > that the package simply didn't need any attention.
> 
> I keep on thinking that we are talking about different packages.  If a
> maintainer is "simply feels that the packages didn't need any attention"
> these are not packages which are for instance:
> 
>   - lagging *way* behind upstream (regarding time or version number)

There were some cases in the past where the maintainer did not package
new upstream version because they had some serious issues (or because
they only wanted to follow stable releases in cases where stable and
preview releases were hard to distinguish for a outsider) while someone
else mistook this for a missing action.

>   - leaving open bugs simply unanswered (=do not give any reasons
> for not working on a bug)

Who of us never put some unimportant bug that would need some longer
investigating in a row to make sure it is actually not a bug and
forgot to post a little note of "will look into this later".

> I do not speak about feelings but measurable facts.

Many facts are not black and white, but in practise there is much of
gray.

> > Also this argument is a form of "this has been waiting for ages so now
> > it is urgent" which I don't really agree with (unless there's an
> > actual deadline of course).
>
> I would rather call it a "this has been waiting for ages so you are
> obviosely not interested and no harm is done if I take action nowish".

This assumes that it actually has been waiting for so long. Different
people often see things from a different perspective. And the point
of this waiting is exactly to make sure that this view is not missing.
If it were so clear when a package is neglected and when not, we could
just do without the whole waiting period and giving the maintainer
chance to object and simply hijack the package directly.

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/20121031080420.gb11...@client.brlink.eu

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Svante Signell 
On Wed, 2012-10-31 at 09:04 +0100, Bernhard R. Link wrote:
> * Andreas Tille  [121031 08:06]:
> > > Consider the case where a maintainer objects.  In that case you're
> > > counting in the previous "long waiting" time a period which the
> > > orphaner probably thinks shows disinterest in the package, but during
> > > which the maintainer may well feel (for part of the time at least)
> > > that the package simply didn't need any attention.
> > 
> > I keep on thinking that we are talking about different packages.  If a
> > maintainer is "simply feels that the packages didn't need any attention"
> > these are not packages which are for instance:
> > 
> >   - lagging *way* behind upstream (regarding time or version number)
> 
> There were some cases in the past where the maintainer did not package
> new upstream version because they had some serious issues (or because
> they only wanted to follow stable releases in cases where stable and
> preview releases were hard to distinguish for a outsider) while someone
> else mistook this for a missing action.

How to solve the following problem: Assume a package with wishlist bugs
filed lagging behind upstream and the maintainer refuses to package any
newer upstream, not even into experimental. And in general there is an
interest (from several people) in having the new upstream versions
packaged. Can this package become salvaged in some way by the ITS/ITO
procedure?  I think this is a rather common case, a cautious maintainer
and some more adventurous salvagers. 


-- 
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/1351672360.363.10.ca...@hp.my.own.domain

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Andreas Tille 
On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote:
> > I keep on thinking that we are talking about different packages.  If a
> > maintainer is "simply feels that the packages didn't need any attention"
> > these are not packages which are for instance:
> > 
> >   - lagging *way* behind upstream (regarding time or version number)
> 
> There were some cases in the past where the maintainer did not package
> new upstream version because they had some serious issues (or because
> they only wanted to follow stable releases in cases where stable and
> preview releases were hard to distinguish for a outsider) while someone
> else mistook this for a missing action.

You simply can not mistake this as missing in action if the maintainer
would state this in the bug log and I *expect* a maintainer to exactly
do this in response to such a bug report.  If you read my mail closely I
was never talking about closing bugs but responding to bugs.
 
> >   - leaving open bugs simply unanswered (=do not give any reasons
> > for not working on a bug)
> 
> Who of us never put some unimportant bug that would need some longer
> investigating in a row to make sure it is actually not a bug and
> forgot to post a little note of "will look into this later".

Me.  It is a question of respect to the bug reporter to at least respond
to the issue.
 
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/20121031084237.gb2...@an3as.eu

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Andreas Tille 
On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
> 
> How to solve the following problem: Assume a package with wishlist bugs
> filed lagging behind upstream and the maintainer refuses to package any
> newer upstream, not even into experimental. And in general there is an
> interest (from several people) in having the new upstream versions
> packaged. Can this package become salvaged in some way by the ITS/ITO
> procedure?  I think this is a rather common case, a cautious maintainer
> and some more adventurous salvagers. 

If the maintainer gives reasons to stick to the old version and is
explaining these reason I do not see a case for a valid salvage process.
If I were the maintainer in question I would offer team maintenance to
the potential salvagers and would even sponsor their packages to
experimental if they would care for the experimental branch.  This is
what I would call sensible and helpful behaviour.

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/20121031084811.gc2...@an3as.eu

Re: Mandatory -dbg packages

2012-10-31 Thread Stefano Rivera 
Hi Andrej (2012.10.29_17:18:41_+0200)
> >The -dbgsym packages are only generated in primary archive builds.
> 
> I'm sorry to disappoint you about the Ubuntu PPAs but look into my
> PPA - https://launchpad.net/~andrej-rep/+archive/ppa/+packages - to see
> all those dbg packages. And users were used them to give me feedback to
> bugs with full backtrace.

I was talking about ddebs, the -dbgsym package generated by
https://launchpad.net/pkg-create-dbgsym

Not -dbg packages, manually generated in the package build.

See also http://wiki.debian.org/AutomaticDebugPackages

SR

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  H: +27 21 461 1230 C: +27 72 419 8559


-- 
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/20121031094731.gf1...@bach.rivera.co.za

Bug#691912: ITP: julia -- high-level, high-performance dynamic programming language for technical computing

2012-10-31 Thread Sébastien Villemot 
Package: wnpp
Severity: wishlist
Owner: "Sébastien Villemot" 

* Package name: julia
  Version : 0.0.0+100592008.r1c28
  Upstream Author : julia-...@googlegroups.com
* URL : http://julialang.org
* License : GPL-2+, MIT
  Programming Lang: C
  Description : high-level, high-performance dynamic programming language 
for technical computing

Julia is a high-level, high-performance dynamic programming language for
technical computing, with syntax that is familiar to users of other technical
computing environments. It provides a sophisticated compiler, distributed
parallel execution, numerical accuracy, and an extensive mathematical function
library. The library, mostly written in Julia itself, also integrates mature,
best-of-breed C and Fortran libraries for linear algebra, random number
generation, FFTs, and string processing. Julia programs are organized around
defining functions, and overloading them for different combinations of argument
types (which can also be user-defined).


--
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/20121031094711.11395.47750.report...@karaba.cepremap.org

Bug#691915: ITP: ruby-httpauth -- Ruby library for the HTTP authentication protocol

2012-10-31 Thread Praveen Arimbrathodiyil 
Package: wnpp
Severity: wishlist
Owner: Praveen Arimbrathodiyil 

* Package name: ruby-httpauth
  Version : 0.2.0
  Upstream Author : Manfred Stienstra
* URL : https://github.com/Manfred/HTTPauth
* License :  MIT/X
  Programming Lang: Ruby
  Description : Ruby library for the HTTP authentication protocol


-- 
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/20121031103003.9003.71050.reportbug@savannah

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Tollef Fog Heen 
]] Svante Signell 

> How to solve the following problem: Assume a package with wishlist
> bugs filed lagging behind upstream and the maintainer refuses to
> package any newer upstream, not even into experimental. And in general
> there is an interest (from several people) in having the new upstream
> versions packaged. Can this package become salvaged in some way by the
> ITS/ITO procedure?

That sounds like a hostile takeover, something I think we really want to
avoid.

-- 
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/87390uvn6i@qurzaw.varnish-software.com

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Ian Jackson 
Andreas Tille writes ("Re: [PROPOSAL v2] Orphaning another maintainer's 
packages"):
> On Tue, Oct 30, 2012 at 02:30:20PM +, Ian Jackson wrote:
> > Consider the case where a maintainer objects.  In that case you're
> > counting in the previous "long waiting" time a period which the
> > orphaner probably thinks shows disinterest in the package, but during
> > which the maintainer may well feel (for part of the time at least)
> > that the package simply didn't need any attention.
> 
> I keep on thinking that we are talking about different packages.

Yes.

>   If a maintainer is "simply feels that the packages didn't need any
> attention" these are not packages which are for instance:
>   [ examples of things which might be wrong ]

The problem is that all of these things are subjective.  The person
doing the ITO may think one thing; the maintainer a different thing.
The rules we are now writing need to be based on objective criteria.
Since there is nothing in the process that actually demands any
particular level of lack of maintenance, the criteria need to be based
on something else - in this case, proper agreement or at least lack of
active objection.

> OK, if you want a chance for objection:  Lets add to the procedure an
> upload to DELAYED/15 which gives another two weeks time to react.  I
> definitely think that somebody who really is in the mood of salvaging
> a package and has some momentum should not be delayed a longer time
> than two weeks to start with some action.

That would satisfy me.

It is also then reasonable for the process to allow (but not require)
this upload to DELAYED/15 to even be a takeover with all the work and
reorganisation that the intending new maintainer thinks is
appropriate.  The risk of course is that the old maintainer rejects
the upload and the work is wasted - and no doubt some bad feeling.
Whether to take that risk is a decision for the prospective new
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/20625.8956.853070.414...@chiark.greenend.org.uk

Bug#691927: ITP: maven-source-plugin -- This Plugin creates a jar archive of the source files of a project

2012-10-31 Thread Thomas Koch 
Package: wnpp
Severity: wishlist
Owner: Thomas Koch 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

* Package name: maven-source-plugin
  Version : 2.2.1
  Upstream Author : The Apache Software Foundation
* URL : http://maven.apache.org/plugins/maven-source-plugin
* License : Apache 2
  Programming Lang: Java
  Description : This Plugin creates a jar archive of the source files of a 
project
   The Maven 2 Source Plugin creates a JAR archive of the source files of the
   current project.

A Git packaging repository has already been initialized:
http://anonscm.debian.org/gitweb/?p=pkg-java/maven-source-plugin.git

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJQkSOnAAoJEAf8SJEEK6ZahkQP/A6P901WLc02wHvx47BuxCs8
+DGCz6TFg4IfYs/F0Ah8p6KbbJd8NnjCzgpXymdix+q8mYqS0yPVyGEVoZF75org
k1HRfnNnBugkuq2PySXD3LlD7Es55mZsaQY+fde1kyPxBMhJkI4sypVmFFH+I1l0
oowJSYIRf4KKeTsdzFq+dUfd6Z1/VuLjEsuEzqw5ZVmD1UtpNzM+OZN1jrFm3rGW
Q4nidOGZz3LQIy/YbKaerlB4CWxlCCmoMmBq901c9kRnDyoOXOKttgQcDlcGeWPI
k/S7Jmz/VfzgRKw4AntY0gTRDt+uzAk2rYQzXXmdIfXO8mFh1A/XszwKR3NSJdcF
mei/8aCYOMx0ho0ETGZwnHHJZytdI350IYqgbEDPl9YPkC7GcnB3FHz+qtla0+8t
9+XbCbjqA2WjLxgaLJ2t2YGC2zV2h8QAE0Dv9xV7mf9OtwTSnhteV+PeQWhV4yxq
YOSmk2rXJM6znpSX4q4rl7cG6Sj3yL6ekAilWCAU5yd4L1GEcML6vmOSf+zRW6JK
ZqHgxqz8S04OSHJKJ9DJJWoOBkvAzSBoHEn5w5mX+KHCplJ90Ynsks5kRrpkBeK0
arYIEdogrBXuD53zTpYNXIiltGHozWVynNL2UHJfWvEaBFECZ3RWiYgiclFMsX0Z
6iP8LNFqu+CyCv3d2w+C
=HN/Z
-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/20121031131211.10998.67834.reportbug@x121e

DATA STUDIO - ESTÚDIO DE GRAVAÇÃO DE BANDAS, JINGLES E SPOTS PUBLICITÁRIOS.

2012-10-31 Thread Data Studio 

OLÁ, VENHO ATRAVÉS DESTE E-MAIL APRESENTAR O DATA STUDIO:
PARA CONSULTAS DE ORÇAMENTOS DE JINGLES, SPOTS, VINHETAS, LOCUÇÕES E TAMBÉM 
CONVERSÃO DE VINIL E CASSETE PARA CD E VHS PARA DVD, BASTA ENTRAR EM CONTATO 
POR ESTE E-MAIL OU PELO SITE.
QUEM TIVER INTERESSE TENHO UM PORTIFÓLIO DE AUDIO NO ENDEREÇO DO SITE, BASTA 
ADICIONAR O FACEBOOK DO ESTÚDIO:
FACEBOOK - www.facebook.com/datastudio.estudiodegravacao
GRATO PELA ATENÇÃO.



--
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/10311149.rhjly...@gmail.com

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Russ Allbery 
Svante Signell  writes:

> How to solve the following problem: Assume a package with wishlist bugs
> filed lagging behind upstream and the maintainer refuses to package any
> newer upstream, not even into experimental. And in general there is an
> interest (from several people) in having the new upstream versions
> packaged. Can this package become salvaged in some way by the ITS/ITO
> procedure?

No, I think that's more of a Technical Committee issue, since that's an
actual disagreement over how to maintain the package where someone wants
to override the maintainer's decision.

-- 
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/87ip9q629c@windlord.stanford.edu

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Bart Martens 
On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
> How to solve the following problem: Assume a package with wishlist bugs
> filed lagging behind upstream and the maintainer refuses to package any
> newer upstream, not even into experimental. And in general there is an
> interest (from several people) in having the new upstream versions
> packaged. Can this package become salvaged in some way by the ITS/ITO
> procedure?  I think this is a rather common case, a cautious maintainer
> and some more adventurous salvagers. 

Can you give a few examples, if this is "a rather common case" ?

Sometimes there are good reasons to not package a newer upstream release, see
for example bugs 672568 and 687690.  Sometimes the maintainer is simply gone,
see for example bug 671890.

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/20121031183400.ga17...@master.debian.org

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Bernhard R. Link 
* Andreas Tille  [121031 09:43]:
> On Wed, Oct 31, 2012 at 09:04:23AM +0100, Bernhard R. Link wrote:
> > Who of us never put some unimportant bug that would need some longer
> > investigating in a row to make sure it is actually not a bug and
> > forgot to post a little note of "will look into this later".
>
> Me.

Does this also include packages where you are listed as Uploader? ;->

> It is a question of respect to the bug reporter to at least respond
> to the issue.

I do not disagree that it is something that should be done. But that
does not mean it is never forgotten. (Or one discusses with the
submitter privately and forgets to follow up in the bug report or
or or).

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/20121031194817.ga12...@client.brlink.eu

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Michael Gilbert 
On Wed, Oct 31, 2012 at 2:34 PM, Bart Martens wrote:
> On Wed, Oct 31, 2012 at 09:32:40AM +0100, Svante Signell wrote:
>> How to solve the following problem: Assume a package with wishlist bugs
>> filed lagging behind upstream and the maintainer refuses to package any
>> newer upstream, not even into experimental. And in general there is an
>> interest (from several people) in having the new upstream versions
>> packaged. Can this package become salvaged in some way by the ITS/ITO
>> procedure?  I think this is a rather common case, a cautious maintainer
>> and some more adventurous salvagers.
>
> Can you give a few examples, if this is "a rather common case" ?

wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
python2.6: http://bugs.debian.org/679030 (new upstream pushed via nmu)
mlocate: http://bugs.debian.org/669368 (new upstream could have been
pushed via nmu before the freeze, but it was prepared too late)


It's not that common to encounter maintainer's with this kind of
unproductive attitude, but when it does happen it seems to occur
rather often in important packages.  Thus, we should really have a
documented guideline for these cases.  The go ahead and fix it via nmu
is one solution that has been quite effective so far and seemingly
uncontroversial to the maintainers that had been getting in the way.

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=MNCgtiFWg9XC6ZJf9Pp+O67njyxf=xp7uyv6gody0z...@mail.gmail.com

Re: [PROPOSAL v2] Orphaning another maintainer's packages

2012-10-31 Thread Arno Töll 
Hi,

On 01.11.2012 00:16, Michael Gilbert wrote:
> It's not that common to encounter maintainer's with this kind of
> unproductive attitude, but when it does happen it seems to occur
> rather often in important packages.  Thus, we should really have a
> documented guideline for these cases.  The go ahead and fix it via nmu
> is one solution that has been quite effective so far and seemingly
> uncontroversial to the maintainers that had been getting in the way.

Developer's Reference contains a guideline for this case. It is by no
way forbidden to package new upstream versions or less important issues
in NMUs. Point being is, NMUs should aim to make changes in spirit of
the packager and in line with his packaging work.

That's not measured by keeping the upstream version or by fixing RC bugs
only, but by being gentle to the maintainer, keeping the design
decisions made and only touch issues which you consider really
beneficial and justify that you enter in someone else's domain.

I keep repeating myself: People really shouldn't be afraid to NMU, we
need more NMUs - genrally speaking - but it should be done in a nice and
friendly way and by respecting design choices by others. A NMU is not
about forcing someone else to obey your personal tastes and preferences.

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



signature.asc
Description: OpenPGP digital signature

Bug#692000: ITP: liblbfgs -- L-BFGS solver for dense nonlinear optimization problems

2012-10-31 Thread Dima Kogan 
Package: wnpp
Severity: wishlist
Owner: Dima Kogan 

* Package name: liblbfgs
  Version : 1.10
  Upstream Author : Naoaki Okazaki
* URL : http://www.chokkan.org/software/liblbfgs/index.html
* License : MIT
  Programming Lang: C
  Description : L-BFGS solver for dense nonlinear optimization problems

This library solves nonlinear optimization problems using the limited-memory
BFGS method. Gradients are required, Hessians are estimated. Several
higher-level interfaces use this library. In particular, there's
Algorithm::LBFGS on CPAN that uses this; I will submit an ITP for that when this
library goes through.


-- 
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/20121101044250.27771.38031.reportbug@shorty.local