[ros-users] REP for rosdistro files

Tue Feb 26 17:37:31 UTC 2013

Hi,

Thank you very much for your feedback.
The draft has been updated accordingly.

https://github.com/po1/rep/blob/rep137/rep-0137.rst

If anything remains unclear, do not hesitate to add remarks to the pull
request here:

https://github.com/ros-infrastructure/rep/pull/27

Cheers,
Paul

On Sat, Feb 23, 2013 at 12:33 PM, Dirk Thomas <dthomas at willowgarage.com>wrote:

> 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
>
>
> ______________________________**_________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/**listinfo/ros-users<https://code.ros.org/mailman/listinfo/ros-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20130226/af00ec5a/attachment-0004.html>