Renaming X.Y branches to KDE/X.Y

[Jeremy Whiting]

Hello all,

Sorry for the cross post, but this concerns many and I want to make
sure everyone is aware.
We have been discussing different ways to fix the inconsistency in
branch naming from the different ways repositories were migrated to
git.  It seems that a decision was made to use X.Y naming scheme based
on a flip of a coin [1]  Before that repositories were migrated using
KDE/X.Y naming scheme.  As can be seen here [2] many repositories
still use the KDE/X.Y naming scheme.  In order to make our
repositories consistent now is a good time to fix the issue since kde
4.7.1 was just released.

Ok it seems most people with a preference prefer KDE/X.Y over X.Y and
for valid reasons
1) Other non-kde blessed branches can have obvious names.
2) Kdelibs, base, etc. are already KDE/X.Y
3) More modules are already KDE/X.Y than X.Y so less to fix when
enforcing consistency.

Thus I propose we agree to use KDE/X.Y for official kde release branches
going forward.  In one week (Sep 15th) perform the required changes to
existing repositories.
1 kdegraphics (mobipocket and okular)
2 kdeedu
3 kdeutils
4 kdepim
5 kdepim-runtime
6 kdeplasma-addons
7 kdepimlibs

Part of the problem with some repositories using X.Y branch naming and
others using KDE/X.Y is that scripts and people that work with our
repositories need to know which ones use which scheme.

My plan to rename the branches is this.  Repository admins (I can do
the kdeedu repos, but other admins will need to do the others) would
checkout X.Y branch as KDE/X.Y then push it back to the repository.
Then the old X.Y branches on the repository would be removed.  This
makes all the branches that are part of KDE SC follow the consistent
KDE/X.Y naming.  Any existing clones with tracking branches to X.Y
named branches would then not be updated unfortunately.  Which is the
reason for the announcement, posting the decision on techbase,
including instructions for updating tracking branches and so on.

In most cases, anyone with a clone without tracking branches will need
to do this:
git remote update
git remote prune origin (or whatever they named the remote)

In cases where tracking branches to X.Y branches are created, they
will need to be recreated to track KDE/X.Y instead.

Feel free to ask any questions.

Jeremy
1. http://lists.kde.org/?l=kde-core-devel&m=131408017429640&w=2
2. http://techbase.kde.org/index.php?title=Projects/MovetoGit/Progress