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
[5] https://wiki.eclipse.org/Every_Detail_Matters
[6] https://wiki.eclipse.org/SimRel/Feature_Categories
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation

|