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

[Hans-Christoph Steiner]

I'd like to suggest a simpler setup that is a more basic version of the Linux workflow.  There is one official git repo for olsrd with only a master branch and tags for releases.  Each developer works in their own git fork, where they are each free to rebase, branch, merge, etc. however they want.  They each push to a separate public repo.  There is one person or a couple people who can pull from any repo into the official master.

This is known as the Integration Manager workflow and its part of the official git documentation:
http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows

.hc

On Jun 22, 2012, at 8:04 AM, L. Aaron Kaplan wrote:

> 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
> 
> -- 
> Olsr-dev mailing list
> (spam-protected)
> https://lists.olsr.org/mailman/listinfo/olsr-dev