[Rock-dev] The issue with Rock

Discussion:

Sylvain Joyeux

2014-06-04 13:43:26 UTC

Is that everyone seem to think that they need master. The majority should
be using stable or next.

Now, I *know* that there are reasons (there are always reasons) why one
might think that master is required. However, the main question for me is:

How can we make people feel confident that they can use next ?

Or

How can we ensure that 'next' can be used except for a few packages that
would go on master ?

The best way to start answering these questions is to answer another one:

Why are you on master ?

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140604/680c6dd9/attachment.htm

Vincent vittori

2014-06-04 13:48:27 UTC

Permalink

For auv_control

V.v

Post by Sylvain Joyeux
Is that everyone seem to think that they need master. The majority should
be using stable or next.
Now, I *know* that there are reasons (there are always reasons) why one
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages that
would go on master ?
Why are you on master ?
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra?e, 28359 Bremen RAUM 1520

<http://maps.google.com/maps?q=&hl=en>*DE Mobile :* +49 152 242 37 465
*DE Office :* +49 421 218 65 641
*FR Mobile :* +33 612 12 35 39
*Email:* vittori.vincent at gmail.com
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140604/98859656/attachment.htm

Matthias Goldhoorn

2014-06-04 13:54:28 UTC

Permalink

Because i using syskit and the next version is even more unstable than
master. I had several times that the depandancy between roby/syskit and
other 'core' packages is hard. So i cannot stay a long time on next and
only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.

So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)

The Second point, is that the release cycle to next is to long for new
features, i i (as rock-dev) add new features to rock. I take ofter
months before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also
for other members of my project. I would prefer a shorter release time
between master/stable/next...

Best,
Matthias

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
--
Matthias Goldhoorn
Unterwasserrobotik

Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany

Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140604/c7ff1d1e/attachment.htm

Sylvain Joyeux

2014-06-04 15:00:06 UTC

Permalink

Then ... my next question would be:

Why isn't there more resistance w.r.t. switching to master ?

I mean, when you say "oh I had a bug on syskit on next", did you report it
as a functionality bug on next ? Did you insist that it should be fixed *on
next* ? instead of switching to master ?

For new functionality, how much of it is "oh but I need X, it is so shiny"
instead of "without X, I really cannot do it !". I mean, when I worked on
the Orion I *wanted* some features from master, but quickly realized that I
did not *need* them. I had what was strictly needed to get the Joints type
(meaning typelib/master but orogen/next)

As for the release schedule / frequency, I can only do +1. Releases are too
far apart.

My big problem here is that master has become the de-facto version of Rock
that everyone uses, which really hinders possibility to do some actual
development.

Sylvain

On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn <

Post by Sylvain Joyeux
Is that everyone seem to think that they need master. The majority should
be using stable or next.
Now, I *know* that there are reasons (there are always reasons) why one
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages
that would go on master ?
Why are you on master ?
Because i using syskit and the next version is even more unstable than
master. I had several times that the depandancy between roby/syskit and
other 'core' packages is hard. So i cannot stay a long time on next and
only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for new
features, i i (as rock-dev) add new features to rock. I take ofter months
before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also
for other members of my project. I would prefer a shorter release time
between master/stable/next...
Best,
Matthias
Sylvain
_______________________________________________
Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

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

Matthias Goldhoorn

2014-06-05 07:08:39 UTC

Permalink

Good Morning,

I don't know what you mean with resistance, in the past master was the
most "stable" version with the newest features.
Therefore there was no resistance.

Specially for Syskit/Roby i not posted all bugs, most of the bugs i
workaround, but i will start to create bug-requests for this...

Regarding the new functionality, you are right, most of these features
are not needed, they make only the life easier..., but if i as developer
see the need of a feature and implement it, i want to use this directly.
I think this is normal, since the rock-devs are not pure-rock devs, work
is done if we feel that we need enhancements...

Maybe we should rename the structure or introduce a experimental branch.
Phsychological i have the impression that "master" gets associated with
"newest" not with an "unstable development" version. Maybe we should
rename or create an additional "unstable" branch, from where the release
policy to master is not so fixed windowed...

example development:
- work is done on experimental and pushed as soon as the dev thing it
might work
- experimental is pushed to master, as soon the responsible dev thing
his changes work for all (few days upto a week?)

Again i thing the primary reasons why most of all stays on master ist
that the other branches does not have the "needed"("wished") features,
or they have bugs that are not pushed from master

