On 12/03/2010 09:33 PM, Garrett Holmstrom wrote: > On 12/3/2010 18:34, Jesse Keating wrote: >> The original thought was to have top level branches that are named after >> distribution releases, eg "f14", "f15", "el5". Then we would force >> branches of those branches use a naming structure of "f14/topic". The >> reason was so that our tooling could look at the name of the branch and >> easily work back to the "f14" part. This would work even if it was >> "f14/user/fred/topic/mybranch" or other such craziness. When I went to >> test this, I realized that git won't allow you to have both "f14" and >> "f14/topic" as branches, because of the way the git metadata works on >> the filesystem. When I encountered this, I made "f14/master" become the >> top level branch, and then "f14/somethingelse" could coexist. >> Unfortunately I also wanted to keep things easy for users and tried to >> maintain tooling that would allow you to just say "f14". This didn't >> get enough real world testing and in hindsight was a bad idea. Things >> go wrong quickly in git if your local branch name doesn't match the >> remote branch name. >> >> When thinking about the above, and the two bugs I'm working on, I >> realized that we don't have any real strong need to be using "/" as a >> delineator. It makes some code easier, but makes other things more >> complex and difficult. So what if we changed it? >> >> What I'm thinking about now is switching from / to - as a delineator. >> This would improve a couple things. First, we could achieve upstream >> top level branch names that are short and simple: "f14", "f15", >> "master". We can have branches that build upon those names: >> "f14-rebase", "f15-cve223", "f15-user-jkeating-private". We could keep >> the simple fedpkg tooling that allows users to just type "f14" and the >> like to reference a branch, and now the local branch will match the name >> of the remote branch. > > Yes, please! Getting rid of the '/' strangeness ought to make things a > little easier to understand and use across the board. I suspect that > few enough packages use shared feature or bugfix branches that a > transition won't trip up very many people. Perhaps a hook on Fedora's > repositories that prints transition instructions when one attempts to > push to old-style branches in conjunction with a fedpkg command that > attempts to migrate existing local branches and remotes would help somewhat. That's certainly something to look into. I'm not sure a hook would fire off soon enough, or the client would notice that the upstream branch doesn't exist anymore and balk before any upstream hooks could run. Certainly worth looking into. > >> As for the first two bugs I mentioned, it doesn't directly help them. >> However I would feel better about telling people that their local >> branches must follow a naming scheme of<release>-<something> and then >> we could easily guess what release the local branch is for if it isn't >> tracking a remote branch. However the bug about what to do if there are >> no remote branches is really not touched by any of this, it just got me >> thinking about branches :) > > Why tie branch names down to specific releases? While that scheme makes > it easy for fedpkg to guess what release to attempt to build against > when one only cares about one release, it makes little sense to call a > branch "f14-rh123456" when in reality that branch will merge into "f13" > as well as "f14". Couple reasons. First, the naming structure gives us the ability to "easily" determine what Fedora your work is targeting. The vast majority of Fedora packages have some macro or another that depends on "dist" value, and they need to be defined any time the spec is parsed. I prefer a scenario where this data is determined automatically, but allowed to be overridden. Also I don't envision a lot of these branches existing on the upstream side. Downstream you can call the branch whatever you want, so if you want to clone then branch for a bug to do test work, eventually merging the work onto master, f14, f13 that's just fine. Only the shared upstream branches would need a naming scheme. Lastly by putting some soft of naming scheme in place it can help with the ACL system, to provide ACLs for allowing non-ff changes in certain branch types, or allowing all users to create branches of a package or whatever. Although on that last point I think we need something like github to easily allow users to 'fork' a repo when they don't have commit rights to it, perhaps off to fedorapeople.org somewhere. Rambling now. -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
