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

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

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.