Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Equinox fix for Luna SR1 now available as a feature patch in "4.4" repository.

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 <christian.campo@xxxxxxxxxxxx>
To:	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
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:	cross-project-issues-dev-bounces@xxxxxxxxxxx



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
<akurtako@xxxxxxxxxx>:

>----- Original Message -----
>> From: "Thomas Hallgren" <thomas@xxxxxxx>
>> To: "Cross project issues" <cross-project-issues-dev@xxxxxxxxxxx>
>> 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
>> cross-project-issues-dev@xxxxxxxxxxx
>> 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
>cross-project-issues-dev@xxxxxxxxxxx
>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
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Back to the top