On Thu, Nov 01, 2012 at 07:10:06PM -0400, Michael Gilbert wrote:
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
Maybe an example will help get us on the same page. Russ seems to
have the impression that my proposal is
On Thu, Nov 01, 2012 at 01:58:28PM -0400, Michael Gilbert wrote:
On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
This is a good example where talking helped to gather all views on all
aspects
from all involved
On Thu, 2012-11-01 at 10:51 +0100, Tollef Fog Heen wrote:
]] Michael Gilbert
mlocate: http://bugs.debian.org/669368 (new upstream could have been
pushed via nmu before the freeze, but it was prepared too late)
many others I'm sure
The suggested NMU that does random changes like
On Wed, Oct 31, 2012 at 07:16:56PM -0400, Michael Gilbert wrote:
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
]] Michael Gilbert
mlocate: http://bugs.debian.org/669368 (new upstream could have been
pushed via nmu before the freeze, but it was prepared too late)
many others I'm sure
The suggested NMU that does random changes like changing the packaging
to 3.0 (quilt) and adding an uploader? Is that
On Thu, 2012-11-01 at 08:48 +, Bart Martens wrote:
On Wed, Oct 31, 2012 at 07:16:56PM -0400, Michael Gilbert wrote:
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
On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote:
]] Michael Gilbert
mlocate: http://bugs.debian.org/669368 (new upstream could have been
pushed via nmu before the freeze, but it was prepared too late)
many others I'm sure
The suggested NMU that does random changes like changing the
On Thu, Nov 1, 2012 at 4:48 AM, Bart Martens wrote:
wine: http://bugs.debian.org/585409 (new upstream pushed via nmu)
This is a good example where talking helped to gather all views on all aspects
from all involved people. My impression is that finally the maintainer
allowed
new
]] Michael Gilbert
On Thu, Nov 1, 2012 at 5:51 AM, Tollef Fog Heen wrote:
[...]
The new upstream release did not include any particularly compelling
changes for wheezy, which is why I did not update to the newer
upstream version.
It may not have include changes interesting to you,
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote:
The new upstream release did not include any particularly compelling
changes for wheezy, which is why I did not update to the newer
upstream version.
It may not have include changes interesting to you, but there was
certainly interest
Michael Gilbert mgilb...@debian.org writes:
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote:
«For wheezy» is operative in my statement. hurd is not a wheezy
release architecture, and it's actually not even part of Debian any
longer any more than HPPA or AVR32 is. Making changes for
On Thu, Nov 1, 2012 at 3:29 PM, Russ Allbery r...@debian.org wrote:
That's where nmus help. Someone that does care and does have the time
can go ahead and get the features interesting them (and likely many
other users) to work.
That's only true if you're happy with all of the changes being
Michael Gilbert mgilb...@debian.org writes:
Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or
whatever would be agreed on). The maintainer can cancel things that he
doesn't like before they get uploaded.
You're still making the maintainer take explicit action to stop
]] Michael Gilbert
On Thu, Nov 1, 2012 at 3:16 PM, Tollef Fog Heen wrote:
The new upstream release did not include any particularly compelling
changes for wheezy, which is why I did not update to the newer
upstream version.
It may not have include changes interesting to you, but
Michael Gilbert michael.s.gilb...@gmail.com writes:
On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote:
Michael Gilbert mgilb...@debian.org writes:
Not if the nmu has a sufficient delay (DELAYED/10 or DELAYED/30 or
whatever would be agreed on). The maintainer can cancel things that
he
On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote:
You're still making the maintainer take explicit action to stop
something that he already said they didn't want to happen.
For a time, this is how regular nmus were greeted, but as a project,
we've gotten over that
On Thu, Nov 1, 2012 at 5:00 PM, Stefano Zacchiroli wrote:
On Thu, Nov 01, 2012 at 04:30:51PM -0400, Michael Gilbert wrote:
You're still making the maintainer take explicit action to stop
something that he already said they didn't want to happen.
For a time, this is how regular nmus were
On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
Maybe an example will help get us on the same page. Russ seems to
have the impression that my proposal is somehow a license to push
unwanted changes at a maintainer. That is not true.
Let's consider mlocate as a hypothetical:
On Thu, Nov 1, 2012 at 6:59 PM, Bart Martens wrote:
On Thu, Nov 01, 2012 at 06:41:24PM -0400, Michael Gilbert wrote:
Maybe an example will help get us on the same page. Russ seems to
have the impression that my proposal is somehow a license to push
unwanted changes at a maintainer. That is
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
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
* Andreas Tille andr...@an3as.eu [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
On Wed, 2012-10-31 at 09:04 +0100, Bernhard R. Link wrote:
* Andreas Tille andr...@an3as.eu [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
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
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
]] 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
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
Svante Signell svante.sign...@telia.com 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)
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
* Andreas Tille andr...@an3as.eu [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
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
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
Lucas Nussbaum writes ([PROPOSAL v2] Orphaning another maintainer's packages):
- one week has passed since the ITO bug was submitted, and at least
3 DDs supported the orphaning (possibly including the submitter
of the ITO bug, if it was a DD), while nobody objected.
I think one
On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote:
Lucas Nussbaum writes ([PROPOSAL v2] Orphaning another maintainer's
packages):
- one week has passed since the ITO bug was submitted, and at least
3 DDs supported the orphaning (possibly including the submitter
Andreas Tille writes (Re: [PROPOSAL v2] Orphaning another maintainer's
packages):
On Tue, Oct 30, 2012 at 01:13:25PM +, Ian Jackson wrote:
I think four weeks would be much better. A maintainer might
reasonably go abroad for 2-3 weeks - we even have a VAC process for
handling absences
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I think four weeks would be much better. A maintainer might
reasonably go abroad for 2-3 weeks - we even have a VAC process for
handling absences. (And we don't want to complicate this third-party
orphan process with references to VACs.)
Le mardi 30 octobre 2012 16:03:35, Stuart Prescott a écrit :
I think four weeks would be much better. A maintainer might
reasonably go abroad for 2-3 weeks - we even have a VAC process for
handling absences. (And we don't want to complicate this third-party
orphan process with references
Stuart Prescott writes (Re: [PROPOSAL v2] Orphaning another maintainer's
packages):
I'm not suggesting that VAC status should be public information, but blanket
statements that we know if maintainers are on VAC (or MIA or whatever) are
wrong for 50% of our maintainers as are statements
Quoting Lucas Nussbaum (lu...@lucas-nussbaum.net):
I think I agree with everybody, so here is a new version of the last step of
the proposed procedure:
I read the huge thread quickly during last days and I think your
text well summarizes what seems to be the best consensus.
That's great
On Sun, Oct 28, 2012 at 12:19 AM, Michael Gilbert mgilb...@debian.org wrote:
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote:
maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
packages which seem abandoned by the maintainer, and to submit ITA-bugs for
packages
Andrew Starr-Bochicchio a.star...@gmail.com writes:
Michael Gilbert mgilb...@debian.org wrote:
If, as Bart has found, such mistakes are quite rare, then why worry so
much? We don't need new formal processes for rarely occurring social
problems. We need more people willing to help those that
On Sun, Oct 28, 2012 at 12:07 PM, Russ Allbery wrote:
If, as Bart has found, such mistakes are quite rare, then why worry so
much? We don't need new formal processes for rarely occurring social
problems. We need more people willing to help those that make social
mistakes to learn and improve
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote:
---8
4. When/if consensus has been reached, or if no objections have been raised,
the package can be orphaned by retitling and reassigning the ITO bug
accordingly. Here are some example
On Mon, 29 Oct 2012 03:07:16 Russ Allbery wrote:
Andrew Starr-Bochicchio a.star...@gmail.com writes:
It's not that too many people are making mistakes. It's that too many
people don't take any action out of fear of making the mistake in the
first place. That's why we need a well defined
Hi,
According to the huge thread starting at
https://lists.debian.org/debian-devel/2012/10/msg00469.html, it seems that:
- there's consensus that a lightweight process for orphaning unmaintained
packages is a good idea (if you are not convinced yet, I urge you to read
Russ' post at
On Sat, Oct 27, 2012 at 11:36:15AM +0200, Lucas Nussbaum wrote:
- there's some disagreement [...]
More disagreement than I expected.
here is a new version of the last step of
the proposed procedure:
For completeness, here is the full proposal. I've also addressed a few
cosmetic comments.
On Sat, Oct 27, 2012 at 10:19 AM, Bart Martens wrote:
So maybe we could simply allow
anyone, including non-DDs, to submit O-bugs for packages which seem abandoned
by the maintainer, and to submit ITA-bugs for packages he/she wishes to
salvage. Sounds revolutionary, but in reality this is more
On Sun, 28 Oct 2012 01:19:25 Bart Martens wrote:
So maybe we could simply allow anyone, including non-DDs, to
submit O-bugs for packages which seem abandoned by the maintainer, and to
submit ITA-bugs for packages he/she wishes to salvage.
Yes please. This is common sense and most obvious thing
Le Sat, Oct 27, 2012 at 02:19:25PM +, Bart Martens a écrit :
Thanks for your effort, Lucas. I don't object against this new text.
Many thanks and thumbs up to Lucas as well.
maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
packages which seem abandoned by the
On Sat, Oct 27, 2012 at 8:51 PM, Charles Plessy wrote:
maybe we could simply allow anyone, including non-DDs, to submit O-bugs for
packages which seem abandoned by the maintainer, and to submit ITA-bugs for
packages he/she wishes to salvage.
I think that this misses one of the reasons for the
50 matches
Mail list logo
