[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Should another criteria to be "LTS ready" be "Be part of the yearly
Simultaneous Release"?
It seems many of the presentations about LTS sort of assume it, but it is
not stated.
I doubt there is any technical reason this is literally required but it
would sure make thing easier! If not actually required, probably need at
least some reference to it; such as "Be part of the yearly Simultaneous
Release (or, clearly compatible with it)".
Just a suggestion.
From: David M Williams/Raleigh/IBM@IBMUS
To: Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>,
Date: 01/11/2012 05:21 PM
Subject: Re: [cbi-dev] LTS-ready
Sent by: cbi-dev-bounces@xxxxxxxxxxx
> "is easily reproducible on suitably-configured systems"?
I like this ... and not just for LTS, but also for CBI.
That is, I did want to make sure to mention at some point, that, IMHO, a
good "CBI" system should be able to run "on a suitably-configured system".
I know this might mean, if not running on eclipse build system, that some
things might not work exactly the same ... such as signing ... but, that's
the point ... it'd be nice if the build would "keep working" (and/or some
functions be "pluggable"). The use case I have in mind comes from WTP ...
we have our "official" builds at build.eclipse.org, that are signed, map
files tagged, etc., but often run "local" builds while experimenting with
things ... these "local" builds are not signed, map files are not tagged,
etc., but otherwise it "works the same" as the system on build.eclipse.org.
That gives us good assurance that once the experimenting is finished that
things will still work on build.eclipse.org. Maybe this requirement is
obvious or implied by others ... just thought I'd mention it explicitly.
For LTS itself, eventually it might help to define or describe some things
more, such as "Is deterministic". I'm sure we all know what that means
intuitively ... but (obviously) there are times if a pre-req for a LTS
project changes (or, perhaps even if the source p2 repository changes) then
the build result of that LTS project might change even though the the
project itself didn't change. I'm thinking of this more in terms of
"offering advice" to projects to make sure they are deterministic, rather
than simply stating that they must be deterministic. (For example,
"included" features be included at an exact version level, rather than a
version range). But, other than that one thing, I'm not sure what else to
say about how to make a build deterministic.
For LTS itself, I'm not sure how important or feasible it is that "Can be
cloned/checked out with one step". Or, maybe I simply do not know what you
mean by that. I know for WTP ... we do "check out" one thing in one ant
step, but then what we check out there tells us what else to check in the
next step ... all automated, all deterministic. So is that's two steps?
Or, is two things of one step each? :) Not to mention PDE build itself
continues to get/checkout/p2-pull scores of things as the build
progresses ... in what I would consider many steps. But, maybe you mean
something else.
But, it is good to see the list ... you are off to a good start.
From: Andrew Overholt <overholt@xxxxxxxxxx>
To: Common-build Developers discussion <cbi-dev@xxxxxxxxxxx>,
Date: 01/11/2012 04:36 PM
Subject: Re: [cbi-dev] LTS-ready
Sent by: cbi-dev-bounces@xxxxxxxxxxx
Hi,
* Andrew Ross <andrew.ross@xxxxxxxxxxx> [2012-01-11 16:09]:
>
> - A build that:
Do you want to add something like "is easily reproducible on
suitably-configured systems"?
Andrew
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
_______________________________________________
cbi-dev mailing list
cbi-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cbi-dev
