Re: [boost] [git] [modular boost] Switchover schedule proposal

Subject: Re: [boost] [git] [modular boost] Switchover schedule proposal
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-10-30 08:22:48

> > The thing that distinguishes tags from branches is whether they are
> > expected to change.  I wanted to keep these things in
> > tags/old-branches/whatever because presumably there they'd be out of the
> > way until and unless someone wanted to use them as the base for further
> > development.  At that point they could create a branch named "whatever"
> > from that commit and continue.
> 
> OK, I see your point.

The issue I see with having tags at all before the final migration is that 'fetch'ing doesn't update tags, only branches and therefore, anyone that pulls the repo's now will have tags that don't match any changes going forward for any tag that doesn't have a different name. I suppose that should be documented somewhere and how to fix it (they would have to delete their local tags and then fetch again).

> I don't suggest deleting any branches in the libraries. I suggest
> allowing maintainers to delete branches in their libraries.
> Therefore, we must assume some branches will get deleted.
> 
> In the superproject, we don't want to reference deleted branches from
> the libraries, so we delete all branches that might potenially
> reference a deleted branch from a subproject.
> 
> If we hide the branches in the superproject instead of deleting them,
> they still will be accessible, so we would still have the problem,
> don't you think?
> 
> If we hide the branches in the subprojects instead of... what? The
> only alternative here would be to not allow maintainers to delete old
> branches. I don't want to force anybody in this direction.

This is a complex situation and there probably isn't a good answer. If you have the approach of tags or hidden tags, they slowly become useless as maintainers slowly delete branches that the superproject refers to. However, if you require that devs delete the tag first, there's no stopping someone from pushing it back later, besides the fact that they couldn't get the consensus to remove it (short of the steering committee voting to delete them). And if you don't have the data in the superproject, then you lose changes that depended on multiple libraries.

So, exactly what is the goal here? It's not obvious what these changes from branches to tags is to achieve other than 'sweeping them under a rug'? Hopefully that doesn't sound negative, I'd just like to understand the vision if only to ensure that you guys have thought this through. (Though, there is something to be said for just getting it done and over with. :) )