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)
> >
>
> The suggested NMU that does random changes like changing the pack
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 invo
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 propos
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. Tha
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 hypotheti
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 nmu
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 unwa
Michael Gilbert writes:
> On Thu, Nov 1, 2012 at 4:20 PM, Russ Allbery wrote:
>> Michael Gilbert 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.
]] 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 interest
Michael Gilbert 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 something
that he alread
On Thu, Nov 1, 2012 at 3:29 PM, Russ Allbery 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 reverted
Michael Gilbert 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 such
>> archite
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
>> cert
]] 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
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 co-m
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)
>>
>
> The suggested NMU that does random changes like changing the packaging
> t
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
]] 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)
>
The suggested NMU that does random changes like changing the packaging
to 3.0 (quilt) and adding an uploader? Is that even a serious
sug
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
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
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 in
* 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
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 (fr
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 up
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 &qu
]] 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 upstrea
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
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* beh
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 packag
* 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 t
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
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 w
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
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 ref
-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.)
Re
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
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
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), w
On Mon, 29 Oct 2012 03:07:16 Russ Allbery wrote:
> Andrew Starr-Bochicchio 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 process (or to a
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 si
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
Andrew Starr-Bochicchio writes:
> Michael Gilbert 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 lear
On Sun, Oct 28, 2012 at 12:19 AM, Michael Gilbert 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 he/she wish
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 w
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
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
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 thi
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 m
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 comment
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 https://lis
50 matches
Mail list logo
