[Qemu-devel] KVM call minutes for May 18

[Qemu-devel] KVM call minutes for May 18

[Chris Wright]

0.13 release
- push out to July 1st
- esp. important to solidy/crispen QMP
- 1 rc to shake out brown paper bag bugs, then final release

block i/o performance (high CPU consumption)
- memset can be removed (patch posted, queued by kwolf)
- cpu_physical_memory_rw known, should gather data

block 1TB limit
- sounds like integer issue
- bug report needs to be updated (verify it's still happening in 0.12.4?
- should be able to easily reproduce (can use lvm to create sparse volume)

sourceforge bug tracker...
- sucks
- unclear if there's active triage
- anthony prefers the launchpad instance
- alex likes the sf email to list, wuld be good to keep that feature
- had to migrate existing bugs (be nice if we could stop sf from growing)
- need more people involved w/ bug work
- possible bug-day before next release
  - suggested June 1st

0.12.4 bugs
- migration regression...follow-up on email, open a bug ;-)

[Qemu-devel] Re: KVM call minutes for May 18

[Brian Jackson]

On Tuesday 18 May 2010 09:29:25 Chris Wright wrote:
> 0.13 release
> - push out to July 1st
> - esp. important to solidy/crispen QMP
> - 1 rc to shake out brown paper bag bugs, then final release
> 
> block i/o performance (high CPU consumption)
> - memset can be removed (patch posted, queued by kwolf)
> - cpu_physical_memory_rw known, should gather data
> 
> block 1TB limit
> - sounds like integer issue
> - bug report needs to be updated (verify it's still happening in 0.12.4?
> - should be able to easily reproduce (can use lvm to create sparse volume)
> 
> sourceforge bug tracker...
> - sucks


Agreed.


> - unclear if there's active triage


I do. I go in every couple of weeks and go through the last two pages of bugs 
or so.


> - anthony prefers the launchpad instance


I prefer one tracker that more than just I look at. If that's launchpad, I'm 
fine with that.

Avi/KVM devs, what are your feelings?


> - alex likes the sf email to list, wuld be good to keep that feature


It looks (at first glance) that we can still have this functionality. It's 
certainly available to individuals.


> - had to migrate existing bugs (be nice if we could stop sf from growing)


A lot of the existing bugs are irrelevant and/or woefully out of date. I've 
been hesitant to go back and mess with too many old bugs for fear of making 
too much noise that I know isn't going to do anything useful (i.e. marking the 
100 oldest bugs as Closed - Out Of Date)


> - need more people involved w/ bug work


And need a better way for those of us that do to be able to get ahold of devs 
to look at things that are actually important to users.


> - possible bug-day before next release
>   - suggested June 1st


Personally (and in general for volunteer projects), weekends are better for 
bugs days. That said, I realize that most of the developers for qemu/kvm do 
this for their day job.


> 
> 0.12.4 bugs
> - migration regression...follow-up on email, open a bug ;-)
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Qemu-devel] Re: KVM call minutes for May 18

[Anthony Liguori]

On 05/18/2010 04:34 PM, Brian Jackson wrote:
> A lot of the existing bugs are irrelevant and/or woefully out of date. I've
> been hesitant to go back and mess with too many old bugs for fear of making
> too much noise that I know isn't going to do anything useful (i.e. marking the
> 100 oldest bugs as Closed - Out Of Date)
>    

One activity for bug day should be migrating bugs from SF to Launchpad 
that can be confirmed.  I don't know if SF has an expiration mechanism, 
but on Launchpad, you can mark a bug as needs info and if it isn't 
updated in 90 days, it automatically expires.

>> - need more people involved w/ bug work
>>      
>
> And need a better way for those of us that do to be able to get ahold of devs
> to look at things that are actually important to users.
>    

Part of the idea of bug day is to get devs in an IRC channel so that 
people can ask questions in real time about bugs.

>    
>> - possible bug-day before next release
>>    - suggested June 1st
>>      
>
> Personally (and in general for volunteer projects), weekends are better for
> bugs days. That said, I realize that most of the developers for qemu/kvm do
> this for their day job.
>    

Not everyone has the same weekend due to TZ/country differences.  That 
said, if the first bug day is successful, we can hold more and try to 
accommodate different groups of people.

Regards,

Anthony Liguori

>    
>> 0.12.4 bugs
>> - migration regression...follow-up on email, open a bug ;-)
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>      
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    

[Qemu-devel] Re: KVM call minutes for May 18

[Avi Kivity]

On 05/18/2010 05:29 PM, Chris Wright wrote:
>
> sourceforge bug tracker...
> - sucks
> - unclear if there's active triage
> - anthony prefers the launchpad instance
>    

Kernel bugs can go to bugzilla.kernel.org.  Of course it isn't always 
clear if a bug is a kernel or qemu bug.  Recommend we ask users to post 
to the list first, get some guidance, then the bug is either resolved or 
we ask them to file a bug report.  Should improve the experience for 
users and developers.

> - alex likes the sf email to list, wuld be good to keep that feature
>    

Pretty critical IMO.  The little attention the tracker gets is entirely 
due to the email.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.