Re: gnome-randr-applet and Xfree86 4.3.0 ...
On Thu, Apr 03, 2003 at 05:06:49PM +1000, Daniel Stone wrote:
> On Thu, Apr 03, 2003 at 08:32:09AM +0200, Sven Luther scrawled:
> > On Thu, Apr 03, 2003 at 07:53:12AM +1000, Daniel Stone wrote:
> > > Well, if we were were working on 4.3.0, 4.2.1 wouldn't be as well
> > > supported as it is: it takes quite an amount of work to support, and
> > > porters would also be split on which one to support - do they debug
> > > problems and try to fix with 4.2.1, or do new porting with 4.3.0?
> >
> > That is just a problem right now, because we are one version behind. If
> > we manage to release a quality 4.3.0 soon, and start working on the next
> > upstream version immediately, then when it is released, we will have
> > packages. We could also decide to skip 4.3.0 and decide to go with the
> > next version directly, but i would say this is a bit dangerous right
> > now, while things are floating and upstream has not given a fixed
> > schedule. Just after the Woody release we could have done that with
> > more confidence though.
>
> 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 ?
> 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.
> 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.
> 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.
> > > Well, it's the best we've got in the meantime, I'm afraid.
> >
> > Sure, because nobody seriously considers the alternatives.
>
> 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.
> > > And I've been doing 4.3 for months, working as closely with Branden as I
> > > can (you'll notice that I do regular back-syncs with 4.2.1, and a few of
> > > the design decisions I made were stuff Branden was going to do in his
> > > 4.3 tree anyway). There's no need to fork the XFree86 team. If you want
> >
> > Yes, but they are not officially part of debian, i cannot upload
> > gnome-randr-applet, and if i submit a bug report about a X related
> > package, the maintainer ask me what strange X package i am running, and
> > there is no BTS for the 4.3 package. I understand that the current pool
> > system is not able to offer more than that, but it would be nice if it
> > were.
>
> 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.
> 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.
> > > to make good, quality packages, go ahead and create them. Just let
> > > Branden know, try to ensure they don't diverge too much from his
> > > packages, or how he plans to do things, and stuff like that. This is
> > > what I've been doing for months now.
> >
> > Yes, and instead of having duplicate work, have triplicate work. Anyway,
> > i have not the time (rigth now) to do this kind of stuff, i have my own
> > group of packages in debian, and have also upstream work to do on X.
> > Back then when i got burnt by my awkward attempt to do X debian package,
> > i decided that i would limit myself to upstream work, which was ever
> > more comprehensive, despite what the huge flamewar seems to imply.
>
> 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'm not "ahead" of it per se. There are still more patches to continue
> > > merging, more documentation to continue writing, and more architectures
> > > to port it to.
> >
> > Yes, but it is no more 4.3, if you (and i would help with this if you
> > want, altough i need a bit of time to adapt to the needs of the debian X
> > package, understand the issues at hand, etc.) where to integrate all upstream
> > changes into this package, and submit the debian diffs upstream also,
> > then when the next release is done, it would not be so difficult to have
> > a debian package quickly after the upstream release. Some of the debian
> > team could even try to get commit access in upstream's CVS. The problem is that
> > this is not done, for whatever reason, and that there is no will to even
> > try to attain this.
>
> 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 ?
> 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 ?
> 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.
Friendly,
Sven Luther
Reply to: