[Ros-release] Catkinization & Bloom

Sun Nov 11 04:57:52 UTC 2012

On 11 November 2012 12:38, William Woodall <wwoodall at willowgarage.com>wrote:

> I agree that the pull request mechanism is over head for us and it puts a
> delay in the developer workflow.  However, with pull requests we can gate
> invalid changes to the yaml file from getting through. If invalid yaml gets
> into the distro file then every job on the build farm will fail.

I suspected this was probably a concern. It makes it a showstopper for any
other method.

> Once we get the rosdistro repo setup on either Jenkins or Travis-ci then
> all pull requests will be automatically run against the unit tests, and
> then we can be relatively certain that nothing invalid will get into the
> rosdistro files.
>
> Once that is setup, we can reduce the overhead for the maintainers and
> increase convenience for developers whom we trust by giving them authority
> to merge pull requests. This way they can still see if the changes they
> made pass the tests, but will not have to wait on someone else to merge the
> changes.  This also allows us to keep relying on the post commit hook to
> trigger jenkins.
>
> It would be nice to have someone else checking these in a different time
> zone, I'll ask about getting you added.
>
>
Awesome.

Regards,
Daniel

--
>
>
> On Fri, Nov 9, 2012 at 11:51 PM, Daniel Stonier <d.stonier at gmail.com>wrote:
>
>>
>>
>>
>> On 10 November 2012 03:06, William Woodall <wwoodall at willowgarage.com>wrote:
>>
>>> Keeping the latest version in the distro file causes a pull
>>> request/merge, which like Lorenz mentioned is hookable, and it allows us to
>>> query the version of a released package at one glance of the rosdistro
>>> file. With a latest keyword, any tools that wanted that information would
>>> have to fetch it from the release repository.
>>
>>
>> There are ways of working around these things. You could just run a
>> single script x times each day to parse and generate a list of versions -
>> use this to compare with the previous list for differences and trigger
>> builds off that. Provide that list to tools who want to know the latest
>> released versions (like those generated at http://www.ros.org/debbuild/).
>>
>> The details are irrelevant though, my main point was with regards to
>> wondering if the human-intensive work of accepting pull requests could be
>> minimised. Now, if you guys are happy to do that, I'm also happy (since a
>> script like rosrelease for fuerte would remove the human intensive work of
>> making the pull requests for users). But I can imagine this will start to
>> generate alot of pull requests and that increases your overhead. Also, if
>> it becomes a burden, it increases latency time between releases for users.
>>
>> If you need more eyes on rosdistro, I'm willing to help in order to cover
>> the asian region.
>>
>> Regards,
>> Daniel.
>>
>>
>>> What I plan to add to bloom is a feature to automatically open a pull
>>> request for you during the release process, but that will likely not land
>>> for a few weeks.
>>>
>>> --
>>>
>>>
>>> On Fri, Nov 9, 2012 at 7:34 AM, Lorenz Mösenlechner <moesenle at in.tum.de>wrote:
>>>
>>>> Hi,
>>>>
>>>> I guess one reason for using pull requests on a single repo was that
>>>> the package build can be triggered by some github hook. By just
>>>> pointing to latest or really just using the release repo, this would
>>>> become much more complicated and expensive since the system either
>>>> needed to subscribe to all repose which would only be possible if they
>>>> are hosted on github, or the system needed to continuously monitor
>>>> many repos.
>>>>
>>>> Lorenz
>>>>
>>>> On Fri, Nov 9, 2012 at 4:29 PM, Daniel Stonier <d.stonier at gmail.com>
>>>> wrote:
>>>> >
>>>> > On Nov 9, 2012 9:05 PM, "Daniel Stonier" <d.stonier at gmail.com> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On 9 November 2012 20:11, Armin Hornung
>>>> >> <HornungA at informatik.uni-freiburg.de> wrote:
>>>> >>>
>>>> >>> On 2012-11-09 12:05, Daniel Stonier wrote:
>>>> >>>>
>>>> >>>> Hi,
>>>> >>>>
>>>> >>>> I'm trying catkinization & bloom for the first time on a very
>>>> simple
>>>> >>>> msg/srv package (zeroconf_comms) which is having trouble building
>>>> the source
>>>> >>>> debian on jenkins.
>>>> >>>>
>>>> >>>> It is not looking for the correct tag, in particular, it's not
>>>> looking
>>>> >>>> for the increment number that is postfixed to the version number
>>>> for the
>>>> >>>> package.
>>>> >>>
>>>> >>>
>>>> >>> Afaik the rosdistro file tells the build job which version to check
>>>> out,
>>>> >>> it needs to exactly match the tagged one you released:
>>>> >>> https://github.com/ros/rosdistro/blob/master/releases/groovy.yaml
>>>> >>>
>>>> >>> It appears to be 0.1.7 where it should be 0.1.7-0. The
>>>> debian-increment
>>>> >>> number now always gets added, and is 0 by default.
>>>> >>>
>>>> >>
>>>> >> Damn, I thought I checked that - I must have looked up fuerte's file
>>>> at
>>>> >> the time.
>>>> >>
>>>> >> I wonder. This process could generate alot of pull requests and work
>>>> on
>>>> >> both ends (developers and the rosdistro maintainers). Most of the
>>>> time,
>>>> >> simply the highest version number is the valid choice. As an
>>>> alternative to
>>>> >> specifying the exact version, would specifying the keyword 'latest'
>>>> and
>>>> >> automating the selection process be useful (assuming people follow
>>>> the x.y.z
>>>> >> pattern)?
>>>> >>
>>>> >
>>>> > You could even put version pointers in the bloom generated
>>>> xxx-release repo
>>>> > instead.
>>>> >
>>>> >>>
>>>> >>> I usually directly edit the file at github to adjust the version
>>>> numbers,
>>>> >>> that will create a patch and pull request automatically - neat!
>>>> >>>
>>>> >>
>>>> >> Thats awesome! I didn't know about that feature.
>>>> >>
>>>> >> Regards,
>>>> >> Daniel.
>>>> >>
>>>> >>>
>>>> >>> Best,
>>>> >>> Armin
>>>> >>>
>>>> >>
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > Ros-release mailing list
>>>> > Ros-release at code.ros.org
>>>> > https://code.ros.org/mailman/listinfo/ros-release
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Lorenz Mösenlechner            | moesenle at in.tum.de
>>>> Technische Universität München | Karlstraße 45
>>>> 80335 München                  | Germany
>>>> http://ias.cs.tum.edu/         | Tel: +49 (89) 289-26910
>>>> _______________________________________________
>>>> Ros-release mailing list
>>>> Ros-release at code.ros.org
>>>> https://code.ros.org/mailman/listinfo/ros-release
>>>>
>>>
>>>
>>>
>>> --
>>> William Woodall
>>> Willow Garage - Software Engineer
>>> wwoodall at willowgarage.com
>>>
>>>
>>> _______________________________________________
>>> Ros-release mailing list
>>> Ros-release at code.ros.org
>>> https://code.ros.org/mailman/listinfo/ros-release
>>>
>>>
>>
>>
>> --
>> Phone : +82-10-5400-3296 (010-5400-3296)
>> Home: http://snorriheim.dnsdojo.com/
>> Yujin R&D: http://rnd.yujinrobot.com/
>>
>>
>>
>> _______________________________________________
>> Ros-release mailing list
>> Ros-release at code.ros.org
>> https://code.ros.org/mailman/listinfo/ros-release
>>
>>
>
>
> --
> William Woodall
> Willow Garage - Software Engineer
> wwoodall at willowgarage.com
>
>

-- 
Phone : +82-10-5400-3296 (010-5400-3296)
Home: http://snorriheim.dnsdojo.com/
Yujin R&D: http://rnd.yujinrobot.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20121111/5a894a49/attachment-0009.html>