<div class="gmail_quote">On Wed, Sep 30, 2009 at 6:59 PM, Dave Airlie <span dir="ltr"><<a href="mailto:airlied@redhat.com" target="_blank">airlied@redhat.com</a>></span> wrote:<br> <blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote"> <div> <div></div> <div>On Wed, 2009-09-30 at 18:35 -0700, Daniel Stone wrote:<br>> Hi all,<br>> Following on from Peter's email about the 1.8/7.6 release process[0], we<br>> had a BoF about the same[1] at XDC. Everyone broadly agreed on the<br> > substance of Peter's mail, and here are our rough conclusions.<br>><br>> Release process: We're going to aim for a six-month release process, as<br>> Peter outlined, with 3 months feature freeze, 2 months bugfix, and the<br> > final month release freeze. We're going to start this for 1.8, and<br>> hopefully we'll be able to land predictable releases.<br>><br>> 7.6: Either Peter or keithp will be the RM: they can arm-wrestle for it.<br> > I assume the six-month cycle will start on the day 1.7/7.5 is released<br>> (hopefully Monday).<br>><br>> Development model: xserver master will be closed to general commits; it<br>> will be owned by the RM, or one of their delegates. Again, DO NOT<br> > COMMIT DIRECTLY TO XSERVER MASTER. Everyone should have their own<br>> xserver trees, and/or one per subsystem (I'll have xserver-xkb and an<br>> input tree, I guess Peter will have an input tree, there should be an<br> > EXA tree, etc, etc). When you want to push something to master, either<br>> send patches to the list, or send a pull request for your tree. ajax<br>> has quite unwisely volunteered to run a trivial-patch tree, accumulating<br> > random misc. When you send a pull request or patches, it's expected<br>> that they've been tested and are working to preserve bisectability, and<br>> don't destroy ABI every other commit, so feel free to buffer them up a<br> > bit. Judicious use of rebase -i is not wholly discouraged. I know this<br>> sounds concerning, but if your merge request just gets forgotten or<br>> dropped on the floor, bug us until we make it happen.<br><br> </div></div>My main issue with this is, while we'd like to be the kernel, we have in<br>no way got the developer/testers bandwidth they have. Generally when<br>developing a feature for the kernel, you can find someone else to<br> interact with while you write the code and bounce it around to get the<br>bugs out, etc.<br><br>With X generally requests for testing things no on master and not<br>directly affecting another developer at that point go unnoticed, the<br> only way stuff really gets tested in X is indirectly, by people cloning<br>master and running it, its unfortunate but I don't think its due to our<br>process but lack of bandwidth.<br></blockquote> <div> </div> <div>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 (<a href="http://www.linuxfordevices.com/c/a/News/Linux-summit-surprises/" target="_blank">http://www.linuxfordevices.com/c/a/News/Linux-summit-surprises/</a>) for his contribution to <a href="http://kernel.org/" target="_blank">kernel.org</a> and nurturing new programers (my first dummy patch was picked up by Andrew before it went unnoticed). I agree that <a href="http://x.org/" target="_blank">x.org</a> is different from <a href="http://kernel.org/" target="_blank">kernel.org</a>. But <a href="http://x.org/" target="_blank">x.org</a> has a broad application developer and user base. Those people care about the changes in <a href="http://x.org/" target="_blank">x.org</a> a lot more than in <a href="http://kernel.org/" target="_blank">kernel.org</a>. If <a href="http://x.org/" target="_blank">x.org</a> 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.</div> <div> </div> <div>I didn't contribute to <a href="http://x.org/" target="_blank">x.org</a>. 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.</div> <div> </div> <div>1. Have a page (pages) that describes the simple steps to get started with testing and contributing to <a href="http://x.org/" target="_blank">x.org</a>. 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 <a href="http://x.org/" target="_blank">x.org</a> website. Leaving potential contributors to "google" around the internet for programming and testing <a href="http://x.org/" target="_blank">x.org</a> is not a good attitude.</div> <div> </div> <div>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.... <a href="http://x.org/" target="_blank">x.org</a> is a worldwide recognized project. There are a lot of reasons for people to make contributions here. </div> <div> </div> <div>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 <a href="http://x.org/" target="_blank">x.org</a> 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.</div> <div> </div> <div>Ping</div></div>