[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: gnome-randr-applet and Xfree86 4.3.0 ...



On Thu, Apr 03, 2003 at 09:28:41AM +0200, Sven Luther scrawled:
> On Thu, Apr 03, 2003 at 05:06:49PM +1000, Daniel Stone wrote:
> > 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
> 
> And here is the problem. Until upstream patched it ? But i suppose the
> debian package ran ok on ia64, did it not, or that we where working on
> it. Did we submit patches about this to upstream ? Or did they duplicate
> the work we did ?

xserver-xfree86-dbg ran. xserver-xfree86 didn't. I talked to mharris and
upstream about it, and no-one really had any idea, so we passed it
upstream.

> > stop. You picked whether you wanted to run it on Intel or HP, with no
> > middle ground, full stop.
> 
> Well, upstream supported ppc before debian did.

Yes, but we now support far more stuff than XFree86.

> > 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,
> 
> Yes, this is true, but it only proves my point. It has no porting work
> done to it, because we are doing the porting work in our corner, and
> don't contribute it back to upstream at least not before the release.
> 
> Also maybe they don't support as many architectures as we do, but they
> support many more OSes, so maybe they have other priorities.

As I said, take your pick: always having the latest and "greatest", or
something with rock-solid stability, in unstable. I'll go for the
latter, personally.

I'm sure they have other priorities, but we're not going to completely
shatter ours just to fall in line with the priorities of every other
project around.

> > 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, i well understand this, but by taking this position, you also
> imply that it is inevitable, and that nothing can be done to change it.

Considering I'm not in a position, either physically, or in terms of
time, to pull a 4.4/5.0 package setup before it's released, and fully
ported, then there's nothing *I* can personally do. As I said before,
and to AJ, a lot of people talk about it, but there are only three
people doing something about it.

> > The alternative involves cloning Branden and/or myself (if you clone me,
> > don't clone the RSI bit, that's counter-productive).
> 
> Or adding more people to the X strike team. Something which you are more
> likely to obtain with a more open goal than the current attitude. I know
> that at least two debian developpers (Michel and me) are also upstream
> XFree86 developpers.

Yes, and how much work on the packages do you guys both do?

You don't add people to the team and hope they work after that, it's
vice-versa. So far, Ishikawa-san has been the only other person to
actually work quite productively on Debian's XFree86 packaging, and I
commend him on a great job.

It's still down to three of us.

> > 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
> 
> False, there is no reason for it not entering unstable, it cannot reach
> testing until it is buildable on all supported arches, but there is
> nothing stopping it from being in unstable, maybe as a renamed package,
> like galeon and galeon-snapshot, but this is a pain to do, i think,
> which is why i said that a more advanced pool system (where you have the
> XFree86 4.2.1 pool, the XFree86 4.3.0 pool and maybe a development
> snapshot pool) would help us out here.

Yes, but then you have the situation whereby some packages built with
XFree86 4.3 don't work on 4.2 installations, because the API has
changed, or whatever. It also bloats the archive, and the amount of work
that would be spent doing this, is better spent on getting it ported.

> > 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..
> 
> Not really scalable either.

No, it isn't. As I said, I'm considering setting up debbugs here, which
is quite scalable. At the moment, there is exactly one maintainer of my
XFree86 4.3 packages, so I'm going to be a large factor in any
scalability anyway.

> > 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.
> 
> Do you discuss these things between yourselves ? Or are there any forum
> or docs or whatever speaking about the current situation, and what the
> plans are ? If you don't communicate, and have in addition the don't ask
> us about attitude, people will not feel like wanting to get involved.

I don't ask Branden if I can wipe my nose, but I have frequent
discussions with him about patches, packaging, directions, et al, on
email and IRC. A lot more of the 4.3 design decisions than you may think
have been made by Branden.

> > 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.
> 
> Yes, and that is what started this whole polemic, didn't it ?

Which whole polemic?

> > 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.
> 
> But it should be a worthy goal, shouldn't it ?

Yes. A similarly worthy goal is having no child living in poverty by
1990[0].

> > 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.
> 
> Maybe i will, but like said, i am mostly a lowlevel driver guy, even if
> i ever got commit access, it would be for that area only, as i really am
> not enough familiar with the debian specialities. This may change in the
> future though, depending on free time and such.

Well, what makes you think that *we're* likely to get global commit
access, especially given XFree86's track record with dealing with
distribution vendors?

The best way to get things moving with regards to XFree86 4.3 is to get
in and help. So far, I've seen no volunteers to do this; several porters
have been really helpful, and Ishikawa-san's patch work was a great
base, and Branden's been very helpful (the XFree86 packaging setup is no
trivial beast, even with my quite good previous knowledge of DBS, and
this is my first time with XFree86 packaging, so his experience has been
invaluable), as have several porters, but that's the sum total of it.

I cannot stress this enough: paragraphs about the situation on debian-x
are pointless. Diffs in emails to me are invaluable, and really the only
way to get the whole thing moving quicker than it already is.

[0]: Former Australian Prime Minister Bob Hawke promised this. Guess how
well it worked.
 
-- 
Daniel Stone                                     <dstone@trinity.unimelb.edu.au>
Developer, Trinity College, University of Melbourne

Attachment: pgpCbJY13na1G.pgp
Description: PGP signature


Reply to: