----- 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 _______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
