I have opened a bug [1] to inform the project of my recommendation
and have invited them to make their case to stay on the train.
As I state on the bug, I will give the Planning Council the standard
five business days to weigh in on the matter before taking action.
My recommendation and implied call for a vote was initiated on June
22; based on your feedback, I will take the necessary action on June
27th, the day of the actual release.
As I stated previously, this is little more than a formality and the
full extent of the action will be to "unflip the Juno bit" on the
project. This will automatically remove the project from any project
lists that we generate (e.g. on /juno and the /project/releases
pages) and drop the number of participating projects from 72 to 71.
Thanks,
Wayne
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=383457
On 06/22/2012 02:10 PM, Wayne Beaton wrote:
Greetings Planning Council.
I recommend that we remove Query2 [1] from Juno.
At this point, I believe that this is little more than a
formality. The project was unable to get their bits together in
time to make them available for the aggregator and so are not in
the combined repository. Query2 is not consumed by any other
project on Juno.
Frankly, it is my opinion that the project is simply not ready to
be part of the simultaneous release and that removal of the
project increases the overall integrity of the simultaneous
release process.
From a technical POV, all we need to do is unflip the Juno bit in
the portal. This will remove the project from the Juno landing
page and anywhere else that Juno projects are listed.
A little history...
EMF Query2 (modeling.emf.query2) was split from EMF Query [2]
(modeling.emf.query) late last year. AFAICT, there was no
significant development activity following the split. By virtue of
Query2 being split from a mature/regular project, it was created
as a mature/regular project. Despite this designation, it turns
out that the developers were not familiar with the Eclipse
Development Process and had made the assumption that the
restructuring review that created the project could serve as the
release review for the bits contributed to Juno.
The project was consistently late in providing materials, or
setting project metadata. In fact, it was only after I made
requests for the IP Log and review documentation that these
materials were provided. It was only after I made the request that
the project metadata was updated to indicate a +2 offset (it had
been specified as +0). It took several iterations for them to
provide me with what I consider to be bare minimum review
documentation. This conversation took place on Bug 381786 [4].
They had originally intended to provide a 1.0 release. I pushed
the project back into incubation and requested that they change
the version number to 0.7.
The project developers appear to be completely unaware of the Juno
participation documentation. It is pretty clear to me that the the
project requires more guidance with our processes. I will find
some Architecture Council mentors to assist them.
In the future, I will take a more proactive approach with projects
that join the simultaneous release to make sure that they join in
on the cross-project-dev communication channel and are fully aware
of the necessary process.
I've also been thinking that we might consider requiring that a
project engage in at least one independent release before joining
the simultaneous release. I don't think that this introduces
significant burden, and it has the benefit of making sure that the
project is knowledgeable in the process.
Thanks for your attention.
Wayne
[1] http://www.eclipse.org/modeling/emf/?project=query2
[2] http://www.eclipse.org/modeling/emf/?project=query
[3] https://bugs.eclipse.org/bugs/attachment.cgi?id=200206
[4] https://bugs.eclipse.org/bugs/show_bug.cgi?id=381786
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse Projects
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal to the Eclipse Foundation. To be permanently removed from this list, you must contact emo@xxxxxxxxxxx to request removal.
--
Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Explore Eclipse
Projects
|