I have opened bug 419746 to discuss
these issues and make plans to solve them.
- Tag each milestone of b3aggrcon files, and tighten required input
Mickael Istria <mistria@xxxxxxxxxx>
10/06/2013 04:41 AM
Luna M2 repo and packages are ready
On 10/04/2013 07:34 PM, David M Williams wrote:
We just call these "milestones"
... the term "release" we reserve for ... well, releases. :)
FWIW, in our team, we're used to call "release" any labeled build,
and we also use release as a verb, and say things like "let's release
Beta2", which are synonyms for the whole process of building, tagging,
And, no, we do not currently tag milestones
b3aggrcon files ... the reason being is there is a lot of flexibility (i.e.
looseness) in how people have set them up, so you may or may not get the
same results, if you just re-ran it ... depending on current state of the
project repositories it points to. We've discussed requiring a stricter
"input format" but, not there yet.
I've noticed that some b3aggrcon files (even for a release)
contain URL with mutable content, such as composite files with multiple
versions, or a /luna URL whose content get changed on each milestone. Moreover,
such b3aggrcon usually don't set s a specific version for there features.
This kind of p2 site for which content is not stable prevents aggregation
from being reproducible/predictable, which is a major pitfall.
Shouldn't we enforce usage of fully qualified feature and usage of stable
URLs with stable content in .b3aggrcon files instead? If such rules are
set, it would probably be easier to use Gerrit only on org.eclipse.simrel.build
repo, and check all incoming contributions conforms to such rule.
I hope that answer suffices for what
ever purpose or use case you had in mind. If not, feel free to ask
again with more detail.
Yes, this answer is clear, although I expected a tag there.
Anyway, it's not a critical issue for our use-case.
The use-case is that we mirror locally (on jboss.org server) all the p2
sites we depend on. When a new milestone/release gets available, we usually
update our target definition file to get developers and build running against
this recent milestone/release. So for this example of Luna M2: in order
to set up the target platform for Luna M2, I'd like to mirror on download.jboss.org
some p2 sites that were part of this Luna M2 (for some projects, we don't
use directly the simrel repo because it misses some source features; such
sites includes EGit, m2eclipse, TM/RSE, WebTools...). And when it comes
to mirroring the sites that were part of Luna M2, I go to read the b3aggrcon
files for Luna M2 to find the contributed repo URLs and feature versions.
That's where I expected a tag. Since there was none, I did use master.
IMO, although the build is not reproducible because of some not-specific-enough
contributions, tagging it would help in some extent to reproduce it and
to make clearer what was used for the milestone.