On Tuesday 12 May 2009, Rick Altherr wrote: > > 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.
I'd have said those goals weren't really established then! :) > > 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. > > 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 everything > that 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? 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. 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. > > 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. 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. > 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. - Dave > > > - Dave > > > > > -- Unsigned > > > > _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
