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:
> Hi everybody,
>
> Here is a tentative REP-137 draft, which gives a rationale and a
> specification for rosdistro files, with the intent of formalizing what
> was not.
> These files are used by the release process as well as the buildfarm.
> The mid-term goal is to ease binary package builds, especially by
> custom buildfarms.
>
> You can find this draft REP here:
>
> https://github.com/po1/rep/blob/rep137/rep-0137.rst
>
> And the pull request is here:
>
> https://github.com/ros-infrastructure/rep/pull/27
>
> Please note that the REP still lacks some tiny bits here and there.
> Any good will is more than welcome to contribute.
>
> Thanks,
>
> --
> Paul Mathieu
>
>
> _______________________________________________
> ros-users mailing list
> ros-users@code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
(text/plain)