On 11 September 2013 00:01, Antonio Quartulli <[email protected]> wrote: > On Tue, Sep 10, 2013 at 03:45:44PM +0300, Mihail Costea wrote: >> On 10 September 2013 08:38, Antonio Quartulli <[email protected]> wrote: >> > On Tue, Sep 10, 2013 at 07:35:34AM +0300, Mihail Costea wrote: >> >> On 9 September 2013 17:53, Antonio Quartulli <[email protected]> >> >> 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? > > multiple patches is always the way to go when we have more than one change, we > cannot mix them all. > >> 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. > > this is normal when you have multiple patches: if a fix in the very first > patch > of a series creates conflicts with all the following ones, you have to adjust > them all (this is what the "git rebase" helps you with). >
I haven't used it before but I will try it now. >> >> It would be easier to do the changes directly on the existing code >> than restart everything from scratch. > > restart everything from scratch? I did not get this. > The changes I'm doing now are quite big (as they change the first patch). That will make big changes to the code base. I will send next days the first patch for review first because it changed how the generalization works (more exactly I have remove mac_addr to introduce a new void * member). I'd like the base to be written correctly as everything depends on the structures introduces there. > >> I'm not sure if this is what you meant by using github. >> > > for using github (or whetever else remote repository) I meant that instead of > rebasing on top of master every time you have to send the patches to the ml > for > review, you could upload your code on a remote repo and have us reviewing the > code on there directly. > In this way you save the pain of respinning all your patches on top of master > every week.. > > I hope I clarified your doubts. Thanks, Mihail
