On Mon, Apr 14, 2003 at 07:51:30AM +0200, Sven Luther wrote: > On Mon, Apr 14, 2003 at 10:30:16AM +1000, Daniel Stone wrote: > > Then it's largely useless to the XSF - the bulk of the work in migrating > > to new upstream versions lies in debian/patches. > > Yes, but this is checking all older debian/patches when a new upstream > release comes out and applying them again, which could include looking > at the code and adapting or rewriting them. If some/many of these > patches where already integreated upstream, then the work is much less, > and it is there where i hope to help. Even keeping patches up-to-date between CVS revisions is non-trivial, let me assure you. > But then, maybe the XSF prefer to continue maintaining the debian fork > of X, i don't think it is really all that efficient in the long run, as > we have seen by the late adoptal of new upstream releases, but it sure > give them the possibility to say "upstream don't support as many arches > as we do". Funny also what Branden did say in the last X teleconference, > if the quotes where rightly attributed to him, it was especially funny > watching him push upstream, while knowing he don't like to be pushed. no > offense intented Branden ... Well, seeing as there's currently only two people working on packaging X, it means that we have a more stable X. If you want to add yourself to the effort by doing this, by all means, go ahead. But us abandoning releases for working out of CVS will never happen, as much as you'd like it to, because that would result in a horrifically unstable XFree86 in sid. We've been over this before. > > Well, the X team will use that as a base for their future work. > > No, that is not my aim, i want an official .deb, so it get auto-built > and such, altough even that is not necessary, but it should never get > integrated by the XSF (err, that is what you mean, for me, the X team, > is the X upstream team). Once there is a new release, they just will > find it better/easier/quicker to debianize it, as there will be less > patches. See below. > > For two reasons: > > * It implies that it's supported by Debian/XSF. > > No, it implies that it is supported by me, since i am the maintainer, > and there will be a big disclaimer about this in the description, maybe > even a debconf warning at install time. > > As an example, we had until recently the galeon and galeon-snapshot > packages, with different maintainers, and it worked well. You're expecting users to follow this? No matter how many disclaimers you paint up, I guarantee you at least 50% of users won't follow it. Despite having massive disclaimers all over the unofficial/backport KDE packages not to ever report anything about them to the BTS, a few bugs still hit the BTS. And those packages weren't even in the archive. > > * It bloats the archive further. > > That is the real problem. It's another large problem (excuse the pun), especially in places where people pay for their bandwidth. Debian's large enough already without all this hideously unnecessary bloat. > > Well, just throw them source packages every now and then. sbuild helps. > > In a bi-monthly way ? maybe i will skip one of the snapshots or so at > first. They are scheduled for the 10th and the 25th of the month. Well, I just email all the porters who help me out when I have a new source package ready, and get them to build it. They come back with either a location for debs, or a log of the build failure; can't ask for much more than that. > > Well, some of them. But, IME, most aren't. > > Well, let say it differently, most fixes between your packages and mine > should be common. After all 4.3.99.2 is not so different from 4.3.0 yet, > and you even have part of it already integrated. Yes, but it's only been a month or so. Wait another month or more, and watch how significantly they've diverged. Soon enough, you'll have your packages as different from mine, as mine are now from Branden's. You'll also probably be in the situation I'm in, where design decisions, such as xlibs-data (and, for the future, the xlibs/xbase-clients splits), are implemented in your package, but not in the ones in the archive, because it would be too large a change for a minor revision. > > 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. > > Pure FUD. You don't have to work against them but together. The real > reason of making packages was : > > 1) to use our autobuild network, but then maybe we can use them in an > automated by-monthly way outside the debian packaging system. Problem with this is, feeding a huge package like XFree86 every fortnight to autobuilders is no good. Some of the slower architectures are running pretty close to full-usage already, and it'll be woeful if we have a situation like m68k, where half of the buildd rotation went out of action for a week, and built packages declined rapidly, and took a while to catch up. > 2) to get feedback from at least some users who are willing to try > these package, and to notice breakage on other arches as soon as they > happen upstream, so it is easier to track them, and get the > cooperation/attention of the ones doing the breaking. Nice side-effect, sure. > 3) So people who need the CVS snapshot's (like me or other upstream X > developpers for example) can have packages installed and don't need to > make their own installation. Define "need" - are you talking about another i845g situation? > > Of course not. Some bugs about my packages still go to daniel-x. > > That is solely because you have not a debian package, and also not a a > proper BTS entry. I of course meant 'debian-x', but putting it in the archive implies: * overloading autobuilders, especially when you have to try a couple of things before your build succeeds. * bloating the archive. > > You're expecting people to follow what we say and attach them? > > Well, if they don't, Branden has a form letter he send to them, and they > give these files if they care about the bug. It's still a nuisance to send that form letter. -- Daniel Stone <daniel@raging.dropbear.id.au> <dstone@kde.org> KDE: Konquering a desktop near you - http://www.kde.org
Attachment:
pgpAj6SHy_ZPu.pgp
Description: PGP signature