Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 03:15:19PM +0200, Adrian Bunk wrote: > >... > > You will never find all issues in the BTS. > > E.g. the BTS doesn't tell you that the unstable package of SpamAssassin > contains a fix for a potential DoS attack. Your answer isn't constructive in anyway. What are you trying to contribute, or are you here just to spread doomsday fear? -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 04:14:40PM +0200, Adrian Bunk wrote: [...] > How does the release team ensure that you won't release Debian 3.1 with > known serious problems already fixed in unstable (e.g #237071 or the > potential DoS attack in SpamAssassin)? Basically letting it going to Sarge: Spamassassin: http://packages.qa.debian.org/s/spamassassin.html # The package has not yet entered testing even though the 2-day delay # is over. Check why . Testing Status # 6 days old (needed 2 days) # out of date on alpha: spamc (from 2.63-1) # out of date on mipsel: spamc (from 2.63-1) # Not considered -- Jose Carlos Garcia Sogo [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 04:14:40PM +0200, Adrian Bunk wrote: > On Thu, Aug 12, 2004 at 02:51:56PM +0100, Colin Watson wrote: > > That's OK, but please take your disagreement with that and your posts > > that stem from this disagreement off this mailing list. Right now, it is > > simply not in the least constructive. > > > > debian-release is not a discussion list. > > OK, no more discussion, but please answer the following question: > > How does the release team ensure that you won't release Debian 3.1 with > known serious problems already fixed in unstable (e.g #237071 or the > potential DoS attack in SpamAssassin)? There are two release managers, equalling two human beings with maybe 10 to 20 hours of Debian-related time a day between us; we simply cannot track the entire distribution by hand. If you want a bug fixed, you MUST file it in the BTS with a suitable severity. If we are told about a bug that needs to be fixed, we'll generally upgrade it to a suitable severity. I don't know what this SpamAssassin bug is, but if it wasn't filed in the BTS then it should be. The solution to "unfiled bug" is not "come up with ways to track unfiled bugs" but "file the bug". Jeroen and Joey have both been doing very good jobs of tracking RC bugs that need fixed in testing and security advisories that need fixed in testing respectively, for which I thank them. (To some extent these are workarounds for the lack of version tracking, and yes, I should have had the nerve to deploy that ages ago, sorry.) We'll be making heavy use of both as well as the usual sources in making any final decision on sarge's releasability. In the meantime I ask that we be allowed to do our jobs with the limited amount of Debian time we have rather than being drawn into long and time-consuming mailing list discussions about how dreadful a job we're doing. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 04:05:48PM +0200, Adrian Bunk wrote: > On Thu, Aug 12, 2004 at 02:21:24PM +0200, Andreas Barth wrote: > > #237071 is _not_ required for security suports. Furthermore, there is > > some difference between "keeping track" and "fixing everything". > > It's not required for security support. > > But it was announced that the toolchain should be in order starting > today. That's not true if sarge lacks fixes that are already in > unstable. The announcement referred to the compiler toolchain. As of today, we have current versions of gcc-3.3 and gcc-3.4 in testing, which was the goal. grep depending on a library in /usr is totally irrelevant to that goal. > My understanding is: > If you announe "next release is targetted at 19 September 2004" you have > to ensure that all work required to achieve this goal is done. I think you're not helping and are simply sniping. Please take it elsewhere. Thank you. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 02:51:56PM +0100, Colin Watson wrote: >... > > The Debian release management thinks freezing testing is less work. > > That's OK (I have no influence on it - I'm not even a Debian developer), > > but I do not plan to do anything of the work that is only caused by the > > fact that testing is frozen. > > That's OK, but please take your disagreement with that and your posts > that stem from this disagreement off this mailing list. Right now, it is > simply not in the least constructive. > > debian-release is not a discussion list. OK, no more discussion, but please answer the following question: How does the release team ensure that you won't release Debian 3.1 with known serious problems already fixed in unstable (e.g #237071 or the potential DoS attack in SpamAssassin)? > Cheers, cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 02:21:24PM +0200, Andreas Barth wrote: > * Adrian Bunk ([EMAIL PROTECTED]) [040812 14:10]: > > On Thu, Aug 12, 2004 at 01:21:22PM +0200, Andreas Barth wrote: > > > * Adrian Bunk ([EMAIL PROTECTED]) [040812 12:25]: > > > > Why do you think this task is not worked on, if you're not subscribed > > > to -release? (And of course, Jeroen is not member of the release team, > > > but I don't care for that as long as the job is done.) > > > It was announced that "Official security support for sarge begins" and > > the toolchain is in order after "12 August 2004". > > > > If such an easy and clearly RC bug as #237071 which is already fixed in > > unstable isn't adressed in testing until today, something is definitely > > going wrong. > > #237071 is _not_ required for security suports. Furthermore, there is > some difference between "keeping track" and "fixing everything". It's not required for security support. But it was announced that the toolchain should be in order starting today. That's not true if sarge lacks fixes that are already in unstable. > > And if it was Jeroen's job as you said, he isn't doing it > > properly. > > It seems to me that you might just have a wrong opinion how jobs in > debian are done. Nobody says: "Hereby, I order you, $SOMEBODY, to do I don't think we disagree on this. My understanding is: If you announe "next release is targetted at 19 September 2004" you have to ensure that all work required to achieve this goal is done. > $JOB.". Instead, people like Jeroen stand up, track problems by > themselfs. Also, one package being seven days too old (and this means > a specific problem on one specific platform) is not so bad as you just > tell us all. This issue is even present in the BTS. With the tough timeline the release team set one week is much time. > > It will be worse between "28 August 2004" and "16 September 2004" > > when many hundred packages with a more recent version than in unstable > > whether sarge have to be evaluated and fixed during only three weeks. > > You're invited to help there. If you don't intend to help, then please > stop waisting our time. If reporting a problem without being willing to solve it myself is considered evil you'd better close your BTS immediately ... > Cheers, > Andi cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Who checks for bugs fixed in unstable but not in sarge?
Hi, Adrian Bunk wrote: > BTW: Who had the idea of including three different versions of GnuTLS in > sarge? Nobody. The former maintainer didn't track Upstream; about a month ago, I took over and started pushing for inclusion of the latest versions. Since that was somewhat late, we now have two old and unsupported versions in Sarge. Fortunately, most (if not all -- depending on the NMUs going smoothly) programs using gnutls10 will be converted. Transiting from gnutls10 to 11 is a no-brainer and requires recompilation only. gcrypt1+gnutls7 have a different API. Conversion is rather trivial but requires work. It's the maintainers' job to do that. I'm sure that most of them will be happy if you help out. See [0] for the bug list. > I'm sure the security team will be happy to support three > different versions... The idea is to rip out gcrypt7+gnutls10, and to make gcrypt1+gnutls7 as unused as possible. [0] http://bugs.debian.org/cgi-bin/pkgreport.cgi?submitter=smurf%40debian.org -- Matthias Urlichs
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 03:00:45PM +0200, Adrian Bunk wrote: > On Thu, Aug 12, 2004 at 02:23:00PM +0200, Jeroen van Wolffelaar wrote: > > I made a list of RC bugs that are still unfixed in sarge after they were > > fixed for over a month in sid. You would have known that if you > > subscribed to this list, but although you apparantly want to question > > the release team's quality, you don't. > > > > By the way, it isn't my job to track those bugs. It's indeed an issue, > > and you could help by propose a constructive solution and/or produce a > > list of relevant RC bugs, like I'm trying to do. > > It's still my opinion that it would be less work to simply freeze > unstable. That's my constructive solution. We disagree, and there is no point rehashing this yet again. > The Debian release management thinks freezing testing is less work. > That's OK (I have no influence on it - I'm not even a Debian developer), > but I do not plan to do anything of the work that is only caused by the > fact that testing is frozen. That's OK, but please take your disagreement with that and your posts that stem from this disagreement off this mailing list. Right now, it is simply not in the least constructive. debian-release is not a discussion list. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 04:06:18PM +0300, Riku Voipio wrote: > > If such an easy and clearly RC bug as #237071 which is already fixed in > > unstable isn't adressed in testing until today, something is definitely > > going wrong. And if it was Jeroen's job as you said, he isn't doing it > > properly. > > > It will be worse between "28 August 2004" and "16 September 2004" > > when many hundred packages with a more recent version than in unstable > > whether sarge have to be evaluated and fixed during only three weeks. > > > This extra work is a price you have to pay for freezing testing, but if > > it isn't done properly and very fast, it might result in serious delays > > of the release. > > What would really be needed would be proper version tracking in BTS, > so that bugs get closed by a specific version, and we could search > all bugs affecting specific versions of packages. >... You will never find all issues in the BTS. E.g. the BTS doesn't tell you that the unstable package of SpamAssassin contains a fix for a potential DoS attack. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Who checks for bugs fixed in unstable but not in sarge?
> If such an easy and clearly RC bug as #237071 which is already fixed in > unstable isn't adressed in testing until today, something is definitely > going wrong. And if it was Jeroen's job as you said, he isn't doing it > properly. > It will be worse between "28 August 2004" and "16 September 2004" > when many hundred packages with a more recent version than in unstable > whether sarge have to be evaluated and fixed during only three weeks. > This extra work is a price you have to pay for freezing testing, but if > it isn't done properly and very fast, it might result in serious delays > of the release. What would really be needed would be proper version tracking in BTS, so that bugs get closed by a specific version, and we could search all bugs affecting specific versions of packages. Lacking that, RC bugs should be kept open (but tagged sarge) until the package migrates to testing. To achieve that, I think the best way would be a combination of reminding developers to keep their RC bugs tagged sarge on the next release update on d-d-a, and concerned volunteers like you who can keep an eye on debian-bugs-rc mailing list and reopen + tag any inadvertently closed RC bugs. -- Riku Voipio| riku.voipio at iki.fi | kirkkonummentie 33 |+358 44 5000343 --+-- 02140 Espoo| | dark> A bad analogy is like leaky screwdriver |
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 02:23:00PM +0200, Jeroen van Wolffelaar wrote: > > Rather than complaining and posing that people aren't doing their jobs, > and asking "which member of e release team is responsible for doing this > task?", you could _help_ instead. If the release management has announced a concrete timeline for the next release, this implies that the release management knows who handles such forseeable tasks. > I made a list of RC bugs that are still unfixed in sarge after they were > fixed for over a month in sid. You would have known that if you > subscribed to this list, but although you apparantly want to question > the release team's quality, you don't. > > By the way, it isn't my job to track those bugs. It's indeed an issue, > and you could help by propose a constructive solution and/or produce a > list of relevant RC bugs, like I'm trying to do. It's still my opinion that it would be less work to simply freeze unstable. That's my constructive solution. The Debian release management thinks freezing testing is less work. That's OK (I have no influence on it - I'm not even a Debian developer), but I do not plan to do anything of the work that is only caused by the fact that testing is frozen. > I'll soon generate that list again, but now also with all bugs regarding > frozen packages, as they won't proceed to sarge automatically. And now > that the full freeze comes closer, I'll include the bugs unfixed in > sarge for over 11 days. >... You will never find all issues if you only generate lists from the BTS. If you want to prove me wrong, please show that your scripts tell about the missing fix for a potential DoS attack in the sarge SpamAssassin. > --Jeroen cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 02:21:24PM +0200, Andreas Barth wrote: > * Adrian Bunk ([EMAIL PROTECTED]) [040812 14:10]: > > > > It will be worse between "28 August 2004" and "16 September 2004" > > when many hundred packages with a more recent version than in unstable > > whether sarge have to be evaluated and fixed during only three weeks. > > You're invited to help there. If you don't intend to help, then please > stop waisting our time. > i've not finished the thread titled like "debian culture" and i may be well OT, but as i'm perceiving this reply by Andreas it is one pretty adherent to the "debian culture", isn'it? please flame me in private, i don't want to clutter this ml. thanks domenico -[ Domenico Andreoli, aka cavok --[ http://people.debian.org/~cavok/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 02:02:38PM +0200, Adrian Bunk wrote: > On Thu, Aug 12, 2004 at 01:21:22PM +0200, Andreas Barth wrote: > > * Adrian Bunk ([EMAIL PROTECTED]) [040812 12:25]: > > AFAICS, Jeroen is keeping overall track now. > >... > > > Since I astonishingly discovered that this task hasn't been completed > > > for the frozen base packages until now, I'd like to know which member of > > > the release team is responsible for doing this task? > > > > Why do you think this task is not worked on, if you're not subscribed > > to -release? (And of course, Jeroen is not member of the release team, > > but I don't care for that as long as the job is done.) > > It was announced that "Official security support for sarge begins" and > the toolchain is in order after "12 August 2004". > > If such an easy and clearly RC bug as #237071 which is already fixed in > unstable isn't adressed in testing until today, something is definitely > going wrong. And if it was Jeroen's job as you said, he isn't doing it > properly. Rather than complaining and posing that people aren't doing their jobs, and asking "which member of e release team is responsible for doing this task?", you could _help_ instead. I made a list of RC bugs that are still unfixed in sarge after they were fixed for over a month in sid. You would have known that if you subscribed to this list, but although you apparantly want to question the release team's quality, you don't. By the way, it isn't my job to track those bugs. It's indeed an issue, and you could help by propose a constructive solution and/or produce a list of relevant RC bugs, like I'm trying to do. I'll soon generate that list again, but now also with all bugs regarding frozen packages, as they won't proceed to sarge automatically. And now that the full freeze comes closer, I'll include the bugs unfixed in sarge for over 11 days. > BTW: Who had the idea of including three different versions of GnuTLS in > sarge? I'm sure the security team will be happy to support three > different versions... You keep wanting to know who broke/did something, for what? Sue them? It helps better if you try to look for solutions and/or politely (!) note the problem to the relevant people (the maintainer(s), for example). --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber & MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl
Re: Who checks for bugs fixed in unstable but not in sarge?
* Adrian Bunk ([EMAIL PROTECTED]) [040812 14:10]: > On Thu, Aug 12, 2004 at 01:21:22PM +0200, Andreas Barth wrote: > > * Adrian Bunk ([EMAIL PROTECTED]) [040812 12:25]: > > Why do you think this task is not worked on, if you're not subscribed > > to -release? (And of course, Jeroen is not member of the release team, > > but I don't care for that as long as the job is done.) > It was announced that "Official security support for sarge begins" and > the toolchain is in order after "12 August 2004". > > If such an easy and clearly RC bug as #237071 which is already fixed in > unstable isn't adressed in testing until today, something is definitely > going wrong. #237071 is _not_ required for security suports. Furthermore, there is some difference between "keeping track" and "fixing everything". > And if it was Jeroen's job as you said, he isn't doing it > properly. It seems to me that you might just have a wrong opinion how jobs in debian are done. Nobody says: "Hereby, I order you, $SOMEBODY, to do $JOB.". Instead, people like Jeroen stand up, track problems by themselfs. Also, one package being seven days too old (and this means a specific problem on one specific platform) is not so bad as you just tell us all. > It will be worse between "28 August 2004" and "16 September 2004" > when many hundred packages with a more recent version than in unstable > whether sarge have to be evaluated and fixed during only three weeks. You're invited to help there. If you don't intend to help, then please stop waisting our time. Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Re: Who checks for bugs fixed in unstable but not in sarge?
On Thu, Aug 12, 2004 at 01:21:22PM +0200, Andreas Barth wrote: > * Adrian Bunk ([EMAIL PROTECTED]) [040812 12:25]: > > it's obvious that freezing testing requires the extra amount of work for > > someone to check every single frozen package with a more recent version > > in unstable whether sarge lacks required fixes. > > > > They might be RC bugs like #237071, but it's also possible that an > > upload fixed a security bug [1] or other RC issues that had no RC bug or > > no bug at all in the BTS [2]. > > > > Most of the work will be after the full freeze, but even the base freeze > > has over 40 such packages that require manual checking. > > > > It's obvious, that it wouldn't work to say the maintainers of the > > packages were responsible for this task. > > Well, of course, the base reponsibility is with the package > maintainer. That's the theory. But please don't pretend this would work in practice... > AFAICS, Jeroen is keeping overall track now. >... > > Since I astonishingly discovered that this task hasn't been completed > > for the frozen base packages until now, I'd like to know which member of > > the release team is responsible for doing this task? > > Why do you think this task is not worked on, if you're not subscribed > to -release? (And of course, Jeroen is not member of the release team, > but I don't care for that as long as the job is done.) It was announced that "Official security support for sarge begins" and the toolchain is in order after "12 August 2004". If such an easy and clearly RC bug as #237071 which is already fixed in unstable isn't adressed in testing until today, something is definitely going wrong. And if it was Jeroen's job as you said, he isn't doing it properly. It will be worse between "28 August 2004" and "16 September 2004" when many hundred packages with a more recent version than in unstable whether sarge have to be evaluated and fixed during only three weeks. This extra work is a price you have to pay for freezing testing, but if it isn't done properly and very fast, it might result in serious delays of the release. > Cheers, > Andi cu Adrian BTW: Who had the idea of including three different versions of GnuTLS in sarge? I'm sure the security team will be happy to support three different versions... -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Re: Who checks for bugs fixed in unstable but not in sarge?
* Adrian Bunk ([EMAIL PROTECTED]) [040812 12:25]: > it's obvious that freezing testing requires the extra amount of work for > someone to check every single frozen package with a more recent version > in unstable whether sarge lacks required fixes. > > They might be RC bugs like #237071, but it's also possible that an > upload fixed a security bug [1] or other RC issues that had no RC bug or > no bug at all in the BTS [2]. > > Most of the work will be after the full freeze, but even the base freeze > has over 40 such packages that require manual checking. > > It's obvious, that it wouldn't work to say the maintainers of the > packages were responsible for this task. Well, of course, the base reponsibility is with the package maintainer. AFAICS, Jeroen is keeping overall track now. > Since I astonishingly discovered that this task hasn't been completed > for the frozen base packages until now, I'd like to know which member of > the release team is responsible for doing this task? Why do you think this task is not worked on, if you're not subscribed to -release? (And of course, Jeroen is not member of the release team, but I don't care for that as long as the job is done.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
