By 'no, not anymore' you mean that you're not thinking anymore that this
has anything to do with externals or you're not using externals anymore
at all or something else?
It's still difficult for me to understand what you mean.
You seem want to make a general point that we should be very carefully
in handling backwards compatibility and I can assure you that we're
taking this seriously. However sometimes (as in this case IMHO) keeping
complete backwards compatibility is not possible if you want to move
forward or fix other issues (in this case that e-mail notifications get
delayed for several minutes)
I'm still completely not getting why you keep mentioning externals in
this context. I can assure you that this issue has nothing to to with
externals altogether.
cheers
Christoph
Am 29.12.2012 13:42, schrieb Linards Liepiņš:
umm, no, not any more. Release Managament team already gave up trying to
do any externals implementation long time ago and during the migration
from 1.6 to 1.7 version, we had some serious issues as there seemed to
have some leftovers from 1.4/1.5 versions either. My experience is
simply - doing deletion of any default config just by saying "imho no
one uses them, but can reconfigure" will cause billions of new issues
describing "trying adding legacy config, but if failed with NPE." ...
and my though instantly is .. DOOHH .. what you expect if plugin
maintainers did this step without any surveillance / survey whatsoever.
This is SCM plugin type and in the end Jenkins w/o at least critcal
bugfree status for GIT/SVN/Mercurial is pretty huge gambling to waste
some invaluable build time. measuerd usually in hours ...
As long as externals are supported in 1.4 and later versions - it always
is related. The scope / code coverage does not matter here.
2012/12/29 Christoph Kutzinski <[email protected] <mailto:[email protected]>>
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 <tel:29.12.2012> 13:23, schrieb Linards Liepiņš:
-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 <[email protected] <mailto:[email protected]>>
+1
On 28.12.2012 <tel:28.12.2012>, at 10:43, Christoph Kutzinski
<[email protected] <mailto:[email protected]>> 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.
--
A.C. Linards L.
