On May 21, 2009, at 5:02 PM, David Brownell wrote:
On Thursday 21 May 2009, Rick Altherr wrote:At this point we are not introducing new features or functionality to SVN.Hmm, I was hoping to send a new NAND driver now that it's basically working ... and some updated board support ... The earliest proposal I'd heard for a "freeze" was Zach's mentioning of wanting to see one about a week from last weekend ... no particular response, but I was aiming to get this stuff mergeable ASAP. Worth IMO drawing a distinction between "core" support and the rest. One thing that Linux does is recognize that new drivers can't cause regressions ... so that they can safely be added later in the release cycle. While a very strict policy would say "new driver" is a kind of "new feature", it can also be viewed as a flavor of bugfix -- <hardware X> didn't work before. So I'd agree it's certainly time to work on stability for the core, no new features/functionality. But that should leave the door open to other bits, IMO. Especially since work on those other bits has been stalled, off and on, by core stability issues. ;) - Dave
The process for stabilizing hasn't been well defined, so let me explain the process I've been following for the last few rounds of patches as well as what I use for my day job. I use risk vs reward along with the level of testing and time in the release cycle to determine if a path should be applied.
For risk, I use the following criteria: None - Every change has risk. This is never used.Low - The changes either affect a small portion of the code base, are very small but repetitious throughout the code base, or are entirely mechanical in nature (running the code through a script) Medium - The changes affect more than one component in the code base, are medium-sized but repetitious, or change the semantics or output of an infrequently used command High - The changes affect 3 or more components in the code base, affect a core subsystem, are large but repetitious, change the semantics or output of any frequently used command, or may cause any sort of overall instability (crash, hang, etc)
For reward, I use the following:None - No actual impact to a typical user. These are things like changes to maintainer scripts, developer docs, etc. Low - Resolved issue affects a small portion of users, has only minor impact on a medium to large size user base (fixing typos, changing error message, etc), or provides minor improvement to ancillary installed items (documentation, helper scripts, contrib items) Medium - Resolved issue affects a medium-sized portion of the users or provides major improvement to ancillary installed items (docs, scripts, contrib items) High - Resolved issue affects a large portion of users or solves an overall instability issue (crash, hang, etc)
After that, the decision process moves along a sliding scale based on time left until release:
2 weeks before release - Must be medium or high reward with low risk. Must be tested on multiple interfaces and targets if appropriate. 4 weeks before release - Must be medium or high reward with low or medium risk. Must be tested on at least one interface and multiple targets if appropriate. 8 weeks before release - Any reward with low or medium risk. Testing highly preferred but not explicitly required. Over 8 weeks before release - Any well written patch will generally be accepted.
These criteria are just guidelines to help patch authors understand what will be allowed when and to help maintainers decide which patches to apply. Of course, special circumstances can and do happen. If there is a patch that doesn't meet the criteria above but there is a good reason it should be applied for the release, the patch and the justification should be sent to the list for feedback from the community. If in doubt, send it to the list.
If a patch is rejected solely because of the timing within the release cycle, it should be held and resubmitted once the current release is finished. If the patch is rejected for any other reason, it should be reevaluated after any requested changes have been made. You never know if a 10000 patch might have portions meet the criteria once it is broken up into smaller, logical chunks.
I'm also open to suggestions on how to improve this process through both adjustments to the process and usage of tools. My day job uses a specialized issue tracking tool that help facilitate this process and ensures that no submitted patches are lost even if they are rejected for the current release. Something similar could be useful.
So, the introduction of a new NAND driver would probably fall into the Low risk and Low/Medium reward area. Given our hope to release by 7/1, we have a little over 5 weeks. I'd prefer it have some testing, but I'd likely apply the patch today. In another week, I'd be less likely to take such a change unless a significant amount of testing was done and the change in question is useful to a decent number of users.
-- Rick Altherr [email protected]"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 [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
