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]> > 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 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]> > >> +1 >> >> On 28.12.2012, at 10:43, Christoph Kutzinski <[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/ 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. > > > -- A.C. Linards L.
