On May 12, 2009, at 3:36 PM, David Brownell wrote:
On Tuesday 12 May 2009, Øyvind Harboe wrote:I don't know when the cats can be herded into a 0.2 release at this point, but I'm pretty sure it's a month away at least.Hmm, if you don't know ... then who could? The process *does* seem, for now, as if it's largely "commit patches to SVN" without any publicly defined goals/targets or visible criteria.
Or rather, every time the set of goals is established, it gets thrown out the window a week later.
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.
Right now, the options are merge or let it die. For nearly everything that hits the list, it is automatically committed to SVN with little review or commentary. I'm not a fan of this.Right *now*, what criteria are being used to choose whether to merge a patch, reject it, or hold it back until the next release?
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.
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.
- Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr kc8...@kc8apf.net"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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
