Hello, The discussion on smoking and branching is driven by the need to maintain quality across a wide range of compilers and "target"(1) machines. I would add a couple of points.
0. When working through the review process the tool I wanted the most was a simple way to test cross-platform/compiler after I had passed the test-suite on my machine. I have both a Linux and a Darwin platform but that is a fraction of the list. Waiting for some other kind soul to test things out for you on other platforms was slow, and would have been impossible without the usual suspects in #parrot . Could patches in a very specific format be mailed to a build farm, where compile tests/smoke tests would run against the HEAD + patches in the mail ? The reply could contain the test results , and even some sort of "stamp", if it passed, that I could attach to the RT. With the build/smoke farm merit badge the reviewer of the changes can look at the "meat" of the changes without robotic and mind-numbing repetition of the test-suite. The time could be spent better considering the merits of the changes. 1. branching and merging in SVN is very primitive. tracking the last common ancestor must be done in the changelogs, failure to do so is a disaster. * This is an existing merge tool that matches up with the parallel development requirements: http://www.orcaware.com/svn/wiki/Svnmerge.py * This seems to be the official subversion page on merge-tracking http://subversion.tigris.org/merge-tracking/ * cherry picking never seems to work quite as well as you would want. The weak link is diff/patch. Unless the patches are extremely fine-grained you many times end up hand-editing hunks or doing post patch merges. I have tried subversion,git, hand-editing hunks (diff mode), and ediff. Only the last patch in a sequence of dependant changes can be modified without causing a tidal wave (good analogy http://en.wikipedia.org/wiki/Tsunami) of rejects. The end result is changes are not broken up, merger falls back on pass/reject. Are you ready for cherry picking ? 1. Is every whitespace cleanup, bug fix, refactor, and feature change a separate commit ? 2. Are your feature changes layered in even more separate commits ? each one compile/test-suite checked ? A. Why not wait until SVN has proper support for merging ? B. definitely need a tool of some sort to ensure the last common ancestor information is not mistakenly dropped. C. If there is a branch that is forked why not make it the stable branch ? The HEAD assuming the parrot project is flying along like we would all want it to is going to/does have heavy commit traffic on it. The number of changes you want in the stable is low. Put the expensive review checking on the merge "from head" -> "to stable", so the work-set can be reduced by a quick scan of the changelog to cherry pick which things could even be considered canidates. my 2 cents on the branching issue. I have been developing for myself tools to enhance svn for cherry picking, branching etc. I have working code; but that project is on the back-burner since diff/patch is the real problem, cherry picking/merging are the symptoms. All RCS systems use the patch/diff hunk as the fundamental change mechanism. There is just to much information dropped in a diff to handle conflicts cleanly, or rather the wrong kind of information to resolve conflicts in source code as well as it could. With that said I think the build/smoke farm would give developers a tool to widely test their changes, without expecting them to have a room full of computers. The branching model could be used, but it must be used in a way that is not going to push the current tools beyond their working use-cases, if that happens it will take alot of manual labor to compensate. Cheers, Mike Mattie (1) Autoconf lingo for the machine the program runs on.
signature.asc
Description: PGP signature