Thoughts?
Matthias

Post by Sylvain Joyeux
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you
report it as a functionality bug on next ? Did you insist that it
should be fixed *on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is so
shiny" instead of "without X, I really cannot do it !". I mean, when I
worked on the Orion I *wanted* some features from master, but quickly
realized that I did not *need* them. I had what was strictly needed to
get the Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1. Releases
are too far apart.
My big problem here is that master has become the de-facto version of
Rock that everyone uses, which really hinders possibility to do some
actual development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn

Because i using syskit and the next version is even more unstable
than master. I had several times that the depandancy between
roby/syskit and other 'core' packages is hard. So i cannot stay a
long time on next and only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for
new features, i i (as rock-dev) add new features to rock. I take
ofter months before it goes into next.
Therefore i have (due to the same reasons above) switch to master,
also for other members of my project. I would prefer a shorter
release time between master/stable/next...
Best,
Matthias

Post by Sylvain Joyeux
Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Phone:+49 (0)421 218-64100 <tel:%2B49%20%280%29421%20218-64100>
Fax:+49 (0)421 218-64150 <tel:%2B49%20%280%29421%20218-64150>
E-Mail:robotik at dfki.de <mailto:robotik at dfki.de>
Weitere Informationen:http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra??e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic

Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany

Zentrale: +49 421 178 45-6611

Besuchsadresse der Nebengesch??ftstelle:
Robert-Hooke-Stra??e 5
28359 Bremen, Germany

Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de

Weitere Informationen: http://www.informatik.uni-bremen.de/robotik

-------------- n?chster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140605/947677a0/attachment-0001.htm

Alexander Duda

2014-06-05 07:25:04 UTC

Permalink

Post by Matthias Goldhoorn
Good Morning,
I don't know what you mean with resistance, in the past master was the most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the bugs i workaround, but i will start to create bug-requests for this...
Regarding the new functionality, you are right, most of these features are not needed, they make only the life easier..., but if i as developer see the need of a feature and implement it, i want to use this directly. I think this is normal, since the rock-devs are not pure-rock devs, work is done if we feel that we need enhancements...
Maybe we should rename the structure or introduce a experimental branch. Phsychological i have the impression that "master" gets associated with "newest" not with an "unstable development" version. Maybe we should rename or create an additional "unstable" branch, from where the release policy to master is not so fixed windowed...
- work is done on experimental and pushed as soon as the dev thing it might work
- experimental is pushed to master, as soon the responsible dev thing his changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on master ist that the other branches does not have the "needed"("wished") features, or they have bugs that are not pushed from master

I have my doubt here. None of the core packages had major issues the last couple of months forcing people to use master for the hole bootstrap.

Post by Matthias Goldhoorn
Thoughts?

I have the feeling we should just remove master as flavor. In this case everyone has to bootstrap next or stable and if needed he/she can manually overwrite specific packages.

Alex

Post by Matthias Goldhoorn
Matthias

Post by Sylvain Joyeux
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you report it as a functionality bug on next ? Did you insist that it should be fixed *on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is so shiny" instead of "without X, I really cannot do it !". I mean, when I worked on the Orion I *wanted* some features from master, but quickly realized that I did not *need* them. I had what was strictly needed to get the Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1. Releases are too far apart.
My big problem here is that master has become the de-facto version of Rock that everyone uses, which really hinders possibility to do some actual development.
Sylvain

Is that everyone seem to think that they need master. The majority should be using stable or next.
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages that would go on master ?
Why are you on master ?

Because i using syskit and the next version is even more unstable than master. I had several times that the depandancy between roby/syskit and other 'core' packages is hard. So i cannot stay a long time on next and only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and everything else on master.
So generally speaking, incompatibilities between syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for new features, i i (as rock-dev) add new features to rock. I take ofter months before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also for other members of my project. I would prefer a shorter release time between master/stable/next...
Best,
Matthias

Sylvain
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center

Hauptgesch?ftsstelle Standort Bremen:
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany

Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de

Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140605/6bde5c99/attachment-0001.htm

Vincent vittori

2014-06-05 11:23:25 UTC

Permalink

