+1 for removing master
2014-06-05 9:25 GMT+02:00 Alexander Duda <[email protected]>: > > Am 05.06.2014 um 09:08 schrieb Matthias Goldhoorn < > [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]> 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 >> [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 >> Fax: +49 (0)421 218-64150 >> E-Mail: [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 > > > > -- > 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: [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] > 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:* [email protected] *IM:* vincent.vittori1 (Skype) *http://de.linkedin.com/in/vincentvittori/en <http://de.linkedin.com/in/vincentvittori/en>*
_______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
