From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 0/6] DCCP: Implement TFRC Faster Restart
Date: Tue, 04 Sep 2007 14:58:25 +0000 [thread overview]
Message-ID: <200709041558.26097@strip-the-willow> (raw)
In-Reply-To: <200708291113.07431.ian.mcdonald@jandi.co.nz>
| > * when updating to the forthcoming rev04 of the current rev03 of the Faster Restart
| > draft, one needs to track the old changes and it is difficult to say now what the
| > changes will look like
| >
| Agree. But don't think this is an obstacle to merging as we are
| running obsolete code in other branch/mainline ;-)
|
That is not what I meant. Of course it is not an obstacle of getting code `in', but the
problem is in getting the code `out' or updated when there is time for a new revision.
When there is little or no documentation in the code saying which variable or piece of
code belongs where, then each time someone wants to change a bit of code has to reverse-
engineer what actually is going on. This can be very time-consuming. So I was not thinking
in terms of merging (although I am sure that Arnaldo will pick out bad code), but of keeping
the code changeable for a longer period and easier to update.
Don't get me wrong, I don't mean your code here, it is a general problem which I think we
should pay more attention to. And, as said, my ideas of keeping things separate may not be
the best possible solution, only one that I could think of at the moment.
| > * the CCID3 code is currently facing the following revisions
| > - the current code implements rev00
| > - Tommi's CCID4 relies on rev01 (not sure about Leandro's)
| > - your FR code actually would need rev02
| > - rev02 is in the process of being revised and obsoleted into rev03
| >
| Agree all the versions are a mess. I think it's worthwhile starting on
| upgrading the code base but not a project I'm undertaking at the
| moment (or you).
Hopefully there will be some IETF consolidation about rfc3448bis in December, then all this
could be reduced to one revision.
Imagine -- 4 different developers and 3 different draft versions :(
next prev parent reply other threads:[~2007-09-04 14:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-28 23:13 [PATCH 0/6] DCCP: Implement TFRC Faster Restart Ian McDonald
2007-08-30 7:30 ` Gerrit Renker
2007-09-03 23:00 ` Ian McDonald
2007-09-04 14:58 ` Gerrit Renker [this message]
2007-09-04 21:45 ` Ian McDonald
2007-09-05 9:02 ` Gerrit Renker
2007-09-05 10:02 ` Ian McDonald
2007-09-05 15:43 ` Gerrit Renker
2007-09-06 2:57 ` Ian McDonald
2007-09-06 14:59 ` Gerrit Renker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200709041558.26097@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=dccp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.