[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [rt-pmc] Juno Retrospective
|
Hi everyone,
Let me give Virgo's 5 cents on the story.
I'll start with the release train common repo. To me this is Eclipse's annual delivery channel.
I would expect to be able to include and distribute easily updated versions of our p2 features through it, ideally our RT p2 products as well so our users can install them with lean p2 installers.
I've lead the Virgo release train efforts for Juno and did a little digging around to see how other projects are doing it.
What's the current state?
I won't dive into technical details but if an RT projects wants to contribute something to the common repo it is only limited to the "Target Components" Gunnar mentioned. These are features only usable in Eclipse IDE's target platform definition and can't be installed in a standalone p2 product instance(like Virgo, or Eclipse). These components are not the main delivery of an RT project, often that is a standalone instance of something that may or may not run in Eclipse. So it turns out that the common repository seems only good for IDE stuff.
At Virgo
- we can't contribute target components because PDE is limited in a way and can't handle ours properly. So we contributed a p2 product of ours, but in future will opt for our IDE tooling because that makes most sense as a contribution to that common repo.
- we can't include any of our regular features(not target components) as well, because they would be freely installable in the IDE and are not meant to run there so could break it.
It turns out the common repo is just not really that good delivery channel for us and we still stick to our side releases and repositories for bringing up-to-date features to users. My feeling is they find it easier as well. I think it's the same situation for other RT projects too.
During the simrel process I got the feeling that to participate in the release train you strictly must contribute something in the repo, which sometimes doesn't make much sense for an RT project. I think this is where the problem lies.
A solution I can imagine would work is to make the contribution optional:
- one RT project on the release train could optionally participate in the common repo, be aligned with the release train schedule and also comply with its requirements and deliver as they do now.
There are static checks that run on today's common repo checking for simrel requirement inconsistencies, these should easily be executable over an RT project's p2 repo making the same checks.
After all, you could look on the IDE as one big RT project itself with a common repo for features only applicable to it. I doubt any RT project could reach that level of add-ons in their repos, but it's the same model.
To me it makes sense each RT project to release separate p2 repo and still be part of the train. That way we would have many "common repos" each compliant with the rules and the content of each applicable to the particular runtime.
Best Regards
Bobby
On Thu, Aug 23, 2012 at 9:40 AM, Hugues Malphettes
<hmalphettes@xxxxxxxxxxx> wrote:
Hi Jesse and everyone,
A bit of controversy is good to move things along.
So here is my take: a bit of a controversy killer.
TL;DR;
======
There is value in making jetty easy to consume by other projects on the train.
Let's contribute what the other projects are consuming: the jetty bundles.
Doing that is really easier than contributing the web-starter kit repo.
Long story:
=========
Jetty's vision is to be the HTTP-RT library for java; not a framework and not an application server either.
This puts us in an uncomfortable situation when we ship a product. We do need to ship one though.
As a consequence, it has a minimal set of dependencies; and OSGi is not one of them.
The web-starter kit was our take on making a server out of jetty running in equinox.
But history shows that between gyrex, virgo etc we are better off with the community building a product.
What do you think?
Would it be acceptable to only contribute the jetty bundles to the train?
Is it something that will make everyone more comfortable?
Cheers,
Hugues
On Thu, Aug 23, 2012 at 12:11 AM, Gunnar Wagenknecht
<gunnar@xxxxxxxxxxxxxxx> wrote:
Am 22.08.2012 16:36, schrieb Mike Milinkovich:
> [..] Gemini is not on the release train either. Virgo wasn't exactly
> enthusiastic about the idea as far as I could tell.
Gemini JPA is actually in the release train repo. They do not
participate but I brought them in because it's a Gyrex dependency. Thus,
even if Jetty drops of the train, I can imagine they'll end up in the
release train repo somehow...
I think there are two things in the release train which are commonly
thrown together in the same bowl but which really are two distinct
things. (AFAIR)
1) Common p2 repo
2) Release on the same date
AFAIK, only point 2 is the really important here but point 1 is the one
that can cause headache.
Am 22.08.2012 16:43, schrieb Jesse McConnell:
> - the process is bothersome, it takes time to maintain the files (and
> go re-figure out what we needed to do when the time came), build
> metadata, p2
> repositories, release docuware, etc
Release docuware is necessary for a release anyway. Producing p2 repos
is also a very important goal to improve adoption. I won't consider
those (and other stuff like IP log, etc.) specific to the release train.
They have to be done for a release anyway. I know that EMO is really
onto reducing the bulk of additional administrative work to make a
release (hint: automation).
Simply put (if you don't aim for option 1), the only additional overhead
of participating in the train is the gazillion lines long questionnaire
in the portal. Frankly, a bunch of questions in this form don't make any
sense at all for RT projects.
However, participating in the common p2 repo is indeed a bit of
overhead. There are also some technical issues which won't help. But
from chats at EclipseCon I recall that this is not necessary
participating in the train.
Thinking about this myself, the only reason Gyrex wants to be in the
common repo is because of those "Target Components". However, especially
if you do (frequent) releases in between (like Jetty does), then those
contributions are outdated very fast anyway.
-Gunnar
--
Gunnar Wagenknecht
gunnar@xxxxxxxxxxxxxxx
http://wagenknecht.org/
_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc
