[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [dsdp-mtj-dev] Europa Simultaneous Release?
|
Title: Europa Simultaneous Release?
Hi
all,
To get
this started, I did include some opinions and our work estimates to follow the
"Europa" simultaneous release process.
Any
opinions are welcome ...
As these are required
for participation:
- The projects must work together.
-> This means that MTJ has to make a
lot more testcases for that.
-> Work
estimate 1 man month (must do also during our milestones (aka during
builds) and before release)
- Projects must have build process maturity and their own functional project
update site - the Europa site will reference these sites, not replace
them.
-> We have to get
an update site, our build process is quite
ok.
-> Work estimate 1 week (one
or two days for creating and three or four for
testing)
- Projects must optimize
their update site using pack200 to reduce
bandwidth utilization and provide a better update experience for users.
Additionally, they should do site digesting.
-> Also these we should include in
our build process
-> Work estimate
1 week
- Projects must use 4-part version
numbers.
-> Very small issue
-> Work
estimate 1 day
- Projects must provide both run-times and SDKs through their update sites
and thence through the Europa update site. (The Planning Council identified
that this might not be technically possible due to bugs in the update
manager's computation of required dependencies. We will remove this
requirement if it proves to be impossible.)
->Already MTJ does this
-> Work
estimate 0 day
- Projects must use signed plugins using the Eclipse
certificate.
-> This we would need to do
-> Work
estimate 1 week
- Any third-party plug-ins that are common between projects must be consumed
via Orbit; the final Europa
release will not have duplicate third-party libraries (note that this only
applies to identical versions of the libraries; thus if project A requires
foo.jar 1.6 and project B uses foo.jar 1.7, that's ok).
-> No problem to us
-> Work
estimate 0 day
- All plug-ins must correctly list their required JVM versions in the
manifest/plugin.xml.
-> Small issue for us
-> Work
estimate one or two
days
- Project representatives must attend the planning meetings and conference
calls - you have to be involved to be involved.
-> Does this mean Rauno or Mika or
the development guys?
- At least one person from each project must subscribe to cross-project bug
inbox, i.e. edit Bugzilla prefs to watch cross-project.inbox@xxxxxxxxxxx
-> See
above
- Build team members from each project will provide communication channels:
phone, mail, IM, IRC and will be available during to-be-specified
crucial integration times
-> No problem to us
-> Work
estimate 1 week
- Projects must have stated and demonstrated their intent to join Europa by
the M4+0 date. Projects do so by adding themselves to the table/list above,
along with their contact information.
-> Project management
issue
- Projects that have demonstrated an inability to synchronize with Europa
milestones by M6 will be removed from the Europa simultaneous release unless
the remaining Europa projects vote to retain said project.
-> See
above
And these are recommended for
participating projects:
- Projects should have jar'ed plug-ins because this is good Eclipse
citizenship.
->OK MTJ already has nearly all as jarred, thus few
plugins are as folders (but they do have some other content
also)
- Projects should use Eclipse message bundles, not Java bundles because this
is a good Eclipse citizenship. (see Message
Bundle Conversion Tool and [1])
-> We
already have this.
- Build reproducibility? Require that projects be buildable by community
members. Should be identical bits (but not required). All build assets and
documentation in CVS/Subversion.
-> This
needs actually that the build process
is documented.
-> Work
estimate one week
- Non-project-team-members should be able to build each
project.
->See above
- Non-project-team-members should be able to run unit tests on each
project.
-> See
above
- Source tarballs should be created for Linux distros to build
with.
-> This we should
do also
-> Work estimate 2
days
- Should have new & noteworthy for each milestone. Should be something
readable and usable not just a static list of all the bugs. Corollary:
individual new & noteworthy should be linked in to the collective New
& Noteworthy.
-> A small task for us. We should collect some
information about the active tasks and put those in some txt
file.
- Projects should use ICU4J.
- Kevin, do you have an opinion for
this?
- Projects should provide build RSS feeds as per the build
workshop.
-> Rather small issue, but this I would not feel to
be the most important now.
- Projects should have a written ramp down policy. (One of the issues
identified with this guideline is that its not so much the ramp down policy of
how many votes are needed for each bug fix that we need to be consistent on,
but rather the meaning of each of the milestones and release candidates. Here
[2] is the Platform 3.2 ramp down policy as a guideline for
other projects.)
-> This needs some more
discussion.
-Arto
Hi,
As many of you are aware of simultaneuos release
cycle of certain projects, I would like to rise a discussion should MTJ be
part of it.
Here is a link to project wiki: http://wiki.eclipse.org/index.php/Europa_Simultaneous_Release.
If we want to be part
of it, there are plenty of requriements for the project. Please, feel free to
comment the topic.
Rauno