Moving 4.6 to git next Tuesday or Wednesday

[Tom Albers]

----- Original Message -----
> Dirk,
> We were discussing in #kde-sysadmin whether it made sense to move not
> just trunk/4.7 development to Git next week, but 4.6 as well. No one
> really likes the idea of having two SCMs active at the same time,
> which was the current plan.
> 
> Do you consider putting together the release scripts in time for 4.6.0
> to be a blocker? Since i18n is staying in SVN the complicated part of
> the release script won't change any. And kdelibs, kdebase-*, and
> kdepim* are all basically staying with a 1-repo-1-tarball ratio, so
> they shouldn't be much trouble. (kdebindings might be more complicated
> since they want to split up into about 6 or so tarballs at the same
> time as their git release, though still 1 repo:1 tarball, but that
> isn't the subject of this email)
> 
> So if we did the git transition next week, 4.6 rc1 would be the last
> release to come out of SVN. We see the alternative as doing the
> transition shortly after the 4.6.0 release next month. But (speaking
> for myself) I'd only want to delay the release until next month if we
> know for sure that there is a good reason to; eg you need this time.
> 
> Thanks,
> Ian Monroe

I object to the transition next week of the 4.6.x code. I propose to do the transition after the 4.6.0 has been released.

Reasons:
- developers need to learn git / re-setup their system, which is very unfortunate in rc-time where every single development hour should be put in bugfixing.
- if something goes wrong there is no possibility to correct that without delaying rc2 and 4.6.0
- the release scripts can not be tested for rc2, remember that the release candidate tarballs are created, small test build and released, there is not a week between the tarball and the release as is the case with the beta's.

Best,
-- 
Tom Albers
KDE Sysadmin