Re: X bi-monthly snapshot packages.
On Mon, Apr 14, 2003 at 10:30:16AM +1000, Daniel Stone wrote:
> 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.
Ok, i have no problem with that, altough i am not on xfree86@xfree86,
but i am also on the other upstream lists.
> > > 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.
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.
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, 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.
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.
> > > 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.
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.
> * It bloats the archive further.
That is the real problem.
> > > * 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.
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.
> > > 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, 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.
> > > 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.
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.
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.
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.
> > > 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 is solely because you have not a debian package, and also not a a
proper BTS entry.
> > 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?
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.
> > > [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.
:)))
This would maybe not be the final patch, but it solves the problem,
there may still be some cosmetic changes though.
Friendly,
Sven Luther
Reply to: