On Monday 26 October 2009, Øyvind Harboe wrote: > On Mon, Oct 26, 2009 at 8:53 PM, Nicolas Pitre <n...@fluxnic.net> wrote: > > On Mon, 26 Oct 2009, David Brownell wrote: > > > >> Note by the way that public repositories are mostly for > >> publishing work you expect others to use. I'm not sure I'd > >> expect folk to review patches from repositories as any kind > >> of regular thing ... it may be marginally easier to do that > >> way than sending them on the mailing lists. > > > > If that's indicative of anything, on the very Git mailing list (of all > > places) about 98% of all changes are posted as patches and merged as > > such. No one ever ask people to review patches by fetching a repo. > > So here you're really saying that development branches aren't > really used, except as a way for maintainers to track patch series?
That's not what he wrote. :) Branches are used to coordinate between maintainers, and to let bleeding-edge developers work with code before it's deemed ready to merge. As I said, they are for publishing work you expect folk to use. I might also have added "... and which is too complex to just grab as a couple patches off the list". That's the main engineer-to-engineer channel for code; it's easy to review and comment on inlined text. And to cherry pick the (clean) patches that fix bugs you're hitting. > There will be a dozen patches to the mrcmcr stuff before > it's "all over" and ready to be committed. IMO that's fair to have as a branch. Two or three patches ... not worth it. > What could I realistically expect in terms of testing for the below? > > - a patch series a dozen patches long Note that how that series is delivered matters. The three options below presume it's via GIT. Via mailing list can be a bit awkward for that size series. You could put them in your web page on sf.net, individually or as a tarball, too. > - a branch on sf > - branch on that other web site in some repository > - a branch on that other web site in the "testing" branch of > the official testing repository In all of those cases, primarily testing *YOU* perform; which of course should be quite exhaustive. ;) If there's a bug someone's hitting that may be fixed by that series, often you can expect that person to test patches you develop. The more complex it is to test, the less likely ... as I'm sure you know. > - committed to master branch A reasonable amount from the developer community. Once the code is released, via often-delayed bug reports from a frustrated user community. > - some scheme whereby all development branches on all > repositories are automatically merged into the "daily pile" that > users can test... That won't work unless the branches have no conflicts. That model is somewhat along the lines of the "-next" branches that many projects maintain in parallel with mainline after the merge windows close ... that branch exists to resolve those conflicts early. Maintaining a "-next" branch is a significant job; not amenable to automation. Think of it as what a release manager does ... except the inputs are *really* raw. And it's kind of a thankless job, since the "-next" branches tend to be for integration work instead of for testing. For smaller projects (like us!), I'd think it's worth avoiding; we don't have actively developed subsystem branches which sometimes end up in conflict with each other. > ? > > I don't worry about development & branching, git has that > sorted. > > My greatest fear is that we come up with some sort > of fancy scheme that gives *zero* testing before stuff is > finally committed to the mater branch, which is back > to square one really... If anything gets *zero* testing, neither the developer nor the committer have done their jobs well ... at the very least it should have been build-tested. And the the developer should have done much more than that. (If they don't have the hardware in hand, and someone who reported the bug can't test it, that's obviously not a good candidate for merge during the RC series. Hold that patch back till the next merge window.) > If there was a simple and obvious answer to this problem of > testing and branched development, then we wouldn't be having > this discussion. True, but it's important to focus on the process not the tools used to make the process work better. We may want to consider that once the merge window closes, only some release manager will commit things to mainline. This "commit everything ASAP" mindset is not condusive to robust and orderly releases. > I feel that OpenOCD is special in that for it's size(code and > community) it has an insane number of different targets and > a huge distance between developers and test hardware. The "special" comes more from community size, IMO, than anything else. Anything dealing with low level hardware stuff has those issues. - Dave _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
