Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sun, 4 Apr 2004, Keith Packard wrote: Around 14 o'clock on Apr 4, Fabio Massimo Di Nitto wrote: That's why I stressed the testing information and added an example. Forget a machine park of that size. simply impossible to handle. Impossible for Debian to manage, but not impossible for the entire community, especially if you include hardware vendors. Of course. As I said, ATI has every intention of actually constructing a sufficient machine park to test their hardware running Linux. Do we have any contanct with them? would it be wise to ask the status of their project and perhaps start to work a bit closer? If so do you have any contact or can you take care of it? It would be very nice if we could somehow be the first to work in strict cooperation with them. Making it possible for those vendors to test just their drivers without also needing to test the rest of the system is critical to the viability of this kind of project though. Do you have any suggestion on how we could simply this process? Like for eg. sending them some sort of pre-release that they can test... Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
Around 6 o'clock on Apr 5, Fabio Massimo Di Nitto wrote: Do we have any contanct with them? would it be wise to ask the status of their project and perhaps start to work a bit closer? Yes, I have reasonably regular contact with a couple of their developers. I'm not sure what the status of their test lab is; last I heard they were working on getting funding, so it's clearly not there yet. I don't know what kinds of pressure they'll have to pick a particular distribution for their test systems. Linux is heavily used in the motion picture industry, and ATI is a large part of that, so I suspect they'll want to test drivers on the same platform their major customers are using. But, if we can manage to get Debian, Red Hat and SuSE shipping more-or-less the same bits, then we should be able to push bug reports from Debian back to ATI and have them reproducible on whatever system they are running. Do you have any suggestion on how we could simply this process? Like for eg. sending them some sort of pre-release that they can test... Hmm. Ideally, we'd test our driver interfaces completely and so would ATI, so the number of bugs specific to our system would be very small. Keeping very careful track of ABI changes would go a long ways in this direction. I wonder if we couldn't develop some kind of automatic ABI validation system that would scream any time the driver ABI changed. Hmm. ATI has been building and testing drivers against XFree86 4.4 release candiates for several months, so they're clearly interested in making sure their drivers are ready for new X versions. Reducing the downstream changes that Debian makes to X bits would make that effort more valuable for our users. -keith pgp4MVtr99kis.pgp Description: PGP signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, 3 Apr 2004, Andreas Schuldei wrote: As i see it X differs mostly from apache in this regard: it is a bitch because of the hardware. i would like to see the machinepark and logistics to be able to compile and test all the patches. That's why I stressed the testing information and added an example. Forget a machine park of that size. simply impossible to handle. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, 3 Apr 2004, Keith Packard wrote: Fixes which affect only one video driver should be subject to significantly less scrutiny than fixes which affect libraries or the core X server itself. Of course, letting those drivers be released on an hourly basis would make this a lot less painful. Fully agreed :-) Oh, ATI is working on building a sufficient infrastructure to test their cards. They do support the open source drivers, so it's quite reasonable to get their help in testing new releases for those chips. Sorry when I wrote ATI i had in mind my fantastic FOO/BAR card :-) Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
Around 14 o'clock on Apr 4, Fabio Massimo Di Nitto wrote: That's why I stressed the testing information and added an example. Forget a machine park of that size. simply impossible to handle. Impossible for Debian to manage, but not impossible for the entire community, especially if you include hardware vendors. As I said, ATI has every intention of actually constructing a sufficient machine park to test their hardware running Linux. Making it possible for those vendors to test just their drivers without also needing to test the rest of the system is critical to the viability of this kind of project though. -keith pgperr0eP6nzO.pgp Description: PGP signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, 2 Apr 2004, Daniel Stone wrote: I'm in a hurry this morning, so I can't give a substantive response for a couple of hours, Ok I am looking forward to a full response. but I'll just say that I have no confidence in the XSF as a team. Not to do with you, or Michel, or anything, but I have no confidence that it is a team in the true collaborative sense, or that it will ever be managed as such with the current leadership. Again, not a slight to you, Michel, or anyone else helping out with X. While you are at it, would you mind also to explain to the community which are your reasons to candidate as XSF Release Manager while you do not have confidence in the XSF as a team? Here are my motivations to candidate: Recent changes in my Debian activities will soon give me the time and the possibility to take over some bigger tasks than one I am handling now. As you all know I am part of the apache team and my main focus is on apache1.3. Sarge will have apache2 as default web server (task: webserver) and apache1.3 will be soon in a release for sarge state and probably, as obvious next step, obsoleted any time after sarge. The combinantion of the 2 will free quite a lot of time in my Debian life. Due to the fact that I have learned a lot from my own mistakes in handling apache (fixes to these mistakes will be on the way as soon as i will complete my movement to the new house - simply because i can't handle a full discussion in my actual net/resources conditions), plus the experience I have built with cooperative maintaince and that I need to be challenged to keep myself alive, I would love to spend more energy within the XSF. Project and team that i had to place in low priority until now, mainly due to time restrictions. Taking over some responsabilities/tasks from Branden will give him the possibility to reallocate this time to other activities. The short term plan, and i doubt anyone will object to this, is to have X in a release state for sarge. We need to focus our energy towards bug fixing but we need to be extremely carefull with the release cycle. X is not a package we can upload on a daily base. I think the right balance at this point in time is a bi-weekly release or 10 bug fixes, which one comes first, with the flexibility to decide to delay one upload when bug fixes must flow into sarge asap or speeding up via urgency field. It is explicit that no major changes should go in until they are absolutely necessary and never prior discussion on the mailing list. We will work together on a long term plan after sarge. There is no real need for it right now imho. BTS is full of things to do... no doubts about it. There are almost 900 bugs. a bit more than 500 marked as upstream. As a Release Manager i would like to see one person working only on packaging issues, while at least 2 persons taking care of the upstream ones (or at least a similar ratio). Of course XSF should find the best delegates for these tasks and any volunteer or sporadic help will be appreciated. Testing the bug fixes. This is extremely important at this point in time. Do not commit bug fixes without testing them. We are not in the position to ruin uploads with FTBFS. Always try to test on as many archs as you can. Of course there might be exceptions such as hardware restrictions (eg: i can't test this or that because i do not have that specific version of that card) but it must not be the normal case. You can still test that it does not break anything already working. I highly recommends to add information about the tests you have done to verify the bug fix whenever you can, especially when you cannot test directly on a specific setup. Eg. applied patch to fix ATI driver Y,Z but since we can't test on that specific hardware it has been verified that it doesn't break with other ATI cards. and so on.. common sense applies here in how you report and track these information. My position will be to coordinate the people working on bug fixes and monitor their activities to ensure to stick with the plan and coordinate with debian-release management in order to allign XSF activities with Debian ones. Thanks Fabio PS: just a reminder. I will be offline for a couple of days at least (moving more stuff to the new house) as i already wrote and people should be aware of it by now :-) please be nice if i won't answer back in a millisecond.
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Apr 03, 2004 at 08:43:59AM +0200, Fabio Massimo Di Nitto wrote: On Fri, 2 Apr 2004, Daniel Stone wrote: but I'll just say that I have no confidence in the XSF as a team. Not to do with you, or Michel, or anything, but I have no confidence that it is a team in the true collaborative sense, or that it will ever be managed as such with the current leadership. Again, not a slight to you, Michel, or anyone else helping out with X. While you are at it, would you mind also to explain to the community which are your reasons to candidate as XSF Release Manager while you do not have confidence in the XSF as a team? Very badly worded on my behalf. I don't have confidence in the management of the XSF as a team, but that doesn't mean I don't want to help fix X in Debian. As no-one had stepped up (as far as I was aware), I decided I might as well do it, since -8 clearly needed to be done. Recent changes in my Debian activities will soon give me the time and the possibility to take over some bigger tasks than one I am handling now. As you all know I am part of the apache team and my main focus is on apache1.3. Sarge will have apache2 as default web server (task: webserver) and apache1.3 will be soon in a release for sarge state and probably, as obvious next step, obsoleted any time after sarge. Cool, that's good news. The combinantion of the 2 will free quite a lot of time in my Debian life. Right. Due to the fact that I have learned a lot from my own mistakes in handling apache (fixes to these mistakes will be on the way as soon as i will complete my movement to the new house - simply because i can't handle a full discussion in my actual net/resources conditions), plus the experience I have built with cooperative maintaince and that I need to be challenged to keep myself alive, I would love to spend more energy within the XSF. Project and team that i had to place in low priority until now, mainly due to time restrictions. Please don't let me stop you: make your own judgements on what you want to do. I'm just presenting my opinion from my experience, but you will no doubt have yours, and I don't want to impose mine on you in any way. Taking over some responsabilities/tasks from Branden will give him the possibility to reallocate this time to other activities. Definitely. The short term plan, and i doubt anyone will object to this, is to have X in a release state for sarge. We need to focus our energy towards bug fixing but we need to be extremely carefull with the release cycle. X is not a package we can upload on a daily base. I think the right balance at this point in time is a bi-weekly release or 10 bug fixes, which one comes first, with the flexibility to decide to delay one upload when bug fixes must flow into sarge asap or speeding up via urgency field. It is explicit that no major changes should go in until they are absolutely necessary and never prior discussion on the mailing list. Sure. We will work together on a long term plan after sarge. There is no real need for it right now imho. Well, we need to do it ASAP, IMO. If we start on this after sarge, it'll take even longer to do, and we'll need to maintain the old monolithic tree in the interim. As the 4.3 experience has shown us, this is not something we can viably keep doing. I'm working upstream to try to get the fd.o modular trees in good shape, which, along with uni, is sucking up all my time. After this, I intend to help out on the Debian side of things. BTS is full of things to do... no doubts about it. There are almost 900 bugs. a bit more than 500 marked as upstream. As a Release Manager i would like to see one person working only on packaging issues, while at least 2 persons taking care of the upstream ones (or at least a similar ratio). Of course XSF should find the best delegates for these tasks and any volunteer or sporadic help will be appreciated. I don't necessarily see this as an exclusive task. Having a dedicated RM, and designated component handlers (e.g. xserver, xlibs, xapps, xfonts, xdocs, whatever) would be nice, though. Testing the bug fixes. This is extremely important at this point in time. Do not commit bug fixes without testing them. We are not in the position to ruin uploads with FTBFS. Always try to test on as many archs as you can. Of course there might be exceptions such as hardware restrictions (eg: i can't test this or that because i do not have that specific version of that card) but it must not be the normal case. You can still test that it does not break anything already working. I highly recommends to add information about the tests you have done to verify the bug fix whenever you can, especially when you cannot test directly on a specific setup. Eg. applied patch to fix ATI driver Y,Z but since we can't test on that specific hardware it has been verified that it doesn't break with other ATI cards. and so on.. common sense applies
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 06:58:02PM +0200, Fabio Massimo Di Nitto wrote: On Fri, 2 Apr 2004, Daniel Stone wrote: Re-reading the bug log and the thread I still cannot understand why you downgraded the bug in the first place. There is no explanation in the BTS and the downgrade was done before Branden investigation that would have let X entering sarge in any case. You might want to excuse if i missed something but i can't access emails on a daily base but i am sure you can be so kind to give an explanation. I'll need to respond to this (later) in the morning. Ok. I just want to have a clear picture of the situation, since we are a team and we should work as such I think certain decisions (like X or Y should be handled in this way for this reason) should be agreed before rather than after. I'll agree that I should've explained it, but I don't like the suggestion of package management by committee; we'll never get anything done. When I told Warren Turkal he was welcome to maintain libX11, I didn't tell him to run every commit through a build, to test on all the release architectures before he released, or whatever. All I said was to remember what he was working on, and decide accordingly. I think the XSF members have this much sense; just use your head. Anyway, back to the bug. It doesn't cause serious data loss, doesn't break unrelated apps, etc. It belongs as an important bug at most IMO; if 'the X server segfaults when I run it with this revision of a PCI Matrox' is important, then there's no way this bug should be higher. It's an occasional annoyance, and nothing more (IMO). If you want at act as a release manager, you should in the first place stop telling people that they are stupid or whatever and start to cooperate with everyone, even with clueless people (this is not meant to be an attack to Adrian at all, but a general reference to less experienced users) and give good explanations to your actions wearing the RM hat. I said the suggestion was 'stupid', and I stick by it. I'm perfectly willing to co-operate with Adrian, but not to the point of yielding to his every suggestion - I have an opinion on some matters, and I'm not willing to let everyone trample all over it. We all have opinions, neither i say that we need to accept everything from everyone, but upon a rejection I like to see a good explanation that makes 'stupid' a certain suggestion. BTW, I never said Adrian was 'stupid', not at all. I was just stating my opinion on his opinion on the bug. The RM position is all yours if Branden agrees. This is where imho you miss the point. It is OUR decision who has to take the position as RM inside OUR team. Noone until now has been stepping forward and say: hey i would like to take that responsability. Now we are in the exactly the other situation with 2 candidates. I believe that XFS should publically decide who can fit better that position and with XFS i also mean our users and not just us. Ideally, yes, but I haven't traditionally seen this as how the XSF has managed. The only reason I put my hand up for it was because, as best I could tell at the time, no-one else had. I'll be relieved to escape the time pressure, tbh. I don't want to do it; I just said I would because no-one else was (again, as best I could tell). That kind of leaves you per default, no? -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
* Fabio Massimo Di Nitto ([EMAIL PROTECTED]) [040403 09:01]: Testing the bug fixes. This is extremely important at this point in time. Do not commit bug fixes without testing them. We are not in the position to ruin uploads with FTBFS. Always try to test on as many archs as you can. Of course there might be exceptions such as hardware restrictions (eg: i can't test this or that because i do not have that specific version of that card) but it must not be the normal case. You can still test that it does not break anything already working. I highly recommends to add information about the tests you have done to verify the bug fix whenever you can, especially when you cannot test directly on a specific setup. Eg. applied patch to fix ATI driver Y,Z but since we can't test on that specific hardware it has been verified that it doesn't break with other ATI cards. and so on.. common sense applies here in how you report and track these information. As i see it X differs mostly from apache in this regard: it is a bitch because of the hardware. i would like to see the machinepark and logistics to be able to compile and test all the patches. Apart from that i think highly of a more coordinated and team-spirited approach (think small-groups within debian - my talk at debconf3). for this i noticed in the meantime that a certain immediacy (more than mailinglists can provide, but irc does) is necessary to let the teamspirit develop. Try to get people not yet on irc but on the team to reconsider to hang out on irc regularly. /andreas
Re: XFree86 4.3.0 and testing (was: when will the release release)
Around 11 o'clock on Apr 3, Andreas Schuldei wrote: As i see it X differs mostly from apache in this regard: it is a bitch because of the hardware. i would like to see the machinepark and logistics to be able to compile and test all the patches. It's precisely like the kernel in this regard; and the worst part of the kernel is always the device drivers because so few people can test each one. Fixes which affect only one video driver should be subject to significantly less scrutiny than fixes which affect libraries or the core X server itself. Of course, letting those drivers be released on an hourly basis would make this a lot less painful. Oh, ATI is working on building a sufficient infrastructure to test their cards. They do support the open source drivers, so it's quite reasonable to get their help in testing new releases for those chips. Any of you are also welcome to fix bugs upstream as soon as Debian migrates away from XFree86 4.3; I'm hoping that the combined efforts of SuSE, Debian and Red Hat will slowly whittle down the steaming pile of bugs which has accumulated over the years. -keith pgpt6zEx2P1ej.pgp Description: PGP signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Thu, Apr 01, 2004 at 08:48:15PM -0800, Daniel Stone wrote: On Fri, Apr 02, 2004 at 03:50:23AM +0200, Adrian Bunk wrote: On Mon, Mar 29, 2004 at 03:22:52PM -0500, Branden Robinson wrote: There was little point holding up 4.3.0's progress into sarge because of it; the exact same bug is present in XFree86 4.2.1, already in sarge. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libx11-6 I don't disagree with that. All I'm saying is that suh a bug is IMHO release critical in the sense should be fixed before the next stable release. Jesus christ, how much time do you want to spend on X? sarge *should* ship with either xorg, or fd.o's X. sarge *should* ship with a brand-spanking GNOME. sarge *should* have autoconfiguring X. sarge *should* have out-of-the-box wireless, LDAP authentication, et al, support. It doesn't make *any* of these RC. BTW - If you have a bug which you believe deserves to be marked RC you can always just tag it is sarge and sid as well to have it effectively ignored for migration purposes. As long as the version in sid has less bugs it will migrate to sarge. I am not going to comment on the particular case here since I didn't even read the bug report. Chris signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Thu, Apr 01, 2004 at 08:48:15PM -0800, Daniel Stone wrote: important, at best. I'm not suggesting that the patch shouldn't be applied for 4.3.0-8, which, given Branden's lack of response, I assume I am release-managing. However, it is most certainly not RC. Fabio volunteered as well. Why doesn't he get to make the same assumption? -- G. Branden Robinson| Debian GNU/Linux | Bother, said Pooh, as he was [EMAIL PROTECTED] | assimilated by the Borg. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 01:53:53AM -0500, Branden Robinson wrote:
On Thu, Apr 01, 2004 at 08:48:15PM -0800, Daniel Stone wrote:
important, at best. I'm not suggesting that the patch shouldn't be
applied for 4.3.0-8, which, given Branden's lack of response, I assume I
am release-managing. However, it is most certainly not RC.
Fabio volunteered as well. Why doesn't he get to make the same
assumption?
I didn't see that; all I saw was 'why is no-one asking to be RM :('.
--
Daniel Stone[EMAIL PROTECTED]
Debian: the universal operating system http://www.debian.org
signature.asc
Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 12:03:03AM -0600, Chris Cheney wrote: BTW - If you have a bug which you believe deserves to be marked RC you can always just tag it is sarge and sid as well to have it effectively ignored for migration purposes. That's not technically true at the moment, although it'll probably become true fairly soon. It's not a particularly good idea though; if you've got an RC bug, you need to fix it, not find ways to get it ignored. 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 could. http://conf.linux.org.au/ -- Jan 12-17, 2004 signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Thu, 1 Apr 2004, Daniel Stone wrote: important, at best. I'm not suggesting that the patch shouldn't be applied for 4.3.0-8, which, given Branden's lack of response, I assume I am release-managing. However, it is most certainly not RC. Even if i am silent on the list (as you know i am quit busy during these days, and if you don't please read -private) lack of response doesn't mean lack of responsabilities or interest. Re-reading the bug log and the thread I still cannot understand why you downgraded the bug in the first place. There is no explanation in the BTS and the downgrade was done before Branden investigation that would have let X entering sarge in any case. You might want to excuse if i missed something but i can't access emails on a daily base but i am sure you can be so kind to give an explanation. Please don't go around making stupid suggestions like this: you might give other people ideas. If you want at act as a release manager, you should in the first place stop telling people that they are stupid or whatever and start to cooperate with everyone, even with clueless people (this is not meant to be an attack to Adrian at all, but a general reference to less experienced users) and give good explanations to your actions wearing the RM hat. 'REALEASE FASTER! NO NOT LIKE THAT YOU FOOLS,' you forgot your caps lock on. Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Thu, 1 Apr 2004, Daniel Stone wrote:
I didn't see that; all I saw was 'why is no-one asking to be RM :('.
http://lists.debian.org/debian-x/2004/debian-x-200403/msg03703.html
Fabio
--
user fajita: step one
fajita Whatever the problem, step one is always to look in the error log.
user fajita: step two
fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 11:30:07AM +0200, Fabio Massimo Di Nitto wrote:
On Thu, 1 Apr 2004, Daniel Stone wrote:
I didn't see that; all I saw was 'why is no-one asking to be RM :('.
http://lists.debian.org/debian-x/2004/debian-x-200403/msg03703.html
Ahr. Perfect, I am not.
--
Daniel Stone[EMAIL PROTECTED]
Debian: the universal operating system http://www.debian.org
signature.asc
Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 11:12:45AM +0200, Fabio Massimo Di Nitto wrote: On Thu, 1 Apr 2004, Daniel Stone wrote: important, at best. I'm not suggesting that the patch shouldn't be applied for 4.3.0-8, which, given Branden's lack of response, I assume I am release-managing. However, it is most certainly not RC. Even if i am silent on the list (as you know i am quit busy during these days, and if you don't please read -private) lack of response doesn't mean lack of responsabilities or interest. I'll have to flick back through -private; I try to ignore it. Re-reading the bug log and the thread I still cannot understand why you downgraded the bug in the first place. There is no explanation in the BTS and the downgrade was done before Branden investigation that would have let X entering sarge in any case. You might want to excuse if i missed something but i can't access emails on a daily base but i am sure you can be so kind to give an explanation. I'll need to respond to this (later) in the morning. Please don't go around making stupid suggestions like this: you might give other people ideas. If you want at act as a release manager, you should in the first place stop telling people that they are stupid or whatever and start to cooperate with everyone, even with clueless people (this is not meant to be an attack to Adrian at all, but a general reference to less experienced users) and give good explanations to your actions wearing the RM hat. I said the suggestion was 'stupid', and I stick by it. I'm perfectly willing to co-operate with Adrian, but not to the point of yielding to his every suggestion - I have an opinion on some matters, and I'm not willing to let everyone trample all over it. The RM position is all yours if Branden agrees. 'REALEASE FASTER! NO NOT LIKE THAT YOU FOOLS,' you forgot your caps lock on. I use ctrl:nocaps. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
Let's go back to debian-x only. I don't think we need to pester the other mailing list anymore. On Fri, 2 Apr 2004, Daniel Stone wrote: Even if i am silent on the list (as you know i am quit busy during these days, and if you don't please read -private) lack of response doesn't mean lack of responsabilities or interest. I'll have to flick back through -private; I try to ignore it. Well it's nothing secret.. i am changing house and traveling quite a lot so i don't read emails regularly during these days. I will hopefully finish within mid april. Re-reading the bug log and the thread I still cannot understand why you downgraded the bug in the first place. There is no explanation in the BTS and the downgrade was done before Branden investigation that would have let X entering sarge in any case. You might want to excuse if i missed something but i can't access emails on a daily base but i am sure you can be so kind to give an explanation. I'll need to respond to this (later) in the morning. Ok. I just want to have a clear picture of the situation, since we are a team and we should work as such I think certain decisions (like X or Y should be handled in this way for this reason) should be agreed before rather than after. Please don't go around making stupid suggestions like this: you might give other people ideas. If you want at act as a release manager, you should in the first place stop telling people that they are stupid or whatever and start to cooperate with everyone, even with clueless people (this is not meant to be an attack to Adrian at all, but a general reference to less experienced users) and give good explanations to your actions wearing the RM hat. I said the suggestion was 'stupid', and I stick by it. I'm perfectly willing to co-operate with Adrian, but not to the point of yielding to his every suggestion - I have an opinion on some matters, and I'm not willing to let everyone trample all over it. We all have opinions, neither i say that we need to accept everything from everyone, but upon a rejection I like to see a good explanation that makes 'stupid' a certain suggestion. The RM position is all yours if Branden agrees. This is where imho you miss the point. It is OUR decision who has to take the position as RM inside OUR team. Noone until now has been stepping forward and say: hey i would like to take that responsability. Now we are in the exactly the other situation with 2 candidates. I believe that XFS should publically decide who can fit better that position and with XFS i also mean our users and not just us. I use ctrl:nocaps. Check your settings again ;) Fabio -- user fajita: step one fajita Whatever the problem, step one is always to look in the error log. user fajita: step two fajita When in danger or in doubt, step two is to scream and shout.
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, 2004-04-02 at 18:58, Fabio Massimo Di Nitto wrote: On Fri, 2 Apr 2004, Daniel Stone wrote: The RM position is all yours if Branden agrees. This is where imho you miss the point. It is OUR decision who has to take the position as RM inside OUR team. Noone until now has been stepping forward and say: hey i would like to take that responsability. Now we are in the exactly the other situation with 2 candidates. I believe that XFS should publically decide who can fit better that position and with XFS i also mean our users and not just us. FWIW, you have my support Fabio. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 11:12:45AM +0200, Fabio Massimo Di Nitto wrote: Re-reading the bug log and the thread I still cannot understand why you downgraded the bug in the first place. For context, we're talking about #239991. I would probably have made the same call, given that lost keystrokes are not what I consider data loss, even non-serious data loss. I could be convinced otherwise by the bug submitter, but it is true that the justification for downgrading the bug's severity should have been explicitly called out. Particularly since the bug submitter *did* go to the trouble of using the Justification: header, which I wish more people would do. I think the specific point is largely moot, as there's a patch, and the fix is on the TODO list. Whether this fix goes into the next release is a decision for the XFree86 4.3.0-8 release manager to make. :) But to summarize: yes, when downgrading the severity of any bug, we should explain why. I'll try to do better on this score myself. -- G. Branden Robinson|Any man who does not realize that Debian GNU/Linux |he is half an animal is only half a [EMAIL PROTECTED] |man. http://people.debian.org/~branden/ |-- Thornton Wilder signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 06:58:02PM +0200, Fabio Massimo Di Nitto wrote: On Fri, 2 Apr 2004, Daniel Stone wrote: The RM position is all yours if Branden agrees. This is where imho you miss the point. It is OUR decision who has to take the position as RM inside OUR team. Noone until now has been stepping forward and say: hey i would like to take that responsability. Now we are in the exactly the other situation with 2 candidates. I believe that XFS should publically decide who can fit better that position and with XFS i also mean our users and not just us. I'm in a hurry this morning, so I can't give a substantive response for a couple of hours, but I'll just say that I have no confidence in the XSF as a team. Not to do with you, or Michel, or anything, but I have no confidence that it is a team in the true collaborative sense, or that it will ever be managed as such with the current leadership. Again, not a slight to you, Michel, or anyone else helping out with X. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Mon, Mar 29, 2004 at 03:22:52PM -0500, Branden Robinson wrote: There was little point holding up 4.3.0's progress into sarge because of it; the exact same bug is present in XFree86 4.2.1, already in sarge. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libx11-6 I don't disagree with that. All I'm saying is that suh a bug is IMHO release critical in the sense should be fixed before the next stable release. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Apr 02, 2004 at 03:50:23AM +0200, Adrian Bunk wrote: On Mon, Mar 29, 2004 at 03:22:52PM -0500, Branden Robinson wrote: There was little point holding up 4.3.0's progress into sarge because of it; the exact same bug is present in XFree86 4.2.1, already in sarge. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libx11-6 I don't disagree with that. All I'm saying is that suh a bug is IMHO release critical in the sense should be fixed before the next stable release. Jesus christ, how much time do you want to spend on X? sarge *should* ship with either xorg, or fd.o's X. sarge *should* ship with a brand-spanking GNOME. sarge *should* have autoconfiguring X. sarge *should* have out-of-the-box wireless, LDAP authentication, et al, support. It doesn't make *any* of these RC. important, at best. I'm not suggesting that the patch shouldn't be applied for 4.3.0-8, which, given Branden's lack of response, I assume I am release-managing. However, it is most certainly not RC. Please don't go around making stupid suggestions like this: you might give other people ideas. 'REALEASE FASTER! NO NOT LIKE THAT YOU FOOLS,' Daniel -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Mar 27, 2004 at 05:06:21PM +0100, Adrian Bunk wrote: On Sat, Mar 27, 2004 at 06:39:47AM -0800, Daniel Stone wrote: On Sat, Mar 27, 2004 at 02:18:03PM +0100, Adrian Bunk wrote: On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: ... Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Please don't forget to upgrade the bug again later. Downgrading RC bugs for getting a package into testing sometimes has the effect that the then non-RC bug gets forgotten later [1]. I downgraded it because it is NOT A VALID RC BUG IN THE FIRST PLACE. I'd say a bug in a library that causes segfaults in programs is a good candidate for being RC. There was little point holding up 4.3.0's progress into sarge because of it; the exact same bug is present in XFree86 4.2.1, already in sarge. http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=libx11-6 -- G. Branden Robinson| The more ridiculous a belief Debian GNU/Linux | system, the higher the probability [EMAIL PROTECTED] | of its success. http://people.debian.org/~branden/ | -- Wayne R. Bartz signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Mar 27, 2004 at 05:06:21PM +0100, Adrian Bunk wrote: On Sat, Mar 27, 2004 at 06:39:47AM -0800, Daniel Stone wrote: On Sat, Mar 27, 2004 at 02:18:03PM +0100, Adrian Bunk wrote: On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: ... Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Please don't forget to upgrade the bug again later. Downgrading RC bugs for getting a package into testing sometimes has the effect that the then non-RC bug gets forgotten later [1]. I downgraded it because it is NOT A VALID RC BUG IN THE FIRST PLACE. I'd say a bug in a library that causes segfaults in programs is a good candidate for being RC. 'important'. It only triggers in a relatively rare situation; virtually everyone else using the package is fine with it. I know that XFree86 with nearly 200 important bugs has other rules for RC bugs than the rest of Debian, and it's a different question what to do with such bugs if they are hard to fix, but at a first glance the bug in question that includes both an analysis of the problem and a patch seems to be an example of a perfect bug report. No, it does not. It just so happens to be so friggin' huge that very few problems have such an adverse impact as to make the entire library useless. Once I catch one, I'll let it through. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
XFree86 4.3.0 and testing (was: when will the release release)
On Wed, Mar 24, 2004 at 07:21:10PM -0500, Nathanael Nerode wrote: XFree86 4.3 should be in as soon as it builds and is uploaded on s390. There's no other new upstream version IMHO worth actually delaying the release for. XFree86 4.3.0 is now only being help up by weird stuff I don't fully understand: Checking xfree86 * trying to update xfree86 from 4.2.1-12.1 to 4.3.0-7 (candidate is 8 days old) * Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed)[1] Checking sppc * trying to update sppc from 1.0.1-6 to 1.0.1-8 (candidate is 0 days old) * sppc is only 0 days old. It must be 10 days to go in. * sppc is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed[2] Checking tulip * trying to update tulip from 1.2.5-3 to 1.2.5-4 (candidate is 23 days old) * tulip is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed) * Updating tulip makes 1 non-depending packages uninstallable on alpha: tulip[3] If someone who's better at reading these tea leaves can tell me what I can do to help move this along, please let me know. [1] http://bjorn.haxx.se/debian/testing.pl?package=xfree86 [2] http://bjorn.haxx.se/debian/testing.pl?package=sppc [3] http://bjorn.haxx.se/debian/testing.pl?package=tulip -- G. Branden Robinson| Debian GNU/Linux | Bother, said Pooh, as he was [EMAIL PROTECTED] | assimilated by the Borg. http://people.debian.org/~branden/ | signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Mar 27, 2004 at 02:40:00AM -0500, Branden Robinson wrote: On Wed, Mar 24, 2004 at 07:21:10PM -0500, Nathanael Nerode wrote: XFree86 4.3 should be in as soon as it builds and is uploaded on s390. There's no other new upstream version IMHO worth actually delaying the release for. XFree86 4.3.0 is now only being help up by weird stuff I don't fully understand: Checking xfree86 * trying to update xfree86 from 4.2.1-12.1 to 4.3.0-7 (candidate is 8 days old) * Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed)[1] Checking sppc * trying to update sppc from 1.0.1-6 to 1.0.1-8 (candidate is 0 days old) * sppc is only 0 days old. It must be 10 days to go in. * sppc is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed[2] Checking tulip * trying to update tulip from 1.2.5-3 to 1.2.5-4 (candidate is 23 days old) * tulip is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed) * Updating tulip makes 1 non-depending packages uninstallable on alpha: tulip[3] If someone who's better at reading these tea leaves can tell me what I can do to help move this along, please let me know. vorlon has hinted the three together, so they should all progress in just fine. AFAICT, it actually progressed in with this testing run, but my update_output-fu is ageing. Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: On Sat, Mar 27, 2004 at 02:40:00AM -0500, Branden Robinson wrote: On Wed, Mar 24, 2004 at 07:21:10PM -0500, Nathanael Nerode wrote: XFree86 4.3 should be in as soon as it builds and is uploaded on s390. There's no other new upstream version IMHO worth actually delaying the release for. XFree86 4.3.0 is now only being help up by weird stuff I don't fully understand: Checking xfree86 * trying to update xfree86 from 4.2.1-12.1 to 4.3.0-7 (candidate is 8 days old) * Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed)[1] Checking sppc * trying to update sppc from 1.0.1-6 to 1.0.1-8 (candidate is 0 days old) * sppc is only 0 days old. It must be 10 days to go in. * sppc is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed[2] Checking tulip * trying to update tulip from 1.2.5-3 to 1.2.5-4 (candidate is 23 days old) * tulip is waiting for xfree86 o Updating xfree86 makes 2 depending packages uninstallable on alpha: sppc, tulip (recur was tried but failed) * Updating tulip makes 1 non-depending packages uninstallable on alpha: tulip[3] If someone who's better at reading these tea leaves can tell me what I can do to help move this along, please let me know. vorlon has hinted the three together, so they should all progress in just fine. AFAICT, it actually progressed in with this testing run, but my update_output-fu is ageing. Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Yes, the sppc upload was impeccably timed. Rather than letting more packages build up behind xfree86 in the queue for the next 10 days (X is at the base of 3 of the 4 top blocking issues on http://bjorn.haxx.se/debian/toplist.html), I've hinted sppc for removal from testing on Sunday; it should make its own way back in 10 days hence. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: ... Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Please don't forget to upgrade the bug again later. Downgrading RC bugs for getting a package into testing sometimes has the effect that the then non-RC bug gets forgotten later [1]. cu Adrian [1] this is not meant against the xfree86 developers, it should more be a general rule -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Mar 27, 2004 at 02:18:03PM +0100, Adrian Bunk wrote: On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: ... Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Please don't forget to upgrade the bug again later. Downgrading RC bugs for getting a package into testing sometimes has the effect that the then non-RC bug gets forgotten later [1]. I downgraded it because it is NOT A VALID RC BUG IN THE FIRST PLACE. -- Daniel Stone[EMAIL PROTECTED] Debian: the universal operating system http://www.debian.org signature.asc Description: Digital signature
Re: XFree86 4.3.0 and testing (was: when will the release release)
On Sat, Mar 27, 2004 at 06:39:47AM -0800, Daniel Stone wrote: On Sat, Mar 27, 2004 at 02:18:03PM +0100, Adrian Bunk wrote: On Fri, Mar 26, 2004 at 11:42:30PM -0800, Daniel Stone wrote: ... Kamion said the only thing holding it up yesterday was an RC bug, which I promptly downgraded; if it didn't go in today, I expect that will be because of the new sppc upload, making it a transitive problem. Please don't forget to upgrade the bug again later. Downgrading RC bugs for getting a package into testing sometimes has the effect that the then non-RC bug gets forgotten later [1]. I downgraded it because it is NOT A VALID RC BUG IN THE FIRST PLACE. I'd say a bug in a library that causes segfaults in programs is a good candidate for being RC. I know that XFree86 with nearly 200 important bugs has other rules for RC bugs than the rest of Debian, and it's a different question what to do with such bugs if they are hard to fix, but at a first glance the bug in question that includes both an analysis of the problem and a patch seems to be an example of a perfect bug report. And I have to admit I don't fully understand the, ahem, very descriptive subject of yor mail that downgraded this bug. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed
