CHANGELOG.rst 315.2.3

[snozawa]

(CHANGELOG.rst)

I updated CHANGELOG.rst considering latest hrpsys-base-source
because I'd like to use SampleRobot scripts[1] in hrpsys ROS package example[2].

I created CHANGELOG.rst using [3] script.
I just concatenated hrpsys-base-source git log and hrpsys ros package git log,
so the orders are not sorted by date.

(The orders within hrpsys-base-source are sorted and the orders within hrpsys are also sorted,
but the orders within all hrpsys-base-source and hrpsys git log are not sorted.)

[1] fkanehiro/hrpsys-base#252
[2] #97
[3] #96

[k-okada]

Please update hrpsys-base version first

See fkanehiro/hrpsys-base#231

[k-okada]

#88

[130s]

In general, I would suggest we try to follow the Best Practice for debian/changelog http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog

Adding to that practice I suggest the changelog is for "users", more than it is for developers. I found the well organized changelogs will be highly valuable when you're talking to a group of users (so now I'm trying to be a good changelogger).

If it's too tedious and time taking then I can take this role for hrpsys-related packages.

[k-okada]

If it's too tedious and time taking then I can take this role for
hrpsys-related packages.

Thanks, please do that.

@snozawa, if you have deadline that you want to release new version, please
let him know.

On Mon, Jul 21, 2014 at 8:45 PM, Isaac I.Y. Saito notifications@github.com
wrote:

In general, I would suggest we try to follow the Best Practice for
debian/changelog
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-changelog

Adding to that practice I suggest the changelog is for "users", more than
it is for developers. I found the well organized changelogs will be highly
valuable when you're talking to a group of users (so now I'm trying to be a
good changelogger).

If it's too tedious and time taking then I can take this role for
hrpsys-related packages.

—
Reply to this email directly or view it on GitHub
#99 (comment).

[snozawa]

Sorry for too late reply...

If it's too tedious and time taking then I can take this role for hrpsys-related packages.

Thank you for your suggestion and it would be better to do that.

@snozawa, if you have deadline that you want to release new version, please let him know.

I'd like to use latest hrpsys-base samples in downstream hrpsys package[1],
but currently releasing new version is not hurry for me.
[1] #97

I'd like to know:

• After this, how can I request @130s for releasing new version?
  Creating a new issue at hrpsys repository?
• What do you think about periodic releasing?
  If you can release new version periodically (e.g., once per few week...etc??), I can wait for it.
  If I'm in a hurry, I'll send you the request not waiting for periodic release.

[130s]

@snozawa I made a preq against your fork snozawa#1 as a summary of the current changelog. Hope it looks better. What I did was to put together multiple lines into a single line about same components. If the component wasn't clear I put them at the bottom.

I suggest every new release to be done on a request basis on issue tracker so that people get notified. And the one who update changelog and who make a release don't have to be the same person IMO.

[130s]

And I'm afraid periodic release, while I like the concept, might not work out for various situations (error in up/down stream, release person being too busy etc.). As far as I've seen how ROS maintainers have been trying to enforce it (they planned to sync twice a month but actually it hasn't happened that frequently) it looks not simple.

[snozawa]

@130s ,
I see, I'll create a new issue if I need a new release version instead of periodic release.

I made a preq against your fork snozawa#1

In addition to this PR, could you update hrpsys-base version?
fkanehiro/hrpsys-base#231
https://github.com/start-jsk/hrpsys/pull/88/files

@k-okada
In my understanding, how to update new release version is as follows:

1. Send PR to hrpsys-base asking for set new tag. bump version to 315.2.2 fkanehiro/hrpsys-base#231
2. After 1, set new version hrpsys/Makefile.hrpsys-base. https://github.com/start-jsk/hrpsys/pull/88/files
3. Send PR to update hrpsys/Changelog.rst

Is this correct?

[k-okada]

In my understanding, how to update new release version is as follows:

1. Send PR to hrpsys-base asking for set new tag.
   bump version to 315.2.2 fkanehiro/hrpsys-base#231
   bump version to 315.2.2 fkanehiro/hrpsys-base#231
2. After 1, set new version hrpsys/Makefile.hrpsys-base.
   https://github.com/start-jsk/hrpsys/pull/88/files
3. Send PR to update hrpsys/Changelog.rst

Is this correct?

yes, to be correct

1. send PR to update new tag to hrpsys-base
2. send PR to update makefile.hrpsys-base, changelog, package.xml and
   release

[snozawa]

Thanks, I understood it.

[snozawa]

I close this PR because already this PR is not necessary.

[130s]

I close this PR because already this PR is not necessary.

Why do we not need this PR?

And, release steps for hrpsys is now documented here.

[snozawa]

I think this PR is replaced by your PR (snozawa#1), so we do not need this PR any more.

[130s]

In that case merge that, so that this PReq will automatically get updated.

[130s]

Sorry, I found I've been misunderstanding something in the first place. #99 was NOT for 315.2.2. It IS 315.2.3. Maybe that's why I might have confused @snozawa. 申し訳ありません mOm. I updated the title accordingly.

So anyway, what needs to be done hasn't changed much. Rewriting:

What should happen is 1) I update PReq snozawa#1. Then 2) @snozawa merge snozawa#1, 3) I'll merge #99. Then 4) finally I or someone merge #101.

[130s]

Closing in favor of #102