Re: [PROPOSAL] Debian Release Plan
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 of GCC 2.95 would be just plain pathetic. So sometimes, version number milestones *are* important for a release. Admittedly, most of the time they are not such a big deal. I guess what really matters here is having versions which aren't ludicrously out of date. Specifically, if something was released upstream over a year ago, and Debian releases with an even *older* version (without good reason), that's not good at all. -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html
Re: [PROPOSAL] Debian Release Plan
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 so easily monitored. Releasing with KDE 2.2, GNOME 1, and a default of GCC 2.95 would be just plain pathetic. I don't run KDE or GNOME, so I care hardly at all what version we release with. Most of the people I know who use GNOME 1 are unhappy with the current state of GNOME 2 anyway. gcc I use, but 3.3 has been in testing for some time now. So sometimes, version number milestones *are* important for a release. Admittedly, most of the time they are not such a big deal. They are important to you, apparently, because otherwise we are pathetic. I personally do not feel the same way. I guess what really matters here is having versions which aren't ludicrously out of date. Specifically, if something was released upstream over a year ago, and Debian releases with an even *older* version (without good reason), that's not good at all. 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). -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 users _use_. KDE and GNOME may be bad cases here as they seem to be too large for rc bugs to really give a usefull idea on the relative stability of the software hidden behind the package name. There really isn't a reason for users to _ever_ really not use the lastest stable release of KDE (at least that's been my impression for the last two stable releases of KDE). I would note that _every_ liveCD based on debian ships with non-maintainer releases of KDE and GNOME from testing (or even from unstable, iirc.). Thomas -- - mdz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] pgpqFz1zazaZm.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
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 monitored. Releasing with KDE 2.2, GNOME 1, and a default of GCC 2.95 would be just plain pathetic. So sometimes, version number milestones *are* important for a release. .. I guess what really matters here is having versions which aren't ludicrously out of date. Specifically, if something was released upstream over a year ago, and Debian releases with an even *older* version (without good reason), that's not good at all. 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 is, as it lacks modern drivers on the CDs. Already people are running into problems installing woody due to old drivers: eg new servers with gigabit NICs not supported in woody CDs make installing very painful. 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 maintainers (upstream). Why is it considered OK for other commercial distributions to ship shoddy software? Instead of being ashamed of shipping old versions, we should ship whats in testing, and let people ask questions as to why we're not shipping gcc 3.3. And answer them. regards, Alastair -- Nathanael Nerode neroden at gcc.gnu.org http://home.twcny.rr.com/nerode/neroden/fdl.html -- Alastair McKinstry [EMAIL PROTECTED] GPG Key fingerprint = 9E64 E714 8E08 81F9 F3DC 1020 FA8E 3790 9051 38F4 He that would make his own liberty secure must guard even his enemy from oppression; for if he violates this duty he establishes a precedent that will reach to himself. - --Thomas Paine
Re: [PROPOSAL] Debian Release Plan
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 is, as it lacks modern drivers on the CDs. Already people are running into problems installing woody due to old drivers: eg new servers with gigabit NICs not supported in woody CDs make installing very painful. But the very same applies to XFree86 and supported graphics boards. 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 maintainers (upstream). Why is it considered OK for other commercial distributions to ship shoddy software? Instead of being ashamed of shipping old versions, we should ship whats in testing, and let people ask questions as to why we're not shipping gcc 3.3. And answer them. Yes. One implicit part of the development is however that many projects advance much faster than older maintained versions, not only in terms of features, but also in terms of bug fixes. For lots of projects the saying it's old but proven to be rock-stable does thus not apply. I'm not talking about the one-liners (which can be applied to stable branches even in upstream CVS), but about redesign and/or rewrites. There's probably a difference between 'stable' and 'mature software'. Apart from that, packages which don't go into testing because of compilation errors shows IMO that whenever there's an upgrade of the default compiler, some weeks are always needed for problems to settle down. Josef -- Play for fun, win for freedom. Hurd^H^H^H^HLinux-Info-Tag Dresden 2003: http://www.linux-dresden.de
Re: [PROPOSAL] Debian Release Plan
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 maintainers (upstream). Why is it considered OK for other commercial distributions to ship shoddy software? A great part of the RC bugs preventing packages to migrate to testing are bugs on non-x86 architectures. Most commercial distributions only deal with x86... For instance, from what C.Cheney says, the problem with the glibc ISO C thing is for s390. This problem will appear to those distributing GNU/Linux for s390... which we can count on one finger... (if you only consider big distros) -- I have sampled every language, french is my favorite. Fantastic language, especially to curse with. Nom de dieu de putain de bordel de merde de saloperie de connard d'enculé de ta mère. It's like wiping your ass with silk! I love it. -- The Merovingian, in the Matrix Reloaded
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
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 next stable release. 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. 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 goal we wants to achive. A system where tasks may be splitted, merged, spowned, assigned, revoked, opened, closed, tagged. A system where tasks, like bugs, can have severities, can be handled via mail, browsed via web interface etc. That would be a system to let us to show our user what we are planning to do, how we want to achive our goal, who will work on what, discuss with them. A system i was thinkg about from time but which i had never time to implement. Looking at these discussions, i'm really considering to bould one. ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpCiEl7ULOmj.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
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 system where tasks may be splitted, merged, want achieve spowned, assigned, revoked, opened, closed, tagged. A system where tasks, like spawned bugs, can have severities, can be handled via mail, browsed via web interface etc. That would be a system to let us to show our user what we are users planning to do, how we want to achive our goal, who will work on what, discuss achieve with them. A system i was thinkg about from time but which i had never time to implement. thinking Looking at these discussions, i'm really considering to bould one. Guys, don't be too hurry in sending mails... ops that mail was mine... ciao, -- Luca - De Whiskey's - De Vitis | Elegant or ugly code as well aliases: Luca ^De [A-Z][A-Za-z\-]*[iy]'\?s$ | as fine or rude sentences have Luca, a wannabe ``Good guy''. | something in common: they local LANG=[EMAIL PROTECTED] | don't depend on the language. pgpyN5ineBCq3.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
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 release (either the older or newer version). But this is software that users _use_. KDE and GNOME may be bad cases here as they seem to be too large for rc bugs to really give a usefull idea on the relative stability of the software hidden behind the package name. 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. -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 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 issue, and the m68k people don't have the time or interest to reproduce it or track it down, should imply that the package is unreleasable! For that matter, I can't seriously believe that new XFree86 should not be released because of bugs which are pre-existing in old XFree86 (#143825, #185936, #190323). This is actually a *very* common problem; a lot of RC bugs existed in older (released) versions, and so shouldn't be considered blocking if they happen to still be present in newer versions, but the 'testing' scripts don't realize this because the bugs weren't *reported* earlier. (Actually, rumor has it that there's a 'sarge-ignore' tag available now, which may do the right thing for supposedly RC bugs which shouldn't really block release; I don't know much about it though.) Also, you're not taking dependency issues into account. You're also not taking architecture differences into account. KDE 3 has been releasable on i386 for a long time. It has been held up by toolchain issues on various other architectures, one at a time generally. 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, especially when upstream doesn't care about some of the architectures. :-( Of course, there are already options individual maintainers can use to deal with such issues, such as declaring their packages to be non-m68k or non-s390 (for instance). Perhaps this should be used more aggressively. :-/
Re: [PROPOSAL] Debian Release Plan
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 issue, and the m68k people don't have the time or interest to reproduce it or track it down, should imply that the package is unreleasable! It might mean that it can't be released on the affected architecture, though. For that matter, I can't seriously believe that new XFree86 should not be released because of bugs which are pre-existing in old XFree86 (#143825, #185936, #190323). This is actually a *very* common problem; a lot of RC bugs existed in older (released) versions, and so shouldn't be considered blocking if they happen to still be present in newer versions, but the 'testing' scripts don't realize this because the bugs weren't *reported* earlier. (Actually, rumor has it that there's a 'sarge-ignore' tag available now, which may do the right thing for supposedly RC bugs which shouldn't really block release; I don't know much about it though.) Just to fend this off now, you should absolutely not use the sarge-ignore tag without explicit authorization from the RM. I believe that aj's going to be making some kind of announcement about this in the near future anyway, though. Of course, there are already options individual maintainers can use to deal with such issues, such as declaring their packages to be non-m68k or non-s390 (for instance). Perhaps this should be used more aggressively. :-/ Changing the Architecture: line alone isn't enough; you have to get somebody with appropriate access to change the Packages-arch-specific file. Historically Architecture: i386 was abused far too much, which is why there's this extra step. -- Colin Watson [EMAIL PROTECTED]
Re: [PROPOSAL] Debian Release Plan
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, especially when upstream doesn't care about some of the architectures. :-( Of course, there are already options individual maintainers can use to deal with such issues, such as declaring their packages to be non-m68k or non-s390 (for instance). Perhaps this should be used more aggressively. :-/ I realize that this position is unpopular, but I would have to agree. Perhaps m68k, etc. should not be supported until Sarge-r1 (i.e. the latest release for m68k would be Woody-r-whatever until Sarge-r1 is released with new support). Although this could make the security team's life even more complicated :-/ I had a vague idea which I believe would be easy to implement. I might just try it later today, depending on how complicated it turns out to be. The testing scripts block entry when a package is not buildable/has bugs/etc. on any architecture for which it claims support... it should be simple to make modified versions which would tell us what an i386-only (or whatever 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 wouldn't expect that be true of all of them). Anyway, if someone else wants to try this, go for it :-) I may try, later tonight or this weekend, and I'll post if I get any interesting statistics. Or damn lies. Or benchmarks. Have a nice day! -thomas
Re: [PROPOSAL] Debian Release Plan
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 has been assigned the wrong severity. 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 issue, and the m68k people don't have the time or interest to reproduce it or track it down, should imply that the package is unreleasable! I am about to be closing 196564 since it does not seem to be reproducable, meinproc is used in every kde app during the build process and it is working. Thanks, Chris
Re: [PROPOSAL] Debian Release Plan
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 AFAICT, there are no arch-specific tags in the BTS (I may be wrong, I don't know the debbugs source well enough to be able to get the canonical list of all tags). Should there be? Once a bug has been confirmed as only applying to a particular architecture (or several, I guess) it can be tagged as that architecture. It would help porters hunt down bugs on their pet arch, and allow efforts such as Thomas' to go much smoother. Do the BTS maintainers wish to comment on how hard/easy it would be to add a tag for each of our released architectures? Or even our non-released ones as well? - Matt
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
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 version numbers. For example, RC bug fixes. I don't find goals such as we want version X of package Y because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 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 because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. If there are RC bugs to packages that 'release-status-sarge' depends on, it won't go to testing... We can think of a new release when 'release-status-sarge' will be in testing. -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgpU6BP0phUe5.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
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 because it's the newest to be very useful in producing a quality release, nor do I believe that these are the kind of goals which are responsible for Debian's long release cycle. 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 met. And how would you know in which version the bug would be fixed? -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. 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 dependency =21.2 is ok. I think I do not understand what you mean or I do not see where the problem is. What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. The existance of this package in testing does not mean the next stable release must come out as soon as possible, but it's a monitor, it can give important informations on what have to be done to reach the next stable release. I think about this proposal just after the first mail of Adrian Bunk, but I think I did not think enough :( Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. Best regards, -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgpa0RwcemmKk.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
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 it would, unless it had a versioned dependency that could not be met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. 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 dependency =21.2 is ok. And what if the version in testing has an RC bug? release-status-sarge says everything is OK. What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. I am saying that the reality of the situation is more complex than is accounted for in this approach. Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. 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. -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 dependency =21.2 is ok. And what if the version in testing has an RC bug? release-status-sarge says everything is OK. You are rigth. I thought we can fill a RC bug to early for a stable release but you are right, if one of the version we want is in testing and we are OK for a release, yes, the monitor will be wrong! What I think is interresting with my proposal is that the release happens when packages we want for the next stable release are ready, stable. I am saying that the reality of the situation is more complex than is accounted for in this approach. Isn't it a beginning? Don't you agree with a way of monitoring the steps to be done to the next stable release? Maybe you exactly know where Debian goes and what we are waiting for (yes I saw the mails about gnome2, kde3, gcc3.3, etc...)? I do not. 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. I agree. Anybody to try another proposal? ;) -- Arnaud Vandyck, STE fi, ULg Formateur Cellule Programmation. pgp4qsb6l9Ypc.pgp Description: PGP signature
Re: [PROPOSAL] Debian Release Plan
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 '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 met. And how would you know in which version the bug would be fixed? 'release-status-sarge' is just a package to monitor the work to be done to have a stable release. 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 dependency =21.2 is ok. 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 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. Chris
Re: [PROPOSAL] Debian Release Plan [was: Re: Future releases of Debian]
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. ... While it would be nice to see at a glance how far along the next release is, the proposal doesn't address the real problem of the release cycle being too long... fix that and a more readable status of the next release would be moot. This has been an issue for as long as I can remember (I've been a Debian user since 1.3), creating a permanent testing archive was an attempt to solve it... but it hasn't worked because new software hits testing too fast for testing to stabilize enough to freeze (how long until the KDE packages in testing are a mix of 2.2, 3.1.2, and 3.1.3... two weeks?). I can only see two viable options: freeze at regular intervals and live with whatever happens to be in testing at the time, or extend the flow of packages paradigm all the way to stable. The first is like taking a 1/2 a step backwards (imo), the second requires another archive because testing can not work as both the output of unstable and the input for stable (it could if multiple versions of all packages could exist in the same archive at the same time). - Bruce
Re: [PROPOSAL] Debian Release Plan
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. 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. - Bruce
Re: [PROPOSAL] Debian Release Plan
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 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. For now, http://ftp-master.debian.org/testing/testing_probs.html is the best idea we've got. -- Colin Watson [EMAIL PROTECTED]
Re: [PROPOSAL] Debian Release Plan
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 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. Yep. The testing scripts try to guess, but really we have no concrete numbers. It is up to individual maintainers to know whether their package in sarge is releasable. One problem is that they have no reason to speak up if it is not, until the threat of release approaches. Then there is a big rush where everyone says but my package isn't ready. :-/ -- - mdz
Re: [PROPOSAL] Debian Release Plan
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 PROTECTED]
