[Olsr-dev] [PATCH] olsrd: fix stack corruption in net_output()
L. Aaron Kaplan
Fri Jun 22 14:04:50 CEST 2012
I like this approach a lot!
It reminds me very much of Debian and Debian bug fixes in -stable.
We should go in this direction!
On Jun 22, 2012, at 12:52 PM, Henning Rogge wrote:
> I had planned to do this discussion next week, but maybe its better to do it now as it appears on the list. *G*
> We need to sort out how to commit things for Olsrd and still have a good way to review them and then commit them to "stable" later.
> I think Saverios suggestion about splitting "pure bugfixes" and "normal commits" would be an advantage for the future.
> What would you think about reviving the "master" branch again? Not as a long term development branch, but as the place to put new commits without directly killing "stable"?
> We could rename the current "master" to something like "legacy-master" and then create a new "master" based of the current "stable" branch.
> (maybe even copying all "stale" branches like master/nhdp/olsrv2 into a second repository and removing them from the normal one would make sense)
> Everyone just commits to master, not directly to stable anymore.
> Every times we get a commit in "master", we can see if its a necessary bugfix for the current "stable", review it and later cherry-pick it over to "stable".
> When we begin with a new release, we make a temporary "release-x.x.x" branch from "master", which can be reviewed and tested (and will get bugfixes only for the next release). When we DO the release, we merge the "release-x.x.x" branch into "stable", tag it with "OLSRD_x_x_x" and remove the "release-x.x.x" branch.
> If someone works on a "long term" feature (like a completely new plugin), he can just add a branch of his own, similar to the PUD branch Ferry had for quite some time until the feature is ready to be merged to master.
> I think we are still too small as a project to put every change into a branch of its own, even small ones. But at least the way above would give us a chance to sort our mess out.
> Feedback and suggestions for improvements are welcome. (this is not necessarily a change we need to do tomorrow, but doing something like this "soon" might be a good choice)
> Henning Rogge
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Olsr-dev