Am 05.09.2014 um 16:02 schrieb Sylvain Joyeux:
>>> This fails if:
>>> - you want to try a package that did not exist at release time
>> Package should be then on a 'additional packages' package set. If you
>> want non release packages, you import an extra package set.
> So ... Now you want a 'stable' package set and a 'master' package set
> ? What about packages whose property change between stable and master
> (long list already posted ?). We need to duplicate ?
>
> Why change so much when the flavor system already provides a good base
> to migrate to a "release frozen in time" system ? You clearly
> completely misunderstand how the flavor system works. The stable
> flavor *already* provides all the guarantees you are talking about
> *until the next stable is pushed*, while still allowing to easily mix
> master and stable. Branching the package set "just before the next
> release" would then provide release-guarantees for the years to come.
>
> In other words, the heavy patching you've done in the release branches
> is really only making the whole release process more complex, and
> reducing the usability of Rock for its developers.
I seriously don't see your point. We started all packages of in projects
and after they got some maturity we moved them over to the global
package set. Nothing changed here.
> What I am talking about is: what if the stable branch of a package and
> the master branch of a package need different build options ? This
> happened many times before.
Then this should be handled in you local overrides, were you also
change the branch to master/whatever
>>> - the repository URL changed between the release and now
>> The version we are interested in, for the release, should hopefully
>> still be at the 'old' url. Actually there were thoughts to mirror external
>> repositories,
>> to be sure that we can rebuild anything years later.
> Again, I am talking about using the devel version of a released
> package while being on a release.
In this case you need to overwrite the url to your fork repo anyway.
You should only need to change to a devel version, if you are
actually working on it.
>>> - there are differences in the way the package is patched
>> Same as above. Might change runtime behavior.
> And same as above, I am talking about using the devel version of a
> released package while being on a release. Of course it changes
> runtime behaviour, it is what the user *wants*.
Definitely not. I don't want my stable packages to be patched
because something in devel changed. Patches are defined in
the source.yml and apply to all version.
>
> There is no "pure user" in Rock (or in ROS for that matter). All
> "users" also develop packages, which might or might not be part of the
> latest Rock release. Any way to "release" rock will have to cater to
> these.
For 90% of the packages I use, on 'my' robots, I don't do any
development. I just stay on the release version. The only ones
I actively develop are the project / robot specific packages. These
ones are in my own package set. So yes, we are gladly at a point,
were a user does not need to touch every package.
>> All the osdeps need to be frozen to a specific commit / version,
>> which is the opposite of how we wanted it in the master/next/stable
>> system.
> No, it is not. 'stable' was always meant to be fixed until the next
> stable release. What we did not bother with is providing a way to go
> back to older releases.
Perhaps it was meant as this, but it was not working this way. If you
changed a osdep before, it applied to all three flavors. Same for the
source.yml. If someone changed the git commit for external/gmapping,
this would have applied to all of them and by chance broke them all.
Greetings
Janosch
--
Dipl. Inf. Janosch Machowinski
SAR- & Sicherheitsrobotik
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-6614
Empfang: +49 421 178 45-6600
Fax: +49 421 178 45-4150
E-Mail: jmachowin...@informatik.uni-bremen.de
Weitere Informationen: http://www.informatik.uni-bremen.de/robotik
_______________________________________________
Rock-dev mailing list
Rock-dev@dfki.de
http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
