It feels like it's getting to be about time for LinuxCNC 2.6, and I volunteer to be your Release Manager.
I've never been a LinuxCNC release manager before, but I've assisted Chris Radek with some of the 2.5 releases he has made, and I've learned a lot from him. I've had RM-like roles in past day jobs, including being responsible for software loads for process-control PCs running experiments on the Space Shuttle and the International Space Station. I place a high value on software quality and stability. How I would run it is roughly like this: * Immediately after being selected RM, I will talk to the developer community and see what feature branches people are working on that they want to get into the 2.6 release, and that they think they can finish in the next few weeks. I will request that features that won't be ready in that time frame be delayed until after I create the release branch. The main feature I want to merge into 2.6 is the new RTOS support that Michael Haberler, John Morris, and Charles Steinkuehler have been working on, but i'm very much open to considering things that other devs want to merge too. * Once all these features are in or have been postponed to 2.7, I'll make a 2.6 release branch and immediately make a first official pre-release. Hopefully this will happen in the first half of July. At that point, the master branch would open up for experimental, unstable new features again. The 2.6 branch would enter a stabilizing phase, where no new features would go in without an extremely compelling reason. I hope that the user community will join me in testing the 2.6 branch, and that the developer community will join me in debugging incoming problem reports. * I will keep making pre-releases as the 2.6 branch stabilizes. * When the branch seems stable enough, I will announce that 2.6.0 is imminent, to spur developers to get any last bug fixes in. A week or so later, I will make the official 2.6.0 release. The schedule for this will be driven by the amount of testing that 2.6 receives and the rate of bug reports we receive. I hope that the branch will be ready for the 2.6.0 release before the end of 2013, but again: I'm not going to promise any dates, quality will drive the release, not any set schedule. * Bugs will keep popping up after the 2.6.0 release, just as they have after every release of every software package ever. I will keep track of bug reports, and apply bug fixes from the developer community, and make 2.6 point releases for at least a year or so, hopefully longer. That's my pitch. I'll be happy to answer any questions in email or on IRC, and let's decide at the IRC meeting on Saturday. -- Sebastian Kuzminsky ------------------------------------------------------------------------------ This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
