-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This Rev 0.0 of a rough development plan for e-smith 6.1 and e-smith 7.0. Feedback is welcome - there won't be anything if I have to do it alone.
Open Issues and Key Assumptions I am using the old e-smith name, which is almost certainly a Trademark (or equivalent) of Mitel now. We need to get agreement from Mitel that we can use the name, or find an alternative name. I am assuming that we want to put out a minor release (which I have called 6.1) based on the Mitel SME Server 6.0 release to work out the development process nits, prior to putting out a major release (which I have called 7.0). What should the development cycle time be? How do we handle translation / localisation efforts? What happens when features from different developers affect the same package? What is the QA mechanism? Informal testing? Formal testing against a range of configurations? Community testing plus a bugzilla? What resources can we get from Mitel? Especially the current bugs list and any in-house documentation? General Development Concept Releases are time based. There are three major roles for each release: * the ToolChain Dude * the Release Dude * the Support Dude Each release is begun by defining the base environment (eg 6.1 will be based on RH 7.3, 7.0 might be based on Fedora Core 2 or RH 9.0). Given the base environment, the ToolChain Dude puts together an installable CD of the core parts of that base environment, plus the development tools (compiler, debugger, -dev libs, etc). This is released to contribs.org. Any subsequent changes to the base environment (eg kernel upgrades) are released at the same time every week (say 1200 GMT each Wednesday), so that all the breakage can be managed at the same time. The ToolChain Dude liaises with the Release Dude to handle any changes. Individual developers identify additional package requirements to the ToolChain dude as early as possible, but no later than the We will maintain up to four feature / package plans: 1. The current minor release feature plan (ie the one we are developing). Right now, this is the 6.1 release plan. 2. The next minor release featureplan (which will be opened just before we close the current minor release plan - features that aren't ready get moved back a release). This will be 6.2, if there is such a release. 3. The major release feature plan (cool stuff that can't make it into the minor release because it is too intrusive). Right now, this will be 7.0. 4. The next major release feature plan (which opens when the current major release plan closes. This would be 8.0. The Release Dude gets to plan out when the various plans open and close, and when the features have to be implemented by. This is documented in a release plan, which has dates and events on it. The feature plan is basically the aggregate of each developer's commitments - features only go into the plan when someone commits to doing the work. The community as a whole can reject items from the feature plan that are contradictory to the general concept (eg adding X would currently be in this area), or are too extensive for a minor release (eg switching from Perl to Python). The release dude can veto anything that is a likely security problem at any time. Obviously "general concept" is something that is likely to change with time. After some period of adding new features, the release goes into stabilisation / bug-fix cycle - beta 1. Additional beta releases should be allowed for major releases. The Release Dude prepares an ISO image for each release. After the beta, we go into release candidate 1. If no show-stopper bugs (decided by the release dude, concensus on mailing list if any doubt), we release it. That release then goes into support mode, and is managed by the Support Dude. The Release Dude may choose to become the Support Dude, but there is no expectation that this will (or will not) be the normal case. No new features get provided in support mode - it only provides fixes for true bugs - typically security bugs and bugs that cause data loss or problems with access. Upgrades/updates that only provide new features have to wait for the next release, or provided as "after-market" contribs. No volunteers for every role - no release. Technology choices RPM. In the long term, they should be signed. We should think about infrastructure to provide easy access to updates - - perhaps we can resurrect the blades stuff from 5.6? Individual developers upload RPMs / SRPMs for their packages to contribs.org Documentation Features without documentation describing what they do, and how to control them (to the extent currently provided in the Vegan book) will not be released. They can still be provided as "after-market" contribs. - -- http://lca2004.linux.org.au - I'm registered. Are you? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/0rw1GwwszQ/PZzgRAnn/AJ0ShQC0/E95yJhsRdsFJ2uHxz9LNQCfQKFn H9KSd62Wvv+2QOoTcEPL6qA= =9Bc5 -----END PGP SIGNATURE----- -- Please report bugs to [EMAIL PROTECTED] Please mail [EMAIL PROTECTED] (only) to discuss security issues Support for registered customers and partners to [EMAIL PROTECTED] To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Searchable archive at http://www.mail-archive.com/devinfo%40lists.e-smith.org
