A prerelease which requires changes across more then one package would then not be possible anymore. - Dirk On Mon, Nov 16, 2015 at 11:32 AM, Austin Hendrix via ros-release < ros-release@lists.ros.org> wrote: > For test builds for PRs, why not do the test (deb)build against the stable > repository, instead of shadow-fixed or building? > > It won't catch issues caused by changes in upstream packages, but by > testing against stable you should always have dependencies available (and > it's stable, so the dependencies are less likely to be broken). > > -Austin > > On 11/16/2015 10:39 AM, Tully Foote via ros-release wrote: > >> Hi, >> >> 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. >> >> 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. >> >> For preventing broken releases I do also want to integrate test builds >> into the PR validation. It will more likely be a test debbuild rather than >> a prerelease. And it has trouble if the buildfarm is in the middle of a >> large rebuild and all the dependencies are not immediately available. >> >> Tully >> >> On Sat, Oct 31, 2015 at 5:16 AM, Daniel Stonier > > wrote: >> >> >> Aye, thanks from me too. >> >> I'd like to +1 Jack's comments about preferring the web service >> that was previously available. >> >> 1. Getting things right on one web server somewhere is always >> going to be far easier than getting it right on thousands of users >> systems. Even if docker does make this proposition easier, what we >> have seen above is it still gets awkward when the dependencies >> shift (e.g. needing a custom version of docker). I also ran into >> problems because of python3 interfering with my environment. >> >> 2. Getting users to pre-release is a desirable thing. Less >> rosdistro PR's to approve, less red blips on the build chart, less >> latency for Tully to wrap up an official release into public. The >> less barriers there are for them to do this, I feel the better and >> easier the maintainence will be. >> >> Daniel. >> >> >> On 27 October 2015 at 06:12, Mani Monajjemi via ros-release >> > wrote: >> >> Thanks Tully. pre-release script now works fine without any issue. >> >> - Mani >> >> Mani Monajjemi >> >> On Mon, Oct 26, 2015 at 11:08 AM, Tully Foote via ros-release >> > >> wrote: >> >> I've pushed ros_buildfarm 0.2.1 it should now be usable >> from the debian packages. >> >> Tully >> >> On Mon, Oct 26, 2015 at 10:42 AM, William Woodall via >> ros-release > > wrote: >> >> On Mon, Oct 26, 2015 at 10:09 AM, Jack O'Quin via >> ros-release > > wrote: >> >> >> >> On Mon, Oct 26, 2015 at 11:24 AM, Daniel Stonier >> via ros-release > > wrote: >> >> >> It has been a while since I've built open >> source debs, but this is above and beyond the >> effort required to prerelease for me though. >> It used to be such a fundamental part of the >> process - what is the current thinking? Given >> that its been out for at least three months, >> are most people just guessing, rebuilding on >> the farm, guessing again? Is there a planned >> remedy on the horizon? >> >> >> Basically, yes. >> >> Presently, the pre-release tests take more effort >> than just hoping for the best and then fixing >> things that break. >> >> >> Why? I've been using them for rviz and it seems to >> work fairly well. What's holding up making them >> useful? It is just the need to install it into a >> virtualenv first? >> >> My 2 cents - I'd really love to see this >> working again ;) ;) ;) ;) >> >> >> Again, what's not working? Is there an issue on Github >> tracking the problem? >> >> >> Saves alot of time for me not having to ping >> pong back and forth trying to get my >> dependencies right and I'm sure it makes the >> job easier on the other end avoiding having so >> many red blips on the radar so often. >> >> >> +1 I would find it helpful, too. I much prefer >> running the tests. >> >> The pre-docker web interface was very convenient. >> I think this could be, too, although it's annoying >> that the Trusty version of docker is too old to use. >> >> >> There's nothing to be done about that unfortunately. >> >> -- joq >> >> _______________________________________________ >> ros-release mailing list >> ros-release@lists.ros.org >> >> http://lists.ros.org/mailman/listinfo/ros-release >> >> >> >> >> -- William Woodall >> ROS Development Team >> william@osrfoundation.org >> >> http://wjwwood.io/ >> >> _______________________________________________ >> ros-release mailing list >> ros-release@lists.ros.org >> >> http://lists.ros.org/mailman/listinfo/ros-release >> >> >> >> _______________________________________________ >> ros-release mailing list >> ros-release@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-release >> >> >> >> _______________________________________________ >> ros-release mailing list >> ros-release@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-release >> >> >> >> >> -- Phone : +82-10-5400-3296 >> (010-5400-3296) >> Home: http://snorriheim.dnsdojo.com/ >> Yujin Inno: http://inno.yujinrobot.com/ >> >> >> >> >> >> _______________________________________________ >> ros-release mailing list >> ros-release@lists.ros.org >> http://lists.ros.org/mailman/listinfo/ros-release >> > > _______________________________________________ > ros-release mailing list > ros-release@lists.ros.org > http://lists.ros.org/mailman/listinfo/ros-release >