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
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 unreleasa
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, espec
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 toolcha
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 #1965
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 i
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 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' stat
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 mainta
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 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 easil
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 t
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
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 defaul
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 [EMA
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 la
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 las
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 si
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
> stab
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
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
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...
> >
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
>
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
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
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 ve
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
27 matches
Mail list logo
