Nick Edelen [off-list ref] writes:
By the way, what would be the best way of posting a revised patchset?
Should I just reply to my older posts, or make new ones?
That depends primarily on how heavily the patches needed to change in
response to review comments, but until the series lands in 'next', you
would typically send updated series as a replacement, not incremental.
Many people seemed to be interested in the series and had a volume of
comments on it. I suspect the updated series would be quite different
from the original, so for the next round I would suspect it would be best
to start anew, marking them as [PATCH N/M (v2)], in a fresh thread. It
would help reviewers if you said "this corresponds to [PATCH 3/5] in the
original series, with the following improvements based on X and Y's
comments" after the three-dash line.
IIRC from previous discussions, kernel.org's main performance problem is
I/O, not CPU. Are there any provisions for sharing rev-caches between
similar repositories, as we already do for objects?
I haven't implemented a transmission protocol or anything, but it
would be perfectly possible to copy cache slices from one repo to
another. Generating the revision cache from scratch on large repos
can take several minutes, so this wouldn't be a bad idea.
That depends primarily on how heavily the patches needed to change in
response to review comments, but until the series lands in 'next', you
would typically send updated series as a replacement, not incremental.
Many people seemed to be interested in the series and had a volume of
comments on it. I suspect the updated series would be quite different
from the original, so for the next round I would suspect it would be best
to start anew, marking them as [PATCH N/M (v2)], in a fresh thread. It
would help reviewers if you said "this corresponds to [PATCH 3/5] in the
original series, with the following improvements based on X and Y's
comments" after the three-dash line.
Ok, that sounds good. I've added a new patch as well so the numbering changes.
On Sat, Aug 08, 2009 at 09:27:55AM +0200, Nick Edelen wrote:
quoted
IIRC from previous discussions, kernel.org's main performance problem is
I/O, not CPU. Are there any provisions for sharing rev-caches between
similar repositories, as we already do for objects?
I haven't implemented a transmission protocol or anything, but it
would be perfectly possible to copy cache slices from one repo to
another. Generating the revision cache from scratch on large repos
can take several minutes, so this wouldn't be a bad idea.
That might be useful, but I was thinking more of an "alternates"-like
mechanism between repos. So that the data is stored only once on disk
and in the disk cache, which is helpful for sites like kernel.org which
serve many similar repositories.
-Peff
That might be useful, but I was thinking more of an "alternates"-like
mechanism between repos. So that the data is stored only once on disk
and in the disk cache, which is helpful for sites like kernel.org which
serve many similar repositories.
Oh, right. Yes, that seems like it could work. We'd have to be
careful that a shared cache slice wouldn' change (like in a fuse or
something), but other than that we could have something as simple as a
link.