Re: [ecf-dev] ECF Release Train Participation

["Campo, Christian" <Christian.Campo@xxxxxxxxxxxx>]

Hi,

just for curiosity. If ECF exits the Release Train, that also means that no other project that is in the release train can be dependant on ECF right ? What does this mean to p2 which AFAIK uses ECF for communication ? Maybe there are other projects that also use ECF (not sure), what does it mean for them ?

regards
christian

Am 16.12.2010 um 04:52 schrieb Scott Lewis:

> On 12/15/2010 6:06 PM, Jeff McAffer wrote:
>> <stuff deleted>
>> I completely understand the resource problem but have an honest question. What is the real incremental cost of being on the train?
>
> Unfortunately, in my view it's quite a lot.  The must dos for Indigo
> continue to increase...and most of the existing (as opposed to new) ones
> also have a significant yearly incremental cost.  There is also the plan
> creation, the review materials creation, the reviews themselves, and the
> inevitable time cost of the IP process (witness the yearly last minute
> fire drills around license consistency, etc), and the incremental releng
> costs (which never seem to actually go to 0...although all of us would
> like it if they did).
>
>
>
>> You don't have to do a new or extra release for the train.  You could contribute the current released version of ECF to Indigo with no additional work other than the must dos.
>>
>> As for the train requirements, yeah, that is a burden.  However, I'd argue that they are in place, for the most part, to help our consumers.
>
> In my view they a) place too much of a burden on the project committers
> (i.e. the committers are the ones that do the actual work of meeting the
> requirements); b) are overly focused on helping certain consumers
> (strategic/corporate).
>
>
>> They are likely good things for your consumers too.
>
> Perhaps for some consumers...but at the necessary cost of other
> consumers.  For example, every bit of time that Markus, Wim, or I spend
> upon releng or IP for the simultaneous release (for example), is time
> *not* addressing other consumer's desires for new discovery features
> and/or providers.
>
>> There are sure to be some that are less relevant to RT-ish projects.  We should seek to change this or get exemptions where it makes sense.  From what I can see though the real work of being on the train is doing a release. So is the question "should ECF do releases" or "should ECF be on the train"?
>
> No, I don't think this is right.  After doing at least 7 releases of ECF
> and 5 simultaneous releases, I can confidently say there *is* a
> significant incremental cost of being on the train...over doing a
> regular ECF release (which is always a fair amount of work).  And thanks
> to the additional must dos, this incremental cost consistently
> increases.   It has become akin to a set unfunded mandates IMHO.
>
> There's little doubt in my mind that we/ECF will continue to do regular
> releases (e.g. we just had a 3.4 release in November and have 3.5
> release tentatively planned for Feb/Mar 2011).  In fact, given our new
> build infrastructure and move to git, our release frequency might
> actually increase.  This is also of benefit to many consumers.
>
>>> In my opinion, however, the value of the simultaneous release to communities like ECF's has gone down...and the costs of participation have gone up over the past few years (i.e. my previous note).  The simultaneous release itself is no longer very 'new' to lots of folks (users/consumers of Eclipse RT technology and/or Eclipse)...and so doesn't really result in much improved exposure/distribution for participating projects (like ECF).
>> Not being in the Indigo repo would significantly dampen exposure and consumption in my opinion. The Helios repo is a very convenient and trusted location to get Eclipse components.
>
> Perhaps...but no resources is no resources.  How is that to be
> addressed?  If additional resources can be found and/or contributed then
> the choice to continue with Indigo is obvious/easy.  If additional
> resources can't be found, then I don't feel I can commit to something
> that I knowingly cannot do.
>
> Scott
>
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-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: http://www.compeople.de/

Vorstand: Jürgen Wiesmaier
Aufsichtsratsvorsitzender: Christian Glanz

Sitz der Gesellschaft: Frankfurt/Main
Handelsregister Frankfurt HRB 56759
Ust-Ident.-Nr: DE207665352
-------------------------------------------------------------