+1 for removing master

Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn <
Good Morning,
I don't know what you mean with resistance, in the past master was the
most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the bugs i
workaround, but i will start to create bug-requests for this...
Regarding the new functionality, you are right, most of these features are
not needed, they make only the life easier..., but if i as developer see
the need of a feature and implement it, i want to use this directly. I
think this is normal, since the rock-devs are not pure-rock devs, work is
done if we feel that we need enhancements...
Maybe we should rename the structure or introduce a experimental branch.
Phsychological i have the impression that "master" gets associated with
"newest" not with an "unstable development" version. Maybe we should rename
or create an additional "unstable" branch, from where the release policy to
master is not so fixed windowed...
- work is done on experimental and pushed as soon as the dev thing it might work
- experimental is pushed to master, as soon the responsible dev thing his
changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on master ist that
the other branches does not have the "needed"("wished") features, or they
have bugs that are not pushed from master
I have my doubt here. None of the core packages had major issues the last
couple of months forcing people to use master for the hole bootstrap.
Thoughts?
I have the feeling we should just remove master as flavor. In this case
everyone has to bootstrap next or stable and if needed he/she can manually
overwrite specific packages.
Alex
Matthias
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you report
it as a functionality bug on next ? Did you insist that it should be fixed
*on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is so
shiny" instead of "without X, I really cannot do it !". I mean, when I
worked on the Orion I *wanted* some features from master, but quickly
realized that I did not *need* them. I had what was strictly needed to get
the Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1. Releases are too far apart.
My big problem here is that master has become the de-facto version of
Rock that everyone uses, which really hinders possibility to do some actual
development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn <

