<div dir="ltr">Hi,<div><br></div><div style>Thank you very much for your feedback.</div><div style>The draft has been updated accordingly.</div><div style><br></div><div style><a href="https://github.com/po1/rep/blob/rep137/rep-0137.rst">https://github.com/po1/rep/blob/rep137/rep-0137.rst</a><br>

</div><div style><br></div><div style>If anything remains unclear, do not hesitate to add remarks to the pull request here:</div><div style><br></div><div style><a href="https://github.com/ros-infrastructure/rep/pull/27">https://github.com/ros-infrastructure/rep/pull/27</a><br>

</div><div style><br></div><div style>Cheers,</div><div style>Paul</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Feb 23, 2013 at 12:33 PM, Dirk Thomas <span dir="ltr"><<a href="mailto:dthomas@willowgarage.com" target="_blank">dthomas@willowgarage.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 23.02.2013 02:20, Thibault Kruse wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Paul,<br>
<br>
can the REP please explain a bit the differences to the current rosdistro files? Also whether the current format can be automatically transformed into the new format, or what actions would be required<br>
for migration.<br>
</blockquote>
<br></div>
The information contained in the existing files can be transformed to the new files with simply reading the existing yaml file and writing the new structure.<br>
Something like the master file will be ust handcrafted which is due to its small size easy to do.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently distribution files have an item release-name and type, e.g. (fuerte + gbp), (fuerte + devel). Did that information move to the master file, or are the types not used anymore?<br>
</blockquote>
<br></div>
With the concepts of a single entry point the name of the distribution is determined in the master file.<br>
So the distribution files to not need that information anymore.<br>
<br>
For the type see your other question below.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently items in the fuerte distribution files list the repository SCM type, why is that missing now? I could live with git being the default, but why restrict ourselves to git?<br>
</blockquote>
<br></div>
For release repositories only git is valid.<br>
But for the test repositories we need to store the SCM type.<br>
That was overlooked and will be added to the REP.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the affected tools, it would be good to state in one or two sentences how these tools need changing. I miss rosdoc / rosdoc-lite there.<br>
</blockquote>
<br></div>
Yes, we need to add that to the REP as well.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Like Ken, I'd get rid of the whole File Format section.<br>
<br>
The gbp-repos item is missing from the examples.<br>
</blockquote>
<br></div>
Since that is only a field for backward compatibility it is only mentioned as such an not part of each example.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
"type: ros-distributions<br>
type: ros-distribution<br>
type: ros-build"<br>
<br>
Why do we need those tags at all? I don't see who would consume that information.<br>
</blockquote>
<br></div>
This is the same as the already existing type field.<br>
It stores the semantic type of the file (previously "gbp", "devel" etc.) as mentioned in the design requirements.<br>
It is used to verify that the appropriate parser is used to read the various yaml files and enables to check for compliance with the spec.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Will this also affect cturtle to fuerte distributions?<br>
</blockquote>
<br></div>
It will affect all distributions which are currently build on the jenkins buildfarm (fuerte+).<br>
Older distributions don't need an update.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In the Distribution file: "version: version number packages will be released for". Am I right that this also has to be a tag or branch in git? If so, state it. Also if we still support svn, do we also<br>
need to specify the version here? (Because with svntags and branches are encoded in the url)<br>
</blockquote>
<br></div>
Version can be a tag, branch or hash for git, hg etc. For SVN the tag/branch is encoded in the URL and the version would be optional to specify a revision.<br>
We will clarify that in the REP.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding build file whitelists, can we have a format that allows to git repo names instead of packages, to avoid duplication?<br>
</blockquote>
<br></div>
No, since the namespace of repositories and packages collides we would have no way to determine if a name is a repo or a package.<br>
Also the repository is only used to simplify the specification for multiple packages - the build files do not care in which repo a package is and don't require an update if that mapping changes.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Why are test-build and release build defined in different files, how does that help preventing missing release files in the tests? Can you also give the example of a test file to show the differences<br>
to a build file for the same distro, if there is any? If there is none, why would we need a second file?<br>
</blockquote>
<br></div>
The distribution files for releases and tests are separate for the same reason they are now:<br>
- the repositories are different (gbp vs. source)<br>
- the sets of packages listed are not equal (some are release-only, some are test-only)<br>
The build files for release and tests are separate because commonly they need to specify different targets.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In your example, I see the master file references multiple build files for different architectures:<br>
release-build: [releases/groovy-build-ubuntu.<u></u>yaml, releases/groovy-build-arm.<u></u>yaml]<br>
yet then in the build file example, I see multiple architectures mentioned as well:<br>
targets:<br>
   oneiric: [amd64, i386]<br>
   precise: [amd64, i386, armel]<br>
How does that work together?<br>
</blockquote>
<br></div>
Each build file describes a set of packages and targets to be build for.<br>
The list of release build files allow to have different sets/targets and combine them.<br>
The packages with their target must not overlap - in the examples it is not intended to use the different file together - the example only show examples for each individual file.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Also, the relationship between the target item in the distribution file and in the respective build and test files seems a bit clumsy. What happens to the architectures in the distribution file, e.g.<br>
what heppanes if there is a platform mentioned in a distribution file but in none of the build files?<br>
</blockquote>
<br></div>
The release file determines what gets released - the build file what gets build. Naturally build targets can only be a subset of releases targets.<br>
But is is valid that the release has multiple platform but one specific buildfarm only cares and builds a subset of the targets.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can the REP please explain a bit more how notification of maintainers works, and why we need this and the feature to disable it? E.g. why can this not be selected per repository?<br>
</blockquote>
<br></div>
For each build on the farm the maintainer gets a notification email about warnings/failures.<br>
This flag allows to disable that for specific builds, i.e. when starting to build armel we don't want all maintainers to be notified until we reach a certain "stable" level.<br>
<br>
We don't see a reason to override that configuration on a per repo/package level.<span class="HOEnZb"><font color="#888888"><br>
<br>
- Dirk</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/<u></u>listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div>