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
On 04.06.2014 17:00, Sylvain Joyeux wrote:
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
<[email protected] <mailto:[email protected]>> wrote:
On 04.06.2014 15:43, Sylvain Joyeux wrote:
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 ?
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
[email protected] <mailto:[email protected]>
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 <tel:%2B49%20%280%29421%20218-64100>
Fax:+49 (0)421 218-64150 <tel:%2B49%20%280%29421%20218-64150>
E-Mail:[email protected] <mailto:[email protected]>
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: [email protected]
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected]
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
