The ideal IMO would be to implement this as a macro— so much as the wiki
today displays the manifest.yml information generated from doc jobs, the
wiki of tomorrow could have a macro which sucks in a similarly-extracted
file.

This allows the flexibility to mix and match wiki-editable content where
that is appropriate with blobs of source-controlled content, where *that*
is more appropriate. It also offers a sane migration strategy.

The really, really ideal would be if the "mytutorial1.roswiki" file in my
repo could actually optionally be itself a templated affair, perhaps
supporting a format like mytutorial1.rowiki.em, so that things like blobs
of example source code or whatever could be sucked in from marked-off
sections of actual working examples which can then be tested during the
source build.

On 24 November 2014 at 10:18, Jonathan Bohren <jonathan.bohren@gmail.com>
wrote:

> On Mon Nov 24 2014 at 3:38:46 AM Miquel Massot Campos <
> miquel.massot@gmail.com> wrote:
>
>> In my opinion, maintaining a repo and the documentation in two different
>> sites is a bit confusing. One often makes changes to the repository without
>> remembering how the roswiki entry was done, thus breaking the completeness
>> or correctness of it. As most of us are developing on GitHub, would it make
>> sense to have a document in each of our repositories "
>> *something.roswiki"* so that the documentation generator
>>
> pastes it into the roswiki?
>>
>
> I agree. The wiki is broken, and package documentation should reside in
> the packages wherever the code is hosted.
>
> Unfortunately, as Dirk said, "whatever change you propose must be
> implemented by someone."  So, I'm asking directly:
>
> What resources does OSRF have to re-work the ROS wiki pages for packages
> and tutorials in a way that simply aggregates documentation from package
> source repositories?
>
> -j
>
> _______________________________________________
> ros-users mailing list
> ros-users@lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users
>
>