[ormf-dev] Re: CM: What's on the list?

["Yahya ÖZTÜRK" <yahyaozturk@xxxxxxxxx>]

Hi Achim,

 

I think we should try to define what's needed in this domain. In my opinion (and everyone else's will vary) we need to

 

--I agree with you. I say same thing in my CM report (chapter Risks/Meet Our Requirements). If we can define our requirements we will make a decision about this.

* Use a standard way to build the separate bundles
This must be runnable on the Eclipse foundation build servers and also on local locations. For the foundation's servers we should asked one of the webmasters for advice. For local builds I think an ant script to emulate the Eclipse environment seems best. This way we can integrate nightly builds into nightly test using CruiseControl (or another continuous build tool).

 

-- You are right. I have found this URL, please read it; your words are same in the URL contents. If we will use a build tool for local building, you can find my thoughts in my report (chapter Tool Possibilities).

I have found a plug-in for automated build; it supports server and local building using PDE build. Please see this URL.

In addition we can use Buckminster, I have been progressing about it and I think I understand its structure but it is not easy to use. If we want to use it we must determine all project dependencies like this (http://wiki.eclipse.org/Image:Buckminster_HelloDemo.gif ).

Other possibility is http://www.eclipse.org/proposals/iam/ but I don't have enough information about it but I am going to read something.

And please read this tread.

* Define a deployment scheme (feature, p2, Equinox magic?, ear/war, whatever)
In the end we want others to use ORMF. So there should be some support and guidelines on how to deploy the server and how to install the client.

 

I don't have any idea because i am beginner in ORMF and i don't know what our deployment strategy is.

* Configure nightly builds
Again this is something we should get advice from the foundation. At my company we do a build every time something is committed to the repository. This catches stupid mistakes like forgetting to commit some part of a change set.

 

 

-- I strongly recommended building every time something is committed to the repository because my company does this too and it is very useful approach for standing repository status is buildable all the time.

* Define a process for milestone/integration/final builds
This is the job called "release engineer". The goal is to make sure everything is in place for a release, all targets are met or canceled and integration with other builds (the release train) is finished. One main tasks is to remind everyone of the dates (and the importance) of this milestones.

 

-- I have some idea about this but it is not clear. I will send an e-mail as soon as possible my solution and approach. (Briefly, source controlàBuild toolà Bugzilla integration and it works one-click approach)

Undoubtedly I didn't mention something extremely important! So please everyone: add your opinion.

Achim

P.S.: And again I took the liberty to use a prefix on the subject.