Actually, when we do our yearly retrospective in August, I'd like to discuss some kind of 'rules enforcement'. I've seen some issues coming up very late, projects contributing new functionality to RC's, and such things and I hope that we can improve again in this area.
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.
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.