Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 04:29:35PM +1000, Daniel Stone wrote:
> 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.
I was thinking of doing it the other way around, but well, time will
tell what i manage to do.
> > 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
And again, i don't want it to.
> it to, because that would result in a horrifically unstable XFree86 in
> sid. We've been over this before.
Yes.
> > > 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.
This only hints at the problem of the current X packages. I had a user
asking about cursor on the X mailing list i think, and sure enough he
was using woody backports of your packages.
> And those packages weren't even in the archive.
That's the problem with them, as i always said, if you have an xfree86
package and an xfree86-snapshot package, most of our users are
knowledgeable enough to know what that means. Compared to having a 4.3.0
package out there, and people thinking it is available because branden
don't care about 4.3.0 or something such.
> > > * 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
???
If they don't want it, they don't download it. The only problem would be
with mirrors.
> all this hideously unnecessary bloat.
So you propose i bloat my DSL line, and my work-room with 10+ machines
of every possible arches instead ?
It would be up to the ftp-master in the end, but i suppose they won't go
for it without at least a green light from branden.
> > > 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.
But they will most assuredly not be really much happier to build 2 such
huges packages. And you have done one release only so far, haven't you ?
> > > 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.
I was thinking of starting from your packages, apply the upstream
patches one by one and stop as soon as somthing breaks and give feedback
to the upstream author of the breaking patch. In parallel i would like
to go over the debian patches, especially the portability ones, and
integrate them upstream. Anyway, i still need to do at least one of
those packages, and we can discuss the merits of it after that.
> > > 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.
Well, as said, i can skip one snapshot, and do it monthly, or maybe the
autobuilders can put the package on hold or something and trigger them
only if there is time for it. I think the problem will be mainly on
m68k, mips/mipsel and arm. I do have access on a m68k box, but it is
rather slow and it is well possible that i would need more than 2 weeks
for the build alone, especially as there are failures.
> > 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?
I am developping a new driver for X. As such i only really need to
install a specific module. Now, near to the 4.3.0 release i can just
install it in the on top of your package by placing it in the right
directory. But usually, i have to have a cvs tree, which installs itself
in another place (/usr/local/X11R6 or /usr/X11R6-cvs or something) and
use the server from there in conjunction with the rest of the 4.2.1 or
now 4.3.0 packages.
Having a package of regular CVS snapshots i can use only this, and just
install my driver module over it.
Granted, there is very few people who will use this, maybe only me and
maybe Michel.
> > > 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:
Well, that is what you openly advertize, i don't remember where i read
it, but somewhere in your package is written that bugreports should be
posted to debian-x.
> * overloading autobuilders, especially when you have to try a couple of
> things before your build succeeds.
I could have a arm/m68k/mips cross compiler on my system, and later have
the packages build on real system once they are ok. Uploading a package
every month only or so, uploading my own m68k packages, it all would
depend on the specific needs of the different autobuilders and porters.
> * bloating the archive.
That is the main problem, but there is speak of adding 100Mo data
tarballs and such, so i suppose the archive can handle a second X
tarball also.
> > > 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.
You know, it could be automated. You could simply have a little program
that parses the x related bugreports, check for "XFree86 Version" or
whatever in it, and send the form letter if they are not present.
BTW, why does the mail from you, or from me to you, get catched by that
stupid spam filter, which insist on putting the mail on a web site
somewhere and telling me about it ?
Friendly,
Sven Luther
Reply to: