Hi David,

yes, I am a representative of Xpand. And Karsten (Thoms) already formally
announced the participation in another mail.
Also Xpand has an aggrecon file, so I think we are fine.

Thank you!
Sven

2016-12-16 15:28 GMT+01:00 David Williams <[email protected]>:

> On 12/15/2016 08:56 AM, Sven Efftinge wrote:
>
>>
>> Xpand is in maintenance mode, but I understood that it needs to be
>> included if other projects have a dependency on it.
>> In that case, I assume it is a viable option to just include last year's
>> release again.
>> Is that correct?
>>
>> That is correct. With some possible complications.
>
> Are you, Sven, saying to include Xpand as a representative of Xpand? If
> so, then I think fine for you to include it, in your own ?.aggrcon file. My
> guess is it would be best to also have a release record, even if it was not
> a new release, just repeat the previously released version, and say
> "maintenance mode, same version" as its release documentation. (But Wayne
> is the authority on release records).
>
> I can envision a few other cases and one of those will get complicated:
>
> 1. In the past, projects wanted to "include" a previous release of a
> project (or a few bundles) that was maintenance mode, and had no ?.aggrcon
> file of their own (i.e. no one left to represent the project) so in those
> cases the participating project "included" it, either directly via features
> or by mirroring to their own repository. This is a direct analogy to "the
> Orbit case".
>
> 2. The new case that might need some new procedure or policy:
> If there is a large project, say like DTP (just as an example), which is
> required by many, but has no one real representative, then technically it
> should NOT be in its own ?.aggrcon file, and SOMEONE should say they will
> include a copy of the previous release in their repository (or, in their
> own ?.aggrcon file?) for themselves and others to use. That way, there is
> always someone at least partially responsible for it if something goes
> wrong. If nothing goes wrong, everything is fine. If something does go
> wrong, SOMEONE has to do SOMETHING! (even if it is to decide "not to
> include it").
>
> I mention this last "special case" since it sounds like there are a number
> of projects "in maintenance mode" and I suspect they will all "work" for a
> while, but eventually, as I am sure you already know, they will no longer
> work. Hence, a long term "ownership" is required, even for maintenance mode.
>
> Thanks,
>
>
>
>
> _______________________________________________
> 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
>



-- 
Sven Efftinge

TypeFox GmbH
Am Germaniahafen 1
24143 Kiel

Sitz: Kiel, Registergericht: Amtsgericht Kiel, HRB 17385
Managing Directors: Sven Efftinge, Moritz Eysholdt, Dr. Jan Köhnlein
_______________________________________________
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

Reply via email to