Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] Target Provisioning

Just two side notes (inline)
Am 03.06.2009 um 14:15 schrieb Jeff McAffer:

Sure.  I added this to the meeting agenda
   http://wiki.eclipse.org/RT/meetings/PMC_Minutes_090603

Some notes inline...
I talked to the RAP team and they are seriously thinking to not
supplying RAP in the Galileo repository because they cannot get the
proposed p2.inf hack to work that would disable the possibility to
install RAP into the Eclipse SDK and certainly leave it (the SDK)
unusable.
The RAP team was using the old metadata generator which does not have
p2.inf support.  They switched to the publisher (all the cool kids are
doing it...) and are happy now.
I am obviously also not very cool (and no one told me how to be cool :-) ) because I used the Eclipse metadata generator just this morning. And I am not sure where that information is there to read. David Williams (who is running the build in Galileo) just gave me a hint that I had to use the metadata generator after the sign process just last week. So information what is cool and what is not, gets easily lost. The note to the wiki page that marks the metadata generator as deprecated was added 5 minutes ago by the RAP team. They lost a day searching for that p2.inf thing and I would have never found out. We can do a lot better.

I am concerned because people will file bugs like "Riena cannot be
installed" rather than suspecting that the target provisioning system
itself is still a little unstable. Look at the bugs above some where
initially raised against Riena and we really have to thank Ekke for
investing weeks and weeks testing the target provisioning story.
Agreed on thanking Ekke.
I'd like to discuss that today. I am NOT proposing to pull it (that is
impossible) but maybe mark it with a "beta" icon or by makig it
crystal clear that we know it has bugs and we expect to find more bugs
(more serious bugs) after GA. Prepare a wiki page to collect them.
Help users to have a good experience and avoid pitfalls.

And this is a thing that will hit Runtime projects the most because
they are the one who uses target provisioning to setup their environment.

The idea of the new target provisioning is really so great, people
waited so long, expectations are high and there is only one chance to
make a first impression. :-)
Understood.  it would be great to make some concrete suggestions to the
PDE team for how to position this function.

One of the things that is an issue is the use of "Include
dependencies".  This runs the p2 planner under the covers.  The planner
works flawlessly yet people do not get what they need in the target
context.  In many cases this is because the metadata is incompletely /
incorrectly specified.  This can often be dealt with by unchecking this
option.  In that case the target provisioner uses the p2 slicer and
essentially just follows the "include" links in the features (ignoring
the requires links).  This still gives you the value of not having to
get zips, check versions, ... and avoids the metadata problem that comes
up in some cases.

Note that this is part of a larger topic around metadata management.  To
get the level of automation and control we want, we have to be more
rigorous about defining the metadata.  To figure out how to do this we
need to setup the situations and work through them.  That, IMHO is the
real value in having the Target provisioning stuff in now and getting
people to use it.

While I think (hope) I get the idea what you are saying, I have to admit that you loose me half way which I believe is part of the problem. Non-p2 people (like me) dont know what the slicer and other "things" are and its hard for them to understand where the problems comes from. So the target provisioning in 3.5. for them is more of a black box that either works or it doesnt.
I totally agree that we are moving in the right direction with metadata management and all the other cool features in p2.



More in the call.
Jeff


christian
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc


Back to the top