...sounds good... but howto integrate this into the flavored concept,
simply not using flavors at all for rock.core?
Best,
Matthias
On 18.06.2014 15:16, Sylvain Joyeux wrote:
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
<[email protected] <mailto:[email protected]>> wrote:
-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
On 05.06.2014 13:23, Vincent vittori wrote:
+1 for removing master
2014-06-05 9:25 GMT+02:00 Alexander Duda <[email protected]
<mailto:[email protected]>>:
Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn
<[email protected] <mailto:[email protected]>>:
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
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
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 <tel:%2B49%20421%20178%2045-6611>
Besuchsadresse der Nebengeschäftstelle:
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:[email protected]
<mailto:[email protected]>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected] <mailto:[email protected]>
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
--
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 <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: [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
_______________________________________________
Rock-dev mailing list
[email protected] <mailto:[email protected]>
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:* [email protected] <mailto:[email protected]>
*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>
Besuchsadresse der Nebengeschäftstelle:
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:[email protected]
<mailto:[email protected]>
Weitere Informationen:http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
[email protected] <mailto:[email protected]>
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
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
