RE: [cross-project-issues-dev] Best practices on versioning

[Kim Moir <Kim_Moir@xxxxxxxxxx>]

With Doug's initial message, Sonia and
I had a discussion about how a unified build process would work.  We
feel that the new build/update technology proposed for the next release
would make a unified build process easier to implement than it would be
today.   I don't think that it would be reasonable for it to build
all the projects every day.  It would be only useful for integration
builds. Otherwise there would be too much breakage.  There is also
the issue of integrated automated testing.

It takes great deal of  time for
us to adopt to new build technology and we have the added bonus of the
PDE Build developers sitting across the hall from us.  So I understand
your pain with respect to adopting to build changes, especially when you
don't have  dedicated releng people. I wholeheartedly agree that more
collaboration is required between teams on release engineering issues.
  I don't think that any team has the best build scripts, but that
we all have best practices that we can share with each other.   

I agree that if we decide to go ahead
with this,  we should start planning soon.  This will allow any
new functionality to support this endeavor to be included in early project
plans, instead of at the end of the release cycle when there is little
time for new feature work.

Kim

Doug Schaefer <DSchaefer@xxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

04/28/2006 10:44 AM

Please respond to
Cross project issues

To	Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject	RE: [cross-project-issues-dev] Best practices on versioning

Well, you'd probably have to have a "script-off"
to see who has the best
build scripts. Of course we are all happy with the Platforms rock solid
build process. But I think Rich's GMF builds are pretty cool too.

Then the unified releng team would have to adapt those scripts to make
sure
they can build all the projects' bits. Obviously, a criteria for the script-
off would be extensibility.

Then we need to make sure we have enough machine power to do it all.

Then there's the process issues dealing with building such a big blob of
software and making sure the builds remain rock solid. Build breakage will
have a much larger impact that it does today for a lot of the projects.

That's just off the top of my head. But if we are aiming for next year
(we
need a name soon for the thing after Callisto), then I think we have a
lot
of time to work out the issues. Getting it done early, though, gives us
the
time to manage the culture change that would have to happen to make it
successful.

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
 

-----Original Message-----
From: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx] On Behalf Of Ward
Cunningham
Sent: Friday, April 28, 2006 10:29 AM
To: Cross project issues
Subject: Re: [cross-project-issues-dev] Best practices on versioning


Doug Schaefer wrote:

> I would like to propose that we have one release engineering team,
 
> with maybe participants from various projects, working on one  
> single set of build scripts and a single simultaneous build. This
 
> would solve a lot of problems, including the lag we have between  
> Platform build and Callisto release, and it would make it easier  
> for us to line up with "best practices".

Richard Gronback wrote:

> Perhaps this is something we can strive for incorporating into the
 
> next Callisto (whatever it's called), meaning that if you sign up
 
> for Callisto, you're also signing up to participate in (read:  
> contribute to) a unified build?

What would have to happen, and how soon would we have to start, for  
the product of this work to be routine, standard operating practice,  
by next year's train?_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev