Post by Janosch MachowinskiI 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.
That's definitely not how all packages ended up in Rock, and whether
it is a good way to do it is arguable. Some packages stay "in devel"
in private package sets for more than a year, which leads to others to
start the same developments because these packages are not available
(and they can't even know that they exist). And it obviously hinders
collaboration, as the private package sets are not available to
everyone.
What you basically say in the rest is: using devel version of packages
will require the user to look into the devel branch of the package set
and copy/paste all the necessary bits. A.k.a. a real pain. You claim
it is worth it. It very well might be, but that's a decision that
should be made willingly, not under the hood "just because you decided
so".
That brings me back to the start of the discussion: I *will* maintain
the stable flavor by synchronizing it with the release. If anything,
this discussion really demonstrates that you've given close to zero
thoughts about the consequences of the change. And are definitely not
ready to inform our user how this change will dramatically modify
their workflow.
Post by Janosch MachowinskiDefinitely 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.
Patches don't have to be defined in source.yml and can be made
version-specific. And there's nothing that says that we can't improve
autoproj on the way to make it nicer for releases.
Post by Janosch MachowinskiPost by Sylvain JoyeuxThere 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.
We don't live in the same world at all, it seems. Let's just think
about all the patches that ended up in trajectory_follower, in the
corridor servoing, in envire, in vizkit and even a few bugfixes to
orogen and typelib (to name only a few) during the preparation of
spacebot last year. They are all packages that were released at the
time.
Post by Janosch MachowinskiPerhaps 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.
That's exactly what I was saying. It is *meant to be that way*.
Scrapping everything (and, in the way, dropping some currently heavily
used functionality) because a few aspects don't work "just the way you
want" instead of looking first into incrementally evolving the current
system is a very obvious symptom of NME.
Then there's the question of how the release should be done / managed.
But did you actually bother reading the wiki page ?
That was my point at the beginning of this thread: you want to release
yesterday, and *of course* it has to be done in a new way *right now*.
Can't release the way everyone knows how to deal with (using
snapshotting to ensure repeatability), and wait for a "100% frozen"
release until we figure out how to do it best. So let's break
everything, because keeping the current way while test-driving a
release system would be more confusing to users. Users that know how
to work within the flavor system will be less confused by a completely
new one. That's obvious.
Sylvain