[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 07:53:12AM +1000, Daniel Stone wrote:
> On Wed, Apr 02, 2003 at 04:21:13PM +0200, Sven Luther scrawled:
> > On Wed, Apr 02, 2003 at 11:49:27PM +1000, Daniel Stone wrote:
> > > That means that we'll be unable to support the version in sid, then.
> > 
> > No, why, it only is a problem right now because we are one version
> > behind the XFree86 releases. If we had ready working X 4.3 packages by
> > the time of its release (and 4.3 was frozen since early november, that
> > gives us more than 4 month time), then we can start packaging the new
> > developpment branch, and release it simultaneously or a short time after
> > the new upstream release, instead of still being fixing 4.2.1. In some
> > way, you do already that with your 4.3.0 packages, which are not
> > strictly 4.3.0, but borrow parts of head. If we had a more advanced pool
> > feature, like it was promissed back then, we could even have a 4.2.1
> > pool (on which Branden would work on) and an official 4.3.0 pool on
> > which you and other would work on.
> 
> 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.

> > > There's only a limited number of maintainers and porters.
> > 
> > Yes, that is the real problem. But doing double job with upstream will
> > not help much here.
> 
> Well, it's the best we've got in the meantime, I'm afraid.

Sure, because nobody seriously considers the alternatives.

> > > The issue here isn't skill or anything like it, just time, pure and
> > > simple.
> > 
> > But the attitude of Branden with regard to anything related to 4.3.0
> > doesn't help here. If we were to say that we will start now and try to
> > set up a second XFree86 team which will be packaging the developpment
> > release of X, still work in common with Branden on some issues, and hand
> > him the baby once the official release is made, i think you will
> > possibly attract more people who are interested in just that, and not
> > frigthen them away. After all, if Branden says not to ask questions
> > about 4.3.0 until he is ready, who is willing to risk entering his line
> > of fire about it ?
> 
> Well, Branden has had bad experiences before, like with 4.2, where he
> got flamed for not having a new major upstream version of XFree86 ready
> in time (quite a few people were unable to appreciate how large an

Well, it is not a new thing, already in 98/99, when i was a fresh new
developper, i got burnt by it. At that time, it was still xfree86 3.x
that was around, the powerpc package didn't even build, while it did a
few weeks before, and upstream had no problems with it. I had no much
problem building a 3.3.6 or whatever package, and uploading it, which
was not a good idea, but like said, i was just a novice developper by
then, but the backlash of it was rather severe, and if i had not had the
support of my fellow ppc users, maybe i would have dropped debian
altogether at that time.

> effort it was). It comes down to this: he's not getting paid for it, so
> doesn't want to get harasses about it. I can see that, personally.

Sure, so do we all.

> 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.

> 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.

> > > Another FAQ entry for me to add to -0ds3v2 (patch merge from hell - 4.3
> > > branch, bits of HEAD, plus Michel's Radeon DDC patch), along with the
> > > other 3 I haven't even written yet. *sigh*.
> > 
> > So you see, you are no more packaging 4.3, you are already ahead of it.
> 
> 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.

Friendly,

Sven Luther



Reply to: