On Mon, 2009-10-26 at 09:51 +0200, Øyvind Harboe wrote: > Nicolas suggested putting development branches on sourceforge > rather than on some other git repository. > > Any objections to that? > > The important thing is to make *testing* easy, IMHO. > > To test the mrcmcr branch a normal tester would simply do: > > git clone xxx > git checkout mrcmcr > > The mrcmcr branch would here be a developer branch that isn't > "owned" by anyone, but all developers could work on. > > Having a general dev branch in addition to the master branch would > also become more natural. At this point in the release process, we > should be on the dev branch cherry picking whatever we want in > the release... > > The maintainers would have the job of making sure to prune > away dead branches so as to avoid the .git repository download > times growing large over time(or after commit accidents in dev > branches).
This should not be our job; the same thing can happen on repo.or.cz, by a periodic cron script that deactivates old inactive forks. In fact, that is what the script is called: http://repo.or.cz/w/repo.git?a=blob;f=inactive;hb=HEAD Your suggestion reflects client-server thinking. Really, Git is P2P. There are few good reasons to do active branch development in the main repository. I established the openocd/testing fork on repo.or.cz to do exactly what you describe. Setting this up requires adding that remote one time, and everyone can create a fork to push. While SF.net offers no forking, maintainers can follow progress of an entire flock of forks here: http://repo.or.cz/w/openocd.git?a=forks I cannot overemphasize that SF.net should be treated like the goose that laid the golden egg. We put the repository there because their hosting virtually ensures its uptime (and backups... let's hope they never forget or fail those). It exists to provide the "master" copy of our repository, barring their server's failure -- but they we all have a fresh up-to-date clone handy, right? That tree is our proverbial Tree of Linus. Do you really want to be playing in that garden? And rough housing? That sounds reckless to me! There is no reason to _ever_ restore the repository because you made a mistake, but you seem to suggest this would be an acceptable practice. Simultaneously, that characterization seems like a Red Herring -- it's still a commons, not a private tree. Practically, I want "pull, rebase and merge branches, and push" to be the *only* allowed usage pattern for the primary repository. I also want to start seeing us move to workflow that requires a set of valid Signed-off-by, Tested-by, or other tags in commit messages, but that would be mere rubber stamps in the distributed processes that I want. Whatever it takes to see patches get the review, spit, and polish that they deserve. Present levels of maintainer Git aptitude lead me to believe that the continued use of the main repository in the fashion proposed would pose an ongoing risk to its integrity. More directly, we are going to continue to merge things to the master branch that should have gone to branches. The above pull/merge/push policy avoids this, and you can do whatever you want in your own branches. So, yes, I object to putting active branches on SF.net that will be maintained by mere fleshy human brains. This approach fails to embrace the distributed Git workflow. If I were to take things to their "logical" extreme, I might try to require one fork be created per branch (sound familiar to anyone?), but Git has rendered that nonsensical. For now, I hope the openocd/testing repository on repo.or.cz will become the incubator. As I mentioned in my last message, I am imagining a cron script that automatically attempts to merge a specified list of forks' branches into the testing repository, so everyone's work will appear in a single location without anyone having to lift a finger. It could be pushed to SF.net afterward with a pull/merge/push cycle, but I would object to that for the same general reason. The tags that might accompany the periodic testing merges (to protect developers against the branch reseting in an hour) should never be promulgated. Thus, that fork serves as a sort of temporary terminus, a regular side show for patches that actually live on our own branches in our own forks. Better, someday it could use 'make distcheck' to automate 'git bisect' to find out who broke things. Imagine, if you can. ;) --Z _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
