They point here, I think, is that you really need to communicate your
Mars needs with the IP Team to ensure that they allocate the necessary
resources to help you.
Wayne
On 09/02/15 09:01 PM, David M Williams wrote:
Part of the purpose of the CQ deadline is to allow the IP staff to
plan amount of effort from now to June ... so, I suggest if someone is
fairly sure a CQ will be coming in Mars to go ahead and open it,
explaining the plan, current state, and when they think the 'released
third party code will be available to attach. That way, IP staff can
put a place holder in their plan for work to do.
HTH
From: Igor Fedorenko i...@ifedorenko.com
To: Cross project issues cross-project-issues-dev@eclipse.org,
Date: 02/09/2015 06:59 PM
Subject: Re: [cross-project-issues-dev] Dates, review documentation,
etc. for Mars
Sent by: cross-project-issues-dev-boun...@eclipse.org
Just a heads up, m2e will miss CQ submission deadline. We are still
waiting for Maven 3.2.6 release we plan to embed.
--
Regards,
Igor
On 2015-02-09 13:30, Wayne Beaton wrote:
Greetings. *If your project is participating in Mars, please read this
entire message.*
The *February 13th deadline for Mars CQs* is this week. Get your Mars
CQs in. Be sure to add a comment with a request for Mars prioritization.
*You need a CQ for every version of a library you use.* Check your
builds; if you've pulled in a new version of a library, you may need a
CQ for it.
The download scanner [1] may be of some help. Please heed the warnings
provided by the tool: it is intended to provide assistance, but is
limited in what it can do. Don't panic if you see a lot of red; it has a
hard time sorting out non-bundle JAR files and so reports many false
positives (some older projects will see this if they include straight-up
JAR files in bundle directories; the Ant bundles are a good example of
this). If you are concerned about what you see in the report: (1) don't
panic; (2) ask me for assistance.
You do not generally need a CQ for a library that you use indirectly as
a result of pulling in the bits from another Eclipse project that uses
the library directly. You only require a CQ for libraries that your
project code uses directly. Clever reflection tricks constitute
direct use.
Any third party library that you distribute requires a prereq CQ. *Any
service that is accessible by the general population is considered to be
a distribution vector.* This includes the downloads area, and source
code repositories. Please review the guidelines for the review of
third-party libraries [2].
It is a simultaneous release participation requirement [3] that
*third-party plug-ins that are common between projects must be consumed
via Orbit*. Please ensure that you are familiar with this and the other
rules of participation.
Note that there is a handy feature in the project management interface
that *automatically populates a list of issues* targeted/addressed by
a release. If you create target milestones in Eclipse Bugzilla with
names that match the name of the release, this page is automatically
populated. If you use this feature, you may be able to get away with a
little less effort in the plan and review documentation (your PMC is the
ultimate authority on how much is enough). The name matching takes
milestones into consideration (e.g. Bugzilla target milestones of 5.2M1,
5.2M2, 5.2, ... all match against the 5.2 release record). There's more
information in the wiki [4].
Please also provide a *concise description of two or three sentences for
your release* in paragraph form in the PMI release record . We'll use
these descriptions as part of our marketing efforts, so please use this
opportunity to draw some attention to your project. Keep it brief; give
the reader a reason to take a closer look at your project.
Finally, you may have heard some rumblings about *Every Detail
Matters* [5]. In the simplest terms, this is an effort that I'm
undertaking to put more focus on the user experience and try to clean up
some of the little things. My intent is to try and use a collection of
relatively small improvements (that are relatively easy for you to fix)
to make the user experience better. *I'm starting with feature names.*
I've captured some thoughts in the wiki [6] and would like to hear from
you regarding the plan (either edit the page directly, use the talk
page, or put your comments in this list). I will be publishing some more
information about this and the Great Fix programme later today.
Thanks!
Wayne
[1] https://www.eclipse.org/projects/tools/downloads.php
[2]
http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf
[3] https://wiki.eclipse.org/SimRel/Simultaneous_Release_Requirements
[4]
https://wiki.eclipse.org/Project_Management_Infrastructure/Release_Metadata#Issues
