Remember the "window" between +0 and "availability"
is now reduced to one week instead of two, which means all contributions
must be "in the build" by Wednesday, 12/18.
As of right now, the following projects have something
disabled in their contribution files:
contribution as a whole is not enabled: amp.b3aggrcon pdt.b3aggrcon soa-sca.b3aggrcon
one or more features or repositories are not enabled: dltk.b3aggrcon riena.b3aggrcon sphinx.b3aggrcon
Please get everything "enabled" ... or,
I know, some of you (such as amp, I believe?) was considering not being
in Sim. Release. So, good time to confirm your plans explicitly.
I am most concerned about "PDT", as I believe
they are proposing to "restore" a PHP Package in EPP? ... if
so, more important than usual to "get in early". Feel free to
correct any errors in my memory.
And a reminder to all, you do not have to wait to
your exact +n day to provide a "warmup" build ... even if you
submit your final bits on your +n day. This often helps find issues "downstream"
from you that no one is aware of yet and is less stressful to know about
Not to mention, it allows some "early testing"
of .../releases/staging to make sure what you think you are contributing
is actually "getting in" the aggregation repository.
I have contributed the M4 candidate Platform bits
to b3aggr files, and while the job is still running, will promote those
to staging soon. (And, will finalize tomorrow, Friday, afternoon, after
all final testing and sign-offs are obtained).
Wayne Beaton <wayne@xxxxxxxxxxx>
Cross project issues
12/11/2013 03:47 PM
Luna M4: The opt-in deadline approaches
Luna M4 is on December 20/2013.
Projects are required to opt-in by that date. As of this moment, I have
56 projects on my list . I'm pretty sure that I'm missing around 20
participants from last year. Opt-in instructions are in the wiki . Note
that your PMC will have to appeal on your behalf if you do not opt-in before
Participating projects must also have a well-formed project plan by this
date. I encourage projects to use the release record metadata  to capture
plan information, including a short (2-3 sentence) description of the release,
milestones, and at least a couple of themes. Note that you can attach Bugzilla
queries  to individual themes.
If you do choose to use the old school XML-style plan format, please at
least provide a description in the release metadata. I'll use this information
when I generate a "what's in Luna" page. If we do a good job
of this, it will be a tremendous help to the marketing folks when the time
comes to start marketing the cool and exciting features in the release.
Keep the description concise. No bullets.
FWIW, project and release metadata can be edited by any project member,
or member of the associated PMC. So PMC members, you can make minor edits
By way of reminder, the release cycle and review process is captured in
the wiki .