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
<igor@xxxxxxxxxxxxxx>
To:
Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx
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
> [5] https://wiki.eclipse.org/Every_Detail_Matters
> [6] https://wiki.eclipse.org/SimRel/Feature_Categories
> --
> Wayne Beaton
> @waynebeaton
> The Eclipse Foundation
> EclipseCon 2015 <http://www.eclipsecon.org/na2015>
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> cross-project-issues-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password,
or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
 |
