On Thursday 21 May 2009, Rick Altherr wrote: > > On May 21, 2009, at 5:02 PM, David Brownell wrote: > > > > Worth IMO drawing a distinction between "core" support > > and the rest. ... > > > > 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. > > > 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.
Most of us do, yes. Although there are other dimensions that also come into play. > 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) Low/medium/high is fair enough, though it's often not easy to quantify. > 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) 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. ;) > 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... > 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. > 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. Best if things *always* require testing, IMO, even if only from the original developer. :) > 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. Yes. > 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. Resubmitting being the responsibility of the initial developer, as with all resubmission (including "split this up", "please fix this problem", etc). Stuff like "quilt" makes it easy to maintain a series of patches on top of whatever SCM is involved, note. > 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. Maybe, but I've observed that Free Software developers are no happier with following rules (even sane ones!) than any other developers. In the end it boils down to *people* doing the right things and working with each other. > So, the introduction of a new NAND driver would probably fall into the > Low risk and Low/Medium reward area. Right ... although, to affected users it would be "high reward", while it would remain low risk to everyone. > 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... > 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. That said, it seems like I'll be sending that patch along very soon, and quite a few modes will have been tested. - Dave _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
