[openstack-tc] rescheduling bug-smash event

Amrith Kumar amrith at tesora.com
Thu Feb 4 12:51:36 UTC 2016


Shane, thanks for your email.

With 6 month sprints, I believe that people are certainly busy throughout the release cycle. It has however been my observation that in software development as it is in most other things, people are most busy just before the deadline. Think tax returns, auto-inspections, ...

For my own part, I think the best time for this kind of a bug smashing event would be in the first quarter of a release cycle. After all, it is not a sustained effort over a week or some such thing. It is one day. And part of the goal is to bring new people into the community. I submit to you that getting them into the process early in a cycle is preferable to getting them in when everyone is running around frantically trying to get everything buttoned down and ready to go.

It may be worthwhile to consider two bug smashing events, one early in the cycle with an intent of adding new people to the community etc., and one later in the cycle (around the compromise dates that Doug Hellmann mentioned in his email) for people to bring a focus to bug fixing before the release goes out the door.

I hope that better explains my rationale,

Thanks,

-amrith   



> -----Original Message-----
> From: Wang, Shane [mailto:shane.wang at intel.com]
> Sent: Wednesday, February 03, 2016 9:30 PM
> To: Amrith Kumar <amrith at tesora.com>; Doug Hellmann
> <doug at doughellmann.com>; Bhargava, Ruchi <ruchi.bhargava at intel.com>
> Cc: openstack-tc <openstack-tc at lists.openstack.org>; Bhandaru, Malini K
> <malini.k.bhandaru at intel.com>
> Subject: RE: [openstack-tc] rescheduling bug-smash event
> 
> Agree to plan it as early as possible. Say, at Austin summit, let's plan
> the next dates for O release. Actually we already planned two in China,
> and this is the first one to host globally and coordinate with more
> organizers.
> 
> I couldn't understand a little bit, you said it was good to host it
> between the summit and the first milestone. However, I heard people are
> busy with the features at that time, even core reviews don't have
> bandwidth to review and approve all helpful/necessary blueprints proposed.
> Some of the blueprints are postponed for several cycles and the owners
> complain. Do they have time to focus on bug fixes then?
> 
> And considering the release candidate cycle, is it the timing to fix bugs
> - RC, Testing, Bug Filing, Bug Fixing, another RC....? Of course, I think
> we might need to focus on CRITICAL bugs only, even for the whole RC (RC1-
> RC3), should we only fix high and critical bugs? So, I am thinking when it
> is the best timing for fixing and merging medium, low and other non-high
> or non-critical bugs for a product cycle.
> 
> Regards.
> --
> Shane
> -----Original Message-----
> From: Amrith Kumar [mailto:amrith at tesora.com]
> Sent: Wednesday, February 03, 2016 11:37 PM
> To: Doug Hellmann; Bhargava, Ruchi
> Cc: Wang, Shane; openstack-tc; Bhandaru, Malini K
> Subject: RE: [openstack-tc] rescheduling bug-smash event
> 
> I strongly urge all involved in this process to try very hard to have
> these kinds of hackathons as far away from crunch time as possible.
> 
> I love the idea and would like to participate and help with it, but I
> think the proximity to the deadline for Mitaka and future releases is very
> problematic.
> 
> First, that's the time when the maximum load is placed on the CI and the
> wait time and false-positive failures are maximum. Having a bug smashing
> event at that time strikes me as problematic.
> 
> Second, since the intent is to use these to bring new people into the
> community, it would provide a newbie the view of our infrastructure at its
> most stressed; such as the turnaround time to get a fix through the
> test/gate, and merged.
> 
> Much earlier in the schedule, like between R23 and R19 would, I believe be
> a good place for such an event; coming off the momentum of summit.
> 
> Thanks,
> 
> -amrith
> 
> > -----Original Message-----
> > From: Doug Hellmann [mailto:doug at doughellmann.com]
> > Sent: Wednesday, February 03, 2016 9:55 AM
> > To: Bhargava, Ruchi <ruchi.bhargava at intel.com>
> > Cc: Wang, Shane <shane.wang at intel.com>; openstack-tc <openstack-
> > tc at lists.openstack.org>; Bhandaru, Malini K
> > <malini.k.bhandaru at intel.com>
> > Subject: Re: [openstack-tc] rescheduling bug-smash event
> > Importance: High
> >
> >
> > > On Feb 2, 2016, at 4:14 PM, Bhargava, Ruchi
> > > <ruchi.bhargava at intel.com>
> > wrote:
> > >
> > > Doug
> > > The intent is to do this every release cycle till we can say that
> > OpenStack is an hardened product.
> > > So my recommendation to Shane would be to move the hackathon to the
> > > week R-4 as recommended - as March 7-9th
> >
> > I applaud the initiative, and commitment. However, if you’re going to
> > continue to hold events like this, please start scheduling them
> > earlier in the cycle, preferably between the summit and the first
> > milestone of a given cycle. R-4 is a compromise recommendation for
> > *this event* to allow for the fact that we’re asking you to reschedule
> > very soon after you’ve announced the dates.
> >
> > Coordinating the large number of contributors we have across all
> > OpenStack projects is challenging and involves the effort of many
> > people coming together and collaborating and making compromises
> > between upstream and downstream commitments. We carefully pace our
> > efforts over the course of a cycle, to ensure that we can make
> > progress on features, bug fixes, documentation, and all of the other
> > aspects of producing OpenStack, while being respectful of the need for
> > community members to fulfill their other responsibilities. The
> > schedule is planned around summit time, so that everyone has a common
> > set of dates to work from. We publish the schedules and ask all of the
> > teams to follow them when selecting timing for mid- cycles, sprints,
> > etc. As far as I can tell, feedback from previous occurrences of these
> > bug-smash events regarding ideal timing has been ignored, resulting in
> > continuing the selection of dates that conflict with the release
> schedule.
> >
> > Please stop doing that. I don’t believe it’s your intent, but you are
> > being disruptive, rather than helpful. We want you to succeed, but to
> > do that, we need you to work with us, too.
> >
> > Holding events late in the cycle increases the chance that they will
> > fall during a period where most of the folks you would want to be
> > mentors or reviewers are heads-down on other work for which they have
> > committed to a hard deadline. Pressuring people to participate in your
> > events by implying that they are the only or best way to address
> > stability issues, while ignoring the cadence of the release cycle and
> > introducing a large spike in review loads at an inopportune time,
> > demonstrates a lack of understanding about how to participate
> > constructively in the project and will result in the reaction from
> > this time repeating: the people you want to help you will be annoyed
> > and either ignore you or deprioritize participating so they can
> concentrate on their existing commitments.
> >
> > If you choose instead to work with the existing contributors to
> > schedule events during a period of lighter load, such as the time
> > leading up to the first milestone, you will increase the chances the
> > events will have a good pool of available mentors, result in
> > successful onboarding of new contributors who will have a further
> > opportunity to contribute over the cycle, and that the patches
> > submitted will be reviewed in a timely way. It also will offer the
> > chance to have fixes back-ported cleanly into early stable releases,
> > and allow for time to rework patches that need to be revised before they
> are accepted and included in the current release.
> >
> > Doug
> >
> > > Thanks
> > > Ruchi
> > >
> > > -----Original Message-----
> > > From: Doug Hellmann [mailto:doug at doughellmann.com]
> > > Sent: Tuesday, February 2, 2016 1:07 PM
> > > To: Wang, Shane <shane.wang at intel.com>
> > > Cc: openstack-tc <openstack-tc at lists.openstack.org>; Barrett, Carol
> > > L <carol.l.barrett at intel.com>; Bhargava, Ruchi
> > > <ruchi.bhargava at intel.com>; Bhandaru, Malini K
> > > <malini.k.bhandaru at intel.com>
> > > Subject: Re: rescheduling bug-smash event
> > >
> > > Shane,
> > >
> > > During our meeting today the TC agreed to request that the event be
> > moved at least to week R-4, which according to the schedule [1] is
> > March 7-11. As you will see in the meeting logs [2], several folks
> > also expressed a preference for moving the event into the first
> > milestone period of the Newton release. We don’t have a schedule for
> > that, yet, but if you are willing to move it that far I can come up
> > with some estimated dates for you this week.
> > >
> > > Please let me know which of those two options you prefer.
> > >
> > > Doug
> > >
> > > [1] http://docs.openstack.org/releases/mitaka/schedule.html
> > > [2]
> > > http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-02-02-20.01.
> > > lo
> > > g.html
> > >
> > >> On Feb 2, 2016, at 12:38 PM, Doug Hellmann <doug at doughellmann.com>
> > wrote:
> > >>
> > >>
> > >>> On Feb 2, 2016, at 12:46 AM, Wang, Shane <shane.wang at intel.com>
> wrote:
> > >>>
> > >>> Hi Doug,
> > >>>
> > >>> I notice that you added a topic about bug smash date onto the
> > >>> agenda
> > of Tuesday TC meeting.
> > >>> Because I am in China, and the meeting will happen in my midnight
> > (4:00am), can you please help to communicate with the TC members at
> > that IRC meeting and make a decision together?
> > >>
> > >> Yes, I’m on the TC so I will be in the meeting anyway, so I can
> > >> take
> > care of it. If anyone else interested in the discussion wants to
> > attend, please do so. The meetings are open to everyone.
> > >>
> > >> Doug
> > >>
> > >>>
> > >>> I will read the meeting log as long as I get up. Many thanks.
> > >>> --
> > >>> Shane
> > >>> -----Original Message-----
> > >>> From: Doug Hellmann [mailto:doug at doughellmann.com]
> > >>> Sent: Saturday, January 30, 2016 3:27 AM
> > >>> To: openstack-tc
> > >>> Cc: Wang, Shane; Barrett, Carol L; Bhargava, Ruchi; Bhandaru,
> > >>> Malini K
> > >>> Subject: rescheduling bug-smash event
> > >>>
> > >>> TC Members,
> > >>>
> > >>> This week a "Global Bug Smash" event involving quite a few of our
> > >>> larger contributing companies was announced as scheduled for March
> > >>> 2-4 [1]. Those dates overlap exactly with our feature freeze
> > >>> deadline
> > for Mitaka, so I contacted the organizers of the event (some of whom
> > are copied on this thread) about rescheduling the event. After
> > explaining my concerns, I suggested that the event move to the
> > following week, possibly March 7-9.
> > >>>
> > >>> Most everyone was understanding about the conflict. Shane Wang
> > >>> seems
> > to be the main person coordinating the event, and he thought it was
> > very possible it could be rescheduled. He did want to get the TC's
> > opinion of the new date. I've added the topic to our agenda for
> > Tuesday's meeting [2], but also wanted to give everyone notice of that
> > in case you have questions that Shane or I can answer before then.
> > >>>
> > >>> For now it would be most helpful to have a clear indication of
> > >>> your
> > preference for Mar 2-4 or 7-9, though I'll be happy with any dates
> > between Mar 7-11, if for some reason 7-9 doesn't actually work for the
> organizers.
> > At some point, I would also like to brainstorm ideas for avoiding this
> > sort of scheduling conflict in the future, but that can come after
> > we've dealt with the more immediate issue.
> > >>>
> > >>> Doug
> > >>>
> > >>>
> > >>> [1]
> > >>> http://lists.openstack.org/pipermail/openstack-dev/2016-January/08
> > >>> 51
> > >>> 9
> > >>> 6.html [2]
> > >>> https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee
> > >>
> > >
> >
> >
> > _______________________________________________
> > OpenStack-TC mailing list
> > OpenStack-TC at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-tc


More information about the OpenStack-TC mailing list