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.
Reading the REP, I found myself scrolling often between the
definitions of the files and their examples. Can the examples
maybe go into the same section as their definition?
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?
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 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.
Like Ken, I'd get rid of the whole File Format section.
The gbp-repos item is missing from the examples.
"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.
Will this also affect cturtle to fuerte distributions?
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)
Regarding build file whitelists, can we have a format that allows
to git repo names instead of packages, to avoid duplication?
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?
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?
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?
"A distribution file listing a couple of repositories...". Maybe
that should be "All the repositories involved in the
distribution". UNöess you mean the example.
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?
I'd like the rosdistro distribution files to all have a header
comment stating the purpose of the file and explaining briefly the
syntax, maybe with a reference to the REP. The header should
explain things like how the packages item works in distribition
file, and how to use anything else than git.
A nicer yaml header with the used yaml version also looks like
this:
"%YAML1.1
---"
If we want to use YAML1.1, that is.
cheers,
Thibault
On 23.02.2013 06:36, Paul Mathieu wrote: