On 11/15/2009 05:41 PM, Jan Kiszka wrote:
Avi Kivity wrote:
On 11/15/2009 05:02 PM, Jan Kiszka wrote:
Where should I add "/* next version to use: 13 */", and who will take
care that this comment will also be kept up to date? The CPU vmstate is
already ordered according to logical groups, just look at earlier field.
Only recent KVM additions happened to create some version ordering as
well.
Er, now I'm confused. 11 and 12 indeed do already exist, so how can you
update 11 retroactively?
Oh, right, good that we discuss this. My patch dated back before the
kvmclock addition, which IMHO incorrectly bumped the version numbers. I
think the current policy in upstream is that we only increment once per
qemu release, not per bit added.
What about stable releases? If we need to port a commit which adds a
bit, we need to port the entire thing.
(well version numbers don't work with nonlinear development anyway).
Shouldn't you create 13 now?
No, I rather think Glauber's 12 should be downgraded to 11 - unless it
misses the qemu merge windows for 0.12. My extensions definitely target
that release, thus will likely carry 11 in upstream. And we should
really try to avoid diverging again.
Agree. Will commit the patches.
(and I meant: /* The above list is not sorted wrt version, watch out!
*/, but now I feel I'm missing something).
Ok, can add such a note at the end.
In upstream...
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
