| 1 |
On Friday, 16. May 2008, Tiziano Müller wrote: |
| 2 |
> Mike Auty wrote: |
| 3 |
> > As one of the primary vmware devs, I'm not sure that vmware easily |
| 4 |
> > fits into this group based on it's closed-source nature, and the |
| 5 |
> > complex (but just about workable) module system we've put in place. I |
| 6 |
> > also wouldn't want to muddy the virtualization email address with all |
| 7 |
> > the random vmware module bugs... 5:) |
| 8 |
> > |
| 9 |
> > I'm pretty happy for the vmware group to go under the virtualization |
| 10 |
> > herd, but I'd very much like to maintain the vmware email |
| 11 |
> > alias/assignment for bugs, and I'm not sure how much we'd be able to |
| 12 |
> > integrate with the larger group. Do you think it's worthwhile vmware |
| 13 |
> > joining the umbrella or should we just stay separate? |
| 14 |
> |
| 15 |
> That's true. How about having a virtualization project which takes care |
| 16 |
> of the common part, the docs and the coordination (if any) and have |
| 17 |
> separate herds for larger "subprojects"? |
| 18 |
|
| 19 |
I have to agree here for the Xen part. One big alias for all packages will |
| 20 |
only jam up everybody's mailbox. |
| 21 |
So we keep the existing herds (vmware, xen) and maintain common packages |
| 22 |
such as libvirt under a super-herd. Question is what happens with the |
| 23 |
packages that are not part of any herd yet (such as virtualbox, qemu)? |
| 24 |
|
| 25 |
|
| 26 |
Robert |
Archives