On Sun, Apr 13, 2003 at 07:55:49PM +0200, Sven Luther wrote: > On Mon, Apr 14, 2003 at 01:54:54AM +1000, Daniel Stone wrote: > > Well, only if they're good quality. If you're going to help the XSF, you > > need to track upstream by reading every line of diff, staying active on > > the lists and watching for new patches and reports of breakage, and > > Err, this is mainly the debian-x list, or do you mean all the -ports > lists ? That would maybe not really be all that productive if i have to > read 12 or so rather high volume list, which will only be X relevant a > small portion of the time. debian-x@ldo, xfree86@xfree86.org, devel@xfree86.org. > > getting your own hands dirty, checking that it actually works on all > > architectures, not just builds, and not letting things slide (e.g. > > That i can difficulty do, i can have access to i386, powerpc soon, m68k > with a bit of work, and sparc until september. Possibly mips also, but > it is not at all sure, and anyway, the mips box doesn't has the disk > space to build X on. I suggest you find people with other ports. > But i hope that there will be at least some users of the packages that > will provide feedback if it breaks, or at least that some porters will > try it from time to time. Or do you test your packages on all arches > before you release a new version ? I'm stalling the -0ds3v2 release until I can get it working on alpha, hppa, hurd-i386, i386, ia64, powerpc, s390 and sparc. > > It's really a full-time job, although maintaining the .99.x snapshots > > was easier, because I didn't have to deal with the patch hell I have > > now, with 4.3.0. > > My idea is to try to integrate the debian's patch as much as possible > with the upstream ones, to work from the last good debian version by > applying all upstream patches, instead of the other way around. As said, > i really don't think these would be as high quality packages as > Branden's package, at least at first, nor is that my aim. Then it's largely useless to the XSF - the bulk of the work in migrating to new upstream versions lies in debian/patches. > > Well, you're really very much on your own. I personally won't put my > > name to something I'm not involved in, let alone something I don't even > > use, and Branden probably feels the same way. > > Err, i was more thinking about recomendations on what not to do based on > your experience and such. What not to do: start packaging X. ;) > > If your package is of good enough quality, it'll get integrated in. It's > > really that simple. > > I don't understand what you mean by integrated in. Well, the X team will use that as a base for their future work. > > There are only two ways you can get it built on every supported > > architecture: > > * Upload it to Debian. > > That was what i was thinking. Altough some may object to having a second > such huge source package around. Yes. Me, in fact. For two reasons: * It implies that it's supported by Debian/XSF. * It bloats the archive further. > > * Have one machine of every architecture, or be friends with someone who > > does. > > Highly unprobable and maybe not time efficient, as it would demand of > these friends to do the builds by hand. Altough i guess some > autobuilders trigger X builds by hand anyway. Well, just throw them source packages every now and then. sbuild helps. > > It doesn't happen any other way, unfortunately - I'm pretty sure regular > > developers can't inject stuff into sbuilds. I personally spend a fair > > bit of time running around on IRC and in private email talking to all > > the porters, trying to get things built, rebuilt, patches tested, > > getting failure reports, et al. > > Yes, ... > > But BTW, i think that, as you said, many of the problems encountered > will be common to all three packages, yours, mine and brandens, and so > should the fixes be also, i think. Well, some of them. But, IME, most aren't. > > Well, you're welcome to create them - I'd certainly be out of line to > > attempt to prevent you doing so. I'd be interested to see how they > > progressed as it went along, patches gradually became more difficult to > > maintain (commenting out checksource_command is *not* the right > > solution), etc. The key issue here is how much work you intend to put > > in, as it's really not a part-time job. > > I will do that as part of my free time, so it will be a part-time job > whatever happens, but i think it is not as difficult as you may think, > since contrary to your and branden's package, my aim is to lower the > quantity of needed patches by applying as much of them as i can > upstream. If your aim is to be an upstream patch-pusher, I wish you the best of luck, but you can do this without making packages. David Dawes is also notoriously hard to get patches past. > > hinder the X team, because it means they'll have to deal with a lot more > > questions from users, cut because they can't cleanly upgrade, or they > > don't have a working X, or whatever. > > Well, i don't know, i was goign to preface the discution by a 'highly > unstable, use at your own risk, never bother branden about them, send > all bug reports to me' kind of thing. Not that everyone would read them. Of course not. Some bugs about my packages still go to daniel-x. > That said, it would be clear from the /var/log/XFree86.0.log which > version is run, and bugreports because /var/log/XFree86.0.log are > not handled anyway. You're expecting people to follow what we say and attach them? > > [0]: The most-commented on feature of XFree86 4.3 is the cursor stuff. > > Well, it is broken, and upstream ships it disabled by default. > > BTW, can you apply this patch please to your next version of packages, > it fixes a server crash in case you are using shadowfb and SW ARGB > cursors adn bring the cursor to the bottom of the screen. You can name > it as stolen from head, as it will be commited soon. You have to apply > it in xc/programs/Xserver/hw/xfree86/shadowfb. Applied. -- Daniel Stone <daniel@raging.dropbear.id.au> <dstone@kde.org> KDE: Konquering a desktop near you - http://www.kde.org
Attachment:
pgp6r1y0DrC8n.pgp
Description: PGP signature