On Thu, Apr 03, 2003 at 08:32:09AM +0200, Sven Luther scrawled: > On Thu, Apr 03, 2003 at 07:53:12AM +1000, Daniel Stone wrote: > > Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well > > supported as it is: it takes quite an amount of work to support, and > > porters would also be split on which one to support - do they debug > > problems and try to fix with 4.2.1, or do new porting with 4.3.0? > > That is just a problem right now, because we are one version behind. If > we manage to release a quality 4.3.0 soon, and start working on the next > upstream version immediately, then when it is released, we will have > packages. We could also decide to skip 4.3.0 and decide to go with the > next version directly, but i would say this is a bit dangerous right > now, while things are floating and upstream has not given a fixed > schedule. Just after the Woody release we could have done that with > more confidence though. Well, the problem is, you're always going to have problems. Until upstream patched it a couple of days ago, X didn't work on ia64, full stop. You picked whether you wanted to run it on Intel or HP, with no middle ground, full stop. This is the sort of thing that necessitates having the older version in unstable for a while. XFree86 releases, *ESPECIALLY* .0 releases, are basically code drops, and have rarely had any porting work done to them, and often have quite a few bugs. It's not Debian-quality, period, and the only way we'd get extensive testing done would be to neglect the version currently into unstable, which means we'd have an unsupported and shoddy version inunstable. That's not something I'm prepared to stand up for. > > Well, it's the best we've got in the meantime, I'm afraid. > > Sure, because nobody seriously considers the alternatives. The alternative involves cloning Branden and/or myself (if you clone me, don't clone the RSI bit, that's counter-productive). > > And I've been doing 4.3 for months, working as closely with Branden as I > > can (you'll notice that I do regular back-syncs with 4.2.1, and a few of > > the design decisions I made were stuff Branden was going to do in his > > 4.3 tree anyway). There's no need to fork the XFree86 team. If you want > > Yes, but they are not officially part of debian, i cannot upload > gnome-randr-applet, and if i submit a bug report about a X related > package, the maintainer ask me what strange X package i am running, and > there is no BTS for the 4.3 package. I understand that the current pool > system is not able to offer more than that, but it would be nice if it > were. Well, you can upload it to an external repository and put it on apt-get.org. XFree86 4.3, as it stands, cannot enter Debian until hppa, sh3, sh4, mips, mipsel, m68k and arm porters have a bash at it. s390 and hurd-i386 ports are underway (hi guys! haven't forgotten you), but yeah. Not near complete yet. The BTS is myself, and I'm contemplating setting up debbugs here to manage the bugs. If you run reportbug, you'll just get a bug sent to myself, with all the need information, and I follow up all bug reports.. > > to make good, quality packages, go ahead and create them. Just let > > Branden know, try to ensure they don't diverge too much from his > > packages, or how he plans to do things, and stuff like that. This is > > what I've been doing for months now. > > Yes, and instead of having duplicate work, have triplicate work. Anyway, > i have not the time (rigth now) to do this kind of stuff, i have my own > group of packages in debian, and have also upstream work to do on X. > Back then when i got burnt by my awkward attempt to do X debian package, > i decided that i would limit myself to upstream work, which was ever > more comprehensive, despite what the huge flamewar seems to imply. Well, I've been able to work with Branden with relatively few problems. I don't see any problem if people come along and are prepared to put in a great amount of hard work (I've been at it for quite some time now), to create rocking 4.4/5.0 packages. I'd be happy to see that happen, and possibly work with anyone who is prepared to do it (Ishikawa-san has been doing good things in this regard). Code is more important than words in this regard. > > I'm not "ahead" of it per se. There are still more patches to continue > > merging, more documentation to continue writing, and more architectures > > to port it to. > > Yes, but it is no more 4.3, if you (and i would help with this if you > want, altough i need a bit of time to adapt to the needs of the debian X > package, understand the issues at hand, etc.) where to integrate all upstream > changes into this package, and submit the debian diffs upstream also, > then when the next release is done, it would not be so difficult to have > a debian package quickly after the upstream release. Some of the debian > team could even try to get commit access in upstream's CVS. The problem is that > this is not done, for whatever reason, and that there is no will to even > try to attain this. I can do most everything but the porting. If anyone wants to port to any of the architectures listed above, *please* contact me. The Debian diffs most likely won't enter 4.3; myself and Mike Harris sat down and decided which patches to submit upstream, and submitted them, before 4.3.0. A few got submitted, a few got rejected, that's how it goes. And every new upstream packages introduces its own bugs, or non-portable stuff. You're never going to have the Utopian situation of having no patches to maintain, even if you exclude the Debian-specific patches. I have no intention of shooting for upstream commit access. You can, if you like. In the meantime, I'm just continuing to try and get my packages out as best as I can. That's all I can do. -- Daniel Stone <dstone@trinity.unimelb.edu.au> Developer, Trinity College, University of Melbourne
Attachment:
pgpn5nu1zsaQh.pgp
Description: PGP signature