[ros-users] REP for rosdistro files

[Dirk Thomas]

On 23.02.2013 02:20, Thibault Kruse wrote:
> Hi Paul,
>
> 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
> for migration.

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.
Something like the master file will be ust handcrafted which is due to its small size easy to do.


> 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?

With the concepts of a single entry point the name of the distribution is determined in the master file.
So the distribution files to not need that information anymore.

For the type see your other question below.


> 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?

For release repositories only git is valid.
But for the test repositories we need to store the SCM type.
That was overlooked and will be added to the REP.


> 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.

Yes, we need to add that to the REP as well.


> Like Ken, I'd get rid of the whole File Format section.
>
> The gbp-repos item is missing from the examples.

Since that is only a field for backward compatibility it is only mentioned as such an not part of each example.


> "type: ros-distributions
> type: ros-distribution
> type: ros-build"
>
> Why do we need those tags at all? I don't see who would consume that information.

This is the same as the already existing type field.
It stores the semantic type of the file (previously "gbp", "devel" etc.) as mentioned in the design requirements.
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.


> Will this also affect cturtle to fuerte distributions?

It will affect all distributions which are currently build on the jenkins buildfarm (fuerte+).
Older distributions don't need an update.


> 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
> need to specify the version here? (Because with svntags and branches are encoded in the url)

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.
We will clarify that in the REP.


> Regarding build file whitelists, can we have a format that allows to git repo names instead of packages, to avoid duplication?

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.
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.


> 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
> to a build file for the same distro, if there is any? If there is none, why would we need a second file?

The distribution files for releases and tests are separate for the same reason they are now:
- the repositories are different (gbp vs. source)
- the sets of packages listed are not equal (some are release-only, some are test-only)
The build files for release and tests are separate because commonly they need to specify different targets.


> In your example, I see the master file references multiple build files for different architectures:
> release-build: [releases/groovy-build-ubuntu.yaml, releases/groovy-build-arm.yaml]
> yet then in the build file example, I see multiple architectures mentioned as well:
> targets:
>    oneiric: [amd64, i386]
>    precise: [amd64, i386, armel]
> How does that work together?

Each build file describes a set of packages and targets to be build for.
The list of release build files allow to have different sets/targets and combine them.
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.


> 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.
> what heppanes if there is a platform mentioned in a distribution file but in none of the build files?

The release file determines what gets released - the build file what gets build. Naturally build targets can only be a subset of releases targets.
But is is valid that the release has multiple platform but one specific buildfarm only cares and builds a subset of the targets.


> 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?

For each build on the farm the maintainer gets a notification email about warnings/failures.
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.

We don't see a reason to override that configuration on a per repo/package level.

- Dirk