<div dir="ltr">The prerelease does more than a normal release build. It not only runs tests for the package in question, but it also builds the packages which depend on your package. If you rarely see a difference in a release job and a prerelease job then you probably are working with a leaf package or one with very few packages which depend on it.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 20, 2015 at 4:40 PM, Asmodehn Shade via ros-release <span dir="ltr"><<a href="mailto:ros-release@lists.ros.org" target="_blank">ros-release@lists.ros.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi all,</p>
<p dir="ltr">Just my two cents here, but I found prereleases were definitely needed when I started to learn how to develop in ROS.</p>
<p dir="ltr">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.</p>
<p dir="ltr">So I m wondering if :<br>
- that is actually true<br>
- we could work towards merging these two ( technically and in docs ) and have a prerelease process that is roughly :<br>
"Fork rosdistro, Install that ros-indigo-jenkins-modified on your trusty machine, and release your package into the forked rosdistro"<br>
Which would in fact be the same steps as setting up a local build farm/server.</p>
<p dir="ltr">Hopefully this could make things simpler and save time both for developers and maintainers, which would make it more stable in the end.</p>
<p dir="ltr">Cheers,<br>
--<br>
AlexV</p>
<div class="gmail_quote"><div><div class="h5">On Nov 18, 2015 4:07 AM, "Jack O'Quin via ros-release" <<a href="mailto:ros-release@lists.ros.org" target="_blank">ros-release@lists.ros.org</a>> wrote:<br type="attribution"></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Nov 16, 2015 at 12:39 PM, Tully Foote via ros-release <span dir="ltr"><<a href="mailto:ros-release@lists.ros.org" target="_blank">ros-release@lists.ros.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>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. </div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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.<br></div></div></blockquote><div><br></div><div>I did not mind the delays much, because I could do other tasks while waiting. And, I don't mind using my own resources.</div><div><br></div><div>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.</div><div><br></div><div>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.  </div></div>-- <br><div> joq</div>
</div></div>
<br></div></div><span class="">_______________________________________________<br>
ros-release mailing list<br>
<a href="mailto:ros-release@lists.ros.org" target="_blank">ros-release@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-release" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-release</a><br>
<br></span></blockquote></div>
<br>_______________________________________________<br>
ros-release mailing list<br>
<a href="mailto:ros-release@lists.ros.org">ros-release@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-release" rel="noreferrer" target="_blank">http://lists.ros.org/mailman/listinfo/ros-release</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">William Woodall<div>ROS Development Team</div><div><a href="mailto:william@osrfoundation.org" target="_blank">william@osrfoundation.org</a></div><div><a href="http://wjwwood.io/" target="_blank">http://wjwwood.io/</a></div></div></div>
</div>