[Ros-release] Catkinization & Bloom

Sun Nov 11 03:38:49 UTC 2012

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. 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.

--

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-release/attachments/20121110/3d76ce9a/attachment-0009.html>