Planning patch release this week for rqt_common_plugins

[Isaac Isao Saito]

rqt plugin developers,

for rqt_common_plugins, I'm thinking to release a new patch version on
Friday, primarily because of the issue on buildfarm that needs a new
release [0].
If you're making changes and planning to commit soon, please let me
know so that we can put altogether.

[0] https://github.com/ros-visualization/rqt_common_plugins/issues/104

--Isaac

[Aaron Blasdel]

I'm looking into https://github.com/ros-visualization/rqt_common_plugins/issues/31

and if I finish quickly https://github.com/ros-visualization/rqt_common_plugins/issues/68

Contact me before releasing

--Isaac

--
--
To unsubscribe from this group, send email to ros-sig-rqt...@googlegroups.com
Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
rqt: http://ros.org/wiki/rqt

[Aaron Blasdel]

before releasing any new versions please merge pull 112 and 113 to fix issue #31.

It looks like #68 might be a bit more work to figure out. I am going to open a ticket on qt since strange rendering seems to show up on rviz as well in some places.

So feel free to release (both hydro/groovy) after those merges are done

[Dirk Thomas]

Please hold off from a release of the pluging packages for now.
The failing buildfarm test is only an (annoying) detail but not worth a new release.

I think we need more structure for the rqt development for the next weeks.
Hydro is only two and a half weeks away and the focus should be on fixing bugs and significant issues first and as soon as possible.

Please try to spend time on reproducing filled tickets, adding information to the tickets if necessary/helpful and than propose fixes via pull requests.

It should be possible for every addressed ticket to either:
* be able to reproduce the issue, apply a pull request and confirm that the issue is fixed/improved by this.
This should than be verified by a second person (and I mean including the reproduce, apply, validate steps and not only visual inspection of the diff)
or
* be able to reproduce that the issue is not valid anymore or that the ticket does not contain enough information to reproduce the problem.
Than the person filled the ticket should be asked to provide more details to enable reproducing the problem.

I will try to coordinate the incoming pull request and do the next releases when significant fixes have been merged.

Thank you,
- Dirk

> To unsubscribe from this group, send email to ros-sig-rqt...@googlegroups.com <mailto:ros-sig-rqt%2Bunsu...@googlegroups.com>

[Aaron Blasdel]

This seems like a good idea. Currently there are a few new bugs that are not on milestones.

Unless anyone minds I will add any "non-minor" bugs to the hydro release milestone and bump any on the hydro-beta that are not fixed to hydro release.

Aaron

        To unsubscribe from this group, send email to ros-sig-rqt+unsubscribe@googlegroups.com <mailto:ros-sig-rqt%2Bunsu...@googlegroups.com>

        Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
        rqt: http://ros.org/wiki/rqt




--
--

To unsubscribe from this group, send email to ros-sig-rqt+unsubscribe@googlegroups.com

Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
rqt: http://ros.org/wiki/rqt

--
--
To unsubscribe from this group, send email to ros-sig-rqt+unsubscribe@googlegroups.com

[Isaac Isao Saito]

Thanks for plotting out the strategy Dirk. I'll try to follow that.
I talked to Aaron too and just agreed that (we/)I need to spend time
on closing open tickets, as well as becoming more responsive to the
issues reported as bugs.

My time is limited due to my main work, and if I have to leave open
some tickets I'm assigned to (, most of which I did by myself), I'll
unassigin myself with adding more info as possible.

Isaac

>>> ros-sig-rqt...@googlegroups.com

>>> <mailto:ros-sig-rqt%2Bunsu...@googlegroups.com>
>>>
>>> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
>>> rqt: http://ros.org/wiki/rqt
>>>
>>>
>>>
>>>
>>> --
>>> --
>>> To unsubscribe from this group, send email to

>>> ros-sig-rqt...@googlegroups.com

>>> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
>>> rqt: http://ros.org/wiki/rqt
>>>
>>>
>>
>> --
>> --
>> To unsubscribe from this group, send email to

>> ros-sig-rqt...@googlegroups.com

>> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
>> rqt: http://ros.org/wiki/rqt
>
>
> --
> --
> To unsubscribe from this group, send email to

> ros-sig-rqt...@googlegroups.com

[Isaac Isao Saito]

rqt SIG,

regarding Hydro milestone on rqt plugin repositories (which I
originally set), unfortunately I haven't been and won't be able to
spend enough time to fix issues assigned to me.

For the issues set Hydro MS, I'd suggest to move them to untargeted if
they were reported by me (meaning, might not be harmful to users),
unless there has been users who showed interest on each issue ticket.
That way Hydro issues assigned to me will become only a few that I've
already started taking care of.

Sorry for the short notice. Let me know how this sounds.

Isaac

[Aaron Blasdel]

Since I don't think we can push back the milestone anymore this seems to be a good idea to me. 

