On Mon, 26 Oct 2009, Zach Welch wrote: > 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
You said it: "developers". Testing, however, comes from "users". And they sure won't make the effort of tracking and merging multiple scattered repositories in order to provide feedback to developers. And considering the importance of my contributions to OpenOCD so far, I still consider myself as a user. To me the stake is not high enough for me to bother with separate repositories just to test Øyvind (or anyone else's) work. The incentive is just not there. > 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? It hosts the _master_ branch, indeed. But where do you get that idea that it can't serve development and proposed feature branches? Sure Git is p2p, but that is good for a huge development community to scale. I don't think OpenOCD has faced this issue so far. And for casual users/testers, a single central point to get work in progress is just so convenient. Doesn't mean that every branches from every developers have to be pushed on sourceforge of course. But for those who think their stuff is worth publishing for public feedback then why not having extra branches for that along the sacred master branch? Technically, Git can deal with both: separate repositories and/or separate branches. In the end, if you set up a remote and fetch it you end up with those multiple branches locally. But the advantage of having them already gathered in the remote repository greatly simplifies the effort for those who might be interested to provide some testing by not having to hunt for them in other repositories and configure their retrieval locally. And to those who maintain that repository on sourceforge... really there is no real cost, is there? > 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! Bad comparison. Linus is the gate keeper for a project that is a couple order of magnitude bigger than OpenOCD. We are still a bunch hacking together in one's basement or garage here. It is not relevant to erect fences yet I think. Of course I'm not proposing to give everyone who asks the privilege to push branches to the sourceforge repo. That privilege may remain with those who have it now due to their significant implication with the project. However if I come up with a sizeable patch series and put it in a Git repo somewhere and there is some value in it, then I think that one of the sourceforge repo maintainer could pull that branch and make it available along with other proposed changes in the sourceforge repository for wider visibility. > 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. Is this really a serious issue? The idea is for people to mess with their own branches, not the master one. That's why I suggested a model for branch namespace. If you're really concerned about the validity and coherency of the master branch, then some extra security mechanism can be applied to it with the Git update hook for example. > Simultaneously, that characterization seems like a Red Herring -- it's > still a commons, not a private tree. No one is suggesting to make the sourceforge tree everyone's private tree. Neither should be repo.or.cz for that matter. Common sense should be applied concerning the suitability of a branch to a public repo, and to the _reference_ repo. [...] > 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. We may agree to disagree and leave it at that. After all, I said already that I'm not a major contributor hence my opinion has little weight. But for one last time, I'm stating that such rigid arrangement will simply turn away a sizeable portion of the very few testers OpenOCD might need to get to the next level. What you're proposing might certainly make sense if the project grows and the contribution rate becomes a problem, in which case it would be time to enforce stricter rules and greater distribution. When a project has sufficient momentum those restrictions are rarely a problem as most users are motivated enough to overcome them. But at the moment I think this is highly premature for OpenOCD because the project is not big enough for scattered forks to keep enough relevance by themselves yet. Heck, you're giving the impression that OpenOCD developers have little Git skills... but did you think about the few _users_ that we have? As to the "distributed Git workflow"... I must mention that I'm one of the major contributor to Git itself. I therefore know Git _quite_ well. And Git is amenable and already used through a wide spectrum of different workflow models. There is simply no such thing as _the_ Git workflow. And in this context the word "distributed" means that any clone of the "main" repository is just as valid and complete as that source repository. And qualifying one repository as the "main" repository is now a social convention instead of being a technical limitation. > 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. Why not making this a "testing" branch on sourceforge directly then? Same principle, same effort from the maintainer, but less work for _users_ aka testers. The merging will have to occur on one of the developer's workstation anyway (I really doubt you can get away with a cron job for this as merge conflicts always happen and always require manual intervention even if they're trivial) and therefore pushing to sourceforge.net or repo.or.cz (or both) is really the same thing. But you don't truly have a single location if the master branch and testing branch are in separate repositories. > It could be pushed to SF.net afterward with a pull/merge/push cycle, but I don't get the meaning of your pull/merge/push cycle. A testing branch would be just that: a bunch of branches merged together for testing purposes. That branch might fast forward, or it may simply be reset afresh onto a different base after a major release of the master branch. That's how Git itself is developed, and the Linux kernel started using that work flow a while ago too. > 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. Sure. > Better, someday it could use 'make distcheck' to automate 'git bisect' > to find out who broke things. Certainly. But I don't see the connection with the discussion at hand. > Imagine, if you can. ;) Should I return you the compliment? ;) Nicolas
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
