4.6 branches created in git again

John Layt johnlayt at googlemail.com
Sun Mar 20 15:02:41 GMT 2011


On Sunday 20 Mar 2011 14:28:11 Andreas Hartmetz wrote:
> On Sunday 20 March 2011 15:17:11 Ian Monroe wrote:
> > On Sun, Mar 20, 2011 at 09:09, Andreas Hartmetz <ahartmetz at gmail.com> 
wrote:
> > > On Sunday 20 March 2011 14:38:40 Albert Astals Cid wrote:
> > >> Can you please be careful and do not create incorrectly 4.6 branches
> > >> in places where the branch is called KDE/4.6 (e.g kdelibs and
> > >> kde-runtime)
> > >> 
> > >> Ian can you kill them?
> > >> 
> > >> Albert
> > > 
> > > Maybe we can go through with renaming the branches to n.m (without
> > > KDE/) prefix?
> > > Some repositories have the prefix, some don't, I think it doesn't make
> > > sense to have the prefix, and it was decided (by tossing a coin...)
> > > that the prefix should be removed.
> > 
> > This would just cause more chaos until we block the creation of
> > whatever the non-favored naming scheme is.
> 
> I'd suggest doing exactly that no matter if the branch names are changed or
> not.

It's a necessary pre-requisite for the rename, or chaos will reign.

I'll declare here I prefer a prefix simply for organisation and grep-ability 
and to to make it official looking, perhaps a compromise of 
origin/Release/4.6?

Anyway, if we do declare straight numbers the winner, the following rules 
should apply:
1) Any branch starting with a number is deemed to be a release branch, as such 
only members of the Release Team or Sysadmins can create new branches starting 
with a number.
2) The KDE/ prefix in any form or mixture of case is deemed a special reserved 
prefix, as such only sysadmins can create new branches starting with KDE/.
3) Once these rules can be enforced by filters, then the block and the branch 
name must give live at the same moment (or in very short order).

Obviously these rules would only apply in a hard fashion to the main KDE 
modules, i.e. the SC, playground and extragear are free to do as they please 
but following the rules should be recommended.

John.




More information about the kde-core-devel mailing list