On Mon, Jul 28, 2014 at 5:37 AM, Janosch Machowinski <[email protected]> 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 _______________________________________________ Rock-dev mailing list [email protected] http://www.dfki.de/mailman/cgi-bin/listinfo/rock-dev
