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 here in how you report and track these > information. I think that as long as it builds, and we have at least one success report, we should throw it in. Of course, if we can reliably verify it, we should, but we shouldn't hold up putting in a fix because no-one has an M9 with a specific revision of the iBook. > 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. Go for it. :) Again, I have specific management issues with the XSF, as I'm sure you guys are all well aware. This does not mean I think any member of the XSF is 'stupid', that I think anyone from the XSF is technically unskilled, or whatever. All it means is that I had a few specific issues with one member of the XSF, and that's it; don't read anything more into it. I've said what I mean: there's nothing lying between the lines. -- Daniel Stone <daniels@debian.org> Debian: the universal operating system http://www.debian.org
Attachment:
signature.asc
Description: Digital signature