Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-planning-council] Remove Query2 from Juno

+1

 

From: eclipse.org-planning-council-bounces@xxxxxxxxxxx [mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Achim Lörke
Sent: Monday, June 25, 2012 11:43 PM
To: eclipse.org-planning-council
Subject: Re: [eclipse.org-planning-council] Remove Query2 from Juno

 

+1

 

Achim

 

On 22.06.2012, at 20:10, 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.

 


Back to the top