On Wednesday 04 December 2013 12:32:58 Adam Spiers wrote: > Comments inline ... > > Sascha Peilicke (speili...@suse.com) wrote: > > Hi there, > > > > here's a slightly edited per repository list of branches merged into their > > master branch. All of those are behind master. In other words, those are > > fully merged branches waiting to be cleaned up. So if nobody objects, I'd > > like to drop those later this day. > > I'm a big fan of cleanup, but I think we should wait another day or > two at least, to give our colleagues in the US some time to think it over.
Sure thing. > > > <semi-side-topic> > > Playing the same game against release/roxy/master produces slightly > > different results. It mainly digs up old release branches that are only > > behind (i.e. there was never ever something committed to them). Let's > > take swift for example (already removed the ones that will also appear in > > the merged-in-> > > master list further down below): > > remotes/crowbar/feature/grizzly/master > > remotes/crowbar/release/betty/master > > remotes/crowbar/release/fred/master > > remotes/crowbar/release/hadoop-2.3/master > > remotes/crowbar/release/hadoop-2.4/master > > > > So the question here is do we want to keep those old / never-modified > > release branches or are tags actually more appropriate? My take is kill > > whatever we can and add tags instead. This has the nice side-effect that > > github auto- generates releases for each tags (and thus a downloadable > > source tarball). This way old releases are more accessible, should anyone > > ever wanted to use those. But I may be missing things, so please speak up > > which branches really matter. > > </semi-side-topic> > > I think it's a question of support. If we know for sure that *noone* > will *ever* need to modify $OLD_RELEASE again or even build an ISO > from it, then I think it's OK to convert it from a branch to a tag, > with the goal of shrinking the currently long list of branches. > However, even needing to still build ISOs from old releases would > probably prevent this branch->tag conversion, because ./dev depends on > the branches in order to build the ISOs. *Maybe* if the tag had an > identical name to the old branch it was replacing, it could still > work. But I doubt anyone tested that yet (and Victor might be able to > immediately think of reasons why that wouldn't work, e.g. ./dev tool > calling "git branch" directly). Totally forgot about the ./dev tool :-) So let's wait what Victor and the others say. > > > Repo: ApacheHadoop > > > > remotes/crowbar/feature/cb20_devguide/master > > I think features can and should be removed *iff* they are fully merged > in *all* repos. > > > remotes/crowbar/release/rails3anddb/master > > I'm not sure why the rails3anddb branches had the "release/" prefix. > Pretty sure they can be removed. > > > remotes/crowbar/andi-node-alloc-change > > remotes/crowbar/perf-imp > > This kind of stuff can almost certainly go iff it's merged. > > > remotes/crowbar/pull-req/cloudedge/485 > > AFAIK that shouldn't be there. I'm guessing accidental leakage due to > use of ./dev followed by a misguided git push? > > > remotes/crowbar/vlowther-barclamp-pkg-metadata > > remotes/crowbar/vlowther-gemrc-hotfix > > Obviously stuff with someone's name on shouldn't be deleted until > they've approved :-) But in general, best practice is probably to > avoid polluting the main repo with personal branches - that stuff > should stay in our personal forks. (And as we saw recently, I'm just > as guilty of breaking that guideline as anyone else ;-) -- With kind regards, Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
