On 11 November 2012 12:38, William Woodall 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 wrote: > >> >> >> >> On 10 November 2012 03:06, William Woodall 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 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 >>>> wrote: >>>> > >>>> > On Nov 9, 2012 9:05 PM, "Daniel Stonier" wrote: >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> On 9 November 2012 20:11, Armin Hornung >>>> >> 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@code.ros.org >>>> > https://code.ros.org/mailman/listinfo/ros-release >>>> > >>>> >>>> >>>> >>>> -- >>>> Lorenz Mösenlechner | moesenle@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@code.ros.org >>>> https://code.ros.org/mailman/listinfo/ros-release >>>> >>> >>> >>> >>> -- >>> William Woodall >>> Willow Garage - Software Engineer >>> wwoodall@willowgarage.com >>> >>> >>> _______________________________________________ >>> Ros-release mailing list >>> Ros-release@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@code.ros.org >> https://code.ros.org/mailman/listinfo/ros-release >> >> > > > -- > William Woodall > Willow Garage - Software Engineer > wwoodall@willowgarage.com > > -- Phone : +82-10-5400-3296 (010-5400-3296) Home: http://snorriheim.dnsdojo.com/ Yujin R&D: http://rnd.yujinrobot.com/