Sascha Peilicke (speili...@suse.com) wrote: > On the other hand, we could probably kill some branches across > repos.
Great idea - very low-hanging fruit ... if we are scared about losing important stuff for ever, we can always take a backup first. > This is what I currently have just for the "crowbar" remote: > > remotes/crowbar/andi-node-alloc-change > remotes/crowbar/feature/cb20_devguide/master > remotes/crowbar/feature/folsom/master > remotes/crowbar/feature/grizzly/master > remotes/crowbar/feature/pfs-folsom/master > remotes/crowbar/judd-cmdb > remotes/crowbar/master > remotes/crowbar/perf-imp > remotes/crowbar/pull-req/cloudedge/485 > remotes/crowbar/release/betty/master > remotes/crowbar/release/elefante/master > remotes/crowbar/release/essex-hack/master > remotes/crowbar/release/fledermaus/master > remotes/crowbar/release/fred/master > remotes/crowbar/release/hadoop-2.1/master > remotes/crowbar/release/hadoop-2.2/master > remotes/crowbar/release/hadoop-2.3/master > remotes/crowbar/release/mesa-1.6.1/master > remotes/crowbar/release/mesa-1.6.1/openstack-build/master > remotes/crowbar/release/mesa-1.6/master > remotes/crowbar/release/mesa-1.7/master > remotes/crowbar/release/mesa.1.6.1/master > remotes/crowbar/release/pebbles/master > remotes/crowbar/release/rails3anddb/master > remotes/crowbar/release/roxy/master > remotes/crowbar/rob-bc-import > remotes/crowbar/topic/opensuse-12.3-iso > remotes/crowbar/v1.2-openstack > remotes/crowbar/v1.2.1-openstack > > So we have some hack-of-the-day branches, we got feature/ branches (why?) and > we keep release branches for ancient stuff. If I'd be a newcomer, I would > wonder what to look at. More honestly, this looks like a typical SVN > branches/ > tree to me. Do we really need 5 different mesa branches? Do we really use git > tags as we could do? Does "andi-node-alloc-change" really belong into the > crowbar org rather than Andi's clone? Right :-) > Another example is "topic/opensuse-12.3- > iso". I'm sure this was just done we have other feature branches pushed here > as well but this really belongs into a private clone. If someone wanted to > work on the feature too, he would just add a new (git) remote to his local > clone, work there and submit back to John's clone. I'm to blame for that one actually - I created it on Saturday when I quickly needed a copy of John's working feature branch. Yes it should have been pushed to his clone not github.com/crowbar, but at 1am I wasn't thinking straight ... now deleted. > When looking at the full picture (http://paste.opensuse.org/90805842) I feel > a > little lost in SVN-country :-) Right. > Lastly, what are fred, betty and pebbles about anyway? Though I know we > already discussed this particular aspect to death, but the whole release > naming is broken. As a newcomer, I would be inclined to think releases are > named alphabetically (like _E_ssex, _F_olsom, _G_rizzly), but in fact they > aren't. This would be clearer if it was easier to navigate to this page: https://github.com/crowbar/crowbar/wiki/Roadmap > Semantic versioning would also work. +1 > I would also wonder why we append > /master to every branch :-) Why not just "release/roxy" ? Or better > "stable/roxy" which seems like a more common pattern in the git world. Because the original pre-flattened branching model included product info ("openstack-os-build" etc.) in the branch name, and then it got partially moved into the releases/ tree in the main repo, leaving behind the branch naming scheme. I believe Victor is working on tidying this up, but I don't yet know how that would work: https://github.com/crowbar/crowbar/pull/1951 _______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
