Re: Administrative notice: xfree86-list@xxxxxxxxxx mailing list deprecation alert.

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

 



Thomas Dodd wrote:
Mike A. Harris wrote:

Since our switch to X.Org X11 away from XFree86, the already
low volume on this mailing list has dropped quite a bit, which
I believe is indicative that while not all people upgrade to
each new OS release, the majority of people using our community
OS releases have upgraded to FC2 or later already, and seem to
participate in the various Fedora mailing lists we provide, as
well as the upstream xorg@xxxxxxxxxxxxxxx mailing list.


Is the shipping X.Org packages be closer to the upstream versions than the Red Hat XFree86 packages were?

Technically that depends on the given X project. Let me explain what I mean in greater detail.

With XFree86, releases
were 12-18 months apart, which is an incredibly long time to wait for
an upstream X release.  People do not want to wait that long for a new
X, and then wait another 1-6 months or so for their favourite distro
to update to the new X just to get their now 14 month old video card
to work.

Also, when bugs get fixed, either by the upstream X projects, by Red
Hat, by other distributions, or by random developers in the community,
a bug fix is a bug fix is a bug fix, and the masses of people out there
using our OS, or Debian, or Mandrake, SuSE, or anything else - do not
want to be told "you have to wait 16 months until the new release of
XFree86 is out, sorry, we wont apply patches because then we're not
"stock".

People want support for their hardware, and they want it to be stable
and reliable.  They don't generally care wether the code is 100% stock
upstream code, or patched with new driver support and bugfixes.

So it really doesn't matter.  People use a prebuilt OS distribution
because they want to use a working OS, not because they want to
reduce the number of patches in use for pedantic reasons of purism.

Those who are purists, are of course free to recompile the buggy
stock source code themselves, with ancient driver support if they
like, and keep all the bugs.  ;o)


One of the reasons X.Org was re-established, was specifically to solve a number of the problems with other existing open source X implementations at the time. The emphasis has always been to make X.Org not only continue to be an open source project, but to be an "open project" project. One that people can easily get involved with, and are helped - not hindered. To build a community around X11 development, and to nurture and mentor new developers, and encourage people to get involved.

Another goal of X.Org, is to follow the "release early, release
often" mantra of the open source community.  Whereas XFree86
generally released a new release every 12 to 16 months, which
more or less forced distributions to apply numerous hardware
support and bugfix patches one on top of another, quickly
piling up into the hundreds.

X.Org has released 4 separate releases of X.Org X11 in the
last 12-14 months or so.  There was the initial 6.7.0 release,
followed by the 6.8.0 release about 6 months or so later,
followed by a 6.8.1 release a week or two later, then the
6.8.2 release a few months after that.  Work is underway
currently to build a 6.8.3 "bugfix stable" release within
the next few months (no specific date set yet), and the
6.8.x branch will continue to be maintained at least as long
as there are developers or distributions interested in
continuing the branch.  In parallel, the 6.9(monolithic)/7.0(modular)
release is under development, and will be released later this
year.

The bottom line of all of this, is that patches get both
submitted upstream to X.org faster, committed to CVS head
faster (for the next major release), reviewed for consideration
for the next stable branch release (unlike other well known
open source X implementations), and checked into the stable
branch, and actually released in a bugfix point release
within a few months.  This means distros only need to apply
patches for a few months, which makes the patch pileup much
smaller.

Additionally, since it is so much easier to get patches into
X.Org, we've established a more or less "defacto" policy
of NOT including any patches into our rpms, UNTIL they are
submitted by someone to X.Org bugzilla and committed directly
into CVS, then nominated for the stable branch.  While there
are, and always will be some exceptsions to this "defacto"
rule we're observing, the net result is that the majority
of patches you see in xorg-x11-6.8.2 rpms in FC4, are mostly
patches either already committed to Xorg CVS, or are patches
in the "nominated for 6.8.3 and likely to be included" queue.

So when 6.8.3 is released, and I update the rpms for FC4, we
more or less can throw away almost all of the patches we are
applying, minus a small few.

So far, maintenance of xorg-x11 has been a dream, compared
to other X11 implementations from a previous life.  ;o)

> If so, the the X.Org list would be more responsive to questions from
> Fedora/Red Hat uses.

