On Tue, 2009-05-12 at 15:36 -0700, 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?
I do. Cats can be herded. I would try to use cream and treats first. If those measures fail, I suggest loud noises and squirt bottles. :) > The process *does* seem, for now, as if it's largely > "commit patches to SVN" without any publicly defined > goals/targets or visible criteria. > > 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. Precisely, but I can help us take these next steps too. Such criteria impose restrictions, and such could easily railroad the community down lines that it does not want to travel. I have been taking my time to assess the needs of the community and formulate a list of criteria for future development, along with a plan for gradually imposing limitations in such a way that avoids disenfranchisement of existing contributors. Nevertheless, I expect the mere presence of some of those words to ring alarm bells in some members of the community; we cannot please everyone. Simultaneously, I do not want to annoy everybody either. > Right *now*, what criteria are being used to choose > whether to merge a patch, reject it, or hold it back > until the next release? *cough* *mumble* *punt* > 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. This is not what happened. I provided that feedback in order to be able to provide my own assistance, but I made the point that I was deferring to others' judgment for the monolithic patch. Unfortunately, this minor detail seems to have been lost in the shuffle, and it does not matter in the bigger picture of what 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 split and resubmitted, problems with any piece could have been backed out and the rest left intact. They could flow into the trunk after being reviewed, and the split would make that entire process easier. I think it remains possible to revive and submit that work, and I have not written it off yet. But I am not arguing with your point. We need better processes, and I hope we are moving down that road. I have started a document that should address all areas of concern, but it has a long way to go before it even represents a full draft. Cheers, Zach _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
