Markus, If you van connect me with someone who can tell me what needs the most attention and how to get started, I'd be happy to help.
//adam *Adam Lawson* AQORN, Inc. 427 North Tatnall Street Ste. 58461 Wilmington, Delaware 19801-2230 Toll-free: (844) 4-AQORN-NOW ext. 101 International: +1 302-387-4660 Direct: +1 916-246-2072 On Fri, Apr 1, 2016 at 3:46 AM, Markus Zoeller <[email protected]> wrote: > TL;DR: * The Nova bugs team needs more members > * Tasks: https://wiki.openstack.org/wiki/BugTriage > * Cleanup: http://45.55.105.55:8082/bugs-dashboard.html > * Meeting: https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam > * Etherpad: https://etherpad.openstack.org/p/nova-bugs-team > > > The Nova project has a large backlog of open bug reports. Around 5 new > bug reports get created everyday. It is not possible to make a > reasonable progress with the current number of people. The nova bugs > team needs to play a more active role and it needs more people for that. > > > What's in for you? > ------------------ > As bugs are in every software in every place, you will get around a lot. > Having a specific issue makes it also easier to ping other folks to > discuss this issue. Bug fixes also don't have the hard deadlines > imposed on feature patches. Being once on the bug triage side will > improve the quality of your future bug reports which will make them > more likely to get solved. > > > Current Status > -------------- > The main issue which slows down all following steps are bug reports > without the essential informations [1]: > * versions (nova, hypervisor, database, ...) > * steps-to-reproduce (with actual data) > * expected behavior > * actual observed behavior > * logs (in debug mode) > * topology (for example: nova-network vs. neutron) > Although this gets asked for when creating a bug report, the vast > majority of bug reports lack this information. Usually it takes one > to three roundtrips to get this information from the reporter. This > is time consuming. As we focus less on new features in Newton [2] I > have the hope that the bug list will get more attention. > > > Tasks > ----- > The tasks are listed in the wiki [3]. They "just" need to be done. > Repeatedly. Some on a daily basis, some less frequently. The cleanup > dashboard [4] is a tool I use personally but can be used by you too. > > The Neutron folks introduced a weekly rotating bug skimming duty and > they've made good experiences with it. This involves 1-3 people who > check new bugs reports if they are valid and provide the essential > information. We should adapt that [5]. > > In general we should aim for: > * respond to new bugs in a timely manner to get high quality reports > * clean up the "old stuff" (>= 1.5 years) > * spread the effort to multiple shoulders > * rotate the different efforts to prevent exhaustion and tunnel vision > > There is an ongoing effort to move the RFEs (request for feature > enhancements) away from the bug list [6] to allow us to be more > focused on faulty behavior of existing features people already rely on. > > > Organization > ------------ > * The nova bugs team has an IRC meeting [7] which allows us to sync > with each other. > * The cleanup dashboard [4] shows bug reports which need a check > based on the tasks [3]. > * The etherpad [8] can be used to avoid an overlap of efforts of > different people. > > > Education > --------- > It's possible to use the nova bugs team IRC meeting for education > sessions if this helps you. > I will also attend the summit in Austin in a few weeks. We can do an > unofficial "bugs mgmt process" crash course there if you like. Just > talk to me there (or beforehand in IRC) and we will find the time > and space. > At last I can offer a Google Hangout session if some are interested > in that. > > > How to Join? > ------------ > * Join the nova-bugs Launchpad group [9] > * Familiarize with the process [10] > * Attend the bugs meeting [7] > > With a few people who are willing to spent a few hours per week we > can create a well maintained bug list where issues get addressed > in a timely manner to consistently improve the quality of Nova. > > > References > ---------- > [1] "working on bug reports; what blocks you?": > http://lists.openstack.org/pipermail/openstack-dev/2016-March/089677.html > [2] "No spec approvals for new things until after the summit": > http://lists.openstack.org/pipermail/openstack-dev/2016-March/090370.html > [3] https://wiki.openstack.org/wiki/BugTriage > [4] http://45.55.105.55:8082/bugs-dashboard.html > [5] > https://wiki.openstack.org/wiki/Nova/BugTriage#Weekly_bug_skimming_duty > [6] "Wishlist bugs == (trivial) blueprint?": > http://lists.openstack.org/pipermail/openstack-dev/2016-March/089365.html > [7] https://wiki.openstack.org/wiki/Meetings/Nova/BugsTeam > [8] https://etherpad.openstack.org/p/nova-bugs-team > [9] https://launchpad.net/~nova-bugs > [10] http://markuszoeller.github.io/posts/2015/12/01/openstack-bugs/ > > > Regards, Markus Zoeller (markus_z) > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
