On Wed, 20 Mar 2013 01:15:58 -0400, Michael Gilbert wrote:
> Even the suggestion of a testing removal can evoke negative feelings
> for those affected (sometimes from those on the sidelines too). A
> recent example:
> http://bugs.debian.org/703258
There seems to be a misunderstanding; at least m
On 20/03/13 at 01:15 -0400, Michael Gilbert wrote:
> On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote:
> >> Maybe we could discriminate on the package's priorities. For example,
> >> about a third of the 49 packages *really* blocking the release (not
> >> waiting for a transition) are from "ex
On Tue, Mar 19, 2013 at 3:14 AM, Lucas Nussbaum wrote:
>> Maybe we could discriminate on the package's priorities. For example,
>> about a third of the 49 packages *really* blocking the release (not
>> waiting for a transition) are from "extra"[2]. Only 5 bugs affect
>> required, important or stand
On 18/03/13 at 19:41 -0400, anarcat wrote:
> On 2013-03-11, Moray Allan wrote:
> > When to release: I would also note that we should continue to be
> > flexible about "-ignore" tags where appropriate. In some cases
> > leaving a package in the release with RC bugs is more useful to users
> > than
On 2013-03-11, Moray Allan wrote:
> When to release: I would also note that we should continue to be
> flexible about "-ignore" tags where appropriate. In some cases
> leaving a package in the release with RC bugs is more useful to users
> than removing it altogether. Indeed, we always release wi
Lars Wirzenius writes:
> Gegerly, Moray, and Lucas:
>
> We're currently in the middle of a freeze for the next release. We've
> been in this release since June 30. That's over eight months. That's a
> long time, even for a project the size of Debian. Releasing when we're
> ready is all well and g
On 2013-03-12 07:17, Paul Wise wrote:
Removing packages in the freeze is way too late, they should be
removed from testing in an (semi-)automated fashion during the whole
release cycle. IIRC the release team are planning on doing this and
have done it manually in the past.
Indeed -- I should re
On Tue, Mar 12, 2013 at 3:30 AM, Moray Allan wrote:
> Earlier removals: I wonder if removing RC-buggy packages much earlier in the
> freeze would help -- even if it's logically no different to saying they will
> be removed later, it might wake up maintainers into bug-fixing action
> faster, and es
On 2013-03-11 01:35, Lars Wirzenius wrote:
In your opinion, what are the fundamental reasons the release freeze
is so
long, and so painful, and what do you propose to do, as DPL, to fix
them?
On one level I'm cautious about answering this. I don't think that a
DPL should try to impose polici
On 11/03/13 at 21:49 +0800, Paul Wise wrote:
> On Mon, Mar 11, 2013 at 9:19 PM, Lucas Nussbaum wrote:
>
> > to make fixing RC bugs more rewarding. For example, in the Debian Project
> > News, we could list the most efficient RC bug squashers.
>
> Just discussed this in #debian-publicity, if you c
On Mon, Mar 11, 2013 at 9:19 PM, Lucas Nussbaum wrote:
> to make fixing RC bugs more rewarding. For example, in the Debian Project
> News, we could list the most efficient RC bug squashers.
Just discussed this in #debian-publicity, if you can write a query to
run against UDD, the publicity team i
> In your opinion, what are the fundamental reasons the release freeze is so
> long, and so painful, and what do you propose to do, as DPL, to fix them?
The release process is hard to grasp. The most visible side of it is the
number of RC bugs (which I contributed to increase :p) As a DPL, I will
Gegerly, Moray, and Lucas:
We're currently in the middle of a freeze for the next release. We've
been in this release since June 30. That's over eight months. That's a
long time, even for a project the size of Debian. Releasing when we're
ready is all well and good, but it's a problem when it take
13 matches
Mail list logo
