Mickael and others, I have opened bug 419746 to discuss these issues and make plans to solve them. Bug 419746 - Tag each milestone of b3aggrcon files, and tighten required input
Thanks, From: Mickael Istria <[email protected]> To: [email protected], Date: 10/06/2013 04:41 AM Subject: Re: [cross-project-issues-dev] Luna M2 repo and packages are ready Sent by: [email protected] On 10/04/2013 07:34 PM, David M Williams wrote: We just call these "milestones" ... the term "release" we reserve for ... well, releases. :) OK. 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, publishing, blogging.... 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. Cheers, -- Mickael Istria Eclipse developer at JBoss, by Red Hat My blog - My Tweets_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
