On 10 September 2013 08:38, Antonio Quartulli antonio@meshcoding.com wrote:
On Tue, Sep 10, 2013 at 07:35:34AM +0300, Mihail Costea wrote:
On 9 September 2013 17:53, Antonio Quartulli antonio@meshcoding.com wrote:
On Mon, Sep 09, 2013 at 05:05:47PM +0300, Mihail Costea wrote:
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.
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.
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.
I understand, but it should be done similar? Like multiple patches? The idea is that I might add some patches and then find a bug that was in an old patch. That means to find the patch with the bug, resolve it, and re-patch everything after it.
It would be easier to do the changes directly on the existing code than restart everything from scratch. I'm not sure if this is what you meant by using github.