On Tue, 2007-03-06 at 11:36 +0000, Richard W.M. Jones wrote:
Mark McLoughlin wrote:
> On Tue, 2007-03-06 at 11:25 +0000, Richard W.M. Jones wrote:
>
>> So far, the release model for libvirt (correct me if I'm wrong) has been
>> that you periodically bundle up the latest version of libvirt and put it
>> on the website. There's no experimental branch where we can place
>> things like a libvirt remote patch with the proviso that at some point
>> later we can say "sorry, that didn't work".
>
> I'd be happy to see this stuff in CVS on a "remote branch", but it
> would be quite a pain for you to maintain a branch in CVS.
It's probably about the same work that I'm doing now - periodically
pulling in CVS commits into git and resolving conflicts (there usually
aren't many, and so far none have been complex).
It's especially a pain with CVS, though.
But yes, really I was talking about what the libvirt policy is /
should
be on experimental stuff.
Okay, in general terms, I'd be happy to see experimental stuff on
experimental branches, but it'd be quite a pain to maintain these
experimental branches.
So, experimental branches should only be used where we really can't get
the stuff on HEAD in the short term because e.g. the API won't have
settled by the time the next release is made.
You could argue that we should have a branch from which stable releases
are made, allowing unstable releases to be made, but it looks like this
"every release is stable, CVS is less stable" model works well for
smaller self-contained projects like this.
Cheers,
Mark.