10 Sep
2013
10 Sep
'13
5:38 a.m.
On Tue, Sep 10, 2013 at 07:35:34AM +0300, Mihail Costea wrote:
On 9 September 2013 17:53, Antonio Quartulli
<antonio(a)meshcoding.com> wrote:
I understood. Well, the problem is also that this period is a sort of
"transition" because batman-adv is getting changed in some of its most
important
part
and we would like all the "new features" that are not essential to come after
these changes.
We still need to merge two (or two and a bit) patchsets before we can start
merging other things.
This means that before your patchset gets merged we have to wait a bit more.
I think it would be better to do this:
- for a while you don't care about rebasing on top of master
- when you have a some code ready to be reviewed you can put in on a remote git
repo that we can check (e.g. github?)
- we/I review the code so that we make it ready to be sent as PATCH
- when these two (and a bit) patchsets are merged you can do the final rebase
and send them to the ml for merging.
What do you think?
In this way we same some painful rebase cycles, but we can continue preparing
the code.
Cheers,
--
Antonio Quartulli
..each of us alone is worth nothing..
Ernesto "Che" Guevara
On Mon, Sep 09, 2013 at 05:05:47PM +0300, Mihail
Costea wrote:
I took a small rest last week and now I'm redoing everything.
I was thinking about sending the first part for merging (the one with
generalization the DAT).
That is the one that needs most rewriting every time because it
affects the most existing code.
The rest I think I can send them together. Hi Antonio,
Is it possible to send the new model for the generalization as a patch
first (the part without IPv6), or maybe everything as a patch as once?
Having 5-6 patches to rewrite every time something changes makes the
development harder.
Which patches do you want to merge?
If they are ready it is better to send them as PATCH to the ml and then base
your work on top of them assuming they will be merged at some point.