[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [provisioning-dev] Provisioning going forward

I am all with you.
I am a pragmatist, and when it comes to open source , there is only one
truth: the code.
Equinox has a code base, and Maya will have one soon. (That I am
anxious/excited to checkout ASAP if possible)
I highlighted those. Anyone else that has a code base now, and a plan to
make it grow has my respect.
So I am cool. You are cool. 
(Note that BTW, we have one too @ easyeclipse, as we sponsored an intern
last summer to work on a replacement to the update manager, it was fun
stuff, but I do not think it is worthy pursuing for now).

Yet I am worried when I see a gadzillion of projects intersections: it
smells like design by comittee to me. (bad smell)
Variations one one theme and one code base makes sense, as long as it is
clear that there is one theme and code base.
Because being a pragmatist, the solution that is part of the core SDK
will be the most widely distributed and available.
And it will win. So we better make it good, solid and the point of first
focus, rather than diluting efforts (beyond existing code base like
Or else we can end up with yet another partially useful and broken story
that has been the update manager so far.


As a side note, I am the admin for the Google Summer of Code @ Eclipse,
together with Wayne Beaton.  Among the 21 students that have been
selected to contribute to Eclipse this summer, there are a couple which
are closely related to provisioning.
*Eclipse web interface (with a possible use case to trigger provisioning
from an arbitrary web page in any web browser)
*New Update manager UI (which will focus to bring a face to Equinox
*An auto-configuration plugin for Eclipse (in a more holistic view of
provisioning, to get automated preferences and discovered services
*Java Executable Wrapper Plugin for Eclipse (vaguely related)
*WebDAV EFS Implementation ( a potential transport)
*Semantic-aware software component provisioning: actually reusing
software ( to define a component ontology)

I invite everyone to check out those abstract and stand by to support
and help those students and their mentors when their work will start in
late May, as they can contribute small code bricks to the larger
edifice. The best way to get plugged in the short term is to join
#eclipse-soc on freenode.

http://easyeclipse.org - http://phpeclipse.net - http://eclipse.org/atf
philippe ombredanne @ eclipse.org
philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
nexB - Open by Design (tm) - http://www.nexb.com 

> -----Original Message-----
> From: Tim Webb (tiwebb) [mailto:tiwebb@xxxxxxxxx] 
> Sent: Tuesday, April 17, 2007 11:14 AM
> To: pombredanne@xxxxxxxxx; Developer discussions for 
> provisioning (Update Manager)initiatives
> Subject: RE: [provisioning-dev] Provisioning going forward
> Philippe,
> Without a doubt everything will ultimately be built on top of the
> Equinox provisioning work as it provides the key enabling technology
> that will provide both consistency and enablement for a variety of
> services.  That said, it is unlikely that Equinox's scope will (or
> should) grow to cover the full set of use cases that will ultimately
> need to be supported in a the full Eclipse provisioning solution.
> Instead, I would look at Equinox to provide a rich set of capabilities
> for provisioning and then certain projects such as Maya to provide
> additional user interfaces and concrete implementations to 
> meet specific
> user scenarios -- in the case of Maya being targeted for organization
> and enterprise provisioning.
> To pick a particular example, certain consumers of Eclipse require
> central management.  This is an area that will likely 
> continue to reside
> in the Maya project even as the Equinox project evolves.  Similar to
> Equinox having extensibility, so will the central server 
> component in a
> provisioning system to enable capabilities such as licensing and
> governance.  I personally see the continued need for multiple projects
> to be successful if we are hoping to have a successful end-to-end
> provisioning story for the 3.4 timeline.  From the workshop, we
> identified multiple areas of intersection between projects.  
> From those
> intersections we will next be splitting out work to be 
> performed in the
> various provisioning projects.  
> Regarding where to focus attention, I'd suggest focusing it 
> from a given
> interest or need instead of project and then we can work as a 
> community
> to determine which project is the right home for the near term to
> support development of that component.  Once the projects 
> mature out of
> incubator status, we may then decide to restructure project placements
> but only once we've better defined and delivered on the base
> provisioning needs for Eclipse.  At the end of the day, there are many
> areas of provisioning as was highlighted by discussions at 
> the workshop.
> I absolutely agree that we need to make sure the Equinox provisioning
> work is very successful but I wouldn't want to do that at the 
> expense of
> the other provisioning work needed.  In addition, as we found at the
> workshop, by talking through projects like Maya, IBM's 
> Install Manager,
> SmartUp and other technologies represented, we were able to further
> mature and identify needs that would be required at the Equinox level.
> Continuing to move the entire provisioning solution forward will help
> ensure we have not only a successful base story to replace 
> what we have
> today but a rich platform that will meet needs of the future.
> Cheers,
> Tim
> -----Original Message-----
> From: provisioning-dev-bounces@xxxxxxxxxxx
> [mailto:provisioning-dev-bounces@xxxxxxxxxxx] On Behalf Of Philippe
> Ombredanne
> Sent: Tuesday, April 17, 2007 10:51 AM
> To: provisioning-dev@xxxxxxxxxxx
> Subject: [provisioning-dev] Provisioning going forward
> Hi all:
> I could not join the provisioning workshop last week, so I 
> did read all
> the posts I could find and here is how I have reformulated the
> conclusion for me:
> - Equinox is the way to go for provisioning and will be the core
> platform way. Everyone will contribute and/or migrate to that.
> - Maya does address some specific use cases and provides a non
> Equinox-based solution for now, but will also migrate to Equinox
> provisioning in a near future, and have specific use cases 
> for Equinox.
> So we all need to focus and concentrate our energies behind Equinox,
> since it will be lowest common denominator.
> Fair enough?
> -- 
> Cheers
> Philippe
> http://easyeclipse.org - http://phpeclipse.net - 
> http://eclipse.org/atf
> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com 
> nexB - Open by Design (tm) - http://www.nexb.com 
> _______________________________________________
> provisioning-dev mailing list
> provisioning-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/provisioning-dev