Re: [ros-release] Indigo PreReleases on Trusty

Top Page
Attachments:
Message as email
+ (text/plain)
+ (text/html)
+ (text/plain)
Delete this message
Reply to this message
Author: Dirk Thomas
Date:  
To: Austin Hendrix, The ROS release mailing list
Subject: Re: [ros-release] Indigo PreReleases on Trusty
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 <
> 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 <
>> <mailto:d.stonier@gmail.com>> 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
>>     < <mailto:ros-release@lists.ros.org>> 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
>>         < <mailto:ros-release@lists.ros.org>>
>>         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 <
>>             <mailto:ros-release@lists.ros.org>> wrote:

>>
>>                 On Mon, Oct 26, 2015 at 10:09 AM, Jack O'Quin via
>>                 ros-release <
>>                 <mailto:ros-release@lists.ros.org>> wrote:

>>
>>
>>
>>                     On Mon, Oct 26, 2015 at 11:24 AM, Daniel Stonier
>>                     via ros-release <
>>                     <mailto:ros-release@lists.ros.org>> 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
>>                     
>>                     <mailto:ros-release@lists.ros.org>
>>                     http://lists.ros.org/mailman/listinfo/ros-release

>>
>>
>>
>>
>>                 --                 William Woodall
>>                 ROS Development Team
>>                 
>>                 <mailto:william@osrfoundation.org>
>>                 http://wjwwood.io/

>>
>>                 _______________________________________________
>>                 ros-release mailing list
>>                 
>>                 <mailto:ros-release@lists.ros.org>
>>                 http://lists.ros.org/mailman/listinfo/ros-release

>>
>>
>>
>>             _______________________________________________
>>             ros-release mailing list
>>              <mailto:ros-release@lists.ros.org>
>>             http://lists.ros.org/mailman/listinfo/ros-release

>>
>>
>>
>>         _______________________________________________
>>         ros-release mailing list
>>          <mailto:ros-release@lists.ros.org>
>>         http://lists.ros.org/mailman/listinfo/ros-release

>>
>>
>>
>>
>>     --     Phone : +82-10-5400-3296 <tel:%2B82-10-5400-3296>
>> (010-5400-3296)
>>     Home: http://snorriheim.dnsdojo.com/
>>     Yujin Inno: http://inno.yujinrobot.com/
>>     <http://rnd.yujinrobot.com/>

>>
>>
>>
>>
>> _______________________________________________
>> ros-release mailing list
>>
>> http://lists.ros.org/mailman/listinfo/ros-release
>>
>
> _______________________________________________
> ros-release mailing list
>
> http://lists.ros.org/mailman/listinfo/ros-release
>

_______________________________________________
ros-release mailing list

http://lists.ros.org/mailman/listinfo/ros-release