[Olsr-dev] [PATCH] olsrd: fix stack corruption in net_output()

[L. Aaron Kaplan]

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:

> Hi,
> 
> 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...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120622/fd4d5703/attachment.sig>