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

[Henning Rogge]

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

On 06/22/2012 12:34 PM, Markus Kittenberger wrote:
> imho i have no objections to have an OpenWRT package which is NOT an
> release,..
>
> i.e. just a version of our stable branch, but one with an correct hash, and
> maybe some sort of tag (-;
>
> Markus
>
> On Fri, Jun 22, 2012 at 12:28 PM, ZioPRoTo (Saverio Proto) <
> (spam-protected)> wrote:
>
>>> And a real nasty and subtle one too. "Normally" the stack will be still
>>> there, but the compiler optimizations do something clever and wreck this
>>> crazy "optimization".
>>
>> Thanks to Jo for fixing the bug.
>>
>> So we have now a 0.6.3 with a patch applied in the OpenWRT package
>> that again changes the binary hash.
>> https://dev.openwrt.org/browser/packages/net/olsrd/patches
>>
>> I have a proposal. Instead of keeping this patches in the OpenWRT
>> package, we can have a git branch where we start from the latest
>> stable tag and we cherry-pick these commits that are critical
>> bugfixes.
>>
>> I can rewrite easily the OpenWRT Makefile to fetch the head of this
>> new branch instead of the tarball.
>>
>> what do you think ?
>>
>> Saverio
>>
>> --
>> Olsr-dev mailing list
>> (spam-protected)
>> https://lists.olsr.org/mailman/listinfo/olsr-dev
>>
>


-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:(spam-protected) http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6169 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.olsr.org/pipermail/olsr-dev/attachments/20120622/5045541f/attachment.bin>