[Qemu-devel] KVM call minutes for May 18

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 ;-)

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

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.

quoted

- 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.

quoted

- 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

quoted

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
   

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.