On May 14, 2009, at 1:39 PM, Zach Welch wrote:
Rick,Following on my post about maintainer roles, I wanted to see if I could talk you into seizing the responsibilities and authority for the release process, with the particular mindset of getting us rolling toward 0.2.0. I am willing to support you in whatever way possible to make it happen.If you are still willing continue in this role, I would like to see you document the release processes (perhaps in doc/manual/releases.txt?) andinform the rest of us what we need to do to make 0.2.0 a reality.Personally, I think the present circumstances call for a feature freeze,but you should provide your input on where you think we stand today. Please feel free to curtail or extend these requests as you see fit. Cheers, Zach
Per my previous emails, my life is a bit busy for the next few months. As such, I can't really be guaranteed to do the day-to-day patch review process or handle every commit to the branches, but I can definitely chime in on process, occasional patch reviews, etc.
To get started on a 0.2.0, we really need to pin down all the open issues in trunk. I'm not referring to open issues as in "anything that is broken", but things that are currently in development in some form in trunk. The List should certainly help in this regard. We need to break The List into two pieces: the things currently in trunk and everything else. Once we start the road to 0.2.0, anything in progress in trunk needs to either be finished or stubbed out for end users. Anything in the "everything else" category needs to _not be introduced_ into trunk until _after_ a 0.2.0 branch has been cut. Even then, I'd prefer that it be delayed until 0.2.0 is mostly ready so patches to trunk can easy be ported to the 0.2.0 branch. Note that I'm not advocating completely stopping development of trunk, but rather a temporary pause to stabilize enough that we can cut a 0.2.0 branch. After we do that, only small, directed fixes will go into that branch while trunk can be open for small to medium changes.
I'm specifically going to ignore any discussion of setting a specific release date or schedule. While I would like to have 0.2.0 wrapped by 7/1 (1/7 for the parts of the world that prefer sensible date formats), given the nature of open-source and the infrequency of contributions, any such hard date would be relatively meaningless. Instead, I'll just send more and more emails as we approach that rough estimate.
Past history has shown that having action items tends to motivate people to provide data _after_ emails/meetings.
Zach - Can you separate The List to items in progress and things not started? Cortex-A8 crowd - Estimate time to implement full Cortex-A8 support. If >2 weeks, plan to hold that work until after 0.2.0 Anyone with an in progress item - Estimate time to finish. Wild guesses are fine. Not going to hold you to it.
-- Rick Altherr kc8...@kc8apf.net"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
