I fully agree with Kutzi and don't understand what externals would have to do with this. /Domi
On 29.12.2012, at 18:36, Christoph Kutzinski <ku...@gmx.de> wrote: > 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 <ku...@gmx.de <mailto:ku...@gmx.de>> >> >> 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 <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. >> >> >> >> >> -- >> A.C. Linards L. >
