> The EDP provides for considerable flexibility around
incubators. In
> general, incubators are a place to try new ideas in a very
> lightweight way (no additional management overhead, ability to use
> the Parallel IP process, relatively easy to add new committers, that
> sort of thing). As those ideas get heavier (i.e. more real), the EDP
> provides for those ideas to be extracted and grown into separate
> projects of their own. I would argue that we should probably have
> considered moving the JPA Diagram Editor out of the incubator a
> while ago (around the time that it stopped being an idea that you
> were bouncing around and it turned into something with legs of its
own).
I don't disagree with anything that has been said, but
will add some history and additional use-cases here. We in WTP (and WTP
Incubator) have released incubating components in the past, prior to graduating
into a project, such as for XSL 0.5. I don't recall if this was an exception
to the "only projects release" rule at the time (several years
ago), or simply several EDPs versions ago where the rules were not clear
or did not prohibit it. The reason for doing that sort of thing, that I
do not think has been emphasized enough, is that one or more adopters wanted
to use it in their own release of a product or other open source project.
They are motivated simply to have an IP clean version that will be persisted
for a long time (on downloads, or archives, as our WTP policy is to archive
all releases, but little else). The dynamic behind this is simply that
they may not care if it is not quite a mature "stand on its own"
project, but it serves their needs. And while we normally discourage people
from using pre-1.0 code in products or project releases ... at the same
time, we are highly motivated to fill the needs of adopters.
Also keep in mind, some other reasons for having an incubator
is having an lower bar for committers to get started, that do not yet have
a long, visible history at Eclipse ... thus, the code they are working
on may not be so much "exploring new ideas", but lean more towards
simply "exploring open development" ... learning the ropes of
working at Eclipse, both the mechanics and culture of working in the open.
In fact, I'd say very little of the current code/components in WTP Incubator
are simply "trying new ideas" but most are very well established
ideas, that are simply trying to firm up their code while collaborating
with potential adopters and committers, firming up their activity levels,
and get into the "Eclipse Way" of managing builds, having regular
milestones, managing bugzilla, mailing lists, newsgroups, forums, open
status meetings, etc. (all no small task, as is well known).
I think in this specific case, some deadlines crept up
on us sooner than we expected, and yes, we could have gotten started earlier
... but, not sure that's the only thing to learn. It does seem that perhaps
we have been putting too much in the general WTP Incubator, and in the
future, we should just request new proposals to just to go ahead and propose
a new incubating subproject and reserve the WTP Incubator for simply kicking
around new ideas. Well, that, and just make sure everyone knows well up
front that nothing from WTP Incubator can release (I probably did know
that, at some level, but didn't really think it through in the normal course
of meetings and planning).
I do not know how much need there would be for it, that
is, don't know if worth expending effort on improving EDP, but there might
be some need to have a different type of release, let's call it a "pre
1.0 release" that could be components, lets say of incubating projects
only, and would mostly mean "IP Clean" but not rise to the level
of "graduating" into its own project. But, again, I don't disagree
with what has been said, and I do not see much harm in encouraging more
and quicker movement of incubating components to incubating subprojects,
since that doesn't mean it has to be final ... it could always move and
reorganize later. But it may just take us some time to "internalize"
this way of thinking and make it a practice. In any case, I have
opened
an "EDP
Bug" (330729) to document and discuss possible
long term changes in EDP to allow incubating components to release, in
case it comes up frequently.
Wayne, we appreciate your attention and efforts on helping
us with our projects and processes.
And Kaloyan, I especially appreciate your efforts to blaze
these trails and help these fledgling components get through the processes
so adopters can take advantage of the functionality.
Thanks to you both.
From:
Wayne Beaton <wayne@xxxxxxxxxxx>
To:
"Raev, Kaloyan"
<kaloyan.raev@xxxxxxx>
Cc:
"WTP PMC communications
\(including coordination, announcements, and
Group discussions\)" <wtp-pmc@xxxxxxxxxxx>, "Dimov,
Stefan" <stefan.dimov@xxxxxxx>
Date:
11/19/2010 11:17 AM
Subject:
Re: [wtp-pmc]
JPA Diagram Editor Release Review
Sent by:
wtp-pmc-bounces@xxxxxxxxxxx
The EDP provides for considerable flexibility around incubators.
In general, incubators are a place to try new ideas in a very lightweight
way (no additional management overhead, ability to use the Parallel IP
process, relatively easy to add new committers, that sort of thing). As
those ideas get heavier (i.e. more real), the EDP provides for those ideas
to be extracted and grown into separate projects of their own. I would
argue that we should probably have considered moving the JPA Diagram Editor
out of the incubator a while ago (around the time that it stopped being
an idea that you were bouncing around and it turned into something with
legs of its own).
I will review your proposal document and return any feedback to you before
I post it and announce it to the membership. It'll need to be vetted by
EMO(ED) as well. I will initiate the trademark search immediately so that
we are prepared for the Creation Review.
We can combine the Creation and Release reviews which will effectively
alloyou to release as soon as the review is complete, but prior to provisioning.
The only wrinkle is that there will be no official place to put the bits.
I suppose that it would be reasonable to put the bits (at least temporarily)
in the downloads area for the WTP Incubator if that is acceptable by the
PMC.
The initial contribution will be the result of a move. No CQ is required.
The CQs corresponding to the code will be moved along with the code.
We will need to do the IP Log review prior to the release. I don't think
that the Woolsey tools are quite ready yet (I'm hoping for a December release),
but the existing automated log tool seems to work [1]. Though you may need
to remove some stuff manually; if you log in there is a mechanism to help
you with this. Alternatively, you can snapshot the HTML and just hack out
the bits that shouldn't be there.
Actually... this will be easier with Woolsey. If you want to give Woolsey
a try, let me know and I'll put up a repository and spend a couple of hours
providing some initial documentation. That's going to have to happen sooner
or later anyway
OK… I think the root problem
is that the EMO and (at least part of) the Eclipse committers have different
understanding of the Incubator project. My take away from this story is
to never ever dare to think about using an Incubator project for whatever
purpose.
Please, find attached the
proposal document for the JPA Diagram Editor. It’s almost the same as
the one we did to start the project as new component in the WTP Incubator.
Walking this way, I have
now more and more open questions, that I need answers for in order to make
some reasonable planning:
·
We have to wait at least
3 weeks for the project to be created. That’s clear.
·
Can we release before
the provisioning of the project completes (but after the project is created)?
We can use the existing infrastructure in WTP Incubator for this first
release.
·
Do we need to reiterate
the IP review of the initial contribution? The initial contribution will
be the existing code in the CVS of the WTP Incubator. It has a completed
IP review.
·
What happen with the CQs
we’ve done while being in the WTP Incubator project? Do we have to reapply
for them before releasing?
Regarding your suggestion
to move the code as a new component under the Dali project. We discussed
this at the WTP PMC. But, as you have already mentioned, components do
not release by themselves. Since our goal for this first release is to
be compatible to Helios, moving the component from the WTP Incubator to
Dali, does not help at all. Dali already rides the Indigo train. Releasing
a new version of the whole Dali project (just to release the JPA Diagram
Editor) has a greater complexity of the issue we are discussing now.
Greetings,
Kaloyan
From: Wayne Beaton [mailto:wayne@xxxxxxxxxxx]
Sent: 17 ноември 2010 г. 23:46 ч.
To: Raev, Kaloyan
Cc: Dimov, Stefan; WTP PMC communications (including coordination,
announcements, and Group discussions); Mike Milinkovich
Subject: Re: JPA Diagram Editor Release Review
FWIW *every* time I start an email
like my last I first try to resolve to myself whether or not I think the
process is reasonable. This is why I suggested the Creation/Release review
combination using the most aggressive timeline possible. If you believe
that the EDP needs to be adjusted, feel free to open bugs against Community/Process
for consideration next time we revise the EDP.
I'm sure that a good chunk of the world already knows about the JPA Diagram
Editor. I must, however, confess that I had not heard of it before I received
your request for release. I actually spent a good deal of time going through
our database and my mail log to make sure that I hadn't just forgotten
about it. The proposal and review period is to give the community and other
concerned parties an opportunity to comment, criticize and otherwise get
involved. While it may feel like unnecessary bureaucracy to post a proposal
and engage in a review, the EMO and the Board consider it to be an important
part of the process. A lot of organizations, including many of our board
members and adopters, are not able to monitor every forum upon which communication
occurs. They depend on EMO communication about new projects to keep up
with and get involved with new developments.
I agree that there is an element of restructuring happening as part of
this: the relevant code from the incubator will move it a new project (that
restructuring will be implicit in the creation). That new project, however,
is not the result of restructuring the incubator. You are not factoring
the scope of the WTP Incubator or breaking it into manageably-sized subprojects.
Such is the nature of incubators. Incubators are an ideal place to start
working on new ideas, but once those new ideas gain an identity of their
own, it's time for them to move into a newly-minted project. The incubator
does not restructure every time code moves out of it.
Perhaps it can be argued that the EDP does not make this clear enough,
and--while I loathe to add more words to the EDP--perhaps the next iteration
needs to better define the intent. I believe that the line "The scope
of any new project must be a subset of the scope of the original project."
covers my interpretation. I don't believe that we can reasonably state
that the scope of the new project you want to create is a subset of the
scope of the incubator.
If the JPA Diagram Editor makes sense as a subproject of Dali, could it
also just be a piece of Dali? Is there some reason that a new project is
required? Does the function of JPA Diagram Editor fall within the scope
of Dali? If we can argue that JPA Diagram Editor is a reasonable piece
of Dali, then we can initiate a restructuring review and then Dali can
do a release (of course, you'll have to get the project on board for the
release).
Wayne
On 17/11/2010 1:32 PM, Raev, Kaloyan wrote:
Wayne,
I think we are entering a process hell
that goes completely out of rationale.
The development of the JPA Diagram Editor
in the Eclipse community has been done in a transparent way. We did a proposal
for the WTP Incubator. It was discussed in the wtp-dev mailing list and
in the WTP PMC. We posted some blogs to planet.eclpise.org during the development.
We did a talk at Eclipse Summit Europe. We had some discussion in the Eclipse
Forums. We did CQs, IP Reviews, IP logs…
The world knows about the JPA Diagram Editor
and that it is developed in the WTP Incubator. Spending 3 weeks (or perhaps
many more as I see where the wind blows to) in reiterating the complete
EDP will not give more transparency or get any new feedback.
I understand it was a terrible mistake
starting the project in the WTP Incubator, but I hope we can find a meaningful
solution in an acceptable time. We just want to release. If EDP does not
allow this, or wants to make our life miserable in order to release, then
the EDP is wrong, or we read it in a wrong way.
I really don’t understand why this cannot
be considered as Restructuring of the WTP Incubator project. Over the last
months we’ve done a lot of work and produced some artifacts like code,
Bugzilla items, CQs, etc. We want to *move* them to a new place,
where we can release from. We don’t want to throw them away and start
from scratch. Yes, this new place is a new project, but chapter 6.3.8 of
EDP says that, as part of the Restructuring Review, new projects can be
created. And the time for the review is still one week.
Greetings,
Kaloyan
From: Wayne Beaton [mailto:wayne@xxxxxxxxxxx]
Sent: 17 ноември 2010 г. 20:03 ч.
To: Raev, Kaloyan
Cc: Dimov, Stefan; WTP PMC communications (including coordination,
announcements, and Group discussions)
Subject: Re: JPA Diagram Editor Release Review
I think we're really talking about
a creation review. While it might be convenient to think of it as such,
you're not really restructuring the incubator.
A creation review requires a proposal period of no less than two weeks
followed by one week of review (a total of three weeks). If you can get
me a proposal document before noon ET tomorrow, we can have the project
created by Dec. 8 and provisioned shortly thereafter. http://wiki.eclipse.org/Development_Resources/HOWTO/Starting_A_New_Project
I'm pretty sure that this has never been done before, but we could consider
a combined Creation/Release review. This will allow you to release as soon
after provisioning as you can manage.
We should start with a proposal document as normal, and then build a Creation/Release
Review document in time for the release. If you can have the proposal document
ready by tomorrow, the review document would need to be ready by Dec 1.
HTH,
Wayne
Raev, Kaloyan wrote:
Hi Wayne,
Any news from you? I missed to tell that
there is a time pressure. We would like to have the release available on
December 1st at latest. I hope we have enough time to go through
EDP.
I am reading the about EDP right now. I
find chapter 6.3.8 Restructuring Review relevant for our case:
“A
Restructuring Review may necessitate the construction of one or more new
projects. This tends to occur when an existing project is decomposed into
two or more projects. In this case, a Restructuring Review is similar to
a Creation Review. Any new projects that are created as part of a Restructuring
Review must have their scope explicitly specified as part of the review.
The scope of any new project must be a subset of the scope of the original
project.”
So, in our case we would like to take part
of the WTP Incubator project – the JPA Diagram Editor component, and create
a new project for it with the same scope, code and committers. And we want
to combine this (chapter 6.3.9) with a Release Review.
Please, let me know if this is meaningful
and possible. I will appreciate any hints about required documents.
Thanks,
Kaloyan
From: Raev, Kaloyan
Sent: 16 ноември 2010 г. 19:38 ч.
To: 'Wayne Beaton'
Cc: Dimov, Stefan; 'WTP PMC communications (including coordination,
announcements, and Group discussions)'
Subject: RE: JPA Diagram Editor Release Review
Hi Wayne,
We have just discussed this issue in the
WTP PMC. We decided that the best approach should be that the JPA Diagram
Editor, which is currently a WTP Incubator Component, “moves” to a new
subproject (yet incubating) under the WTP Dali project. So, at the end,
we release version 0.5 from this new JPA Diagram Editor project and not
from the WTP Incubator component.
Now, the big question is: “How is this
going to happen?”. We suggest that we extend the Release Review to a “Pre-graduation
Release Review + Move/Creation Review”. We will include some more slides
in the document, which describe the “move mechanics” – what infrastructure
moves where.
Does this sound reasonable? Do we need
to create a new proposal document? We still have the one from the time
we introduced the JPA Diagram Editor in the WTP Incubator:
http://wiki.eclipse.org/WTP/JPA_Diagram_Editor/Proposal
Greetings,
Kaloyan
From: Raev, Kaloyan
Sent: 12 ноември 2010 г. 18:54 ч.
To: 'Wayne Beaton'
Cc: Dimov, Stefan
Subject: RE: JPA Diagram Editor Release Review
Thanks, Wayne.
We will discuss this in the PMC.
Greetings,
Kaloyan
From: Wayne Beaton [mailto:wayne@xxxxxxxxxxx]
Sent: 12 ноември 2010 г. 18:47 ч.
To: Raev, Kaloyan
Cc: Dimov, Stefan
Subject: Re: JPA Diagram Editor Release Review
There is no notion of releasing
a component in the EDP. Only projects can release and projects designated
as "incubators" don't tend to release at all.
If you think that JPA Diagram Editor is ready to stand on its own outside
of the incubator, then maybe it's time to create a new project for it.
Or perhaps it should move to another project under WTP and align with their
release schedule.
Wayne
Woolsey's not ready yet.
Raev, Kaloyan wrote:
Hi Wayne,
We would like to schedule a release review
for the JPA Diagram Editor, which is currently incubating under the WTP
Incubator.
Which is the next possible date to schedule
a Release Review?
I attach the docuware, that Stefan (the
project lead) has prepared. The only thing left is to generate the IP Log.
Could you give us some instructions how to do this? We try to use the Woolsey
tools, but we are not sure if it is “production ready”. Could you point
us to some documentation how to use it?
Thanks,
Kaloyan Raev
Senior Developer
TD Core JS App Model & Dev
SAP Labs Bulgaria
136A Tzar Boris 3 blvd.
1618 Sofia, Bulgaria
T +359 2 9157-416
mailto:kaloyan.raev@xxxxxxx www.sap.com
Save a tree - please do not print this email unless you really need to.