If I remember correctly, it was the outcome of one of the endless discussions mentioned by David that if we want to get more frequent/continuous releases, we should make the milestone/integration/nightly releases more visible instead of creating something new. I have been doing continuous updates of my IDE for the past two years using the integration or nightly update sites only like [1][2] and I am very satisfied because I always get the latest fixes and I don't remember any significant problems with it.
I don't think that creating a new EPP package solves the problem. Instead of reinventing the wheel and discussing the situation all over again, maybe it would be sufficient to point users to the update sites that contain latest version of the projects to get the latest and greatest. It could be up to the EPP package maintainers to decide whether it is useful to add those update sites to their packages. I guess it is possible to make the sites disabled by default so "Check for Updates" would do nothing, but as soon as the user enables them, he could get the latest available version. Note that the fix for the bug that started this discussion was available at [3] much earlier than the feature patch so anyone could get it faster if this update site was used. This would likely bring more fixes than just this particular one so it is potentially more risky as David already pointed out, but if someone is desperately needing a quick fix, then this would be the easiest and fastest way forward. Thanks, Szymon [1] http://download.eclipse.org/eclipse/updates/4.5-I-builds [2] http://download.eclipse.org/egit/updates-nightly [3] http://download.eclipse.org/eclipse/updates/4.4-M-builds From: Christian Campo <[email protected]> To: Cross project issues <[email protected]>, Date: 2014-11-04 09:58 Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in "4.4" repository. Sent by: [email protected] Sounds like we have a pretty stable and fixed situation where we have so many interdependencies that changing the setup becomes a really large effort. Projects depend on each other, commercial products and downstream projects depend on a stable sim rel. I wonder if it would help if we step outside and create a new EPP package that we name „Eclipse RCP IDE (nightly)“. That EPP package would consume whatever fix is available (Somehow) and is clear marked as being used on your own risk and potentially full of errors. I think that would be analog to other projects do like Firefox which has a stable version and a nightly version and you choose how much experiments you like to have. Again as Aleksandar pointed out someone needs to step up. :-) The advantage would be that we dont harm any of the existing distros and yet enable people to get the latest and greatest….. Christian P.s. And yes that doesnt mean we need a nightly for every existing EPP package. Start slow and just experiment with one. Am 04.11.14 09:27 schrieb "Aleksandar Kurtakov" unter <[email protected]>: >----- Original Message ----- >> From: "Thomas Hallgren" <[email protected]> >> To: "Cross project issues" <[email protected]> >> Sent: Tuesday, November 4, 2014 9:36:32 AM >> Subject: Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now >>available as a feature patch in "4.4" >> repository. >> >> Hi David, >> >> I think it's fairly evident that the testing that was made prior to SR1 >>was >> insufficient and I can understand why. Projects have limited resources >> nowadays and unfortunately rigorous testing is one of the first things >>that >> gets a cutback. With lowered quality as a natural consequence. The way >>I see >> it, that problem can be attacked in one of two ways: >> >> 1. See to that the service releases really get tested rigorously which >>means >> that organizations must put up the resources needed to do so. The >>release >> train must be subject to integration testing. > >So, to jump in, >Who is going to do the testing? Is anybody signing for fixing/improving >the test suites? We are at a level where ideas don't bring anything - >"show me the code" is the only thing that matters now from my POV. > >> >> 2. Let the Eclipse users take the hit (like we already do now) and make >>sure >> that any problems that are discovered are remedied more or less >>immediately >> (i.e. push a new build of the release train or platform without delay). >>In >> essence, this would remove the need for service releases. > >Again, who would do the work? Speaking of platform builds only, there are >so many things to improve in the build process and they are a >prerequisite before being able to spin a new release and be sure that the >build will finish first, is good, doesn't regress and last but not least >hasn't costed too much time to the one doing the builds. Everybody is >welcome to jump in, pick something from >https://bugs.eclipse.org/bugs/buglist.cgi?quicksearch=cbi&list_id=10401019 > and fix it, with every fix the probability of faster and easier releases >increases. > >> >> What we have now is the worst case of all. Virtually no integration >>testing >> and when bugs are found, no immediate new release. > >I totally agree with you that this is worst case. The only thing I would >like to clarify is that this is not the problem, it's the result from >very few people contributing to the lower/common/shared bits we all rely >on. Until this changes the situation will stay the same as no matter what >we think/discuss and etc. at the end of the day someone have to step in >and do it, which sadly doesn't happen in many cases for stuff discussed. > >Alexander Kurtakov >Red Hat Eclipse team > >> >> I wasn't referring to feature patches with my remark about p2 (I'm not >>much >> fond of them either). I was referring to p2's ability to deliver >>updates in >> a safe and controlled manner. >> >> - thomas >> >> _______________________________________________ >> cross-project-issues-dev mailing list >> [email protected] >> To change your delivery options, retrieve your password, or unsubscribe >>from >> this list, visit >> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev >_______________________________________________ >cross-project-issues-dev mailing list >[email protected] >To change your delivery options, retrieve your password, or unsubscribe >from this list, visit >https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev ------------------------------------------------------------- compeople AG Untermainanlage 8 60329 Frankfurt/Main fon: +49 (0) 69 / 27 22 18 0 fax: +49 (0) 69 / 27 22 18 22 web: www.compeople.de Vorstand: Jürgen Wiesmaier Aufsichtsratsvorsitzender: Christian Glanz Sitz der Gesellschaft: Frankfurt/Main Handelsregister Frankfurt HRB 56759 USt-IdNr. DE207665352 ------------------------------------------------------------- _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev _______________________________________________ cross-project-issues-dev mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
