[News.eclipse.technology.packaging] Re: Policies for EPP

[Markus Knauer <mknauer@xxxxxxxxxxxxxx>]

Hi Scott,

let me write down some of my thoughts here:

* 'Small number' -> We tried really hard to present the packages on the
donwload page in a way which allows a new user to get what he/she needs. I
think it is still too complicated and every additional package adds more
complexity to the selection process. Maybe we can remove one of the
packages and replace it with another one, but to avoid more confusion this
can only be done with the Ganymede release.

* 'Getting in' -> Again, I don't like to change the existing packages,
because it would be hard to explain to the users, why these packages have
changed ('I user the XY-europa-fall package, now I switched to the
XY-europa-winter package and this feature is missing')
But with Ganymede we can adjust the package content (keeping in mind that it
is easy to add something, but hard to remove anything... so we need to be
very conservative)

* 'Community feedback' -> Maybe we need to specify this more clearly... but
this is one reason for this discussion on the newsgroup.

* 'Small' -> IMHO this is the download size (and only the download size). I
was really surprised that the (small) Java package is on the top position
of every download statistic. 

* 'Release train only' -> The likeliness that a project from the release
train delivers something stable, well tested, etc. is higher than that of
other projects. Based on that assumption it is a natural decision to use
this as a prerequisite for building stable and reliable packages.

* 'Discussion' -> We are trying to get feedback... and I am sure you will
agree that we need some policy/instructions for a project that wants to be
part of an EPP package.

Markus


Scott Lewis wrote:

> Hi Ian,
> 
> Although I applaud an effort to make these criteria public
> (transparent), I question whether these/this set of policies make the
> process more 'open'.  Basically, as below IMHO it's a set of (quite
> restrictive) exclusion criteria...which doesn't seem very open to me.
> 
> For example:
> 
> 'Small number' (2): basically a project therefore can't get in because
> you weren't in the initial set of 4?  And 'strong feedback from the
> community'...what/which community?  Committers?  Stragegic members?  ?
> 'Size' (3):  Size of existing packages small: so if you have anything
> above...what...50K of code/3 bundles that's too big?  What is small?
> Download size, runtime size, # bundles...?
> 'Release train only': (4) Naturally, that excludes quite a number of
> projects (all those that cannot meet all the release train requirements
> as well).
> 'Discussion' (5):  What's the point of discussion if 2, 3, 4, 6 won't
> allow any changes?
> 
> And WRT 7, how/does this overlap with/duplicate the Equinox p2 work
> (which is essentially creating/has created such a framework as well)?
> 
> Scott
> 
> 
> Ian Skerrett wrote:
>> I thought it might be useful for the EPP project to have a set of
>> policies
>> that we use to determine that content of the packages.   The goal is that
>> we
>> all agree to an approach for making decisions on the package content.  
>> This will hopefully make the project more open and transparent in the
>> decision making process.
>> 
>> Here is a draft set of policies that I think might make sense.  
>> Thoughts?
>> 
>> 
>>   1.. The goal of the EPP packages is to improve the initial out-of-box
>> experience for an Eclipse user.
>>   2.. EPP intends to keep the number of packages the project maintains to
>>   a
>> very small number.  The initial 4 packages were defined in the original
>> project proposal and we don't intend to add additional packages unless we
>> receive strong feedback from the community.
>>   3.. We want to keep the size of the existing packages as small as
>> possible.  The existing packages are defined based on the profiles of a
>> target user.   The philosophy is to provide a solution that addresses the
>> basic needs of the majority of the target user population.   We are not
>> trying to solve everyone's requirements.
>>   4.. EPP will update the content of each package to coincide with the
>> annual release train.   We will not change the contents of the packages
>> during the year.  During the Fall and Spring maintenance release we will
>> only update the packages with the new releases from the existing
>> projects.
>>   5.. The package content update will be discussed in an open and
>> transparent way on the EPP newsgroups.  Everyone in the Eclipse community
>> is
>> welcomed to provide feedback.  The EPP committers will make the final
>> decision on the package content.
>>   6.. A project that is included in an EPP package must have the
>>   following:
>> 1) must be part of the annual release train, 2) be at least a 1.0
>> release, 3) must have a stable and reliable build and 4) should have
>> provide a minimal set of features so the EPP package can remain small.
>>   7.. EPP will be creating frameworks to allow others to create other
>> packages.   The Eclipse community is encouraged to take advantage of
>> these frameworks to create their own package for different user profiles.
>> 
>>