[Rock-dev] GitHub migration - status and next steps.

[Sylvain Joyeux]

Current State
-------------------
I've migrated rock.base and rock.toolchain to github, integrating them into
a 'rock.core' package set, adding as some other "core" packages.

I've updated the build configuration and package sets, and put the updated
configurations on github as well in order to not disrupt the current
installations "until it is ready"

It means, in practice, that one can bootstrap a github-based build using
http://github.com/rock-core/buildconf

and https://github.com/rock-core/buildconf/raw/master/bootstrap.sh

What is left to be done
-----------------------
- one question: should not we split the rock package set into subprojects
as well (for me, it is +1, it would make more sense from a management point
of view to have a package and its package set in the same organization)
- one thing to do: re-create the rock.base and rock.toolchain metapackages
in rock.core to ensure smooth migration from the existing buildconfs
- testing
- update the gitorious package sets (that everyone is currently using) to
auto-import rock-core and the github-based rock package set.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140530/77a6331f/attachment.htm

[Javier Hidalgo Carrió]

Post by Sylvain Joyeux
Current State
-------------------
I've migrated rock.base and rock.toolchain to github, integrating them
into a 'rock.core' package set, adding as some other "core" packages.
I've updated the build configuration and package sets, and put the
updated configurations on github as well in order to not disrupt the
current installations "until it is ready"
It means, in practice, that one can bootstrap a github-based build using
http://github.com/rock-core/buildconf
and https://github.com/rock-core/buildconf/raw/master/bootstrap.sh
What is left to be done
-----------------------
- one question: should not we split the rock package set into
subprojects as well (for me, it is +1, it would make more sense from a
management point of view to have a package and its package set in the
same organization)

Does it mean that it will be organized as it is in gitorious? Meaning:
rock.core (now it's rock.base + rock.toolchain + rock.gui + some drivers
like transformer, frame-helper and few more)
rock.slam
rock.drivers
rock.control
rock.planning
rock.tutorials
...

Post by Sylvain Joyeux
- one thing to do: re-create the rock.base and rock.toolchain
metapackages in rock.core to ensure smooth migration from the existing
buildconfs

Question: Would the new rock package set have an impact in the folder
structure? Meaning frame-helper will be located into ./core/frame-helper
instead of the current ./image-processing/frame-helper or perhaps
./core/image-processing/frame-helper

Since there is already a kind of renaming during the migration (e.g.:
rock.core). Question: Do we what to rename some rock package set (i.e:
it would make more sense to have one called rock.perception which could
be the current rock.image-processing + image stitching + pcl related
stuffs, + future things ...) for me it is +1

Javier.

Post by Sylvain Joyeux
- testing
- update the gitorious package sets (that everyone is currently
using) to auto-import rock-core and the github-based rock package set.
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140606/429a45d4/attachment.htm

[Sylvain Joyeux]

Post by Javier Hidalgo Carrió
rock.core (now it's rock.base + rock.toolchain + rock.gui + some drivers
like transformer, frame-helper and few more)
rock.slam
rock.drivers
rock.control
rock.planning
rock.tutorials
...

Yes.

Post by Javier Hidalgo Carrió
Question: Would the new rock package set have an impact in the folder
structure? Meaning frame-helper will be located into ./core/frame-helper
instead of the current ./image-processing/frame-helper or perhaps
./core/image-processing/frame-helper

No. The folder structure stays the same.

Post by Javier Hidalgo Carrió
rock.core). Question: Do we what to rename some rock package set (i.e: it
would make more sense to have one called rock.perception which could be the
current rock.image-processing + image stitching + pcl related stuffs, +
future things ...) for me it is +1

I think this is a separate matter. Would you see the folders being merged
as well ?

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140608/72a64f51/attachment.htm

[Jakob Schwendner]

Hey Sylvain,

thanks for the work on this. I'm just doing a bootstrap off github (username is
jakobs), and it seems to be working fine.

- one question: should not we split the rock package set into subprojects as
well (for me, it is +1, it would make more sense from a management point of view
to have a package and its package set in the same organization)

It seems cleaner to do it this way. But its adding more includes at the
manifest, right? Maybe leaving it for now would be ok.

cheers,

Jakob
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140608/5a54e9f0/attachment.htm

[Sylvain Joyeux]

On Sun, Jun 8, 2014 at 12:15 AM, Jakob Schwendner <jakob.schwendner at dfki.de>

Post by Sylvain Joyeux
- one question: should not we split the rock package set into
subprojects as well (for me, it is +1, it would make more sense from a
management point of view to have a package and its package set in the same
organization)
It seems cleaner to do it this way. But its adding more includes at the
manifest, right? Maybe leaving it for now would be ok.

Would create a rock package set which would simply auto-import the other
ones. But I agree, we can do that later.

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140608/9ce0615b/attachment.htm