On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
* Consider other ways in which our RC-bug-fixing efforts can be
improved, especially during the latter part of the freeze.
I think one way to improve hard to reproduce bugs or bugs in uncommon
package would be to get more users
Yea? When are you filing a patch that corrects it?
complaining does nothing. we all know what would be
better and move toward it
and your forgetting the by-law: you don't fix what
you think is better by breaking software that works
unless you can really prevent all breakage
after all. what
On Mon, 2013-05-13 at 21:41 -0400, John D. Hendrickson and Sara Darnell
wrote:
Yea? When are you filing a patch that corrects it?
complaining does nothing. we all know what would be
better and move toward it
and your forgetting the by-law: you don't fix what
you think is better by
On 2013-05-10 14:57:46 +0200, Piotr Ożarowski wrote:
[Charles Plessy, 2013-05-09]
For a large number of packages if not all, we should allow the
package maintainers to manually migrate their packages to Testing during the
Freeze, within boundaries set on debian-devel-announce by
Hi,
On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
Other steps to take as preventative measures:
* Make it a *MUST* that all transitions, no matter how small, are
checked with the release team starting from as soon as the freeze is
announced (not just after it starts) such
On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker ivo.dedec...@ugent.be wrote:
Hi,
On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
Other steps to take as preventative measures:
* Make it a *MUST* that all transitions, no matter how small, are
checked with the release
On Fri, 10 May 2013 11:24:30 +0200
Ivo De Decker ivo.dedec...@ugent.be wrote:
Hi,
On Wed, May 08, 2013 at 05:28:58PM +0100, Neil Williams wrote:
Other steps to take as preventative measures:
* Make it a *MUST* that all transitions, no matter how small, are
checked with the release
Le mercredi 08 mai 2013 à 16:51 +0100, Ian Jackson a écrit :
* Try to identify the main ways in which bugs can be hard (which
might be technical, political, or a mixture)
One of the general problems I have been running into include several
(sometimes all) of the following patterns.
*
[Charles Plessy, 2013-05-09]
For a large number of packages if not all, we should allow the
package maintainers to manually migrate their packages to Testing during the
Freeze, within boundaries set on debian-devel-announce by the release team.
+1
or a soft freeze (as described
On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
So I would like to suggest that we should have a thread where we:
* Try to identify the main ways in which bugs can be hard (which
might be technical, political, or a mixture)
* Try to think of workflows which might overcome
On Fri, 10 May 2013 10:03:46 -0400
Scott Kitterman deb...@kitterman.com wrote:
On Wednesday, May 08, 2013 04:51:14 PM Ian Jackson wrote:
So I would like to suggest that we should have a thread where we:
* Try to identify the main ways in which bugs can be hard (which
might be
On 2013-05-09 00:48, anarcat wrote:
[...]
In fact, I am of the opinion that we should relax the requirements that
the release team systematically review every diff posted during the
freeze, especially if the freeze is going to last almost a year... That
always seemed to me to be an insane
On Wed, May 08, 2013 at 04:51:14PM +0100, Ian Jackson wrote:
It is good to have it released now, but I think we are all (mostly?)
agreed that wheezy took longer to release than we would have liked.
In particular, the RC bug count didn't drop quickly enough.
Thanks for bringing this up!
I
On 09/05/13 at 08:32 +0200, Niels Thykier wrote:
The execution of the time-based freeze might have failed. Also,
testing did not serving its purpose of always being in (a
near-)releasable state[2] with its 500+ RC bugs at the start of the
freeze was not ideal (either?).
I think that one
Hi!
Lucas Nussbaum lu...@debian.org writes:
Also, we should be more agressive at getting down the number of RC bugs
by automatically removing RC-buggy not-so-important packages. For
example, if we keep the current time-based freeze policy for jessie, we
could announce that all
On Thu, May 9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote:
Also, we should be more agressive at getting down the number of RC bugs
by automatically removing RC-buggy not-so-important packages. For
example, if we keep the current time-based freeze policy for jessie, we
could announce that
Lucas Nussbaum lu...@debian.org writes:
Also, we should be more agressive at getting down the number of RC bugs
by automatically removing RC-buggy not-so-important packages.
This sounds like a good idea. If somebody is interested in the package
they can easily reintroduce it after they have
On 09/05/13 at 13:20 +0200, Julien Cristau wrote:
On Thu, May 9, 2013 at 12:55:03 +0200, Lucas Nussbaum wrote:
Also, we should be more agressive at getting down the number of RC bugs
by automatically removing RC-buggy not-so-important packages. For
example, if we keep the current
It is good to have it released now, but I think we are all (mostly?)
agreed that wheezy took longer to release than we would have liked.
In particular, the RC bug count didn't drop quickly enough.
Firstly, I want to say that I don't think this was anyone's fault. So
I don't want to lay any
On Wed, 8 May 2013 16:51:14 +0100
Ian Jackson ijack...@chiark.greenend.org.uk wrote:
So I would like to suggest that we should have a thread where we:
I suspect a wiki page will be needed at some point...
* Try to identify the main ways in which bugs can be hard (which
might be
On Thu, May 9, 2013 at 12:28 AM, Neil Williams wrote:
(We have this now in the PTS for WNPP issues, an extension to RC bugs
in dependencies could also be really useful.)
Thanks for the idea, I'll pursue implementing this with QA
infrastructure folks.
--
bye,
pabs
How about a slush? A few projects have this period where changes are
not completely forbidden, but slightly restricted.
For example, we could have a period where new upstream releases (yes,
with huge diffstats) would be accepted if they fix a RC bug.
In fact, I am of the opinion that we should
Le Wed, May 08, 2013 at 06:48:01PM -0400, anarcat a écrit :
In fact, I am of the opinion that we should relax the requirements that
the release team systematically review every diff posted during the
freeze, especially if the freeze is going to last almost a year... That
always seemed to me
23 matches
Mail list logo
