> > 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.
That's good ... I guess I was thinking more about the difficulties in expanding that set. (The code could not have gotten to its current state without at least a core of folk with the relevant skills!) > The target protocols are another matter. Right; needs hardware, testers, "users", etc. > > 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. Getting a release out is rarely a picnic even in the best of cases! And it seems like you really needed help that you weren't getting (but should have had): > 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. Likewise, for deferring some patches until the next release. This is one of the things that Linux does interestingly. Except for a brief "merge window" and things like new code that can't break anything (new drivers etc), the "trunk" is managed *always* as a release stage. Everything else gets batched up to merge later, in that merge window. It took time to get that process working well, but at this point there are a LOT of developers who are used to it. > 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. Hrrm, yes. Those all seem like *very* significant problems. It should not have been your job, actually ... folk should have said "this needs to get into <next release>" when the patches were submitted, and if it did need tweaks the work should have been done by the patch submitter. > 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. Given what I've seen work on other projects, I'd agree. > > 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. Status is both output of, and feedback into, the process. Without status, you don't really have a process ... once you start tracking and measuring things (against goals), that is itself a process. Chicken/egg. > > 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. So opt-in was just a testing aid? That's better. I'd still have set the build option the other way ... so the testing was maximized. Maybe not for a week or two, but certainly not very long after merge. > > 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. I'm using git-svn now, FWIW, and quilt on top. It's good having the entire project history accessible without needing server access; and patch bisection "just works". - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
