Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-mtj-dev] Europa Simultaneous Release?

Hi,
 
I think that we have to conclude this time that
1) MTJ will try to try follow practises defined in Europa release train
2) MTJ won't participate Europa release train
 
But while following practises we should be better prepared to
participate to the next release train.
 
mho
 
-------------- Rauno ------------------
I agree with Kevin. We are small project considering the head count and
it would be better to put effort for the product rather than process. As
such the Europa is a great thing but I prefer to be out for now. Being
out doesn't mean we shouldn't try to improve our process and Europa
gives good guidelines so that one day we are ready to it.
 
    Rauno
---------------------------------------------
 
 
----------- Arto -------------------------
Hi!
 
As Kevin pointed out, there may be a lot of  things to do in our next
release and therefore 
all additional work might be too much.
Probably we should keep this in our minds and try to participate to the
'Europa train' after we get the
1.0 release out.
 
-a
 
-----------------------------------------------


________________________________

	From: dsdp-mtj-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Kevin M
Horowitz
	Sent: 07 November, 2006 17:14
	To: Mobile Tools for The Java Platform mailing list
	Subject: RE: [dsdp-mtj-dev] Europa Simultaneous Release?
	
	

	Hi,
	
	I have been thinking about this since the mail went out, and
while I think we should look at all of the required aspects of
participation, and add them to our requirements list (and implement
them), I don't think MTJ is ready to be part of the "Europa" release. We
are just going to hit our 1.0 release, and have a lot to do to hit that.
I think we are better doing the 1.0 release independent of the Europa
train, and then looking to join the next release train with a follow-on.
We have learned a lot over the 0.7 release, but I think we are still
going to be more surprises as we continue. I also think we need to get
more participation from the community before we are ready to part of the
integrated release.
	
	kevin
	-----------------------------
	Kevin Horowitz (khorowit@xxxxxxxxxx)
	IBM Software Group - WPLC
	8051 Congress Ave.
	Boca Raton, Fl 33487
	+1-561-862-2113 (t/l 975)
	
	 <Arto.Laurila@xxxxxxxxx>
	
	
	

				<Arto.Laurila@xxxxxxxxx> 
				Sent by:
dsdp-mtj-dev-bounces@xxxxxxxxxxx 

				11/06/2006 05:32 AM 
	
	Please respond to
Mobile Tools for The Java Platform mailing list
<dsdp-mtj-dev@xxxxxxxxxxx>

 

To

<dsdp-mtj-dev@xxxxxxxxxxx>	


cc

	


Subject

RE: [dsdp-mtj-dev] 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: 

		1. 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)
		2. 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) 
		3. Projects must optimize
<http://wiki.eclipse.org/index.php/Update_Site_Optimization> their
update site using pack200 <http://wiki.eclipse.org/index.php/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 
		4. Projects must use 4-part version numbers.
<http://wiki.eclipse.org/index.php/Version_Numbering>  
		-> Very small issue
		-> Work estimate 1 day 
		5. 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 
		6. Projects must use signed plugins using the Eclipse
certificate. 
		-> This we would need to do
		-> Work estimate 1 week 
		7. Any third-party plug-ins that are common between
projects must be consumed via Orbit <http://www.eclipse.org/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 
		8. 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 
		9. 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?
		10. 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 <mailto:cross-project.inbox@xxxxxxxxxxx>

		-> See above
		11. 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
		12. 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
		
		13. 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: 

		1. 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) 
		2. Projects should use Eclipse message bundles, not Java
bundles because this is a good Eclipse citizenship. (see Message Bundle
Conversion Tool
<http://wiki.eclipse.org/index.php/Message_Bundle_Conversion_Tool>  and 
[1]
<http://www.eclipse.org/eclipse/platform-core/documents/3.1/message_bund
les.html> ) 
		-> We already have this. 
		3. 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 
		4. Non-project-team-members should be able to build each
project. 
		->See above
		5. Non-project-team-members should be able to run unit
tests on each project. 
		-> See above
		6. Source tarballs should be created for Linux distros
to build with. 
		-> This we should do also
		-> Work estimate 2 days 
		7. 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. 
		8. Projects should use ICU4J. 
		- Kevin, do you have an opinion for this?
		9. 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.
		10. 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]
<http://dev.eclipse.org/viewcvs/index.cgi/~checkout~/eclipse-project-hom
e/plans/3_2/freeze_plan_3.2.html>  is the Platform 3.2 ramp down policy
as a guideline for other projects.) 
		-> This needs some more discussion.

	-Arto 

	
________________________________

	From: dsdp-mtj-dev-bounces@xxxxxxxxxxx [
mailto:dsdp-mtj-dev-bounces@xxxxxxxxxxx] 
	Sent: 06 November, 2006 08:57
	To: dsdp-mtj-dev@xxxxxxxxxxx
	Subject: [dsdp-mtj-dev] Europa Simultaneous Release?
	

	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
<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 _______________________________________________
	dsdp-mtj-dev mailing list
	dsdp-mtj-dev@xxxxxxxxxxx
	https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
	

	

GIF image

GIF image


Back to the top