Re: gnome-randr-applet and Xfree86 4.3.0 ...
On Thu, Apr 03, 2003 at 06:04:01PM +1000, Daniel Stone wrote:
> 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.
BTW, you don't build -dbg versions of the 4.3.0 package, right ?
> > > 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.
Far more arches, yes. BTW, do you build your 4.3.0 package on all arches ?
> > > 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.
But if 4.3.0 doesn't make it into stable, like it seems to be going,
then we will ship with a more than a year old X release, and most newer
graphic cards will not work for our users.
I think our priority should be that we ship sarge with a rock solid
stable and at least somewhat recent X server. I know that Branden's aim
is to have a rock solid unstable version, and that these two goals
conflict.
> 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.
Yes, i understand that, but your public stance doesn't invite
cooperation.
> > > 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?
And why do you think that is ? If someone get burned once, he will no
more approach the fire.
> > > 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.
XFree86 should be backward compatible 10 years and more. This should not
be a problem, any program built against any xlibs should be able to run
with any x server. If this is not so, then it is a bug and should be
filled.
Exeption to this is features not available in older versions of xlibs
(like randr), which would depend or build depend on newer versions, or
things like the DRI packages from Michel.
> > 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.
Yes, but this discution is not made public, which don't invite
cooperation from other people either, so you cannot held a closed
developpment model and complain about the lack of people getting
involved at the same time.
> > > 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?
The XFree86 fork by Keith and the whole flamewar on the xforum mailing
list.
> > > 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?
If you submit good patches, you will get commit access eventually. The
things are changing, and it is evident that the core team will widden
the group of committers nextly. Also we have an unique area of expertise
which nobody outside of the X strike team has, we run X on 11 supported
linux architectures, and a handfull others too. This is a valuable
thing, and since nobody else has this expertize and the material to do
the porting, the Debian X Strike team is the natural choice for commit
access for things regarding porting issues.
Mike Harris had commit access, he misused it and lost it, but he had
commit access, and you self said that our packages are the best quality
of them all, so why should we not have access ?
> 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.
Yes, and you have done great work, thanks for 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.
Yes, but if you don't discuss it openly, people will think that there is
no point in helping out, because debian is only interested in 4.2.1,
which don't even build on all arches, and that's it.
Friendly,
Sven Luther
Reply to: