Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] The future of Orbit Builds?

Hi, David,

I agree wholeheartedly with starting a new feature for Io.  I suppose that, if any existing bundles need updating, they would just be added "on demand."

Perhaps we could institute a "rolling" build feature.  Committers list their bundles in this feature only for as long as they need it to build on a semi-regular basis.  Once the bundle is stable, it can be removed from the feature and just sit on the download site in its last-built state.  I suppose this would imply more sophisticated tracking of what versions of what bundles are available on the download site, and might obsolete the all-in-one ZIP (which, IMO, never really made sense anyway).

What do you think?

Christian


On Thu, 2008-06-12 at 20:19 -0400, David M Williams wrote:

Let's be optimistic, and say we are done for the Ganymede time frame :)
And indeed I have moved CC back to "I-builds",
but before we do too much new work, I wanted to raise a few questions on how to best proceed.

My first thought was to wonder if we should do new work, with a new feature.xml (and map file) and to not continuously re-build the 186 bundles we currently have.
I suspect most of them are pretty much "done". I recall in the past that while we had good versions, we knew there would be changes coming associated with source attachments, etc.
so it was not that much of a stretch to think of re-building all of them all, even though they were not changing much. While I am sure we will find exceptions and want to rebuild some of them where we find errors or improvements to make, it sort of goes again my "efficient programmer" nature to keep rebuilding hundreds of bundles which are not changing. For those wondering, ... our current Orbit builds take "just" an hour or so to run ... but  sometimes we want to do several per day, sometimes in quick succession, and then you also have all the duplicate storage, etc., so in general doesn't seem like a good practice to rebuild hundreds when only a few have changed (and, one of the objectives of Orbit was to demonstrate best practices :)

My second thought, was to wonder if there is some P2 magic (the "it-just-works provisioning platform") that would allow some better conceptualization to drive the build, instead of a "feature". Any volunteers to educate us and/or create a P2'd build?

I bring this up now, to ask this Orbit-dev list if we should have a short "moratorium" on new builds for a week or so, until we get this settled? Or, if it seems like it will take a long time to settle, and we should just keep moving and sort it out as we go? As once concrete example, if we were going to start with a "fresh" feature.xml file (and a new map file) for new work, then I'd like to leave the current one just as it is (or, was, for our Ganymede R-build) just to have a clear dividing point.

Any one else had enough time yet to have thoughts of Orbit's future?


_______________________________________________
orbit-dev mailing list
orbit-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/orbit-dev


Christian W. Damus
Senior Software Developer, Zeligsoft Inc.
Component Lead, Eclipse MDT OCL and EMF-QTV

Back to the top