[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Hi all,
the STP-project will be discussing how to restructure their build system:
for each component or subproject they want to have their own build and
automatically generated websites, etc. This will be discussed on the
IRC-channel #eclipse-stp in the near future. I guess it would be a good
opportunity for us to listen and to try to make it similar (okay, we got CVS
and not SVN, but nevertheless). We can probably get a lot of good ideas (and
best practices) how our automatic build should be structured in order to
become integrated in Galileo.
As soon as the date and time has been published on the STP-mailing list,
I'll send a short note, so anyone interested can join the IRC discussion.
Best regards,
Florian
----------------------------------------------------------------------
Message: 1
Date: Wed, 3 Dec 2008 14:22:06 +0000
From: "Oisin Hurley" <oisin.hurley@xxxxxxxxx>
Subject: [stp-dev] Requirements for the build.
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Message-ID:
<e77cb25c0812030622n74ef867ck17d9ca072c805e4c@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
I'd like to open up some discussion on the way we build things right now and
ask for opinions, advice, and eventually, help.
Our build will be changing to accomodate the various SVN changes and now is
the team to think about greater change and flexibility.
The question is, what do you want from it? Cruisecontrol, hudson
build-on-change is very useful, as is a regular full build and test
schedule. Documentation is a must, as is the capability for developers to
build from the command line locally on their own machine. An automatically
generated home page is the norm for other projects too, so something like
that is necessary.
What else? For example, right now the build is just one big blob, wherein
everything gets constructed. I'd suggest that build-per- component and
build-per-project seems to be a better idea. A full roll-up build can be
useful, but follows a different schedule, i.e. it will consume from the
individual builds.
Also, there's platforms - 3.3.2 anyone? Certainly 3.5, that's mandatory, but
maybe people want 3.4.x stream builds too?|
For EID, I would like to have regular 3.4.x, 3.5.x stream builds, with test
and coverage reports, and be able to build on my local machine, outside of
the UI. Consumption then by update site is good. I'd like a separate
download page for EID, linked from a top level STP page, kind of like the
way Modeling does theirs. Also, a list of the dependencies would be very
useful.
Comments? Can we create a plan?
--oh
------------------------------
Message: 2
Date: Wed, 3 Dec 2008 16:00:48 +0100
From: "Antoine Toulme" <antoine@xxxxxxxxxxxxxxx>
Subject: Re: [stp-dev] Requirements for the build.
To: "STP Dev list" <stp-dev@xxxxxxxxxxx>
Message-ID:
<f97124910812030700y34b1b25bq1f0af3633c85a247@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Dec 3, 2008 at 3:22 PM, Oisin Hurley <oisin.hurley@xxxxxxxxx> wrote:
> I'd like to open up some discussion on the way we build things right
> now and ask for opinions, advice, and eventually, help.
>
> Our build will be changing to accomodate the various SVN changes and
> now is the team to think about greater change and flexibility.
>
> The question is, what do you want from it? Cruisecontrol, hudson
> build-on-change is very useful, as is a regular full build and test
> schedule. Documentation is a must, as is the capability for developers
> to build from the command line locally on their own machine. An
> automatically generated home page is the norm for other projects too,
> so something like that is necessary.
I'd be happy to help set up a cruise control system for BPMN and document
that for other components/sub-projects.
>
>
> What else? For example, right now the build is just one big blob,
> wherein everything gets constructed. I'd suggest that build-per-
> component and build-per-project seems to be a better idea. A full
> roll-up build can be useful, but follows a different schedule, i.e. it
> will consume from the individual builds.
I would focus on this first. Have one person per component/sub-project
responsible for the build, and have them have access to the build machine,
and get a quick intro to Buckminster from you. I would suggest to pick a
date and a time, have everybody interested logged into IRC, and start
hacking for an hour. Rinse and repeat until everybody's build works.
>
>
> Also, there's platforms - 3.3.2 anyone? Certainly 3.5, that's
> mandatory, but maybe people want 3.4.x stream builds too?|
The BPMN modeler needs a respin for 3.4.2.
>
>
> For EID, I would like to have regular 3.4.x, 3.5.x stream builds, with
> test and coverage reports, and be able to build on my local machine,
> outside of the UI. Consumption then by update site is good. I'd like a
> separate download page for EID, linked from a top level STP page, kind
> of like the way Modeling does theirs. Also, a list of the dependencies
> would be very useful.
>
> Comments? Can we create a plan?
>
> --oh
> _______________________________________________
> stp-dev mailing list
> stp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/stp-dev
>
--
http://www.lunar-ocean.com/blog
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
https://dev.eclipse.org/mailman/private/stp-dev/attachments/20081203/cde9352
9/attachment.html
------------------------------
_______________________________________________
stp-dev mailing list
stp-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/stp-dev
End of stp-dev Digest, Vol 36, Issue 3
**************************************
