New release process for 1.8 (READ THIS)

[Ping]

On Wed, Sep 30, 2009 at 6:59 PM, Dave Airlie <airlied at redhat.com> wrote:

>  On Wed, 2009-09-30 at 18:35 -0700, Daniel Stone wrote:
> > Hi all,
> > Following on from Peter's email about the 1.8/7.6 release process[0], we
> > had a BoF about the same[1] at XDC.  Everyone broadly agreed on the
> > substance of Peter's mail, and here are our rough conclusions.
> >
> > Release process: We're going to aim for a six-month release process, as
> > Peter outlined, with 3 months feature freeze, 2 months bugfix, and the
> > final month release freeze.  We're going to start this for 1.8, and
> > hopefully we'll be able to land predictable releases.
> >
> > 7.6: Either Peter or keithp will be the RM: they can arm-wrestle for it.
> > I assume the six-month cycle will start on the day 1.7/7.5 is released
> > (hopefully Monday).
> >
> > Development model: xserver master will be closed to general commits; it
> > will be owned by the RM, or one of their delegates.  Again, DO NOT
> > COMMIT DIRECTLY TO XSERVER MASTER.  Everyone should have their own
> > xserver trees, and/or one per subsystem (I'll have xserver-xkb and an
> > input tree, I guess Peter will have an input tree, there should be an
> > EXA tree, etc, etc).  When you want to push something to master, either
> > send patches to the list, or send a pull request for your tree.  ajax
> > has quite unwisely volunteered to run a trivial-patch tree, accumulating
> > random misc.  When you send a pull request or patches, it's expected
> > that they've been tested and are working to preserve bisectability, and
> > don't destroy ABI every other commit, so feel free to buffer them up a
> > bit.  Judicious use of rebase -i is not wholly discouraged.  I know this
> > sounds concerning, but if your merge request just gets forgotten or
> > dropped on the floor, bug us until we make it happen.
>
> My main issue with this is, while we'd like to be the kernel, we have in
> no way got the developer/testers bandwidth they have. Generally when
> developing a feature for the kernel, you can find someone else to
> interact with while you write the code and bounce it around to get the
> bugs out, etc.
>
> With X generally requests for testing things no on master and not
> directly affecting another developer at that point go unnoticed, the
> only way stuff really gets tested in X is indirectly, by people cloning
> master and running it, its unfortunate but I don't think its due to our
> process but lack of bandwidth.
>

I have a different view - I think the root cause is not in the bandwidth.
It lies in the lack of process that attracts people to join the
"bandwidth".  We need people here like Andrew Morton, who was awarded
as "Unsung Hero" by LF this year (
http://www.linuxfordevices.com/c/a/News/Linux-summit-surprises/) for his
contribution to kernel.org and nurturing new programers (my first dummy
patch was picked up by Andrew before it went unnoticed).  I agree that
x.orgis different from
kernel.org.  But x.org has a broad application developer and user base.
Those people care about the changes in x.org a lot more than in kernel.org. If
x.org could attract those developers to make patches and those users to test
release candidates, from long run, I don't see the bandwidth as an issue.

I didn't contribute to x.org.  So I don't think I have the privilege to say
how the processes should be established.  But, with more than 15 years of
proferssional software developerment experience (about 9ish of them are in
Open Source) and my intersest in seeing a robust, realiable, and predictable
(yes, we need a roadmap before starting the coding caravan) X server, I dare
to share my two cents.

1.  Have a page (pages) that describes the simple steps to get started with
testing and contributing to x.org.  Those steps may be just a few links to
other sites or even to some distro's pages. But, these steps should be
searchable on x.org website.  Leaving potential contributors to "google"
around the internet for programming and testing x.org is not a good
attitude.

2.  Delgate the roles for maintaining and managing the subtrees/repositories
to experienced developers.  These maintainers would also be responsible for
"recruiting" new programers and testers. In order to encourage people to
jump into, set the bar as low as you could just recongnize their potentials
in making valuable contribution in the future.  That is, the maintainers may
have to make a lot of changes themselves or make inspirational
suggestions to the first time contributors. However, the bar lifts as people
improving.... x.org is a worldwide recognized project.  There are a lot of
reasons for people to make contributions here.

3.  As a common sense, the maintainers are also responsible for making sure
all patches are merged or rejected with a reason. Regression testing is done
for all x.org release candidates.  The coding and testing work don't have to
be directly done by the maintainers.  It is the same as managers
don't really do the realy work :). You just need to make sure someone you
trust has done the job. Finding the ones that you can trust is definitely
the maintainer's responsibility.

Ping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20091001/0acfdff3/attachment.htm