On May 12, 2009, at 6:09 PM, David Brownell wrote:
Zack's "list" seemed useful in terms of having some kind of direction be defined. But that's distinct from defining release criteria, or merge criteria.Yup. A todo list is great, but we need a more rigid definition of what need to be done to make the next release. Essentially, we need to decide on "features" for a release. Any large changes need to be aligned with a feature. Small fixes should be accepted even if they don't align with a feature.That's one process. Not all small patches are safe enough to merge at any time though; and not all large changes should necessarily be aligned with target features of some release. (Example, some types of code cleanup.) Patches should IMO be graded more by the risk/reward ratio ... and nearer to release milestons, that ratio should shrink to near zero.
Agreed. Risk/reward works well as a metric for rating patches for integration. The difficulty is determining the risk and the reward. Everyone seems to have a different set of criteria for those. Even well established criteria doesn't solve all the problems since no two patches are alike.
Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release?Right now, the options are merge or let it die. For nearly everythingthat hits the list, it is automatically committed to SVN with little review or commentary. I'm not a fan of this.Right. I think some patches should certainly be able to fit into the "keep that in the -next queue" category. Effective review is probably not easy here; who knows JTAG well enough to contribute non-cosmetic feedback?
Actually, a fair number of us _do_ know JTAG fairly well. The target protocols are another matter.
One process that could hardly help but improve things is to define a "release manager" who herds patches for a given release ... and someone else who herds patches for the next one, keeping the queues in sync. OpenOCD doesn't seem to have anyone responsible for the "next" release, whatever it's called (maybe a datecode like "2009-06"?). Such roles should ideally be rotated. Some projects have teams defining them.
Technically, I took that role for the 0.1.0 release. There were two factors that have make continuing as such for 0.2.0 challenging: my home life and lack of community support. My home life is in a bit of turmoil due to a home remodel, new baby, and looking for a new day job. The community support was nearly non-existent. Even slowing things down for 0.1.0 was difficult but I managed. As soon as 0.1.0 was released, trunk had already progressed well ahead and was in chaos. Attempting to slow things down and establish which in-progress developments need to be finished has been met with resistance. As soon as one in-progress item is finished, 3 others have been partially introduced. _If_ a process was put in place for accepting patches to trunk, the job of release management _might_ be possible. Otherwise, it primarily means picking an arbitrary revision of trunk and making it the branch. Then, as in-progress items are finished, merge the patches from trunk into the branch. It sucks and makes the release manager do _a lot_ of work. It's not an easy job watching every commit and determining if it should be taken for the release or not. It's also not easy backporting fixes that don't apply cleanly because trunk has moved on with other widespread changes.
Enough ranting from me. We need to set some criteria for introducing patches into trunk and formalize the process. We also need to establish the same for release branches. Then, everyone with commit access needs to respect those processes. If we all play by the same rules, cutting releases more frequently will be easy and the overall quality of trunk will be better.
Regular status updates help too. Linux has clear progress markers via version codes (2.6.29, then merge window, then 2.6.30-rc1, etc) *and* at least brief status reports every weeks when a new version is tagged. GCC has different status reports (which get rotated among release team members) and very clear tree status. OOCD has nothing similar.
Right. This follows from the above. If you have a process, it is easy to send out updates about what stage we are in. The releases don't need to be on a strict timeline, but knowing that this release is slowing down and another will be opening helps patch authors set their schedules and use their time effectively.
Example: there was a patch a while back (from Dick Hollenbeck) that included about 60K of ft2232 and TMS sequencing updates ... and gratuitous changes to whitespace, and surely other things. I don't know of many projects which wouldn't also reject such patches with "please split into smaller patches so this can be reviewed", as happened. If that *had* been split and resubmitted ... there seems to be no process in place to say which changes are safe to merge *now* versus which can't merge because they'd destabilize release plans, versus which are worth merging even if they *do* destabilize things (because e.g. fixing TMS bugs is critical).If it _had_ been split and resubmitted, I'd have voted to take the FT2232 fixes and the TMS sequencing updates. Both had been discussed for quite a while. They were implemented in an opt-in model. It was safe to take into trunk with no real impact unless you opted-in.Both sounded technically plausible to me. But ... neither was provided as an independently reviewable patch.
I still have it in my inbox somewhere. I believe parts were integrated by Øyvind. When I get some time, I'll see about splitting it up.
If they were merged, I would have argued against "opt-in". When a patch is basically good, any remaining bugs should just get fixed. If it isn't, it shouldn't merge.
Actually, in this case, opt-in was the right model. In general I agree with you, but when you are changing such a fundamental part of the code, it will take time for the other pieces to be tested and debugged. This particular item was made more difficult by the fact that no one on the list owns all the hardware supported by OpenOCD and thus one person could _not_ do all the testing themselves. Now, this _could_ have been done in a branch, but having an opt-in scheme allows the drivers to be updated individually and be tested more broadly once have been. If it has been done in a branch, it is unlikely they would have had as much exposure.
Of course, I'd love a more formal process in which we decide on the feature set for the next release and only accept things into it that implement those features. Of course, we should also allow overlap of releases (branch the release from trunk a while before the release is finished) and also allow radical development to occur on branches where they could be merged into trunk after the release is branched. See any large project for examples.Right. The guts of it boil down, IMO, to defining some responsible roles ... and having people meet those roles. Given that, some tools work better than others. GIT makes it easy to have any number of branches without needing to grant excess permissions to anyone, for example. But we have all probably seen projects managed effectively using tools like CVS or SVN. The tools are secondary to having a process which uses them well.
I'm not entirely sold on GIT as a project source control system, but things like git-svn enable individuals to maintain their own GIT branches and push them to the project as a patch. That provides a reasonable balance between the needs of the project and the needs of the contributors.
- Dave- Dave-- Unsigned
-- 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
