Matt Zimmerman said:
I do not think that version number milestones are important for a
release. I think that having a well-integrated, high-quality
distribution is important for a release, and this is not so easily
monitored.
Releasing with KDE 2.2, GNOME 1, and a default
On Fri, Aug 01, 2003 at 11:51:10PM -0400, Nathanael Nerode wrote:
Matt Zimmerman said:
I do not think that version number milestones are important for a
release. I think that having a well-integrated, high-quality
distribution is important for a release, and this is not
On Sat, 2 Aug 2003 01:25:51 -0400
Matt Zimmerman [EMAIL PROTECTED] wrote:
If something has been in unstable for a year and hasn't managed to
have few enough bugs to make it into testing, then I don't care to
have it in the release (either the older or newer version).
But this is software that
On Sat, 2003-08-02 at 04:51, Nathanael Nerode wrote:
Matt Zimmerman said:
I do not think that version number milestones are important for a
release. I think that having a well-integrated, high-quality
distribution is important for a release, and this is not so easily
On Saturday 02 August 2003 09:01, Alastair McKinstry wrote:
I disagree. We should ship ASAP despite, or even because of, older
milestones. With RC bugs and d-i (as is) fixed, Sarge would still be an
improvement on current stable, woody: the longer between releases the
less useful the distro
On Saturday 02 August 2003 09:01, Alastair McKinstry wrote:
Secondly, we need to signal to upstream to fix up _their_ act, too. If
we can't ship, for example the latest gcc because glibc isn't ISO C
compliant and working with gcc-3.3 (see other thread), then others need
to act: glibc
On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote:
Adrian Bunk [EMAIL PROTECTED] wrote:
[...]
[3] http://www.fs.tum.de/~bunk/Debian/freeze
Reading the whole Future releases of Debian thread, I thought that
the main idea was that Debian need a more 'readable' status for the
On Sat, Aug 02, 2003 at 06:01:51AM -0500, Luca - De Whiskey's - De Vitis wrote:
What we need, is a task management system almost like our bug tracking system.
A way we can express task that have to be done before next relese or any other
tasks
goal we wants to achive. A
On Fri, Aug 01, 2003 at 11:43:15PM -0700, Thomas Zimmerman wrote:
On Sat, 2 Aug 2003 01:25:51 -0400
Matt Zimmerman [EMAIL PROTECTED] wrote:
If something has been in unstable for a year and hasn't managed to
have few enough bugs to make it into testing, then I don't care to
have it in the
Matt Zimmerman said:
I disagree. If I'm not mistaken, this is the definition of an RC bug.
If
the package has an RC bug, it is not releasable. If there is an RC bug
which does not imply that the package is unreleasable, it has been
assigned
the wrong severity.
So you're saying bug #196564
On Sat, Aug 02, 2003 at 01:15:53PM -0400, Nathanael Nerode wrote:
So you're saying bug #196564 should be downgraded then? I don't think
that *possibly* causing a segfault in another package (it's not clear
that it still does), on *one* architecture (m68k), when it's *probably*
a toolchain
On Saturday 02 August 2003 12:15, Nathanael Nerode wrote:
Perhaps the time has come to reconsider the requirement that, to be
releaseable, all packages must be release-ready on all 11
previously-released architectures, and in sync on all 11 architectures.
That's a lot to keep in sync,
On Sat, Aug 02, 2003 at 01:15:53PM -0400, Nathanael Nerode wrote:
Matt Zimmerman said:
I disagree. If I'm not mistaken, this is the definition of an RC bug.
If
the package has an RC bug, it is not releasable. If there is an RC bug
which does not imply that the package is unreleasable, it
On Sat, Aug 02, 2003 at 01:21:52PM -0500, Thomas Smith wrote:
architecture combination) release would be like at any time. It becomes more
complicated when dealing with RC bugs than it is with the buildds, because
they don't have architecture tags (some of them have [subject prefixes] but I
Adrian Bunk [EMAIL PROTECTED] wrote:
[...]
[3] http://www.fs.tum.de/~bunk/Debian/freeze
Reading the whole Future releases of Debian thread, I thought that
the main idea was that Debian need a more 'readable' status for the next
stable release.
I propose to create a meta-package called
On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote:
I propose to create a meta-package called 'release-status-sarge' that
depends on packages (with version number) that we want to see in sarge.
I don't think that the most important release goals can be expressed in
terms of
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Fri, Aug 01, 2003 at 07:03:46PM +0200, Arnaud Vandyck wrote:
I propose to create a meta-package called 'release-status-sarge'
that depends on packages (with version number) that we want to see
in sarge.
I don't think that the most
On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
I don't think that the most important release goals can be expressed
in terms of version numbers. For example, RC bug fixes. I don't find
goals such as we want version X of package Y
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
[...]
If there are RC bugs to packages that 'release-status-sarge' depends
on, it won't go to testing...
Of course it would, unless it had a versioned dependency that could
not be
On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
[...]
If there are RC bugs to packages that 'release-status-sarge' depends
on, it won't go to testing...
Of course
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:
[...]
It does not matter to know in which version the bug will be
fixed. What I want for sarge is emacs21 ( = 21.2 ) so if every RC
bugs are closed with 21.3 or 21.4, the
On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
On Fri, Aug 01, 2003 at 10:06:39PM +0200, Arnaud Vandyck wrote:
Matt Zimmerman [EMAIL PROTECTED] wrote:
On Fri, Aug 01, 2003 at 07:50:15PM +0200, Arnaud Vandyck wrote:
[...]
If there are RC bugs to packages that
On Fri, 1 Aug 2003, Arnaud Vandyck wrote:
Adrian Bunk [EMAIL PROTECTED] wrote:
[...]
[3] http://www.fs.tum.de/~bunk/Debian/freeze
Reading the whole Future releases of Debian thread, I thought that
the main idea was that Debian need a more 'readable' status for the next
stable release.
On Fri, 1 Aug 2003, Chris Cheney wrote:
...
Do we even know which packages in sarge have RC bugs? The last time I
looked when you close a bug with an upload to sid it closes it entirely
still. So we don't really have a good idea of how many RC bugs exist in
sarge, only how many are in sid.
On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote:
On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
And what if the version in testing has an RC bug? release-status-sarge
says everything is OK.
Do we even know which packages in sarge have RC bugs? The last time I
On Fri, Aug 01, 2003 at 04:45:42PM -0500, Chris Cheney wrote:
On Fri, Aug 01, 2003 at 04:38:37PM -0400, Matt Zimmerman wrote:
And what if the version in testing has an RC bug? release-status-sarge
says everything is OK.
Do we even know which packages in sarge have RC bugs? The last time
On Fri, Aug 01, 2003 at 04:45:09PM -0600, Bruce Sass wrote:
The BTS needs to adopt a package pool like mentality, where bugs
are assigned to a particular version of a package instead of just the
package.
Hey, man, we're working on it.
--
Colin Watson [EMAIL
27 matches
Mail list logo
