[ros-release] Indigo PreReleases on Trusty
asmodehn at gmail.com
Sat Nov 21 00:40:34 UTC 2015
Just my two cents here, but I found prereleases were definitely needed when
I started to learn how to develop in ROS.
Nowadays however, having setup a private local build farm (one server
building a few packages), I m starting to think there is no much need to
test prerelease, or more accurately that releasing on a private local
buildfarm is a prerelease in itself.
So I m wondering if :
- that is actually true
- we could work towards merging these two ( technically and in docs ) and
have a prerelease process that is roughly :
"Fork rosdistro, Install that ros-indigo-jenkins-modified on your trusty
machine, and release your package into the forked rosdistro"
Which would in fact be the same steps as setting up a local build
Hopefully this could make things simpler and save time both for developers
and maintainers, which would make it more stable in the end.
On Nov 18, 2015 4:07 AM, "Jack O'Quin via ros-release" <
ros-release at lists.ros.org> wrote:
> On Mon, Nov 16, 2015 at 12:39 PM, Tully Foote via ros-release <
> ros-release at lists.ros.org> wrote:
>> Indeed we agree that getting more prereleases run is important. That's
>> why we've worked very hard to make sure that it as well as all the jobs are
> They are not right now, and that is mostly the fault of docker, which is
> Not Ready For Prime Time. The fact that everyone has to install the latest
> docker version coupled with the fact that they release versions with API
> incompatibilities, makes it an inherently unstable base.
>> The web hosted solution has elements which are nice for users. However,
>> it was an expensive pain to maintain. It also provided an inconsistent user
>> experience, especially if there's a large delay due to waiting for yours or
>> others jobs to run. As long as it's reproducible it's better to users
>> leverage their own resources and know reliably when things will run.
> I did not mind the delays much, because I could do other tasks while
> waiting. And, I don't mind using my own resources.
> I do mind the fact that it frequently does not work, because then I have
> to spend my own time troubleshooting the situation. Consequently, I choose
> to focus my testing time on more-productive activities, that seem more
> likely to find actual bugs in my own code.
> I understand that OSRF would prefer not to maintain pre-release jobs on
> the build farm. But, when reasonably-conscientious package maintainers tell
> you it's not currently a good use of our available testing time to fight
> with the new pre-release tools, we can anticipate additional problems to
> ros-release mailing list
> ros-release at lists.ros.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ros-release