Hi everybody, as nobody else said something i would like to start removing old branches tomorrow! So it's your last chance to say something if you would like to get a copy of specific old branches. I will create tags for all the older release branches except roxy, stoney and hydrogen.
Kind regards, Thomas Boerger On Wednesday, December 04, 2013 02:11:50 PM Sascha Peilicke wrote: > 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 ;-) -- Thomas Boerger <tboer...@suse.de> Research & Development SUSE LINUX Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany HRB 16746 (AG Nürnberg), GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer
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/
