I'm afraid that I'm not getting your point:
a) we're not doing any deprecation. We're removing a legacy default
config (which is IMO very unlikely to be still of use to anyone). Users
can still reconfigure it, if they really want it
b) I would be very surprised if this would be related in any way to
these 105 issues you mentioned. But maybe you have an example?
c) I'm especially puzzled why you put 'externals' in the JQL query. Do
you think that this has anything to do with externals?
Am 29.12.2012 13:23, schrieb Linards Liepin,s(:
-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 <mailto:d...@fortysix.ch>>
+1
On 28.12.2012 <tel:28.12.2012>, at 10:43, Christoph Kutzinski
<ku...@gmx.de <mailto: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/
<http://svn.sourceforge.net/svnroot/> and the dev.java.net
<http://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
<http://dev.java.net> has been discontinued altogether,
svn.sourceforge.net <http://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.
