Re: [IMPORTANT] Savannah issues

[Stefano Lattarini]

On 02/25/2013 11:28 PM, Miles Bader wrote:
> Stefano Lattarini <address@hidden> writes:
>>>>>    * maint -> master
>>>>>    * master -> next
>>>>
>>> Damn, not really.  For some questionable reason, Savannah is rejecting
>>> my non-fast-forward push to master even if I specify '--force', and
>>> I cannot use the usual trick "delete the remote branch, then push the
>>> local one to it" trick that I typically use to work around this
>>> problem, since 'master' is the "current branch" of the remote
>>> repository, and that cannot be deleted to avoid confusing "git clone".
>>>
>>> So *THE AUTOMAKE GIT REPOSITORY ON SAVANNAH IS CURRENTLY IN AN
>>> INCONSISTENT STATE* (not broken, mind you, merely inconsistent with
>>> our new declared policies), and should not be used until this issue
>>> is resolved.
>>>
>>> I don't have time to look into this presently,
>>>
>> I had time today, so I submitted a Task in the Savannah interface:
>> <https://savannah.gnu.org/task/index.php?12497>
> 
> What's the point of this renaming, anyway?
>
The fact that the master branch, being in many ways "the default one"
in the Git world, is the one that is most visible and tested; so it
should be the one where the future minor releases (that we now pledge
to keep backward-compatible) are cut from.

> It doesn't seem to make any functional difference what the names of
> the branches you use for dev sources and releases are
>
Functional differences, no, strictly speaking.  Yet, when someone clones the
Automake repository, he has the 'master' branch checked out automatically
(apart for 'bare' clones, where no branch is checked out -- but that is a
different usage scenario).  And the automated Hydra builder checks the
master branch: <http://hydra.nixos.org/jobset/gnu/automake-master>.  And
there surely are many other situations where the 'master' branch is
handled in special ways, either technically or culturally.

 -- and besides
> being a practical problem, the scheme you've chosen doesn't follow
> common git practice,
>
How so?   If you are referring the practice of having 'next' as a test
bed for the features to be eventually merged into 'master', note that
is not an usual setup, but is only employed by the Git project itself
for its own repository; and while I admit it is an intelligent approach
that works quite well there, it only does so because of Git's large
developer base and very dedicated and very capable maintainer -- things
these that Automake lacks at present.

> so will be surprising/confusing to people...
>
Maybe to Git's developers, but I don't see many lurking in here ;-)

And anyway, even if that turns out to be the case, the solution would
not be to change the new policy for 'master', but to change name to
the 'next' branch.  And I'm not particularly attached to that name;
if anyone wants to suggest a better one, and manage to get a consensus
on it, I'm quite ready to rename accordingly.

Regards,
  Stefano