-1 Because of:
Do JQL with: summary ~ externals OR description ~ externals AND component = subversion 105 issues is way too much to do any deprecation. You will go into bigger software QA issues than jenkins currently has ;) 2012/12/29 domi <d...@fortysix.ch> > +1 > > On 28.12.2012, at 10:43, Christoph Kutzinski <ku...@gmx.de> wrote: > > So if no one has objections, I will happily remove these old svn > repositories for mail address resolving :-) > > Am 18.12.2012 19:10, schrieb Christoph Kutzinski: > > Hi, > > this is about the problem described in > https://issues.jenkins-ci.org/browse/JENKINS-15440. > The mail address resolving via the svn-plugin can be *very* expensive - > for me it takes around 20 minutes! > > Nicolas and I have done some changes to the address resolver, so the > 'known' repositories can be configured now and resolving is skipped > altogether if none are configured. > > See > https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionMailAddressResolverImpl.java > > However, this still leaves the problem in place for users who don't > configure anything here: > per default Jenkins would still try to infer mail addresses against the > svn.sourceforge.net/svnroot/ and the dev.java.net svn repositories. > I'd propose to remove this defaults altogether, so that new users won't > run into this problems, too. > About the state of these 2 repositories (AFAIK): dev.java.net has been > discontinued altogether, svn.sourceforge.net has been replaced by the new > SF svn repository service. > So these 2 are IMHO really legacy and could be removed. > > Any opinions? > Of course these are technically still backwards incompatible changes, but > I'd argue that tey are very minor and the benefit of removing them is much > bigger. > We should of course mention the changes in the changelog, so users who > really want to have these repos in the resolver, can configure them after > the upgrade. > > > cheers > Christoph > > > > -- A.C. Linards L.