There's really no "if" there.  The Xorg community is very friendly
in general, and very helpful.  There is generally no animosity
towards any distributions or individuals.  You'll find the Xorg
community to be very friendly and much more responsive than some
other well known projects.

Also, X.Org doesn't have a "core team" of elite individuals
who reign supreme.  There are a number of developers who are
long time X contributors, who are on the board of directors
or architecture working group, but there is no benevolent
dictator(s) in X.Org.  It is all very much a community thing,
and anyone can get involved tomorrow if they like, dial in on
the confcalls, IRC, all mailing lists (they're all public),
share opinions, nominate patches, etc.  Obtaining CVS write
access is a fairly informal process - one just has to get
involved, chat with everyone in email/IRC, find something
they're interested in working on, and do it.  After they
submit some code, unless it is really crazy or crappy, they
can generally get CVS access right away, or after submitting
code a few times.  It's more or less very similar to how
the GNOME project works.

So you wont find animosity towards Fedora/Red Hat users generally
speaking.  There might be random individuals out there, but
I guess that's unavoidable.  ;o)


X.Org is likly more responsibve that the XF86 lists were when this one was started.

About 10000 times more.

Fedora development seams is a bit more public than Red Hat Linux was, back when this list started.

Yep. So is X.Org compared to other open source X11 implemenation projects. ;o)


I assume nobody here will really have any strong feelings one
way or another, as the list has been mostly dead for quite a
while now, however feel free to respond back to the list if
you have any thoughts about the above plan.


Until/unless Fedora diverges considerably from X.Org sources, you won't see much need for a seperate list.

Generally speaking, the majority of patches we've ever applied to X (XFree86 or Xorg) have all been things that went into the next X release, or the one after that. We very much dislike carting around lots of patches and maintaining them forever. Unfortunately with 12-18 month release cycles of the previous X implementation, we had no choice in order to meet our users and customer's needs. With X.Org however, while we still apply patches that fix bugs and add /some/ new hardware support (but usually very conservatively), we try to stick to the set of things that are in the 6.8.x approval queue, or which we plan on submitting ourselves to the queue, and have a high degree of confidence they'll be accepted.

So our X will never diverge very far from XORG-6_8-branch by nature,
although it will predate it by a few weeks/months a bit.  This is
a good thing though, not a bad thing, because the patches in the
approval queue are much more likely to be included if people such
as myself are saying "we've shipped this for 3 months now and it
fixes the problem and does not seem to regress anything".

Short story is:  X.Org is more interested in progress of X11
technology, and providing the best implementation of it out
there, than getting involved in petty distribution politics,
etc.


Given that there is no longer a "free" Red Hat product, a public list
> from Red Hat isn't very useful either. (I would never have asked a
> Fedora question here)

Well, as you allude to, "Fedora Core" is the "free" thing we now
provide, only it is called a "Project" rather than a "Product".
However in practice, the difference is quite cosmetic and
semantical for the most part IMHO.

Fedora questions related to Xorg are welcome here, but I definitely
would encourage people to use xorg@xxxxxxxxxxxxxxx or
fedora-list@xxxxxxxxxx instead, as the number of useful replies
that would come back would likely be far greater than on this
slowly dying list.  ;o)

Most of us know how busy you are anyway. Maybe when the next big thing comes along you revive this list, or similar ... :)

;o)

My hope for the last n years, has been to see the X11 developer
community come together and unite towards a common goal - working
together and encouraging others to do the same, making progress
focussing on common interests and ideologies, rather than focusing
on differences and politics.  It's been a bumpy ride along the
way, but finally the reborn X.Org came out of it all, and in the
last 16 months everything has magically come together.  Major
strides are being made now, and the developer community is
growing and growing very quickly as more and more people get
involved both in X.Org, and in the variety of projects that
surround X.org and freedesktop.org.

The next "big thing" to come along, will likely be X11R7, slated for
later this year.  That'll definitely keep me busy for FC5 for sure.
By killing this mailing list, I'll have 10-20 more seconds each day
to contribute to X.Org development.  ;o)

Happy trails.
TTYL

_______________________________________________
xfree86-list mailing list
xfree86-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/xfree86-list
IRC: #xfree86 on irc.redhat.com

[Red Hat General]     [Red Hat Watch]     [Red Hat Development]     [Kernel Development]     [Yosemite Camping]

  Powered by Linux