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.

That would akin to the developer stream in a typical streams release model. It's the one stream that has the least amount of consumers and most these consumers already know where to get the new builds.

The opposite of that is the long term support streams, which is rather what we have with the yearly releases, except not really since we never produce an SR3, even when some projects have eligible service releases to contribute.

The crux of the problem is that the final stream (latest releases) is the one that typically has the broadest usage. It is reasonably well tested for most users as it contains finished releases only, but it's not stale like the long term support streams. This is the part that we are lacking.

- Konstantin


-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx [mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Szymon Ptaszkiewicz
Sent: Tuesday, November 04, 2014 3:24 AM
To: Cross project issues
Subject: 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=10401
>019  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
_______________________________________________
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