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 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@code.ros.org > https://code.ros.org/mailman/**listinfo/ros-users >