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
|