On May 22, 2009, at 12:46 AM, David Brownell wrote:
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 ofan 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)Low/medium/high is fair enough, though it's often not easy to quantify.
Very true. I encourage people to evaluate the risk and reward of their patches and include their assessment with the patch. It's even better if they include details on what the risks and rewards are. Quantifying these isn't an exact science, so the more data the better. Having a template to fill out when submitting a patch can also be useful for this. It at least prompts the patch author to think about these items. Of course, that assumes that they know such a template exists and they are willing to fill it out.
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 orprovides 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)Likewise, often hard to quantify. Talking about a "typical" user always raises my suspicions; there are all sizes and shapes. Might be worth thinking about a few different categories for now though. Maybe "GDB user" that wants to debug embedded no-MMU microcontroller code; "Bootloader developer" who's basically focussed on getting U-Boot into flash or de-bricking, working with new boards (or updating older ones); and so on. Unblocking some types of users can broaden the user community. Some of those users, in short, are "potential". And one of the goals of new releases is to grow that user community. ;)
See above. In fact, you could remove the word typical from the description for None and not change the intent. Certainly there are different classes of users and changes will impact them differently. In terms of assessing patches for release integration, we are interested in the impact to the project as a whole. If a change only affects one user class, that's important to note regardless of which class it is.
After that, the decision process moves along a sliding scale based on time left until release:This implies some things about release schedule and process...
Yes, it does. At a certain point, the patches accepted are affected by the release schedule and process and vice versa.
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.I think we're probably now closer to "4 weeks" than "2". Another dimension being: developers during that part of the cycle need to focus on finding and fixing bugs.
Agreed.
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 beaccepted.Best if things *always* require testing, IMO, even if only from the original developer. :)
Also agreed, but I tend to be more willing to accept "code inspection" early on.
So, the introduction of a new NAND driver would probably fall into theLow risk and Low/Medium reward area.Right ... although, to affected users it would be "high reward", while it would remain low risk to everyone.
True, but the reward needs to be considered in the context of the entire project, not just the affected users. If you limit the scope to only the affected users, you find that most bugs are high reward.
Given our hope to release by 7/1, we have a little over 5 weeks.I don't know where 7/1 came from. I had thought "sooner" was in the air...
7/1 has been kicked around a bit, but not formally agreed upon. I think it sets a reasonable deadline.
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.Hmm, that's what I was getting at by pointing out the way Linux has an "exception" for new drivers. The logic is that when it's such a low risk all around, the fact that it's a *very* high reward for a small set of "new" users trumps the fact that the larger set of "old" users won't even notice it.
This would be one of those "doesn't fit the criteria" items. The risk certainly is low but we need to allow sufficient time for the driver to be tested by those new users. The less time it is in trunk, the less exposure it has.
That said, it seems like I'll be sending that patch along very soon, and quite a few modes will have been tested. - Dave
-- 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