Post by Sylvain Joyeux
Is that everyone seem to think that they need master. The majority should
be using stable or next.
Now, I *know* that there are reasons (there are always reasons) why one
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages
that would go on master ?
Why are you on master ?
Because i using syskit and the next version is even more unstable than
master. I had several times that the depandancy between roby/syskit and
other 'core' packages is hard. So i cannot stay a long time on next and
only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for new
features, i i (as rock-dev) add new features to rock. I take ofter months
before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also
for other members of my project. I would prefer a shorter release time
between master/stable/next...
Best,
Matthias
Sylvain
_______________________________________________
Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620
Zentrale: +49 421 178 45-0
Fax: +49 421 178 45-4150 (Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Matthias Goldhoorn

2014-06-05 12:02:02 UTC

Permalink

-1 because for checkint our tree we need master, on we simply remove it
from the server i'm sure people find ways like in the overrides

*:
- branch: master

to do such things.

Best,
Matthias

Post by Vincent vittori
+1 for removing master
2014-06-05 9:25 GMT+02:00 Alexander Duda <Alexander.Duda at dfki.de
Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn

Post by Matthias Goldhoorn
Good Morning,
I don't know what you mean with resistance, in the past master
was the most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the bugs
i workaround, but i will start to create bug-requests for this...
Regarding the new functionality, you are right, most of these
features are not needed, they make only the life easier..., but
if i as developer see the need of a feature and implement it, i
want to use this directly. I think this is normal, since the
rock-devs are not pure-rock devs, work is done if we feel that we
need enhancements...
Maybe we should rename the structure or introduce a experimental
branch. Phsychological i have the impression that "master" gets
associated with "newest" not with an "unstable development"
version. Maybe we should rename or create an additional
"unstable" branch, from where the release policy to master is not
so fixed windowed...
- work is done on experimental and pushed as soon as the dev thing it might work
- experimental is pushed to master, as soon the responsible dev
thing his changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on master
ist that the other branches does not have the "needed"("wished")
features, or they have bugs that are not pushed from master

I have my doubt here. None of the core packages had major issues
the last couple of months forcing people to use master for the
hole bootstrap.

Post by Matthias Goldhoorn
Thoughts?

I have the feeling we should just remove master as flavor. In this
case everyone has to bootstrap next or stable and if needed he/she
can manually overwrite specific packages.
Alex

Post by Matthias Goldhoorn
Matthias

Post by Sylvain Joyeux
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you
report it as a functionality bug on next ? Did you insist that
it should be fixed *on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is
so shiny" instead of "without X, I really cannot do it !". I
mean, when I worked on the Orion I *wanted* some features from
master, but quickly realized that I did not *need* them. I had
what was strictly needed to get the Joints type (meaning
typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1.
Releases are too far apart.
My big problem here is that master has become the de-facto
version of Rock that everyone uses, which really hinders
possibility to do some actual development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn

Because i using syskit and the next version is even more
unstable than master. I had several times that the
depandancy between roby/syskit and other 'core' packages is
hard. So i cannot stay a long time on next and only with
syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on
next and everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to
long for new features, i i (as rock-dev) add new features
to rock. I take ofter months before it goes into next.
Therefore i have (due to the same reasons above) switch to
master, also for other members of my project. I would prefer
a shorter release time between master/stable/next...
Best,
Matthias

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <tel:%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150> (Faxe
bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de <mailto:Alexander.Duda at dfki.de>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra??e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra??e, 28359 Bremen RAUM 1520
*DE Mobile :* +49 152 242 37 465
*DE Office :*+49 421 218 65 641
*FR Mobile :* +33 612 12 35 39
*Email:* vittori.vincent at gmail.com <mailto:vittori.vincent at gmail.com>
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*

Sylvain Joyeux

2014-06-18 13:16:08 UTC

Permalink

One possible solution: decouple rock master from rock.core master
(different release schedules). rock.core master would then become really a
development branch where people should not fear to push tested but not
heavily tested code.

The rules:
1. rock master CANNOT depend on features in rock.core master. This ensures
that the current up-to-date packages are not dependent on development
features in the toolchain. This is ensured by making people always use
rock.core next or stable.
2. rock.core master MUST stay backward compatible, i.e. at the point of
release of rock.core, rock next should be usable with rock.core master. In
other words, releasing rock.core (from master to next) should not break
existing 'next' applications.

Thoughts?

Sylvain

On Thu, Jun 5, 2014 at 2:02 PM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
-1 because for checkint our tree we need master, on we simply remove it
from the server i'm sure people find ways like in the overrides
- branch: master
to do such things.
Best,
Matthias
+1 for removing master

Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn <
Good Morning,
I don't know what you mean with resistance, in the past master was the
most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the bugs i
workaround, but i will start to create bug-requests for this...
Regarding the new functionality, you are right, most of these features
are not needed, they make only the life easier..., but if i as developer
see the need of a feature and implement it, i want to use this directly. I
think this is normal, since the rock-devs are not pure-rock devs, work is
done if we feel that we need enhancements...
Maybe we should rename the structure or introduce a experimental branch.
Phsychological i have the impression that "master" gets associated with
"newest" not with an "unstable development" version. Maybe we should rename
or create an additional "unstable" branch, from where the release policy to
master is not so fixed windowed...
- work is done on experimental and pushed as soon as the dev thing it might work
- experimental is pushed to master, as soon the responsible dev thing his
changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on master ist
that the other branches does not have the "needed"("wished") features, or
they have bugs that are not pushed from master
I have my doubt here. None of the core packages had major issues the
last couple of months forcing people to use master for the hole bootstrap.
Thoughts?
I have the feeling we should just remove master as flavor. In this case
everyone has to bootstrap next or stable and if needed he/she can manually
overwrite specific packages.
Alex
Matthias
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you report
it as a functionality bug on next ? Did you insist that it should be fixed
*on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is so
shiny" instead of "without X, I really cannot do it !". I mean, when I
worked on the Orion I *wanted* some features from master, but quickly
realized that I did not *need* them. I had what was strictly needed to get
the Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1. Releases are too far apart.
My big problem here is that master has become the de-facto version of
Rock that everyone uses, which really hinders possibility to do some actual
development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn <

Post by Sylvain Joyeux
Is that everyone seem to think that they need master. The majority
should be using stable or next.
Now, I *know* that there are reasons (there are always reasons) why
one might think that master is required. However, the main question for me
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages
that would go on master ?
Why are you on master ?
Because i using syskit and the next version is even more unstable than
master. I had several times that the depandancy between roby/syskit and
other 'core' packages is hard. So i cannot stay a long time on next and
only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for new
features, i i (as rock-dev) add new features to rock. I take ofter months
before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also
for other members of my project. I would prefer a shorter release time
between master/stable/next...
Best,
Matthias
Sylvain
_______________________________________________
Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <%2B49%20421%20178%2045-4150> (Faxe bitte
namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra?e, 28359 Bremen RAUM 1520
*DE Mobile :* +49 152 242 37 465
*DE Office :* +49 421 218 65 641
*FR Mobile :* +33 612 12 35 39
*Email:* vittori.vincent at gmail.com
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*
--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
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/20140618/2d672403/attachment-0001.htm

Matthias Goldhoorn

2014-06-18 14:37:17 UTC

Permalink

...sounds good... but howto integrate this into the flavored concept,
simply not using flavors at all for rock.core?

Best,
Matthias

Post by Sylvain Joyeux
One possible solution: decouple rock master from rock.core master
(different release schedules). rock.core master would then become
really a development branch where people should not fear to push
tested but not heavily tested code.
1. rock master CANNOT depend on features in rock.core master. This
ensures that the current up-to-date packages are not dependent on
development features in the toolchain. This is ensured by making
people always use rock.core next or stable.
2. rock.core master MUST stay backward compatible, i.e. at the point
of release of rock.core, rock next should be usable with rock.core
master. In other words, releasing rock.core (from master to next)
should not break existing 'next' applications.
Thoughts?
Sylvain
On Thu, Jun 5, 2014 at 2:02 PM, Matthias Goldhoorn
-1 because for checkint our tree we need master, on we simply
remove it from the server i'm sure people find ways like in the
overrides
- branch: master
to do such things.
Best,
Matthias

Post by Vincent vittori
+1 for removing master
2014-06-05 9:25 GMT+02:00 Alexander Duda <Alexander.Duda at dfki.de
Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn

Post by Matthias Goldhoorn
Good Morning,
I don't know what you mean with resistance, in the past
master was the most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the
bugs i workaround, but i will start to create bug-requests
for this...
Regarding the new functionality, you are right, most of
these features are not needed, they make only the life
easier..., but if i as developer see the need of a feature
and implement it, i want to use this directly. I think this
is normal, since the rock-devs are not pure-rock devs, work
is done if we feel that we need enhancements...
Maybe we should rename the structure or introduce a
experimental branch. Phsychological i have the impression
that "master" gets associated with "newest" not with an
"unstable development" version. Maybe we should rename or
create an additional "unstable" branch, from where the
release policy to master is not so fixed windowed...
- work is done on experimental and pushed as soon as the dev
thing it might work
- experimental is pushed to master, as soon the responsible
dev thing his changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on
master ist that the other branches does not have the
"needed"("wished") features, or they have bugs that are not
pushed from master

I have my doubt here. None of the core packages had major
issues the last couple of months forcing people to use master
for the hole bootstrap.

Post by Matthias Goldhoorn
Thoughts?

I have the feeling we should just remove master as flavor. In
this case everyone has to bootstrap next or stable and if
needed he/she can manually overwrite specific packages.
Alex

Post by Matthias Goldhoorn
Matthias

Post by Sylvain Joyeux
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next",
did you report it as a functionality bug on next ? Did you
insist that it should be fixed *on next* ? instead of
switching to master ?
For new functionality, how much of it is "oh but I need X,
it is so shiny" instead of "without X, I really cannot do
it !". I mean, when I worked on the Orion I *wanted* some
features from master, but quickly realized that I did not
*need* them. I had what was strictly needed to get the
Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1.
Releases are too far apart.
My big problem here is that master has become the de-facto
version of Rock that everyone uses, which really hinders
possibility to do some actual development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn
<matthias.goldhoorn at dfki.de

Because i using syskit and the next version is even
more unstable than master. I had several times that the
depandancy between roby/syskit and other 'core'
packages is hard. So i cannot stay a long time on next
and only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby
on next and everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is
to long for new features, i i (as rock-dev) add new
features to rock. I take ofter months before it goes
into next.
Therefore i have (due to the same reasons above) switch
to master, also for other members of my project. I
would prefer a shorter release time between
master/stable/next...
Best,
Matthias

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <tel:%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
(Faxe bitte namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de <mailto:Alexander.Duda at dfki.de>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra??e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra??e, 28359 Bremen RAUM 1520
*DE Mobile :* +49 152 242 37 465
*DE Office :*+49 421 218 65 641
*FR Mobile :* +33 612 12 35 39 <tel:%2B33%20612%2012%2035%2039>
*Email:* vittori.vincent at gmail.com <mailto:vittori.vincent at gmail.com>
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

Sylvain Joyeux

2014-06-19 09:38:01 UTC

Permalink

We basically would separate the flavor of rock.core from the flavor of the
rest of the packages. The only flavor users would be asked about would be
the non-core one and we would automatically pick the rock.core one based on
that (next for next, stable for stable). People that would want 'master' on
rock.core would have to do it manually in their init.rb

On Wed, Jun 18, 2014 at 4:37 PM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
...sounds good... but howto integrate this into the flavored concept,
simply not using flavors at all for rock.core?
Best,
Matthias
One possible solution: decouple rock master from rock.core master
(different release schedules). rock.core master would then become really a
development branch where people should not fear to push tested but not
heavily tested code.
1. rock master CANNOT depend on features in rock.core master. This
ensures that the current up-to-date packages are not dependent on
development features in the toolchain. This is ensured by making people
always use rock.core next or stable.
2. rock.core master MUST stay backward compatible, i.e. at the point of
release of rock.core, rock next should be usable with rock.core master. In
other words, releasing rock.core (from master to next) should not break
existing 'next' applications.
Thoughts?
Sylvain
On Thu, Jun 5, 2014 at 2:02 PM, Matthias Goldhoorn <

Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn <
Good Morning,
I don't know what you mean with resistance, in the past master was the
most "stable" version with the newest features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most of the bugs i
workaround, but i will start to create bug-requests for this...
Regarding the new functionality, you are right, most of these features
are not needed, they make only the life easier..., but if i as developer
see the need of a feature and implement it, i want to use this directly. I
think this is normal, since the rock-devs are not pure-rock devs, work is
done if we feel that we need enhancements...
Maybe we should rename the structure or introduce a experimental branch.
Phsychological i have the impression that "master" gets associated with
"newest" not with an "unstable development" version. Maybe we should rename
or create an additional "unstable" branch, from where the release policy to
master is not so fixed windowed...
- work is done on experimental and pushed as soon as the dev thing it might work
- experimental is pushed to master, as soon the responsible dev thing
his changes work for all (few days upto a week?)
Again i thing the primary reasons why most of all stays on master ist
that the other branches does not have the "needed"("wished") features, or
they have bugs that are not pushed from master
I have my doubt here. None of the core packages had major issues the
last couple of months forcing people to use master for the hole bootstrap.
Thoughts?
I have the feeling we should just remove master as flavor. In this
case everyone has to bootstrap next or stable and if needed he/she can
manually overwrite specific packages.
Alex
Matthias
Why isn't there more resistance w.r.t. switching to master ?
I mean, when you say "oh I had a bug on syskit on next", did you
report it as a functionality bug on next ? Did you insist that it should be
fixed *on next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I need X, it is so
shiny" instead of "without X, I really cannot do it !". I mean, when I
worked on the Orion I *wanted* some features from master, but quickly
realized that I did not *need* them. I had what was strictly needed to get
the Joints type (meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do +1. Releases are too far apart.
My big problem here is that master has become the de-facto version of
Rock that everyone uses, which really hinders possibility to do some actual
development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn <

Post by Sylvain Joyeux
Is that everyone seem to think that they need master. The majority
should be using stable or next.
Now, I *know* that there are reasons (there are always reasons) why
one might think that master is required. However, the main question for me
How can we make people feel confident that they can use next ?
Or
How can we ensure that 'next' can be used except for a few packages
that would go on master ?
Why are you on master ?
Because i using syskit and the next version is even more unstable
than master. I had several times that the depandancy between roby/syskit
and other 'core' packages is hard. So i cannot stay a long time on next and
only with syskit/roby on master.
Indeed i'm not sure if i can currently use syskit/roby on next and
everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/ base/types/(std)
The Second point, is that the release cycle to next is to long for new
features, i i (as rock-dev) add new features to rock. I take ofter months
before it goes into next.
Therefore i have (due to the same reasons above) switch to master, also
for other members of my project. I would prefer a shorter release time
between master/stable/next...
Best,
Matthias
Sylvain
_______________________________________________
Rock-dev mailing listRock-dev at dfki.dehttp://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
--
Matthias Goldhoorn
Unterwasserrobotik
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Phone: +49 (0)421 218-64100
Fax: +49 (0)421 218-64150
E-Mail: robotik at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
-----------------------------------------------------------------------

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150 <%2B49%20421%20178%2045-4150> (Faxe bitte
namentlich kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra?e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra?e, 28359 Bremen RAUM 1520
*DE Mobile :* +49 152 242 37 465
*DE Office :* +49 421 218 65 641
*FR Mobile :* +33 612 12 35 39 <%2B33%20612%2012%2035%2039>
*Email:* vittori.vincent at gmail.com
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*
--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit?t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra?e 1
28359 Bremen, Germany
Zentrale: +49 421 178 45-6611
Robert-Hooke-Stra?e 5
28359 Bremen, Germany
Tel.: +49 421 178 45-4193
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: matthias.goldhoorn at informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
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/20140619/cd049367/attachment-0001.htm

Matthias Goldhoorn

2014-06-19 09:46:40 UTC

Permalink

Sounds fine,
but we should thik about not callign this flavour here too to prevent
confusions.

But this brings me to another point, it becomes standart that the
overrides.yml and overrides.rb ist part of the autoproj build
configuration. Therefore it's hard to define local overrides. Could we
maybe add a local-overrides.rb and local-overrides.yml that will be
checked by autoproj too?

Best,
Matthias

Post by Sylvain Joyeux
We basically would separate the flavor of rock.core from the flavor of
the rest of the packages. The only flavor users would be asked about
would be the non-core one and we would automatically pick the
rock.core one based on that (next for next, stable for stable). People
that would want 'master' on rock.core would have to do it manually in
their init.rb
On Wed, Jun 18, 2014 at 4:37 PM, Matthias Goldhoorn
...sounds good... but howto integrate this into the flavored
concept, simply not using flavors at all for rock.core?
Best,
Matthias

Post by Sylvain Joyeux
One possible solution: decouple rock master from rock.core master
(different release schedules). rock.core master would then become
really a development branch where people should not fear to push
tested but not heavily tested code.
1. rock master CANNOT depend on features in rock.core master.
This ensures that the current up-to-date packages are not
dependent on development features in the toolchain. This is
ensured by making people always use rock.core next or stable.
2. rock.core master MUST stay backward compatible, i.e. at the
point of release of rock.core, rock next should be usable with
rock.core master. In other words, releasing rock.core (from
master to next) should not break existing 'next' applications.
Thoughts?
Sylvain
On Thu, Jun 5, 2014 at 2:02 PM, Matthias Goldhoorn
-1 because for checkint our tree we need master, on we simply
remove it from the server i'm sure people find ways like in
the overrides
- branch: master
to do such things.
Best,
Matthias

Post by Vincent vittori
+1 for removing master
2014-06-05 9:25 GMT+02:00 Alexander Duda
Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn
<matthias.goldhoorn at dfki.de

Post by Matthias Goldhoorn
Good Morning,
I don't know what you mean with resistance, in the past
master was the most "stable" version with the newest
features.
Therefore there was no resistance.
Specially for Syskit/Roby i not posted all bugs, most
of the bugs i workaround, but i will start to create
bug-requests for this...
Regarding the new functionality, you are right, most of
these features are not needed, they make only the life
easier..., but if i as developer see the need of a
feature and implement it, i want to use this directly.
I think this is normal, since the rock-devs are not
pure-rock devs, work is done if we feel that we need
enhancements...
Maybe we should rename the structure or introduce a
experimental branch. Phsychological i have the
impression that "master" gets associated with "newest"
not with an "unstable development" version. Maybe we
should rename or create an additional "unstable"
branch, from where the release policy to master is not
so fixed windowed...
- work is done on experimental and pushed as soon as
the dev thing it might work
- experimental is pushed to master, as soon the
responsible dev thing his changes work for all (few
days upto a week?)
Again i thing the primary reasons why most of all stays
on master ist that the other branches does not have the
"needed"("wished") features, or they have bugs that are
not pushed from master

I have my doubt here. None of the core packages had
major issues the last couple of months forcing people to
use master for the hole bootstrap.

Post by Matthias Goldhoorn
Thoughts?

I have the feeling we should just remove master as
flavor. In this case everyone has to bootstrap next or
stable and if needed he/she can manually overwrite
specific packages.
Alex

Post by Matthias Goldhoorn
Matthias

Post by Sylvain Joyeux
Why isn't there more resistance w.r.t. switching to
master ?
I mean, when you say "oh I had a bug on syskit on
next", did you report it as a functionality bug on
next ? Did you insist that it should be fixed *on
next* ? instead of switching to master ?
For new functionality, how much of it is "oh but I
need X, it is so shiny" instead of "without X, I
really cannot do it !". I mean, when I worked on the
Orion I *wanted* some features from master, but
quickly realized that I did not *need* them. I had
what was strictly needed to get the Joints type
(meaning typelib/master but orogen/next)
As for the release schedule / frequency, I can only do
+1. Releases are too far apart.
My big problem here is that master has become the
de-facto version of Rock that everyone uses, which
really hinders possibility to do some actual development.
Sylvain
On Wed, Jun 4, 2014 at 3:54 PM, Matthias Goldhoorn
<matthias.goldhoorn at dfki.de

Post by Sylvain Joyeux
Is that everyone seem to think that they need
master. The majority should be using stable or next.
Now, I *know* that there are reasons (there are
always reasons) why one might think that master
How can we make people feel confident that they
can use next ?
Or
How can we ensure that 'next' can be used
except for a few packages that would go on master ?
The best way to start answering these questions
Why are you on master ?

Because i using syskit and the next version is
even more unstable than master. I had several
times that the depandancy between roby/syskit and
other 'core' packages is hard. So i cannot stay a
long time on next and only with syskit/roby on master.
Indeed i'm not sure if i can currently use
syskit/roby on next and everything else on master.
So generally speaking, incompatibilities between
syskit/roby/utilmm/utilrb/typelib/orogen/
base/types/(std)
The Second point, is that the release cycle to
next is to long for new features, i i (as
rock-dev) add new features to rock. I take ofter
months before it goes into next.
Therefore i have (due to the same reasons above)
switch to master, also for other members of my
project. I would prefer a shorter release time
between master/stable/next...
Best,
Matthias

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Ing. Alexander Duda
Unterwasserrobotik
Robotics Innovation Center
DFKI GmbH
Robotics Innovation Center
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Tel.: +49 421 178 45-6620 <tel:%2B49%20421%20178%2045-6620>
Zentrale: +49 421 178 45-0 <tel:%2B49%20421%20178%2045-0>
Fax: +49 421 178 45-4150
<tel:%2B49%20421%20178%2045-4150> (Faxe bitte namentlich
kennzeichnen)
E-Mail: Alexander.Duda at dfki.de
<mailto:Alexander.Duda at dfki.de>
Weitere Informationen: http://www.dfki.de/robotik
-----------------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Stra??e 122, D-67663 Kaiserslautern
Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster
(Vorsitzender) Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
Sitz der Gesellschaft: Kaiserslautern (HRB 2313)
USt-Id.Nr.: DE 148646973
Steuernummer: 19/673/0060/3
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
Vincent Vittori
Robotic engineer MARUM
University of Bremen
4 Leobener Stra??e, 28359 Bremen RAUM 1520
*DE Mobile :* +49 152 242 37 465
*DE Office :*+49 421 218 65 641
*FR Mobile :* +33 612 12 35 39 <tel:%2B33%20612%2012%2035%2039>
*Email:* vittori.vincent at gmail.com
<mailto:vittori.vincent at gmail.com>
*IM:* vincent.vittori1 (Skype)
*http://de.linkedin.com/in/vincentvittori/en
<http://de.linkedin.com/in/vincentvittori/en>*

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev at dfki.de <mailto:Rock-dev at dfki.de>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev

--
Dipl.-Inf. Matthias Goldhoorn
Space and Underwater Robotic
Universit??t Bremen
FB 3 - Mathematik und Informatik
AG Robotik
Robert-Hooke-Stra??e 1
28359 Bremen, Germany
Zentrale:+49 421 178 45-6611 <tel:%2B49%20421%20178%2045-6611>
Robert-Hooke-Stra??e 5
28359 Bremen, Germany
Tel.:+49 421 178 45-4193 <tel:%2B49%20421%20178%2045-4193>
Empfang:+49 421 178 45-6600 <tel:%2B49%20421%20178%2045-6600>
Fax:+49 421 178 45-4150 <tel:%2B49%20421%20178%2045-4150>
E-Mail:matthias.goldhoorn at informatik.uni-bremen.de <mailto:matthias.goldhoorn at informatik.uni-bremen.de>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik

Sylvain Joyeux

2014-06-19 12:40:21 UTC

Permalink

On Thu, Jun 19, 2014 at 11:46 AM, Matthias Goldhoorn <

Post by Matthias Goldhoorn
but we should thik about not callign this flavour here too to prevent
confusions.

I *am* confused by this sentence ... :P

Post by Matthias Goldhoorn
But this brings me to another point, it becomes standart that the
overrides.yml and overrides.rb ist part of the autoproj build
configuration. Therefore it's hard to define local overrides. Could we
maybe add a local-overrides.rb and local-overrides.yml that will be
checked by autoproj too?

I was thinking of having an overrides.d directoy in which one can place any
number of overrides. This will allow to download overrides from other
people (e.g. the orogen_loaders overrides and so on).

Sylvain
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.dfki.de/pipermail/rock-dev/attachments/20140619/267ec23c/attachment.htm