I think it is best to make a statement on the issue that it will not get done for hydro release due to lack of developer time and set it to untargeted. This will allow people to respond to the change if they think it it is an error. Also for all the issues you haven't already started taking care of please unassigned yourself from them so we can get a better idea of what you are working on. 

Aaron

[Dirk Thomas]

First, please do NOT assign ticket to yourself (or others) if you are not actively working on them.
An eassigned issue creates the impression that this person is actually working on it.
Unassigned issues can be "taken" by anyone to work on them and propose a pull request to fix the issue.

Second, the milestone represents a kind of how urgent something is or when to expect a fix / implementation.
If it was previously set to target Hydro (which means important to fix for the release) it should not just be changed to "untargeted" since that implies we don't expect to spend time on this issue
anytime in the near future.

I will make a release of the common and robot plugins before the Hydro release.
Until then *and of course also afterwards) any fix is highly welcome.

- Dirk

On 26.08.2013 06:28, Aaron Blasdel wrote:
> Since I don't think we can push back the milestone anymore this seems to be a good idea to me.
>
> I think it is best to make a statement on the issue that it will not get done for hydro release due to lack of developer time and set it to untargeted. This will allow people to respond to the change
> if they think it it is an error. Also for all the issues you haven't already started taking care of please unassigned yourself from them so we can get a better idea of what you are working on.
>
> Aaron
>

[Aaron Blasdel]

First, please do NOT assign ticket to yourself (or others) if you are not actively working on them.
An eassigned issue creates the impression that this person is actually working on it.
Unassigned issues can be "taken" by anyone to work on them and propose a pull request to fix the issue.

+1!

 

Second, the milestone represents a kind of how urgent something is or when to expect a fix / implementation.
If it was previously set to target Hydro (which means important to fix for the release) it should not just be changed to "untargeted" since that implies we don't expect to spend time on this issue anytime in the near future.

Perhaps we should create an igloo-beta and/or igloo-release milestone for things of this nature? 

Thanks for taking the lead on the release dirk!

Aaron

[William Woodall]

indigo-build and indigo-release

 

Thanks for taking the lead on the release dirk!

Aaron

--

--
To unsubscribe from this group, send email to ros-sig-rqt...@googlegroups.com
Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
rqt: http://ros.org/wiki/rqt

--
William Woodall

ROS Development Team

wil...@osrfoundation.org

http://williamjwoodall.com/

[Dirk Thomas]

Igloo is about 9 month in the future.
We should not create milestones for that yet.
Neither igloo-beta nor igloo-release has any meaning regarding urgency.
Basically it would just state "might be fixed in nine month" which is pretty much worthless.

- Dirk

[Aaron Blasdel]

We will need some place to put tickets that are urgent once we close the hydro-release milestone though. 

Maybe we should create a non release specific milestone to place things that are urgent/important but not slated for fixing by the next milestone.

Perhaps "unassigned-urgent"?

At the moment all we have is a "we don't care about this" milestone and a "next release". It seems whatever we do we need more than than have now to keep the urgency info we want to capture.

Aaron

--
--
To unsubscribe from this group, send email to ros-sig-rqt+unsubscribe@googlegroups.com

[Isaac Isao Saito]

Thanks all for the lead. I've noticed that I'm already unassigned from
issues that I'm not working on. I also added a note to an issue that I
started but stuck at.

Replying inline,

On Tue, Aug 27, 2013 at 2:15 AM, Dirk Thomas <dth...@osrfoundation.org> wrote:
> :

> Second, the milestone represents a kind of how urgent something is or when
> to expect a fix / implementation.
> If it was previously set to target Hydro (which means important to fix for
> the release) it should not just be changed to "untargeted" since that
> implies we don't expect to spend time on this issue anytime in the near future.

At least for the issues I targeted Hydro, it still makes sense to me
to set forward to untargeted (or any MS that comes earlier than Igloo
as proposed); those were just my motivation at the time and I didn't
mean they were critical to next ROS distro (now I know MS should not
be used like that. Sorry...I didn't expect some of you to start
intensively fixing issues toward Hydro MS).

Isaac

>> ros-sig-rqt...@googlegroups.com

>> Google group at http://groups.google.com/group/ros-sig-rqt?hl=en
>> rqt: http://ros.org/wiki/rqt
>
>

> --
> --
> To unsubscribe from this group, send email to

> ros-sig-rqt...@googlegroups.com

[Aaron Blasdel]

I agree with Isaac on the criticality point. Some of the things I set to hydro release I did so just because I mistakenly thought we were going to have enough time to get to it. Not because they were urgent. 

I think urgency needs to be indicated in another way than which milestone they are assigned to. I added the "major bug" distinction to indicate they were more important. Perhaps we should create an entire set of urgency labels for tracking this?

Nailing down how we  use the label would be good if we work out a new set. 
Aaron