I just hope the processes does not burn you to a crisp. One of the few things I would like to see kept in and taken seriously is preempt-rt. Im'm just sayin...
Best of luck to you Seb! On Jun 24 2013 8:44 PM, Sebastian Kuzminsky wrote: > 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. ------------------------------------------------------------------------------ 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
