[Rock-dev] Proposal: the next Rock release

[Sylvain Joyeux]

On Mon, Jul 28, 2014 at 5:37 AM, Janosch Machowinski
<Janosch.Machowinski at dfki.de> wrote:
>>> - Create an (example name) 0714_RC1 Branch from Master of all packets
>>> - If someone does not want his master commits on the release, he/she
>>> reverts them on the RC Branch
>> This is hell. We'll get widely diverging branches or non-fast-forwards
>> (i.e. people will have to force-push to their branch)
> Hm ? As it is a seperate branch, people can just use git revert...
Yes. Hell. The two only ways is to either:
 - revert the commits (meaning that you'll get a bunch of reverts
regularly on every stable branch, great way to make the history
unreadable)
 - create a 'ours' merge, which makes looking at history even harder.
Regardless of the *how*, I am against the principle. The policy should
IMO be: a package is controlled by its maintainer, don't force him to
do something he does not want to do.

>> I personally really would like to think separately about rock.core and
>> rock. The way ROS does is have the 'ros core' managed by the ROS
>> maintainers, and having the package maintainers in charge of the
>> non-core parts. This makes sure that the maintainers are aware about
>> what happens to their packages.
> I would prefer to have as many packages released together.
> The thought here is, that any package that is in the release
> is tested (or compiles at least), and should not create any issues.
How do you know that if you're not maintaining the package ? How do
you know that 'master' is not a work in progress that compiles but is
unusable ?

> If we put e.g. the driver package outside of the branch system,
> we run in the same problems as now, as their master branch could
> depend on changes that are not in the 'core' release.
Yes. And *so what* ? It is the package maintainer's choice to not
release his code, not your place to decide that he should. By
releasing you put pressure *on him* to maintain something (a released
package) that they don't want to maintain / that they don't think is
of high enough quality.

>> The same way we have the 'stable' tag, I would prefer having an easy
>> way for the package maintainers to tell "yes, this package can go on
>> release X" and have an automated mechanism that does so.
> The stable tag never had a meaning regarding stability of the package
> for me. It was just compile as release, or as debug.
I don't see how that is relevant. Because 'stable' had no meaning does
not mean that we can create a policy where some tags would have some
meaning.

>>> - Change all packet sets, to have also branches / Remove this
>>> in_flavor_stable stuff
>> Branching the package sets is problematic (this is why we got the
>> flavor system as it is right now, we *were* branching before). The
>> problem is that if a new package gets defined, the user *cannot* get
>> it.
> Yep, this is ok, as this means, it is not tested / integrated with this
> release.
> If one really wants this package anyway, he can define his own custom
> packageset and add it there.
Great at making testing new packages really really hard. I.e. making
rock unusable as most packages are new.

Sylvain