Open Stack

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/0851
> >>> 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