Sysadmin/SVNInfrastructureShutdown: Difference between revisions
No edit summary |
No edit summary |
||
Line 25: | Line 25: | ||
The anonsvn-mirrors will be shut down. svn.kde.org will remain for now, anonymous checkouts can happen via svn protocol on svn.kde.org. This is a great deadline for all projects to have migrated to git. From this moment on tools are allowed to stop supporting subversion: build.kde.org, lxr.kde.org, api.kde.org and similar services. | The anonsvn-mirrors will be shut down. svn.kde.org will remain for now, anonymous checkouts can happen via svn protocol on svn.kde.org. This is a great deadline for all projects to have migrated to git. From this moment on tools are allowed to stop supporting subversion: build.kde.org, lxr.kde.org, api.kde.org and similar services. | ||
svn.reviewbioard.kde.org will | svn.reviewbioard.kde.org will be closed for new requests. | ||
== November 1st 2013 == | == November 1st 2013 == |
Revision as of 20:33, 14 January 2013
Currently we have a subversion infrastructure and also a git infrastructure. This means everything we do, we do 2 times. Just to give some examples: there is a git server, and a svn server. Both are backed by anongit/svn-servers. Both have hooks which control access for some paths/repo's, send out emails to mailinglists, etc. Not much can be shared between those. Also think about lxr.kde.org, build.kde.org, api.kde.org, kdesrc-build and translations that all need to be able to deal with some weird mix of svn and git.
Not only is this very difficult to maintain organisationally, hard to debug sometimes, causes confusion not only with sysadmin but also with the contributors, but is also a waste of resources (instead of 4 anongit mirrors, we can only have 2, because we also need 2 anonsvn mirrors).
KDE has decided to move to Git a few years ago. Now the time has come to say goodbye to subversion. That's why we created a time schedule to dismantle subversion.
February 1st 2013
SVN hooks will become active that prevent creation of new folders below branches/work/, trunk/playground/*/ and below trunk/extragear/*/. Effectively this means no work branches and no new playground or extragear projects can be made in subversion.
Also at this date we will disable all developers that have not uploaded their ssh keys in the past (currently 669 accounts). These people are not allowed to commit for over a year now and never migrated from a password based account to a ssh-based account and never responded to our mails about that. This is the list that can be seen at line 807 of http://websvn.kde.org/trunk/kde-common/svn/hooks/svnacl.cfg?revision=1329421&view=markup
March 1st 2013
Git repository commits can no longer be tracked via commitfilter.kde.org. You can track commits to git repository via projects.kde.org. commitfilter.kde.org will continue to operate, but only for svn-commits.
July 1st 2013
New contributors will no longer get subversion account by default. If svn access is needed, it can be requested manually via sysadmin. This would be a great deadline for all main modules to have migrated to git.
September 1st 2013
The anonsvn-mirrors will be shut down. svn.kde.org will remain for now, anonymous checkouts can happen via svn protocol on svn.kde.org. This is a great deadline for all projects to have migrated to git. From this moment on tools are allowed to stop supporting subversion: build.kde.org, lxr.kde.org, api.kde.org and similar services.
svn.reviewbioard.kde.org will be closed for new requests.
November 1st 2013
All svn account holders will get a reminder mail about the future of svn, most likely this will inform everyone of the shutdown of the svn-server on January 1st. At this point of time most parts of svn.kde.org will become read-only.
January 1st 2014
Close down of svn.kde.org. All extragear / playground projects still in svn will be 'archived' with loss of history. commitfilter.kde.org will be shutdown as well. Just like svn.reviewboard.kde.org and websvn.kde.org
Note
The only exception are the translations. These will continue to happen via subversion, but this will use the gitolite software as backend, in any case, this will result in only minor changes for translators.