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

[Eric Rizzo <eclipse6@xxxxxxxxxxxx>]

Just to chime in with a neutral outsider's opinion:
I agree mostly with the policies as originally posted; specifically with 
the idea that EPP packages are more carefully/slowly/strictly evolved 
than the general Eclipse ecosystem. I'm coming at it as a person who 
spends countless hours answering questions on the newsgroups, many of 
them from newbies. From that perspective, the primary benefits I am 
hoping to get from EPP are simplicity, ease, and safety. I'm still 
waiting for an installer for the ease part and some of the safety part, 
but the simplicity part has been taken care of by (careful, with 
community feedback) selection of a small number of general-purpose 
packages. I would not want to see the Downloads page polluted with a 
menagerie of choices that need more than a blurb of explanation.

Perhaps a compromise would be to allow EPP to be a little more broad in 
its acceptance policies, but to NOT include all available packages on 
the default Downloads page.

Eric


Scott Lewis wrote:
> Ian Skerrett wrote:
> > > I think saying that things can't change because it would be 'hard to 
> > > explain to users' doesn't really work for me.  Why?  Because new 
> > > software *is* change.  If the EF (and it's associated projects) want 
> > > to have 'innovation networks', then things must change.  Like a 
> > > shark, if it's not moving forward, it's dead :).
> >
> > Scott, there is lots of change that happens in Eclipse.  We are just 
> > talking about the packages that EPP is producing.
>
>
> Of course I understand that.  But if the projects don't have a 
> distribution mechanism, that positive change/innovation will never reach 
> anyone.
>
>
> > > I guess I'm not so worried about users and change as you are.  Change 
> > > is constant (especially in sw dev tools).  I don't think that is 
> > > avoidable. Now I think it's possible to make it simpler for users to 
> > > deal with change, but I thought that's what EPP was really setup to do.
> >
> > I agree with Markus.   The packages need to be consistent from one 
> > release to the next or we run the risk of confusing people.   Change 
> > will happen but at a much slower pace than in other parts of the 
> > Eclipse community.
>
>
> I think this is simply a poor judgment, and based upon user assumptions 
> that are biased away from innovation and toward 'business predictability'.
>
> > > Yes, that is my major point...EPP certainly does need 
> > > policy/instructions for a project that wants to be part of an EPP 
> > > package.  But those instructions will be useless/meaningless to 
> > > projects if it is not possible for them to do anything that will lead 
> > > to inclusion in EPP.
> >
> > I actually think most projects will NOT be included in the EPP 
> > packages.   I think this is where you and I probably disagree.  
>
> Yes.
>
> EPP will fail if it starts
> > to include too much stuff.   
>
>
> I think this is wrong.  EPP will fail if it doesn't deliver what people 
> want and the projects need to survive and flourish.
>
>
> They need to include the base functionality but
> > encourage the use of update sites to get additional project 
> > functionality.
>
>
> Encouraging update sites is fine/good, but as the Europa download 
> numbers show, EPP is/will be responsible for a lot of distribution...to 
> the detriment of the projects that cannot participate (because you say 
> they can't).
>
> > If EPP is viewed as the primary distribution channel for Eclipse 
> > projects then we will fail; in my opinion. 
>
>
> I disagree.
>
> I suppose this means all the second class projects will have to wait for 
> p2 tech to get additional distribution through EF.  A shame.
>
> Scott