Re: Bits from the RM
On Tue, Dec 02, 2003 at 02:47:12PM -0700, Joel Baker wrote: For those playing along at home, I suspect this would look a lot like: clone XX severity -1 important retitle -1 Causes massive failures on package foo assign -1 bar Would it be acceptable to add: forwarded XX http://bugs.debian.org/YY (where YY is the new BTS id for -1)? OR (easier; can be done in the one message) tag -1 upstream Otherwise, there is no way to filter out this bug report in BTS listings. However, both of these are intended for upstream bugs, not bugs in other related packages. Any better ideas? -- Brian May [EMAIL PROTECTED]
Re: Bits from the RM
On Sun, Dec 14, 2003 at 10:58:53AM +1100, Brian May wrote: Otherwise, there is no way to filter out this bug report in BTS listings. Not to mention the problem that if -1 is closed, XX needs to be manually too, but the owner of XX is not informed that -1 has been closed (AFAIK). -- Brian May [EMAIL PROTECTED]
Re: Bits from the RM
On Thu, 2003-12-11 at 12:41, Julian Gilbey wrote:
On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote:
We've often downplayed asking for help in favour of encouraging people
to *offer* to help, but since we're having problems, it's important to
try everything we can to overcome them. One of the more effective way
of getting useful help (as opposed to someone who says they'll help,
then does absolutely nothing), is to find some specific areas (or tasks)
that could use help, and then be specific in your request. There are
plenty of ways to do this, but at the moment, I think the best way is to
file a RFA (which we're redefining as Request For Assistance instead
of just Request For Adoption) report against wnpp, with some decent
information as to what assistance do you want (someone to take over the
package entirely? a co-maintainer? someone to work on some particular
area? someone to fix some particular bugs? what skills are required?).
I wonder whether it would be better to have two different labels: RFA
(Request For Adoption) and RFH (Request For Help)?
I can see a few eager-beavers seeing an RFA and uploading a replacement
package without even bothering to notice the Maintainer's just asking
for someone to fix a particularly fiendish bug on some architecture they
haven't got.
I guess what we're really going for intentwise is similar to the recent
GNOME Bounties thing.
I'm quite tempted to RF{A,H} a couple of the tricky wishlist bugs open
on libtool for example.
Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?
signature.asc
Description: This is a digitally signed message part
Re: Bits from the RM
On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote: We've often downplayed asking for help in favour of encouraging people to *offer* to help, but since we're having problems, it's important to try everything we can to overcome them. One of the more effective way of getting useful help (as opposed to someone who says they'll help, then does absolutely nothing), is to find some specific areas (or tasks) that could use help, and then be specific in your request. There are plenty of ways to do this, but at the moment, I think the best way is to file a RFA (which we're redefining as Request For Assistance instead of just Request For Adoption) report against wnpp, with some decent information as to what assistance do you want (someone to take over the package entirely? a co-maintainer? someone to work on some particular area? someone to fix some particular bugs? what skills are required?). I wonder whether it would be better to have two different labels: RFA (Request For Adoption) and RFH (Request For Help)? Julian -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Julian Gilbey, website: http://www.polya.uklinux.net/ Debian GNU/Linux Developer, see: http://people.debian.org/~jdg/ Visit http://www.thehungersite.com/ to help feed the hungry
Re: Bits from the RM
On Thu, Dec 04, 2003 at 06:31:02PM +0100, Jan Nieuwenhuizen wrote: Peter S Galbraith [EMAIL PROTECTED] writes: another package's was using convert in the build stage to convert some images and it was failing. The bug was elevated to release-critical. I don't think it would be fair to remove imagemagick from the distribution for such a case. From the other package's view, how fair was it to allow a partly broken version of Imagemagick enter the distribution, breaking the build on debian? There are plenty of bugs that should be fixed, certainly, but not all of them need to be release-critical. Cheers, -- Colin Watson [EMAIL PROTECTED]
Re: Bits from the RM
Hi aj, hi all others, On 2003-12-01 14:45 +1000, Anthony Towns wrote: Another possibility is to just drop packages that aren't maintained well enough. While this is somewhat attractive, it doesn't really serve our users any better than saying Why don't we just lower our standards? Basically I agree that instantly dropping 'bad' packages (or, worse, doing it automatically) is not the best option for users. But OTOH it cannot be the best solution neither to keep them forever, begging people to fix them without any success. Currently there are other issues that hold up the release (d-i and others), but when these things have settled, I have the impression that many users would prefer a release with some dropped packages over a never-ending testing period. At least I do :-) Because compiling one or two upstream packaes is much easier that always trying to keep in sync with testing or fiddling with backports.org. Just my EUR 0.02, have a nice weekend everybody! Martin
Re: Bits from the RM
On Sat, Dec 06, 2003 at 03:01:20PM +0100, Martin Pitt wrote: On 2003-12-01 14:45 +1000, Anthony Towns wrote: Another possibility is to just drop packages that aren't maintained well enough. While this is somewhat attractive, it doesn't really serve our users any better than saying Why don't we just lower our standards? Basically I agree that instantly dropping 'bad' packages (or, worse, doing it automatically) is not the best option for users. But OTOH it cannot be the best solution neither to keep them forever, begging people to fix them without any success. Sure. The best solution is to beg people to fix them _with_ success. Please focus your attentions in that direction. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgpk7TnFq5RrA.pgp Description: PGP signature
Re: Bits from the RM
Anthony Towns wrote: * #203339 - freeswan - Rene Mayrhofer FTBFS, patch in the bug log since July, no further activity I feel that I need to respond to that, after being mentioned here :) I fully admit that I have simply overlooked this one, because it is very easy to fix (and indeed has been fixed in my development tree, but didn't make it into the last upload). The reasons for not paying close attention to the other bugs for quite some time were mostly: - trying to get the whole kernel patch mess to work with the Debian kernels and still trying to retain compatibility with vanilla kernels - constantly fighting with the hack that's called NAT Traversal - a lot of real life issues since August, like moving into a new flat This is no real excuse and I should pay closer attention to _all_ RC bug reports, thanks for reminding me ;) PS: 2.01-4, which fixes at least some of the bugs, is stuck in the incoming queue since about 2003-11-20, nobody to blame for that of course. 2.04-1, which fixes all RC bugs and a few of the other ones, is currently in the works, but is having problems with the kernel-patch-freeswan package (because the changes from 2.01 to 2.04 upstream are larger than one would expect). If anybody wants to give it a try, please drop me a mail and I will send what I currently have. I could need some help in testing it with various kernel configurations PPS: I am not subscribed to debian-devel, so please CC me in replies. best regards, Rene
Re: Bits from the RM
Nikita V. Youshchenko [EMAIL PROTECTED] wrote: On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. A release critical bug in one package could be caused by a non-release critical bug in another package. Doesn't this mean that non-release critical bug in another package should become release critical? It has happenned, and I disagreed. I remember when Imagemagick's `convert' failed to convert certain files to certain other types. The `convert' binary is one of many in Imagemagick and it worked correctly for the vast majority of cases. But another package's was using convert in the build stage to convert some images and it was failing. The bug was elevated to release-critical. I don't think it would be fair to remove imagemagick from the distribution for such a case. Peter
Re: Bits from the RM
Anthony Towns aj@azure.humbug.org.au wrote on debian-devel-announce: I think the best way is to file a RFA (which we're redefining as Request For Assistance instead of just Request For Adoption) report against wnpp [cut] Third, personnel deployment. As a complement to the Request For Assistance stuff, we're also creating a new wnpp heading, OTA for Offer To Assist. Will http://www.debian.org/devel/wnpp/ be modified to reflect these new tags? (When it's official I'll modify debian-bug.el) Does the OTA bug get filled against the package you are offering to help with, or against wnpp? I presume against the package you are offering to help with, but then there's no easy way to see where help is offered overall. Thanks, Peter
Re: Bits from the RM
On Thu, Dec 04, 2003 at 10:38:10AM -0500, Peter S Galbraith wrote: Anthony Towns aj@azure.humbug.org.au wrote on debian-devel-announce: I think the best way is to file a RFA (which we're redefining as Request For Assistance instead of just Request For Adoption) report against wnpp [cut] Third, personnel deployment. As a complement to the Request For Assistance stuff, we're also creating a new wnpp heading, OTA for Offer To Assist. Will http://www.debian.org/devel/wnpp/ be modified to reflect these new tags? (When it's official I'll modify debian-bug.el) It is simple to do this and I also offered to do it for another proposal one day before the compromise. When I regain CVS access I can/will take care of it. Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/
Re: Bits from the RM
Peter S Galbraith [EMAIL PROTECTED] writes: another package's was using convert in the build stage to convert some images and it was failing. The bug was elevated to release-critical. I don't think it would be fair to remove imagemagick from the distribution for such a case. From the other package's view, how fair was it to allow a partly broken version of Imagemagick enter the distribution, breaking the build on debian? Jan. -- Jan Nieuwenhuizen [EMAIL PROTECTED] | GNU LilyPond - The music typesetter http://www.xs4all.nl/~jantien | http://www.lilypond.org
Re: Bits from the RM
On Dec 4, 2003, at 10:56, Peter S Galbraith wrote: But another package's was using convert in the build stage to convert some images and it was failing. The bug was elevated to release-critical. I don't think it would be fair to remove imagemagick from the distribution for such a case. More importantly, it'd be quite counterproductive to remove it. But having a RC bug does not mean the RM will remove it; indeed, he may even chose to 'sarge-ignore' the bug.
Re: Bits from the RM
On Dec 4, 2003, at 10:56, Peter S Galbraith wrote: But another package's was using convert in the build stage to convert some images and it was failing. The bug was elevated to release-critical. I don't think it would be fair to remove imagemagick from the distribution for such a case. More importantly, it'd be quite counterproductive to remove it. But having a RC bug does not mean the RM will remove it; indeed, he may even chose to 'sarge-ignore' the bug. Well, earlier in the thread people were talking about a scenario in which packages with RC bugs would automatically get removed. I was just pointing out that it wouldn't be fair to elevate a non-RC bug to RC simply because _another_ package uses that bit (and could probably work around it anyway).
Re: Bits from the RM
Frank Lichtenheld [EMAIL PROTECTED] wrote: On Thu, Dec 04, 2003 at 10:38:10AM -0500, Peter S Galbraith wrote: Anthony Towns aj@azure.humbug.org.au wrote on debian-devel-announce: I think the best way is to file a RFA (which we're redefining as Request For Assistance instead of just Request For Adoption) report against wnpp [cut] Third, personnel deployment. As a complement to the Request For Assistance stuff, we're also creating a new wnpp heading, OTA for Offer To Assist. Will http://www.debian.org/devel/wnpp/ be modified to reflect these new tags? (When it's official I'll modify debian-bug.el) It is simple to do this and I also offered to do it for another proposal one day before the compromise. When I regain CVS access I can/will take care of it. Thanks! Anyone know the answer to my second question? : Does the OTA bug get filled against the package you are offering to help : with, or against wnpp? I presume against the package you are offering : to help with, but then there's no easy way to see where help is offered : overall.
Re: Bits from the RM
On Thu, Dec 04, 2003 at 08:46:19PM -0500, Peter S Galbraith wrote: Anyone know the answer to my second question? : Does the OTA bug get filled against the package you are offering to help : with, or against wnpp? I presume against the package you are offering : to help with, but then there's no easy way to see where help is offered : overall. I'm proposing wnpp, but we'll see how it turns out. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004
Re: Bits from the RM
Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Dec 04, 2003 at 08:46:19PM -0500, Peter S Galbraith wrote: Anyone know the answer to my second question? : Does the OTA bug get filled against the package you are offering to help : with, or against wnpp? I presume against the package you are offering : to help with, but then there's no easy way to see where help is offered : overall. I'm proposing wnpp, but we'll see how it turns out. Cheers, aj Okay, thanks. I'll add those to debian-bug.el soonish then. Peter
Re: Bits from the RM
On Tue, Dec 02, 2003 at 09:33:39AM -0500, Sam Hartman wrote: aj == Anthony Towns aj@azure.humbug.org.au writes: aj or overloaded with work, or, for that matter, fixing compromised Debian aj servers -- do you think it's desirable and possible to: aj * for confirmed bugs with a known fix, upload a fixed package aj within a day or two of the patch been sent to the bug log No, I don't think it is always desirable to do this and certainly my maintinance style doesn't work well with this methodology. The problem is there is a fairly high fixed cost to building, testing and doing release management for a package. Those are really arguments that it's not always /possible/ -- if you weren't having to make those trade offs, I'm sure you'd love to upload fixes within a couple of days if you *could*: But I think dealing with normal bugs with confirmed fixes in a month or two is much more reasonable than a day or two. I'd feel differently if Debian was my primary job or if I found a style of maintaining packages that worked well for me with this goal. So I don't feel any urge to disagree with anything you've said there. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgprTD7CZeCPu.pgp Description: PGP signature
Re: Bits from the RM
On Mon, 2003-12-01 at 15:45, Anthony Towns wrote: Having critical, grave or serious bugs open for an extended period is simply not acceptable. Nor is it excusable. While it's possible that you mightn't have the skill required to fix some security bug, or mightn't have the time to respond to a bug report, you _do_ have both the time and the skill required to file a bug report either orphaning the package, or requesting its removal from the archive. Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. Nor *should* it be excused. You might think the exim bug's not worth worrying about -- after all, exim4's what people should be using, and multiline Conflicts work with most tools at least, and hey shouldn't we think about fixing the things that don't work anyway? So who cares? The reporter of the bug for one. The people affected by it for another. The people who look at the RC bug list and decide Oh, there are so many bugs already, there's no point filing another, it won't ever be fixed, and all the people affected by those bugs. The people who look at the RC bug list and decide that there's too much crap their to ever hope to make I agree the number of RCs should come down definitely. If automatic request for removals are made, they should be very prominently advertised, so that it is easy for the users of any particular package (who might also have pride/ utility invested in the package) can know to do something if they want to avert the pending situation. That could include simply emailing the DD packager (if I got four or five emails from different users, it would tell me my work is valued and I have a userbase worth looking after), or if they're possibly programmatically inclined to try to patch. And (as DD again) getting even a bad patch can be an even bigger motivation to do it right for your userbase. And if none of that happens, the package really, really should be removed from the archive. Is there a conspiracy against anything that might remove packages from the archive? :) a dent in. The people who would be willing to fix that bug, but don't want to have to deal with annoying the maintainer by doing an unauthorised NMU, or waste their time waiting for months for a an answer that'll probably be no, and who spend their time doing things other than Debian work. So, seriously, if you're inclined to think of the current state of much of the software we're distributing as anything but a mortifying shame, please correct your outlook. From how we're going at the moment, the best timeline we can produce is something like this. We'll need to reduce the RC bug count to 0 for at least major pieces of software like KDE, glibc and X. Each of those, or their dependencies, have had various RC bugs open almost continually since woody was released, so from that basis we can extrapolate to those packages continuing to have RC bugs for the next year and a half, and thus that we won't release for at lesat that long. Worse, those packages are the ones that most people like to avoid NMUing, so there's not much we can do on that score, either. What happens if say there are simply not enough people interested in GNOME for example, and the RC counts rise, and rise at an increasing rate, and we never release again? I guess my question is, what does it take for a package(s) to get removed? is that we can re-introduce 0-day NMUs, or some similar policy to get ... Another possibility is to just drop packages that aren't maintained well enough. While this is somewhat attractive, it doesn't really serve our users any better than saying Why don't we just lower our standards? I feel it might be the best whip there is - to start dropping packages. Whip the users - turn them into developers I say! The reason being, I think we've shown a few times now we can't whip ourselves. Of course, a little package dropping might change that... Which is another possibility of course, and one that a number of maintainers seem to like when some of our policies cause problems that they don't want to bother fixing. It's certainly possible, and we have a procedure for it: argue your case on the -policy list. But concurrently with that, you *still* need to fix your packages -- if you're convincing, you can then remove the fix later, if you feel the package is better And this is what? an observation and nothing more. It might be useful for some, I don't know. (Me personally - you naughty DD, not fixing your RC because you disagree with policy - shame, shame! - just doesn't do anything for me. I need a whip :) off without it.
Re: Bits from the RM
Anthony Towns wrote: [...] Fallback plans are important though, and in this case if we're not able to get in a position where maintainers are able to keep control of their RC bug count (which is to say, keep it at zero), we'll have to consider more drastic measures. An obvious one is to transfer packages that aren't being maintained at an acceptable level to new maintainers, whether the existing maintainer likes it or not. Some simple measures for this are things like has this package had any RC bug open for more than a month or two, or has this package had an RC bug open for more than a week or so without any response. Even if you ignore all of the preceeding message, you might like to ensure that those two criteria never apply to you. Would it be a silly idea to consider having something official in policy (or somewhere) outlining a minimal set of QA standards that every debian developer agrees to abide by (in the future as a standard part of the NM process), with the up-front understanding that some kind of intervention process (which should obviously have built-in flexibility, but should be able to ultimately, and as a last resort, result in loss of packages and/or developer status) can/will be entered into otherwise? A few fair, open, clear standards, a level playing field, all very sensible, no surprises for anyone. -- Stephen M. Gava [EMAIL PROTECTED]
Re: [debian-devel] Re: Bits from the RM
A levelezm azt hiszi, hogy Zenaan Harkness a kvetkezeket rta: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. Agreed. But beware, because we could end up with having a lot of blue users and maintainers. To make the thing more efficient, a good mental approach should be developed. Maybe making a request for removal special in some ways? I think there are two things to consider: -make the fact as public as possible, so both the userbase and the other developers be notified. Publicize at least two weeks before the deadline. -educate users and developers about how can they motivate the maintainer to do her job well: the RFR report should include a text explaining why the package would be removed, what one can do to prevent this, what is the right attitude when one communicates with the maintainer
Re: Bits from the RM
On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: Hrm. ] $ grep Harkness /var/lib/apt/lists/*_*; echo $? ] 1 Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? It could, but it shouldn't be -- requests for removal should happen after the analysis of whether it should be removed and what effect that'll have has been done, not before. What happens if say there are simply not enough people interested in GNOME for example, and the RC counts rise, and rise at an increasing rate, and we never release again? That's not a very interesting hypothetical -- there're plenty of people interested in getting Gnome to work on Debian. The aim is to focus on *fixing* the bugs, not remove the packages, and while threats can motivate sometimes (although they often do the opposite too), it's not really where we want to focus our attention or energies. I feel it might be the best whip there is - to start dropping packages. Whip the users - turn them into developers I say! Nice idea, but it's not really possible; our n-m process just isn't efficient enough for that to happen. And this is what? an observation and nothing more. It might be useful for some, I don't know. (Me personally - you naughty DD, not fixing your RC because you disagree with policy - shame, shame! - just doesn't do anything for me. I need a whip :) Fundamentally, as a package maintainer you need to be responsible to yourself. It's not anyone else's job to come along and make sure you're doing the right thing, it's yours. If you can't do that, or don't want to, you should give the package to someone else, and contribute as a co-maintainer or by filing patches. Allow people to demonstrate that they are lazy, and they will. How about we let people demonstrate that they're responsible, and capable of being left alone? Can't speak to the random crackpot thing :), but I feel we need to start kicking some serious DD butt. In the end, that's not something we do. Everyone here's a volunteer, and that means we get to appreciate what they provide, and accept the limits of their contribution. We don't get to kick their butt, we don't get to whip them into shape, we don't get to beat them until morale improves. Certainly, there might come a point where we need to say look, someone else can do a better job than you're doing, please get out of their way and let them, but most of the time that's not actually the case, no matter how it seems, and most of the time you're not just going to get the package maintained somewhat better, you're also going to have the developer you're replacing quit the project in irritation and disgust. Almost all the time, it's far better to ensure that maintainers have access to the help they want, and let them decide who's in a position to replace them, and who's not. A similar approach is to fix things quickly -- if you get a bug about some spelling mistakes, or a simple patch to apply, do them straight away. How can this be encouraged? How do you change entrenched human habitual behaviour? The first step is admitting there's a problem. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004 pgpybWnI1UbRF.pgp Description: PGP signature
Re: Bits from the RM
On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. A release critical bug in one package could be caused by a non-release critical bug in another package. -- Brian May [EMAIL PROTECTED]
Re: Bits from the RM
In article [EMAIL PROTECTED], Anthony Towns aj@azure.humbug.org.au wrote: Without having evaluated null hypotheses or done exhaustive analyses, the correlation nevertheless seems fairly convincing. To put it bluntly, our regular package maintainers are doing such a bad job that without significant assistance from NMUs, about 6% of the archive fails to meet even our _absolute minimum_ expectations. That's bad. It would be bad even if the 6% was random junk that no one uses or cares about, or was a bunch of packages that were so complicated no one knows how to fix them, which is probably what you're thinking. Unfortunately, it's even worse than that. Consider the following examples: I really think you should look at the activity on a bug as well. If there's a grave bug filed against a package, see if there's any reply from the maintainer in that bug report. Sure, a grave bug might be open for a month, and if the maintainer ignores it that is very bad, but if there's an active discussion going on on the relevant [EMAIL PROTECTED] address you can't say the maintainer is ignoring it. Just my EUR .02 Mike.
Re: Bits from the RM
On 20031201T144509+1000, Anthony Towns wrote: * #208646 - grep-dctrl - Antti-Juhani Kaijanaho unspecified problems with version in unstable, should take a couple of days to fix, no activity since September The unspecified problems are mainly recorded in the other open bugs against that package. The main issue is that the rewrite is not yet as good quality-wise as the old version (which is in testing), and thus I'd prefer to release the old version instead of the new one unless I am able to fix the new one in time. The current unstable version probably does not belong in unstable according to the new definition of what unstable is, but the rewrite went in a week or two before the new definition was published, and I haven't had the energy to arrange having the old version again in unstable and then uploading the new one to experimental (when I have that kind of energy, I'd prefer to put it to fixing the new package). That said, it has been too long since I last looked at grep-dctrl. I'll try to fix that in a couple of days :) I can only say that my teaching duties have exhausted me during the autumn. -- Antti-Juhani Kaijanaho, Debian developer http://www.iki.fi/gaia/ signature.asc Description: Digital signature
Re: [debian-devel] Re: Bits from the RM
On Tue, 2003-12-02 at 18:12, Magosnyi rpd wrote: A levelezm azt hiszi, hogy Zenaan Harkness a kvetkezeket rta: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. Agreed. But beware, because we could end up with having a lot of blue users and maintainers. To make the thing more efficient, a good mental approach should be developed. Maybe making a request for removal special in some ways? I think there are two things to consider: -make the fact as public as possible, so both the userbase and the other developers be notified. Publicize at least two weeks before the deadline. -educate users and developers about how can they motivate the maintainer to do her job well: the RFR report should include a text explaining why the package would be removed, what one can do to prevent this, what is the right attitude when one communicates with the maintainer Excellent points, thanks. Zenaan -- Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/ * Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: Bits from the RM
On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. A release critical bug in one package could be caused by a non-release critical bug in another package. Doesn't this mean that non-release critical bug in another package should become release critical?
Re: Bits from the RM
On Tue, 2003-12-02 at 18:09, Anthony Towns wrote: On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: ] $ grep Harkness /var/lib/apt/lists/*_*; echo $? ] 1 It's not much (directly) Debian related (yet), but: I'd be in NM but for the keyservers and NM registration page being down. I have packaged fastdep, and it is being reviewed, and has been through a few rounds of suggestions and repackaging: http://homepages.ihug.com.au/~zenaan/zenaan/files/ Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? It could, but it shouldn't be -- requests for removal should happen after the analysis of whether it should be removed and what effect that'll have has been done, not before. OK I feel it might be the best whip there is - to start dropping packages. Whip the users - turn them into developers I say! Nice idea, but it's not really possible; our n-m process just isn't efficient enough for that to happen. OK. I was thinking more of - if they are told their favourite package is about to get removed (it's a stick for the users of the package, not only the developer), then the user might be motivated to at least send an email to someone, and slowly get educated - if nothing else, about sending emails. That is a useful part of the process. My intention is how can this be emphasized. And this is what? an observation and nothing more. It might be useful for some, I don't know. (Me personally - you naughty DD, not fixing your RC because you disagree with policy - shame, shame! - just doesn't do anything for me. I need a whip :) Fundamentally, as a package maintainer you need to be responsible to yourself. It's not anyone else's job to come along and make sure you're doing the right thing, it's yours. If you can't do that, or don't want to, you should give the package to someone else, and contribute as a co-maintainer or by filing patches. Except it appears the current process of expecting the developer to realise at what point this has occured by themself, is not efficient enough given current size of debian + desired release schedules + current process for [notifying|whipping] developers. Allow people to demonstrate that they are lazy, and they will. How about we let people demonstrate that they're responsible, and capable of being left alone? Definitely. I'm sorry if my comments were not smileyed enough. I understand that I was presenting an extreme viewpoint. It was more for the point of getting the viewpoint down (and I was hoping in a lighthearted way). Can't speak to the random crackpot thing :), but I feel we need to start kicking some serious DD butt. In the end, that's not something we do. Everyone here's a volunteer, and that means we get to appreciate what they provide, and accept the limits of their contribution. We don't get to kick their butt, we don't get to whip them into shape, we don't get to beat them until morale improves. :) Point taken (I found your paragraph above pretty humorous, in a good way). Certainly, there might come a point where we need to say look, someone else can do a better job than you're doing, please get out of their way and let them, but most of the time that's not actually the case, I would be the first to give a developer who desires to continue working on their package and being a maintainer, etc, every possible opportunity and support to do so (eg. deferring RC-driven package removals, etc). Thanks for clarifying this point though - I agree it is central to The Debian Way. We are all volunteers and that is understood. I'm just guessing there might be some additional email notifications or whatever, that can raise the awareness a little, in alignment with what you first proposed. no matter how it seems, and most of the time you're not just going to get the package maintained somewhat better, you're also going to have the developer you're replacing quit the project in irritation and disgust. Almost all the time, it's far better to ensure that maintainers have access to the help they want, and let them decide who's in a position to replace them, and who's not. That shouldn't sound in conflict to what I wrote. I'm in agreement here. A similar approach is to fix things quickly -- if you get a bug about some spelling mistakes, or a simple patch to apply, do them straight away. How can this be encouraged? How do you change entrenched human habitual behaviour? The first step is admitting there's a problem. Good point. Thanks for your very measured response. I do apologise if my email came across too harshly. cheers zenaan -- Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/ * Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: Bits from the RM
On Tue, 2003-12-02 at 18:56, Brian May wrote: On Tue, Dec 02, 2003 at 05:32:59PM +1100, Zenaan Harkness wrote: Can requesting removal from archive be automated, to occur say after 3 weeks of inactivity of rc/grave/serious bug? As a DD, I assume there is some pride and/ or utility in having your package in the archive. This would give you a little no nonsense wakeup call I would guess. And if *even the packager themselves* do not have enough pride/ utility value in worrying at that point, then it is likely better to get removed. A release critical bug in one package could be caused by a non-release critical bug in another package. That the former package's maintainer must fix I guess? Is this a particularly common occurrence? ta zen -- Debian Enterprise: A Custom Debian Distribution: http://debian-enterprise.org/ * Homepage: http://soulsound.net/ * PGP Key: http://soulsound.net/zen.asc * Please respect the confidentiality of this email as sensibly warranted.
Re: Bits from the RM
On Tue, Dec 02, 2003 at 10:34:26AM +0200, Antti-Juhani Kaijanaho wrote: That said, it has been too long since I last looked at grep-dctrl. I'll try to fix that in a couple of days :) I can only say that my teaching duties have exhausted me during the autumn. And hey, if you manage to fix it in anything approaching a couple of days, you'll be able to upload it at the next *possible* moment. Go you! Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Linux.conf.au 2004 -- Because we can. http://conf.linux.org.au/ -- Jan 12-17, 2004
Re: Bits from the RM
On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote: A release critical bug in one package could be caused by a non-release critical bug in another package. How? If the bug is caused by a problem in another package then it should be reassigned (and more importantly fixed). The bug is still RC, even if it only affects dependent packages -- .''`. Mark Howard : :' : `. `' http://www.tildemh.com `- [EMAIL PROTECTED] | [EMAIL PROTECTED] | [EMAIL PROTECTED]
Re: Bits from the RM
On Mon, Dec 01, 2003 at 02:45:09PM +1000, Anthony Towns wrote: Hello world, Hello aj. * LSB 1.3 compatibility mostly achieved (LSB non-compliance issues are now Release Critical; bugs should be filed and addressed by the LSB team, which hangs around the debian-lsb mailing list. Only one compliance issue remains unfixed in sid. LSB 2.0 compliance will be trickier, but will hopefully be being worked on well before the next release.) Just a note (and please bear in mind that I'm a LSB novice): I just noticed that lsbdev has a number of outstanding bugs and is not updated to the latest upstream release (1.3) as described in #188955 and #221287. Even if it's not in testing, and thus not a RC problem per se, could the LSB team please help the maintainer upgrade to a new version? (which would probably fix #194986, #179986, #218081) Thanks Javi signature.asc Description: Digital signature
Re: Bits from the RM
aj == Anthony Towns aj@azure.humbug.org.au writes: aj or overloaded with work, or, for that matter, fixing compromised Debian aj servers -- do you think it's desirable and possible to: aj * for confirmed bugs with a known fix, upload a fixed package aj within a day or two of the patch been sent to the bug log No, I don't think it is always desirable to do this and certainly my maintinance style doesn't work well with this methodology. The problem is there is a fairly high fixed cost to building, testing and doing release management for a package. It takes me about an afternoon to do a PAM or OpenAFS release even if I change one line. OK, for a one line change I can probably get that down to two hours or so. It's a lot easier for me if I batch bugs together and if I did not do so, I'd be even more behind than I already am. I certainly think that expediting package uploads for RC bugs is a critical responsibility I as a maintainer have. But even if someone else claims to have tested a bug, I'm going to be the one signing the package; I'm taking responsibility. So I must spend the time necessary to understand the fix, confirm the fix and do the release engineering cruft I do for every release. Clearly this can be taken too far; pam is an excellent example of a package where I've let things slip enough that I'm having difficulty digging myself out of the hole. But I think dealing with normal bugs with confirmed fixes in a month or two is much more reasonable than a day or two. I'd feel differently if Debian was my primary job or if I found a style of maintaining packages that worked well for me with this goal.
Re: Bits from the RM
On Tue, Dec 02, 2003 at 05:09:37PM +1000, Anthony Towns wrote: What happens if say there are simply not enough people interested in GNOME for example, and the RC counts rise, and rise at an increasing rate, and we never release again? That's not a very interesting hypothetical -- there're plenty of people interested in getting Gnome to work on Debian. The aim is to focus on *fixing* the bugs, not remove the packages, and while threats can motivate sometimes (although they often do the opposite too), it's not really where we want to focus our attention or energies. I agree that GNOME is not a very good example here. Let me propose another: The ARM port. I realize the examples thus far have been in regard to packages, not ports, but at what point does it make sense to say OK, the foo port has held up the release of sarge by virtue of not having a working installer. It is going to be removed from the list of supported platforms for sarge. A quick look at http://www.debian.org/devel/debian-installer/ports-status indicates that, for some platforms, the situation is pretty grim. ARM, for example, hasn't been touched since March, and doesn't even have a working kernel for the installer. m68k is not a whole lot better, but has at least seen some recent activity. Where are the people who originally thought it would be fun to port Debian to some of these architectures? How long do we wait for them? Clearly AJ's message to debian-devel-announce on August 19 announcing a release goal of December 1 didn't inspire any new activity. This gives the appearance that the ARM port maintainers simply don't care if sarge gets released at all. This is very discouraging. I don't want to come across sounding too harsh; I run Debian on a number of architectures besides x86 and appreciate its multi-platform support. But, if those who work on Debian on a given platform are no longer interested in putting in the effort necessary to maintain that architecture, we really should rethink our committment to it. noah pgpw6AT1yxzYE.pgp Description: PGP signature
Re: Bits from the RM
Op di 02-12-2003, om 14:46 schreef Mark Howard: On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote: A release critical bug in one package could be caused by a non-release critical bug in another package. How? A program could use some library for most of its core operation, and fail miserably because of a little bug in said library. This bug could result in the entire package becoming useless, thus would be a grave bug: grave makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. grave is an RC severity. If that program would not use everything available in the buggy library, it could be the case that the right severity for the bug against the library would be either important or normal; consider the possibility of a graphical library which does 3D rendering mostly, but has the possibility of doing 2D graphics as well. A bug in the 2D rendering bits of that library would not be grave (maybe not even important) for that library, although it would certainly be valid to file it as a grave bug against any package that only uses said library for the 2D rendering possibilities. Since important and normal bugs are not RC bugs... (blatantly ignoring the fact that the RM and his team can choose to ignore RC bugs, or make bugs RC if they're not really RC by themselves here...) If the bug is caused by a problem in another package then it should be reassigned (and more importantly fixed). Of course. The bug is still RC, even if it only affects dependent packages. Not always. -- Wouter Verhelst Debian GNU/Linux -- http://www.debian.org Nederlandstalige Linux-documentatie -- http://nl.linux.org Stop breathing down my neck. My breathing is merely a simulation. So is my neck, stop it anyway! -- Voyager's EMH versus the Prometheus' EMH, stardate 51462. signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: Bits from the RM
On Tue, Dec 02, 2003 at 12:27:00PM -0500, Noah L. Meyerhans wrote: release goal of December 1 didn't inspire any new activity. This gives the appearance that the ARM port maintainers simply don't care if sarge gets released at all. This is very discouraging. If that is what happens, then I would say I simply don't care if sarge is not released for ARM. of architectures besides x86 and appreciate its multi-platform support. Likewise; I run it on three different architectures. But, if those who work on Debian on a given platform are no longer interested in putting in the effort necessary to maintain that architecture, we really should rethink our committment to it. That is very true. -- John
Re: Bits from the RM
On Tue, Dec 02, 2003 at 01:46:02PM +, Mark Howard wrote: On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote: A release critical bug in one package could be caused by a non-release critical bug in another package. How? If the bug is caused by a problem in another package then it should be reassigned (and more importantly fixed). The bug is still RC, even if it only affects dependent packages Wouter already answered the The bug is still RC part. However, one point he didn't mention is that if the bug is reassigned in to the other, people will continue to be affected by the bug against the package, look up bug reports, not find anything, and resubmit a new bug report. If you keep at least one grave bug report open against the broken package, then it lets its users know that this is a known problem, and they can be redirected towards the real bug report against the real package. -- Brian May [EMAIL PROTECTED]
Re: Bits from the RM
On Tue, Dec 02, 2003 at 09:33:39AM -0500, Sam Hartman wrote: [...] It takes me about an afternoon to do a PAM or OpenAFS release even if I change one line. OK, for a one line change I can probably get that down to two hours or so. It's a lot easier for me if I batch bugs together and if I did not do so, I'd be even more behind than I already am. [...] pam is an excellent example of a package where I've let things slip enough that I'm having difficulty digging myself out of the hole. With some (creative?) quoting, this reads like a perfect example for the request for assistance-program which Anthony announced. Although I think pam and openafs aren't the simplest packages. My 2 cents as a non-maintainer don't really matter though :) Greetings, Chris Niekel -- I've been down so long, if I'd cheer up, I'd still be depressed. - Lisa Simpson, Moanin' Lisa Blues. pgpI97zJhuZsg.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Dec 03, 2003 at 07:17:57AM +1100, Brian May wrote: On Tue, Dec 02, 2003 at 01:46:02PM +, Mark Howard wrote: On Tue, Dec 02, 2003 at 06:56:13PM +1100, Brian May wrote: A release critical bug in one package could be caused by a non-release critical bug in another package. How? If the bug is caused by a problem in another package then it should be reassigned (and more importantly fixed). The bug is still RC, even if it only affects dependent packages Wouter already answered the The bug is still RC part. However, one point he didn't mention is that if the bug is reassigned in to the other, people will continue to be affected by the bug against the package, look up bug reports, not find anything, and resubmit a new bug report. If you keep at least one grave bug report open against the broken package, then it lets its users know that this is a known problem, and they can be redirected towards the real bug report against the real package. For those playing along at home, I suspect this would look a lot like: clone XX severity -1 important retitle -1 Causes massive failures on package foo assign -1 bar (The key trick is the cloning; it keeps the bugs tied in a way that makes the relationship clear, keeps the discussion history available, and still allows the bugs to be seen accurately, in the places they should be, and at severities that are accurate). -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpiVYa89Vfaf.pgp Description: PGP signature
Re: Bits from the RM
John Goerzen writes: On Tue, Dec 02, 2003 at 12:27:00PM -0500, Noah L. Meyerhans wrote: release goal of December 1 didn't inspire any new activity. This gives the appearance that the ARM port maintainers simply don't care if sarge gets released at all. This is very discouraging. If that is what happens, then I would say I simply don't care if sarge is not released for ARM. of architectures besides x86 and appreciate its multi-platform support. Likewise; I run it on three different architectures. But, if those who work on Debian on a given platform are no longer interested in putting in the effort necessary to maintain that architecture, we really should rethink our committment to it. That is very true. Hmmm s/interested in/capable of/ in some cases maybe, but yes I agree with you. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Re: Bits from the RM
On Wed, 20 Aug 2003 17:12:42 +0200 cobaco [EMAIL PROTECTED] wrote: KDE is not mission critical in the sense that when a user's KDE-instance crashes the KDE-instances of the other users will continue to run. Just like when -in that same organization with some thousands of X terminals- 1 X terminal has a hardware problem this is not a mission critical problem (for the organization, it may be considered a mission critical problem for the user of that particular terminal). No. There's no reason an end user should be considered a second-class user that gets buggy software simply because he's not at some large organization. There's no reason why it's OK for there to be a mission critical problem for ANY user, even if it's just one user. The end user should not find packages that may have persistent, repeated bugs that impair his ability to do what he wants with his system. The end user should not find packages that cause data loss or have security bugs because they were only tested for a couple weeks (on the 11 architectures and with the other elements of the system). To the best of the developers' ability, the stable releases of Debian are supposed to be STABLE, for all packages, for all architectures, for all users, and for all known purposes. This is not Debian: The Server Operating System. And of course, don't forget that there can always exist bugs that will cause the KDE instances of all of the users at this example organization. If the users at the organization happen to use the same application software for the same purposes, or are working on similar projects, then the mission critical problems that occur for one individual user would repeatedly occur for all users, and would impede or make impossible the successful completion of whatever projects that organization is working on. - Chris Hagar Chris Hagar
Re: Bits from the RM
El 22-ago-2003 a las 10:03:47, Adrian von Bidder escribió: Content-Description: signed data On Wednesday 20 August 2003 09:49, Adrian von Bidder wrote: ... what KDE, gcc, X, gnome versions will be in sarge? And what about postfix? 2.0 is in unstable quite a while and works ok. I guess it will make it to sarge. So, what do you think, since you wear the Postfix maintainer t-shirt? :) Regards. -- Teófilo Ruiz Suárez ||(teo)|| Sevilla, España [EMAIL PROTECTED] GnuPG Key ID: 420718E6 FPR: 0280 862C 064B FA76 9A1C EB64 5755 A66C 4207 18E6 pgp9GRulo27gJ.pgp Description: PGP signature
Re: Bits from the RM
On Thu, Sep 04, 2003 at 10:37:20AM +0200, Te?filo Ruiz Su?rez wrote: El 22-ago-2003 a las 10:03:47, Adrian von Bidder escribi?: And what about postfix? 2.0 is in unstable quite a while and works ok. I guess it will make it to sarge. So, what do you think, since you wear the Postfix maintainer t-shirt? :) I'm all for it. lamont
Re: Bits from the RM
On Wed, Aug 27, 2003 at 06:31:03PM -0500, Branden Robinson wrote: On Mon, Aug 25, 2003 at 09:58:31PM +0200, Sven Luther wrote: On Wed, Aug 20, 2003 at 08:11:55PM -0500, Branden Robinson wrote: Interested parties, please catch up on the last month's worth of traffic to the debian-x mailing list to get a feel for the environment. Maybe you could split the debian-x list some, it would make reading it easier. The signal to noise ratio has rather much degraded there these last month, especially with all the control.bugs.debian processed mails going to it. IMO, people who can't keep up with debian-x in its current state probably don't have the time to be the kind of committer who can measurably help me get 4.3.0 into sarge. Well, that is something, but notice that due to the big number of mostly uninformative 'processed' and other BTS mail, i missed the original pm2 bug you then forwarded to me, which would not have happened if debian-x was not so high volume. Face it, if you don't read it each day, you can quickly get 100+ new mails, which makes it a bit difficult to follow. I understand your need to have this info available in the mailing list, but interested people could as well subscribe to the PTS, no need to duplicate things. Replies could still be set to the list or something. At least splitting the automatically generated stuff to a second write only list would be nice, setting the reply-to or whatever of it to debian-x, this would be for SVN logs and bug report traffic. Or maybe lower the quantity of messages the bug report sends, no need to really include the processed messages, they don't really add that much information. Notice i just send to david a 4.2.1 upstream glint_drv.o with debugging log enabled, let's see what this will bring us as information. I will be availing myself more of help tags, though, so people could always scan the xfree86 bug list for bugs tagged help, and volunteer to help in specific cases. Effort could be coordinated simply via [EMAIL PROTECTED] Yep. Friendly, Sven Luther
Re: Bits from the RM
On Thu, Aug 28, 2003 at 01:31:51PM +0200, Sven Luther wrote: On Wed, Aug 27, 2003 at 06:31:03PM -0500, Branden Robinson wrote: IMO, people who can't keep up with debian-x in its current state probably don't have the time to be the kind of committer who can measurably help me get 4.3.0 into sarge. Well, that is something, but notice that due to the big number of mostly uninformative 'processed' and other BTS mail, i missed the original pm2 bug you then forwarded to me, which would not have happened if debian-x was not so high volume. Face it, if you don't read it each day, you can quickly get 100+ new mails, which makes it a bit difficult to follow. I understand your need to have this info available in the mailing list, but interested people could as well subscribe to the PTS, no need to duplicate things. Replies could still be set to the list or something. You could filter out X-PTS-Keyword: bts-control ... -- Colin Watson [EMAIL PROTECTED]
Re: Bits from the RM
On Thu, Aug 28, 2003 at 01:44:09PM +0100, Colin Watson wrote: On Thu, Aug 28, 2003 at 01:31:51PM +0200, Sven Luther wrote: On Wed, Aug 27, 2003 at 06:31:03PM -0500, Branden Robinson wrote: IMO, people who can't keep up with debian-x in its current state probably don't have the time to be the kind of committer who can measurably help me get 4.3.0 into sarge. Well, that is something, but notice that due to the big number of mostly uninformative 'processed' and other BTS mail, i missed the original pm2 bug you then forwarded to me, which would not have happened if debian-x was not so high volume. Face it, if you don't read it each day, you can quickly get 100+ new mails, which makes it a bit difficult to follow. I understand your need to have this info available in the mailing list, but interested people could as well subscribe to the PTS, no need to duplicate things. Replies could still be set to the list or something. You could filter out X-PTS-Keyword: bts-control ... Yes, and maybe i will, altough i have been trying to read all of it, but still its not the nicest solution. Friendly, Sven Luther
Re: Bits from the RM
On Mon, Aug 25, 2003 at 09:58:31PM +0200, Sven Luther wrote: On Wed, Aug 20, 2003 at 08:11:55PM -0500, Branden Robinson wrote: Interested parties, please catch up on the last month's worth of traffic to the debian-x mailing list to get a feel for the environment. Maybe you could split the debian-x list some, it would make reading it easier. The signal to noise ratio has rather much degraded there these last month, especially with all the control.bugs.debian processed mails going to it. IMO, people who can't keep up with debian-x in its current state probably don't have the time to be the kind of committer who can measurably help me get 4.3.0 into sarge. I will be availing myself more of help tags, though, so people could always scan the xfree86 bug list for bugs tagged help, and volunteer to help in specific cases. Effort could be coordinated simply via [EMAIL PROTECTED] -- G. Branden Robinson| Debian GNU/Linux |Yeah, that's what Jesus would do. [EMAIL PROTECTED] |Jesus would bomb Afghanistan. Yeah. http://people.debian.org/~branden/ | pgpevBDMDp06h.pgp Description: PGP signature
Re: Bits from the RM
On Mon, Aug 25, 2003 at 07:36:05PM -0400, Neil Roeth wrote: On Aug 19, Anthony Towns (aj@azure.humbug.org.au) wrote: * September 15th Last major changes to major packages uploaded to unstable * October 1st 1st test cycle, public request for comments Last minute fixes and changes to the installer * October 15th Final, last minute, low-risk bug fixes only They are not major packages, so September 15 does not apply. A new upstream release hardly guarantees there will be only final, last minute, low risk bug fixes required, so it would need to be uploaded well before October 15. If there is no set date, then I will just make sure they meet the relevant criteria by October 15. Note that the layout is: start date activity end date So you should start doing any last major changes to major packages for upload to unstable by sept 15th, and make sure you're finished doing them by oct 1st. (Although, if you're going to misinterpret it, far better to misinterpret the deadlines as two weeks earlier...) Otherwise, the best way to ensure that upstream changes are low-risk is to do a line by line review of the changes, and test it yourself. For minor updates to relatively small packages, this is generally feasible. Other ways are to do copious testing of it, upstream and down; and if there *is* copious upstream testing, to try to keep your .diff.gz as small as possible, so you get the most value you can from that testing. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpIoaABMuATL.pgp Description: PGP signature
Re: Bits from the RM
On Tue, 2003-08-26 at 01:01, Adam Heath wrote: Is there a debian machine I can access that has this problem? Yes. You can use vore, unstable chroot. p.
Re: Bits from the RM
At Mon, 25 Aug 2003 19:01:14 -0500 (CDT), Adam Heath wrote: On Fri, 22 Aug 2003, GOTO Masanori wrote: It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Hmm. I'm reminded of a problem on s390x. 64-bit arch, but when dpkg was initializing some variable, it only did it to the lower(or upper, can't recall) 32 bits. Later, it blew up. dpkg works fine with trex.debian.org dchroot unstable + my self built 2.3.2-1 (2003-07-08 cvs) using LD_LIBRARY_PATH, so it seems other issue. It's too bad valgrind doesn't work on non-i386. Is there a debian machine I can access that has this problem? The last 2 times some odd issue came up like this, one turned out to be a dpkg bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at the end of the buffer, when using mmap, on alpha). In both cases, it didn't take me long to track down(not more than half a day). Yes, you can check on vore.debian.org dchroot unstable. vore:~ dpkg Bus error Regards, -- gotom
Re: Bits from the RM
On Wed, Aug 20, 2003 at 08:11:55PM -0500, Branden Robinson wrote: On Wed, Aug 20, 2003 at 03:13:11AM -0500, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? An educated guess would produce: [...] XFree 4.3.0 (Branden wants this to happen...) If other people want it to happen as well, I need volunteers for the X Strike Force. I'm the only person doing significant commits lately. Interested parties, please catch up on the last month's worth of traffic to the debian-x mailing list to get a feel for the environment. Maybe you could split the debian-x list some, it would make reading it easier. The signal to noise ratio has rather much degraded there these last month, especially with all the control.bugs.debian processed mails going to it. Friendly, Sven Luther
Re: Bits from the RM
On Fri, 22 Aug 2003, GOTO Masanori wrote: It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Hmm. I'm reminded of a problem on s390x. 64-bit arch, but when dpkg was initializing some variable, it only did it to the lower(or upper, can't recall) 32 bits. Later, it blew up. It's too bad valgrind doesn't work on non-i386. Is there a debian machine I can access that has this problem? The last 2 times some odd issue came up like this, one turned out to be a dpkg bug(s390x), and one was a multi-year old bug in libc6 assem(memcpy error, at the end of the buffer, when using mmap, on alpha). In both cases, it didn't take me long to track down(not more than half a day).
Re: Bits from the RM
* Joe Drew | On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: | * Teófilo Ruiz Suárez | | | What about Apache? Should we change the apache2 package to apache? | | No. (Wearing apache apache2 maintainer hat.) | | What are the criteria for the apache package to become Apache 2? Seamless upgrade without loss of functionality (that includes modules), or making pigs fly. (choose one). -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bits from the RM
On Sat, Aug 23, 2003 at 01:26:20PM +0200, Tollef Fog Heen wrote: * Joe Drew | On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: | * Teófilo Ruiz Suárez | | | What about Apache? Should we change the apache2 package to apache? | | No. (Wearing apache apache2 maintainer hat.) | | What are the criteria for the apache package to become Apache 2? Seamless upgrade without loss of functionality (that includes modules), or making pigs fly. Pink Floyd already made the latter happen for the cover for their album Animals. The pig escaped though, and made it a beautiful story. http://www.myputney.co.uk/wandsworth/community-batterseapowerstation.htm http://www.floydianslip.com/discs/animals.htm /David -- /) David Weinehall [EMAIL PROTECTED] /) Northern lights wander (\ // Maintainer of the v2.0 kernel // Dance across the winter sky // \) http://www.acc.umu.se/~tao/(/ Full colour fire (/
Re: Bits from the RM
Tollef Fog Heen (2003-08-23 13:26:20 +0200) : * Joe Drew [...] | What are the criteria for the apache package to become Apache 2? Seamless upgrade without loss of functionality (that includes modules), or making pigs fly. 1. All you need for that is thrust (see Ginger, Mac and Rocky); 2. Debian prides itself on its web of thrust; 3. therefore the web servers in Debian do provide enough thrust. ...or am I missing something? :-) Roland. -- Roland Mas Lord of the rings? Show us. European Juggling Convention -- Svendborg, Denmark. http://ejc2003.dk
Re: Bits from the RM
* Roland Mas | Tollef Fog Heen (2003-08-23 13:26:20 +0200) : [...] | making pigs fly. | | 1. All you need for that is thrust (see Ginger, Mac and Rocky); | 2. Debian prides itself on its web of thrust; | 3. therefore the web servers in Debian do provide enough thrust. | | ...or am I missing something? :-) yes, the pigs. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bits from the RM
On Sat, Aug 23, 2003 at 03:13:40PM +0200, Roland Mas wrote: making pigs fly. 1. All you need for that is thrust (see Ginger, Mac and Rocky); 2. Debian prides itself on its web of thrust; 3. therefore the web servers in Debian do provide enough thrust. ...or am I missing something? :-) You aren't thrusting hard or often enough. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgpuoKc4DXAzK.pgp Description: PGP signature
Re: Bits from the RM
On Sat, Aug 23, 2003 at 03:39:14PM +0200, Tollef Fog Heen wrote: yes, the pigs. I think we already have some pigs in the Debian archive... -- Brian May [EMAIL PROTECTED]
Re: Bits from the RM
* Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `-
Re: Bits from the RM
On Wednesday 20 August 2003 09:49, Adrian von Bidder wrote: ... what KDE, gcc, X, gnome versions will be in sarge? And what about postfix? 2.0 is in unstable quite a while and works ok. I guess it will make it to sarge. cheers -- vbi -- Jack Nicklaus hit a golf shot that only gravity kept on this Earth. -- ESPN (the sports channel) pgpPETWcla0kK.pgp Description: signature
Re: Bits from the RM
On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: * Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) What are the criteria for the apache package to become Apache 2?
Re: Bits from the RM
On Fri, Aug 22, 2003 at 02:41:40PM -0400, Joe Drew wrote: On Fri, 2003-08-22 at 01:42, Tollef Fog Heen wrote: * Teófilo Ruiz Suárez | What about Apache? Should we change the apache2 package to apache? No. (Wearing apache apache2 maintainer hat.) What are the criteria for the apache package to become Apache 2? Having working ports of a reasonable number of the widely used Apache module packages might be a good start. (E.g., there are no packages today for php4 under Apache2, and if there were, much functionality would be missing due to thread-safe issues with php upstream.) -- Steve Langasek postmodern programmer pgpFJmPZUWmFI.pgp Description: PGP signature
Re: Bits from the RM
On Wed, 20 Aug 2003, Colin Watson wrote: On Wed, Aug 20, 2003 at 11:18:24AM -0600, Bruce Sass wrote: On Wed, 20 Aug 2003, cobaco wrote: I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 - 3.2 is evolutionary without big changes to what was already there. It does not take a big change to break software... e.g., openssh changed a message and the sftp kioslave broke http://bugs.kde.org/show_bug.cgi?id=51359 Not that I disagree with you, but frankly, the sftp kioslave was already broken. It should never have been written to depend on 'ssh -v' output. Ya, and it didn't manifest until a minor release of ssh or a patch release of KDE came along. ;-) - Bruce
Re: Bits from the RM
On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Bits from the RM
On Thu, Aug 21, 2003 at 08:56:31AM +0200, Marc Haber wrote: On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Quite confident, are we? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
Re: Bits from the RM
At Thu, 21 Aug 2003 00:17:27 +1000, Anthony Towns wrote: [1 text/plain; us-ascii (quoted-printable)] On Wed, Aug 20, 2003 at 08:49:33AM -0400, Matt Zimmerman wrote: On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote: Also make sure to include some leg room if you depend on packages that have a tendency to be buggy (glibc, for example). The new glibc has already stalled the progress into testing of a large number of packages, and the number of RC bugs still seems to be going up. How are we going to manage to produce a release in 6 months the face of this obstacle? The last time there was this sort of breakage, it took many months just to get glibc itself it sorted out. Yup. The difference is that this time we have a Glibc maintenance team that's able to work together effectively, has some experience with the package, and has a better understanding how important it is to get it fixed quickly. AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Note that (3) becomes ok to revert patches, (4) may be non-glibc bug. Well, they are still something hard work. :-) My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... Regards, -- gotom
Re: Bits from the RM
On Thu, 21 Aug 2003 17:22:38 +1000, Anthony Towns aj@azure.humbug.org.au wrote: On Thu, Aug 21, 2003 at 08:56:31AM +0200, Marc Haber wrote: On Wed, 20 Aug 2003 15:16:05 +0200, Josef Spillner [EMAIL PROTECTED] wrote: - the KDE release plan might be delayed (as well...) The sarge release plan _will_ be delayed. Quite confident, are we? I am only realistic. When in history did a non-trivial software product meet its release schedule? I am surely hoping for the best, but I seriously do expect sarge to be released in early 2004. Which is a pretty good track record if we actually reach that. Greetings Marc -- -- !! No courtesy copies, please !! - Marc Haber |Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG Rightful Heir | Fax: *49 721 966 31 29
Re: Bits from the RM
* GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Note that (3) becomes ok to revert patches, (4) may be non-glibc bug. Well, they are still something hard work. :-) (5) Breakage of all d-i boot images created in an environment with new libc. Seems to be related to libc6-pic and mklibs, bug will be filed against libc6-pic. Sebastian -- PGP-Key: http://www.mmweg.rwth-aachen.de/~sebastian.ley/public.key Fingerprint: A46A 753F AEDC 2C01 BE6E F6DB 97E0 3309 9FD6 E3E6
Re: Bits from the RM
On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?''
RE: Bits from the RM
cobaco [EMAIL PROTECTED] wrote: On 2003-08-20 15:33, John Goerzen wrote: tne pain of breaking desktops is no less when you consider how many more desktops we're talking about here. that's assuming that all those desktops crash at the same time no? No, it's assuming that all those desktops crash with the same average frequency (probability) per duration. Consider one s = 1 company server serving c = 1000 clients (used by one user each). Let's assume any one instance of a server software (e.g. Apache) crashes with a probability p_crash = 1% at any given time (i.e. it's down 1% of the time assuming a zero recovery time), and any one instance of a client software (e.g. Mozilla) does the same. Now the expected number of users u_affected who can't use the company's intranet at any given time is... ...due to server failures: s * p_crash * u_aff,s = 1 * 0.01 * 1000 = 10 ...due to client failures: c * p_crash * u_aff,c = 1000 * 0.01 * 1 = 10 (Of course, these sets of users do overlap, but that's not relevant here.) So, assuming an equal crashing probability (AKA stability) of server and client software, the pain of breaking desktops is no less than the pain of breaking servers. qed.
Re: Bits from the RM
On Thu, Aug 21, 2003 at 11:39:35AM +0200, Marc Haber wrote: I am only realistic. When in history did a non-trivial software product meet its release schedule? I am surely hoping for the best, but I seriously do expect sarge to be released in early 2004. Which is a pretty good track record if we actually reach that. Well, FreeBSD hits their 6-month release targets more often than they miss them (yes, they do miss them sometimes, generally not by very far). True, they've had practice at it; I don't expect the first attempt to be pretty. I do expect that we could manage to match them, if it becomes a consistant release goal to set a date and then hit it. :) Even 'early 2004' is, frankly, not nearly enough time to ensure something as large as KDE goes from 'stable' upstream release (assuming *they* make a Dec 8th release) to 'bugs shaken out, stable enough to not need to turn around and do an r1 release a few weeks later because it blows up on user machines', for values of 'early 2004' that I would find most likely (to wit, right *after* the holidays, since slipping too much would put us into releasing during them; though the Debian Christmas Release would be mildly entertaining :) -- Joel Baker [EMAIL PROTECTED],''`. Debian GNU NetBSD/i386 porter: :' : `. `' `- pgpE56YX0Cv4q.pgp Description: PGP signature
Re: Bits from the RM
On Thu, 21 Aug 2003, Anthony Towns wrote: On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? I'd be interested too. Haven't seen anything on -dpkg about it.
Re: Bits from the RM
On Thu, 2003-08-21 at 09:52, GOTO Masanori wrote: My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... I don't think the hppa glibc is as inscrutable as all that. The main problem seems to be that Carlos is the only person working on the bug, and he is only able to devote a limited amount of time to it. If and when we get to the point of hppa being the only outstanding glibc issue, we will just have to lean on some of the other PA guys to get involved. The main problem that is concerning me at the moment is the large number of reports of binary incompatibility with older versions. It's all very well to dismiss the difficulties with non-free software as somebody else's problem, but the fact that so many of these issues are cropping up all at once does suggest that glibc itself is doing something wrong. However, in absence of a reliable way to reproduce the bug using only free software, it is hard to see a way forwards. I will have a play with that antique inn that seemed to be experiencing trouble, and see if I can get a handle on it like that. p.
Re: Bits from the RM
On Wednesday, Aug 20, 2003, at 09:52 US/Eastern, Santiago Vila wrote: Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built? If by seriously consider you mean ignore all the arguments against it and proceed anyway then I sure hope not.
Re: Bits from the RM
At Thu, 21 Aug 2003 12:09:29 -0500 (CDT), Adam Heath wrote: On Thu, 21 Aug 2003, Anthony Towns wrote: On Thu, Aug 21, 2003 at 05:52:32PM +0900, GOTO Masanori wrote: AFAIK, the unresolved difficult bugs are: (1) hppa build (2) dpkg (setjmp/longjmp) on sparc (3) NIS (will be fixed?) (4) misterious apache on ia64 bug. Is there a bug# for (2)? If not, could someone forward the appropriate mails to the BTS for tracking, please? I'd be interested too. Haven't seen anything on -dpkg about it. It was reported by joshk on IRC, but I'm not still clear where this problem come from. Example: ultra30:~ dpkg -s libc6 | grep Version Version: 2.3.2-3 ultra30:~ dpkg -s dpkg | grep Version Version: 1.10.10 ultra30:~ dpkg Bus error dpkg works well with some options, but only typing `dpkg' breaks with bus error. It's not related with the existence of libc6-sparc64. From tracking with gdb, dpkg breaks setjmp()/longjmp(). The mysterious thing is that it works fine to compile gcc-3.2/gcc-3.3 without -O2 optimization. It's also ok with glibc 2.3.1-17, IIRC. Regards, -- gotom
Re: Bits from the RM
At 21 Aug 2003 17:29:16 +0100, Philip Blundell wrote: On Thu, 2003-08-21 at 09:52, GOTO Masanori wrote: My concern is (1) hppa build. If we can't get hppa glibc, we may need to drop it finally... I don't think the hppa glibc is as inscrutable as all that. The main problem seems to be that Carlos is the only person working on the bug, and he is only able to devote a limited amount of time to it. If and when we get to the point of hppa being the only outstanding glibc issue, we will just have to lean on some of the other PA guys to get involved. Indeed. My point is hppa is release architecture. So if toolchain and core library do not work well, then we can't release, or we drop it from release archs. The main problem that is concerning me at the moment is the large number of reports of binary incompatibility with older versions. It's all very well to dismiss the difficulties with non-free software as somebody else's problem, but the fact that so many of these issues are cropping up all at once does suggest that glibc itself is doing something wrong. However, in absence of a reliable way to reproduce the bug using only free software, it is hard to see a way forwards. I will have a play with that antique inn that seemed to be experiencing trouble, and see if I can get a handle on it like that. Yes, good point. I forgot to write about this binary incompatibility issue. It's numbered as (5) from my previous mail, and it's also concerned item. Regards, -- gotom
Re: Bits from the RM
On Aug 20, Theodore Ts'o ([EMAIL PROTECTED]) wrote: The real problem is that stable has a reputation of taking years and years before we manage to do a release, so people are always desperate to shove every last bit of functionality and new upstream release into it. What folks don't realize is that makes the problem worse, not better, by stretching out the release schedule. Bravo, well put. Better to have a hard freeze schedule, and then try to turn out new stable releases every 6-9 months. Then folks won't be so desperate to shove new things in and screw up the release. The problem, though, is the first such attempt take release schedules seriously and agressively (a) a really hardass RM, and (b) a certain amount of faith by the developers that we really can get our act together about short, regular, predictable releases. I'm completely in favor of (a) in order to improve the release frequency. I suppose that might come back to bite me someday, but so be it :-) As for (b): I firmly believe the critical element is some kind of plan with either specific times or milestones that we can work toward. Since ajt just sent out such a plan, I think we can do it. Some seem to think that we could get KDE3.2 into the next release and not stretch out the release schedule. That implies that it would not be very well tested and less stable than KDE 3.1. In my business, what you put at risk by releasing unstable software is large amounts of money, your job, or both. It is ludicrous to think that people who have to deploy Debian in such an environment would prefer that the new stable release contain the newest, barely tested, less stable versions of major packages rather than slightly older, better tested, more stable versions. -- Neil Roeth
Re: Bits from the RM
On Tue, Aug 19, 2003 at 12:47:44PM -0500, Adam Heath wrote: On Tue, 19 Aug 2003, Anthony Towns wrote: Dateline! [snip] So, where does dpkg 2.0 fit into this? I can commit to a 1 month finish date(from now), for implementing the features we desire for it. If by dpkg 2.0 you mean rewritten dpkg and dpkg-dev, it doesn't. There is no chance that a package management system that hasn't seen the light of day, let alone reached beta test, will be ready for release in four months, let alone one. If by dpkg 2.0 you mean 1.10.11 (ie, minor changes from 1.10.10 only), then I'm not sure why you're asking. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgpAtPPbUoFWN.pgp Description: PGP signature
Re: Bits from the RM
On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? greetings -- vbi [1] avoiding the term release goals here -- featured product: SpamAssassin - http://spamassassin.org pgpIKnwS5gr2w.pgp Description: signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: Content-Description: signed data On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? An educated guess would produce: GCC 3.3.1 Gnome 2.2 (2.4 will probably be out before freeze but whether it goes in is up to them...) [0] KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) XFree 4.3.0 (Branden wants this to happen...) Chris Cheney [0] http://www.gnome.org/start/2.3/
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 10:13, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? [1] http://developer.kde.org/development-versions/kde-3.2-release-plan.html - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/QzqP5ihPJ4ZiSrsRAnebAJ9zijYLaXNXKFdZFKgCfGdqINnVeACfceHe sQC4GkY64v7uhA/rERL7PA4= =Leye -END PGP SIGNATURE-
Re: Bits from the RM
cobaco == cobaco [EMAIL PROTECTED] writes: cobaco kde 3.2 release is slated for 8th december[1], is there any cobaco chance we'll wait for it, just so the outdated kde label doesn't cobaco apply again immediately after release? But does the first few paragraphs of RM's original message exactly trying to convey the message that if it is not considered stable for long enough, don't make it into stable? If so, something to be released during the original target release date doesn't seem to stand even slight chance! Regards, Isaac.
Re: Bits from the RM
Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? It's not KDE 4, so it doesn't really matter that much. And it probably won't be GNOME 2.4 either, so both desktops will be in there with their stable versions. Bye, Mike -- |=| Michael Piefel |=| Humboldt-Universität zu Berlin |=| Tel. (+49 30) 2093 3831
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 11:47, Isaac To wrote: cobaco == cobaco [EMAIL PROTECTED] writes: cobaco kde 3.2 release is slated for 8th december[1], is there any cobaco chance we'll wait for it, just so the outdated kde label doesn't cobaco apply again immediately after release? But does the first few paragraphs of RM's original message exactly trying to convey the message that if it is not considered stable for long enough, don't make it into stable? If so, something to be released during the original target release date doesn't seem to stand even slight chance! quoteBasically, it's the difference between having a sysadmin spending fifteen minutes every day or week tweaking your server to keep it running, or having a sysadmin come in for a week once a year to do a major upgrade./quote Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. Anyhow, just think it would be nice to avoid all the reviews going kde not up to date for a change. - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0lL5ihPJ4ZiSrsRAlPkAJ9rX5SIwtYaGORH6fBDc76CbqyD5QCgixHn NmN1H3kSNWFFz7L2EPYWblc= =QMK6 -END PGP SIGNATURE-
Re: Bits from the RM
cobaco == cobaco [EMAIL PROTECTED] writes: cobaco quoteBasically, it's the difference between having a sysadmin cobaco spending fifteen minutes every day or week tweaking your server cobaco to keep it running, or having a sysadmin come in for a week once cobaco a year to do a major upgrade./quote cobaco Note that the RM was talking about servers there, while kde is cobaco end-user software, big difference IMHO. Taking into account that cobaco kde isn't server-software and that kde won't do release if there cobaco are major bugs left I don't think stability should be a problem cobaco in this case. Why KDE cannot be used on servers (how about a X terminal server? You don't have to set it up?), and why on stable you do not expect a stable KDE? What I perceived: if you want an updated KDE, go run testing or unstable. If many people like a really updated KDE, one of them should act up and package a CVS version in experimental. I really don't see the point to let in really new packages that we don't know whether other packages are broken by it. And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. Regards, Isaac.
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:10, Michael Piefel wrote: Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? It's not KDE 4, so it doesn't really matter that much. there's no big architectural changes but there's considerable improvement, looking at the feature_plan I see: + merging of kroupware_branch, and inclusion of kontact + kdevelop 3.0., and umbrello, + new vim kpart, standalone kregexeditor + new apps kbrug, kig, kgpg, Juk Not stated explictly, so not sure, but I think the the remaining safari-patches to html will also be applied for 3.2 And it probably won't be GNOME 2.4 either so both desktops will be in there with their stable versions. actually that's just it, if we release on 1st december and KDE releases on 8th december, then 7 days after release we no longer have the stable KDE release in stable, which is a rather unfortunate timing, no? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q0/D5ihPJ4ZiSrsRAtbpAJ4nsXOFCuoNu0vkLo9EBB4AM+ucJACfR6de VsOZiTWQ6syfmngdipjMExM= =9MwH -END PGP SIGNATURE-
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:10:18PM +0200, Michael Piefel wrote: | Am 20.08.03 um 11:08:28 schrieb cobaco: | kde 3.2 release is slated for 8th december[1], is there any chance we'll wait | for it, just so the outdated kde label doesn't apply again immediately after | release? | | It's not KDE 4, so it doesn't really matter that much. There were pretty major changes between KDE 3 and KDE 3.1. As a Debian user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( Cameron.
Re: Bits from the RM
On Wed, Aug 20, 2003 at 11:08:28AM +0200, cobaco wrote: On 2003-08-20 10:13, Chris Cheney wrote: On Wed, Aug 20, 2003 at 09:49:03AM +0200, Adrian von Bidder wrote: On Tuesday 19 August 2003 08:49, Anthony Towns wrote: I'm all for aggressive goals, let's aim for sometime in December -- how about 2003-12-01 00:00:00 UTC? Do you have some Official Opinion(tm)[1] as the RM about what KDE, gcc, X, gnome versions will be in sarge? KDE 3.1.4 (KDE 2.2 _will not_ stay in sarge!) kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? There's a big difference between being out of date by a major version and by a minor version. We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. -- Colin Watson [EMAIL PROTECTED]
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:36, Isaac To wrote: cobaco == cobaco [EMAIL PROTECTED] writes: Why KDE cannot be used on servers (how about a X terminal server? You don't have to set it up?) not what I meant: off course it can be used on a server, so can the gimp, this doesn't make the gimp server software does it? All I'm saying is that KDE, when installed on a server is not a mission-critical piece of software. Besides major bugs would've been filtered out by the kde release proces, and minor bugs would not interfere with functioning of a server. and why on stable you do not expect a stable KDE? kde 3.2. will be the stable kde release come 8 december What I perceived: if you want an updated KDE, go run testing or unstable. If many people like a really updated KDE, one of them should act up and package a CVS version in experimental. unless I'm completely mistaken the kde packagers commit there directly in kde cvs. I really don't see the point to let in really new packages that we don't know whether other packages are broken by it. last couple of kde releases there have been deb packages available for testing with the kde release candidates, which were used rather extensively, assuming this continues for kde 3.2 these packages would be tested And I don't mind Debian stable being marked as always having an outdated KDE. It is supposed to work that way. While I agree it wouldn't be the end of the world, and it has certainly been that way sofar, I most definately do _NOT_ agree that it is supposed to work that way. Stable having outdated software is an (undesired) side-effect from keeping the stable release stable. If we can have up-to-date software that is also reasonably stable (again this is end-user software, not server-software) this is better no? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html h http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q1rc5ihPJ4ZiSrsRAiRzAKCGaPLuFHiE7LddNSm7CB4OCI/8zQCeLVJK 82GN0gDu+/RuDyQZPaxuM6Q= =ZACu -END PGP SIGNATURE-
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 12:43, Colin Watson wrote: There's a big difference between being out of date by a major version and by a minor version. agreed, though IMHO kde 3.1.2 - 3.1.3 is a minor version upgrade and 3.1 - 3.2 is a major version upgrade We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. true enough, still releasing a week before a high-profile release of KDE is rather unfortunate I think. - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q15K5ihPJ4ZiSrsRAuLHAJ9Th6EGqjDrn4PDiPeTqv3xc6pShQCdEJVw sr+5p1W6IDaE9RrCe3huC8c= =C40N -END PGP SIGNATURE-
Re: Bits from the RM
On Wed, 20 Aug 2003, Anthony Towns wrote: If by dpkg 2.0 you mean rewritten dpkg and dpkg-dev, it doesn't. There is no chance that a package management system that hasn't seen the light of day, let alone reached beta test, will be ready for release in four months, let alone one. Just dpkg-deb, and dpkg-source. No other major changes are planned. The complex code in dpkg/dselect will just be interfaced to the new libary code. However, as I've been thinking, I'd rather take more time, and get more features in, then rush to have it completed in one month. If by dpkg 2.0 you mean 1.10.11 (ie, minor changes from 1.10.10 only), then I'm not sure why you're asking. So, I guess I'm looking for people who'd like to work on dpkg 1.10, and fix the important bugs it has.
Re: Bits from the RM
On Wed, 20 Aug 2003 20:48, Cameron Patrick wrote: There were pretty major changes between KDE 3 and KDE 3.1. As a Debian Anyone who wants to can establish their own repository for back-ported KDE packages. KDE has a good history of having people do that, at times there have been 3 or more back-port repositories of KDE. Just because something isn't in the main Debian distribution doesn't mean you can't use it! As long as a reasonably recent version of KDE is in stable you won't have any big problems as all the dependencies will be installed. user, I'd be rather miffed if a new version of KDE came out within a week of sarge being released ... on the other hand, if sarge is to be frozen in a couple of months' time, it seems unlikely that KDE 3.2 will be able to make it in. *grumble* :( Are there any big features you expect from KDE 3.2? If given a choice between a KDE release that's stable, solid, and reliable and a bleeding edge release that gives SEGV's on critical programs such as Konsole and has font problems I would choose the stable release every time. KDE 1.x was quite usable, while many of the beta releases in the 2.x and early 3.x series weren't... -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
Re: Bits from the RM
On Wed, Aug 20, 2003 at 01:40:53PM +0200, cobaco wrote: We're never going to manage to release just after high-profile releases of all our major components, so let's not delay for this one unless we have to. true enough, still releasing a week before a high-profile release of KDE is rather unfortunate I think. Release one week before will not be a real target [1]. data [1] read: if we delay the release for one week to include kde3.2, we have to make sure the packages work, the upgrade path is not breaking anything,... which will mean delaying the release at least 3 weeks more. By that time a new major release of Harsecorp (TM) 9.x will be out... Solution: use backports, use Sid, form a team to release a stable debian version more often, say in 6 more months. data -- Jesus Climent | Unix SysAdm | Helsinki, Finland | pumuki.hispalinux.es GPG: 1024D/86946D69 BB64 2339 1CAA 7064 E429 7E18 66FC 1D7F 8694 6D69 -- Registered Linux user #66350 proudly using Debian Sid Linux 2.4.21 - ... todos necesitamos creer en algo. - Si, yo también creo... Creo... que me voy a tomar una cerveza. --Sor Trini (Año Mariano)
Re: Bits from the RM
On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote: Also make sure to include some leg room if you depend on packages that have a tendency to be buggy (glibc, for example). The new glibc has already stalled the progress into testing of a large number of packages, and the number of RC bugs still seems to be going up. How are we going to manage to produce a release in 6 months the face of this obstacle? The last time there was this sort of breakage, it took many months just to get glibc itself it sorted out. -- - mdz
Re: Bits from the RM
On Wed, Aug 20, 2003 at 01:26:17PM +0200, cobaco wrote: and why on stable you do not expect a stable KDE? kde 3.2. will be the stable kde release come 8 december The reality is that if KDE 3.2 is stable in KDE, and it entered testing on December 8th, it would probably delay the release of sarge by at least 6 weeks just so we can make sure the Debian build of KDE 3.2 was bug-free. And then in the meantime, no doubt some other significant package (GNOME, perhaps?) would become stable, and people would agitate for us to hold up the release for another 6 weeks, OR developers would take the opportunity to destablize the release further because they see the vast major, gaping exception to the freeze schedule set forth by the RM. AND this all assumes that KDE actually hits their release schedulate! Bad ju-ju. The real problem is that stable has a reputation of taking years and years before we manage to do a release, so people are always desperate to shove every last bit of functionality and new upstream release into it. What folks don't realize is that makes the problem worse, not better, by stretching out the release schedule. Better to have a hard freeze schedule, and then try to turn out new stable releases every 6-9 months. Then folks won't be so desperate to shove new things in and screw up the release. The problem, though, is the first such attempt take release schedules seriously and agressively (a) a really hardass RM, and (b) a certain amount of faith by the developers that we really can get our act together about short, regular, predictable releases. - Ted
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:38:57PM +0200, cobaco wrote: On 2003-08-20 12:10, Michael Piefel wrote: Am 20.08.03 um 11:08:28 schrieb cobaco: kde 3.2 release is slated for 8th december[1], is there any chance we'll wait for it, just so the outdated kde label doesn't apply again immediately after release? actually that's just it, if we release on 1st december and KDE releases on 8th december, then 7 days after release we no longer have the stable KDE release in stable, which is a rather unfortunate timing, no? No. This is the way stable releases work. You can't have the latest and greatest version of the software in the distribution the day it releases and expect the whole thing to actually be stable, and you shouldn't ask the RM to delay the release on account of an impending upstream release of one piece of software. There's *always* new software being released in the community, and KDE is probably very low on the priority list *of those who use stable*. KDE3.2 doesn't miss the deadline by 7 days, it misses the deadline by almost two months: * October 15th Final, last-minute, low-risk bug fixes only If we manage to release Sarge and it contains the current upstream KDE packages for a whole seven days, THAT is a noteworthy improvement all its own. -- Steve Langasek postmodern programmer pgpngD3xvmkzg.pgp Description: PGP signature
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. That is both delusional and flat-out wrong. While I have been a happy KDE user for some time, I'll be the first to tell you that it has problems. For instance, Konqueror is almost completely unusable on Alpha because it frequently dies with SIGFPE and draws little black boxes instead of text on a number of webpages. That is not a bash against KDE; they probably do not have a large number of Alpha testers. Also, I find your argument that breaking desktops is somehow better than breaking servers to be rather naive. While the effects of breaking servers can likely be felt farther, tne pain of breaking desktops is no less when you consider how many more desktops we're talking about here. -- John
Re: Bits from the RM
On Wed, 20 Aug 2003, Matt Zimmerman wrote: On Tue, Aug 19, 2003 at 04:49:25PM +1000, Anthony Towns wrote: Also make sure to include some leg room if you depend on packages that have a tendency to be buggy (glibc, for example). The new glibc has already stalled the progress into testing of a large number of packages, and the number of RC bugs still seems to be going up. How are we going to manage to produce a release in 6 months the face of this obstacle? The last time there was this sort of breakage, it took many months just to get glibc itself it sorted out. Will we some day consider seriously the idea of autobuilders compiling against testing those packages which do not need libraries from unstable to be built?
Re: Bits from the RM
On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: quoteBasically, it's the difference between having a sysadmin spending fifteen minutes every day or week tweaking your server to keep it running, or having a sysadmin come in for a week once a year to do a major upgrade./quote Note that the RM was talking about servers there, [...] I'm sorry, that was a thinko. It should've read machine or system or similar. And the conclusions apply even moreso to desktop boxes than to servers, because there tend to be so many more of them, and because most of the time, sysadmins are geared towards managing servers rather than desktops, making changes to the latter harder, and less smooth. YMMV on the details, of course, but there wasn't intended to be any differentiation between servers and desktops in my mail. Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. ``Is this some kind of psych test? Am I getting paid for this?'' pgputibltegHl.pgp Description: PGP signature
Re: Bits from the RM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2003-08-20 15:33, John Goerzen wrote: On Wed, Aug 20, 2003 at 12:11:20PM +0200, cobaco wrote: Note that the RM was talking about servers there, while kde is end-user software, big difference IMHO. Taking into account that kde isn't server-software and that kde won't do release if there are major bugs left I don't think stability should be a problem in this case. That is both delusional and flat-out wrong. While I have been a happy KDE user for some time, I'll be the first to tell you that it has problems. For instance, Konqueror is almost completely unusable on Alpha because it frequently dies with SIGFPE and draws little black boxes instead of text on a number of webpages. ok, so kde releases are not necessarely stable on the more exotic debian-supported architectures. But exactly how is staying with an older kde release going to help that? I'd agree if there had been a rewrite of kdelibs or something, but kde 3.1 - 3.2 is evolutionary without big changes to what was already there. Also, I find your argument that breaking desktops is somehow better than breaking servers to be rather naive. not better, breaking things is never good, but less serious: a crash of a server affects all users of that server, a crash of a desktop affects the one user using that desktop at that time. What's more when a server crashes the users affected are dependend on the server admin to fix things, while on a desktop they can take action themselves (like say restart whatever app that crashed). While the effects of breaking servers can likely be felt farther agreed tne pain of breaking desktops is no less when you consider how many more desktops we're talking about here. that's assuming that all those desktops crash at the same time no? Out of curiosity (not relevant to the discussion) is it just individual apps like konquer that are buggy on alpha or is it also the kde-enviroment? - -- Cheers, cobaco /\ ASCII Ribbon Campaign \ / No proprietary formats in attachments without request X i.e. *NO* WORD, POWERPOINT or EXCEL documents / \ Respect Open Standards http://www.fsf.org/philosophy/no-word-attachments.html http://www.goldmark.org/netrants/no-word/attach.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE/Q4BM5ihPJ4ZiSrsRAnxbAKCMYfBf4vhLnYJf+1erqtkiLK78DwCeOReu cXYTU8AYHxEEIWJuH2iyDYo= =dJ4V -END PGP SIGNATURE-
