Hi all, 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 farm/server. Hopefully this could make things simpler and save time both for developers and maintainers, which would make it more stable in the end. Cheers, -- AlexV On Nov 18, 2015 4:07 AM, "Jack O'Quin via ros-release" < ros-release@lists.ros.org> wrote: > > On Mon, Nov 16, 2015 at 12:39 PM, Tully Foote via ros-release < > ros-release@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 >> reproducible. >> > > 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 > ensue. > -- > joq > > _______________________________________________ > ros-release mailing list > ros-release@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-release > >