[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [epp-dev] EPP Process
|
Is this the start of an EPP Process Document? (Sounds like it).
In addition to these technical and mechanical details, I'd like to see
some explicit "steps" such as something like the following:
'Package must appear in at least 2 milestones (4 preferable).'
There are several reasons: demonstrates predictable, sustained development
and maintenance capability; allows time for feedback about the package
from users and adopters
Note: this is not only about the quality of the code in the package, it is
more about allowing time for feedback about the concept of package ...
does it include the right code? Should it have more? Less? Do other
projects want to participate? Or not participate? Is it downloaded at all
by the community during this period? Downloaded enough to justify being
included on the main Eclipse download page?
I also think we need to revisit the concept of incubating code appearing
on this main download page (that is, also, in EPP packages). I think
Eclipse is mature enough not to have to "feature" incubating code ...
Projects can do that themselves, have news items, perhaps a separate
download page for incubating packages?
You may want to include a process step that includes some Planning Council
Review or Approval? (Not that I want it ... but, seems there ought to be
some larger body to represent Eclipse interests? ... other than Ian and
Markus (not that they couldn't do a good job of it!)
Just some ideas to keep the process discussion going ... it is important
to get this documented so expectations are set and the process perceived
to be fair to all (all projects, all users, all adopters, and all
Members). And ... I have a selfish interest ... I may propose a few more
packages for Helios! :)
Thanks,
From:
Markus Knauer <mknauer@xxxxxxxxxxxxxxxxx>
To:
Eclipse Packaging Project <epp-dev@xxxxxxxxxxx>
Date:
09/09/2009 07:37 AM
Subject:
Re: [epp-dev] A new EPP SOA package
Sent by:
epp-dev-bounces@xxxxxxxxxxx
Here is some input for this discussion:
Build: The product definition, its bundle etc. of every package is located
in a CVS location that belongs to the EPP project. Every product that is
found there will be picked up by the EPP package build. So adding a new
package is semi-automated. On the other hand this implies that one needs
write access to the EPP CVS to add a new package.
But adding a new package means more than that: Setting up a new component
in Bugzilla, adding a dependency to the new package in order to include it
in the EPP p2 repo, etc.
Build mechanism: In EPP, everything is based on Buckminster and p2, i.e.
there is no special "EPP" mechanism, nothing that would prevent others
from doing their own builds.
Release train / number of packages / this and that: Most of the time, p2
and Buckminster are doing a perfect job. But someone needs to look at the
build, adjust repository paths, version numbers, and other things. But now
and then the build fails for different reasons, sometimes there are
problems on the server, sometimes a repository has vanished, is
inconsistent or p2 is not able to fulfil the dependencies. And we should
not forget that EPP has to build packages against a moving target because
all the projects are under heavy development - this makes it different to
something that consumes only stable output from the projects.
There are many reasons like this why I think that the limitation to the
release train repository is important and here I fully agree to David.
Incubation: Every package that includes components from projects in
incubation phase is clearly marked with "incubation" in the filename and
on the download page. E.g. see the Modeling package. The same needs to be
done with the new SOA package.
Download page (eclipse.org/downloads): My understanding is that the
download page does not "belong" to EPP. It is the decision of the Eclipse
Foundation what to put there. eclipse.org/downloads/packages is different,
because it gives you access to old builds and new milestone builds.
Regards, Markus
2009/9/8 Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx>
I completely agree that the build mechanism used by EPP should be
avaliable to all. (I actually assumed it already was) In that case,
projects would not even have to ask or talk to EPP, they'd run the process
and make the results available. We would not be having this conversation.
But it seems the topic did come up and that Markus is having to do some
stuff which implies that it is more than just the build. Other topics that
have come up are : coordination with the release train, exposure on the
downloads page, testing/quality of the package, ...
Jeff
On 8-Sep-09, at 2:35 PM, Ian Skerrett wrote:
IMHO, ideally anyone should be able to specify a package and the EPP
automated build process will build it. We have the infrastructure in
place
so it would be a shame for people to have to re-invent the wheel.
-----Original Message-----
From: Jeff McAffer [mailto:jeff@xxxxxxxxxxxxxxxxx]
Sent: Tuesday, September 08, 2009 2:18 PM
To: ian.skerrett@xxxxxxxxxxx; Eclipse Packaging Project
Subject: Re: [epp-dev] A new EPP SOA package
I agree with the agility points 100%. By the same token, EPP is not
the only place that "packages" can be put together. Any project,
working group, ... is free to bundle up a mess of stuff and call it
useful and make it available.
Its just my opinion. EPP should not be the only conduit.
Jeff
Jeff McAffer | CTO | EclipseSource | +1 613 851 4644
jeff@xxxxxxxxxxxxxxxxx | http://eclipsesource.com
On 8-Sep-09, at 11:25 AM, Ian Skerrett wrote:
I think it is important that we have the SOA package available for
SR1. A
couple of points:
- We can't get into a situation where the packages are tightly tied
to the
release train schedule. In the agile world we live in today, we
need to
have the ability to respond to new requirements. In this case a new
group
would like to create a new package, so I believe it is important
that we can
respond to their request.
- As for quality, as with any package it is the responsibility of the
package maintainers to ensure the quality. Like all the other
packages,
Zsolt is responsible for testing and signing off on the quality. I
agree it
would be nice to have more time to community feedback but I believe
that is
Zsolt decision to make.
- In terms of the release review, of course if Swordfish does not
pass then
they will not be able to release, so a package is moot. However, it
is very
easy to remove something. :-)
- I agree it does seem that SOA package is close to the Java
Enterprise
package but fortunately/unfortunately (depending on your
perspective) the
intention of the packages is to appeal to a certain user profiles.
In this
case the user profile is a SOA developer not a Java developer. The
contents
are similar but we want to attract developers that are interested in
SOA.
In conclusion, I am a +1 on the SOA package. For me it is important
EPP
continues to be responsive and agile between release trains. We
can't live
in a static environment and only change once a year.
Ian
-----Original Message-----
From: epp-dev-bounces@xxxxxxxxxxx [mailto:epp-dev-
bounces@xxxxxxxxxxx] On
Behalf Of David M Williams
Sent: Monday, September 07, 2009 9:24 PM
To: Eclipse Packaging Project
Subject: Re: [epp-dev] A new EPP SOA package
Question: Is there anyone out there who is against (1)? Any
objections
from other package maintainers or team members?
I'm a little against '1'. I don't want my voice to make the
decision, but
I'll at least give a dissenting point of view and see if anyone else
agrees (or disagrees).
My largest concern is that there's no time for any use or feedback
from
the community or adopters. Part of the purpose of the simultaneous
release
(and packages, in my view) is not the end-result, but the build-up
to that
end-result. Seems like the plan for option '1' focus on only the
end-result ... producing a package ... with out demonstrating the
steady
predictability of milestones and release candidates.
A smaller concern is that I think 'Swordfish' is part of the
package, and
they are not having their Release Review until the very last minute
(Sept
14th or so?)
So, there is some risk that it won't make it, and this won't be known
until the very last minute.
In fact, looking at the list of features, it seems like exactly the
same
thing as the EPP 'Java Package' (that is, the one that has mylin,
and xml
in it) except for the addition of
- org.eclipse.wst.ws_ui.feature
- org.eclipse.swordfish.tooling.feature
So ... doesn't seem like anything that should be hard for users to
install
or construct.
On the flip side, I see how the "working group" wants the publicity,
etc.,
but I just don't like the packages being a "marking tool" without the
normal path of users and adopters trying it out for a few months
first.
(Remember, normally, someone must be "in the build" for Simultaneous
Release by M4 or M5, which translates into nearly 6 months of
community
use before release).
Would "Galileo SR2" be an option? That'd at least give some time to
publish some versions before it was officially released.
But, like I said, mine is just one view and I don't feel so strongly
about
it that I'd be insulted if you or others didn't agree. I definitely
don't
want to be 'negative' to new things, I just felt it important to
voice the
counter point of view. I'm fine to go with your decision (as EPP lead)
either way, without further discussion or justification.
Good luck!
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
--
Markus Knauer
EclipseSource
### phone: +49 721 664 733 0 (GMT +2)
### fax: +49 721 664 733 29
### web: www.eclipsesource.com
Innoopract Informationssysteme GmbH
Stephanienstrasse 20, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
_______________________________________________
epp-dev mailing list
epp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epp-dev
