Better story for non-github rosdistro repos

[mikepurvis]

Currently non-github rosdistros throw an "Automated pull request only available via github.com". Perhaps it could offer to simply git push using the vcstools facility?

Would be great for internal/test rosdistros.

[wjwwood]

There is some discussion on this here:

http://answers.ros.org/question/135976/bloom-could-not-resolve-rosdep-key-message_runtime/

I won't likely have anytime to spend on this in the near future. So, I'll say what I said in the above FAQ. If you find a way to improve the bloom-release script for non-github.com rosdistro forks, then I will work with you to get it merged and released.

[mikepurvis]

An obvious starting point here would be to break up open_pull_request, ideally by moving most of that functionality into rosdistro— eg, having a generic method for mutating details of an entry, and then implementations to handle the details of "via local file, generic git, github PR, etc."

Does this seem a reasonable path to pursue?

[wjwwood]

I do not agree that pull request functionality should go into python-rosdistro. However, splitting up open_pull_request and abstracting the pull request part to support different targets is ok.

[mikepurvis]

Would you support moving that functionality somewhere other than python-rosdistro? It would be great to have a set of reusable tools for manipulating rosdistro repos (mutate, merge, diff, import, etc). Would it make sense to build that out elsewhere?

[wjwwood]

You plan on using this separately from bloom? As I see it there are several different tasks:

• Given a rosdistro dict, modify it some how (add repo, change version in repo, change doc entry, etc...)
  • This could be in python-rosdistro, but only operates on a rosdistro locally (in memory).
• Given a source and set of changes make a pull request, or push to a repository, or modify local file system.
  • This is, in my opinion, an abstraction that is completely rosdistro agnostic and shouldn't be part of python-rosdistro.
  • It could be a properly abstracted and reusable module within bloom or in its own repository.
• Combine the other two bullets, in order to automate the process of releasing a package.
  • This should be in bloom, imho.
  • You could have a different version of this that just updates the doc entry, for example, and that could be in bloom as a new command line tool or elsewhere if it is specific to your companies workflow or something.

Also, there's no reason a custom tool or additional service couldn't depend on and use modules from within bloom. I'd only create new packages if depending on bloom becomes a burden.

[mikepurvis]

In general, we're trying to build out some tooling around managing our relationship with upstream— currently we do that at the built-packages level, by pulling in snapshots of OSRF-built debs, but it would be nice to do it at the rosdistro level instead. Obviously we can just pyyaml it up and do this as a one-off, but if there was interest from other parties, we could try to do something more generally useful.

[wjwwood]

Well, I think modification actions can be encapsulated in python-rosdistro (like I mentioned before, add/remove/modify parts of the rosdistro as an API rather than editing yaml directly).

For any actions which automate this stuff or interact with files remote or through processes like pull requests, I'd say a module in bloom unless it is generically useful, in which case a separate Python library.