Open Stack

> On Feb 3, 2016, at 9:29 PM, Wang, Shane <shane.wang at intel.com> wrote:
> 
> 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?

This is a really good question. As Amrith pointed out in his response, earlier in the cycle we have a little more room to be flexible. So although the drivers on each team are primarily focused on reviewing and approving plans for large feature work, other reviewers (and even some drivers) are more likely to have time to work with you. The important thing is that having a potentially large number of patches all be submitted around the same time is less disruptive overall early in the cycle, when deadlines to land changes are generally less strict.

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

We do actually review bug fixes all the time, not just at the end of the cycle. Our *focus* near the end of the cycle is resolving issues that we consider to be critical before the release is prepared. Those issues are usually related to new code, introduced in the current cycle, and so the folks who did that original work are best positioned to be productive in fixing the problems, rather than someone looking at it for the first time. The thing we want to avoid between feature freeze and the final release candidate is having a lot of “churn” in the code, since that can introduce other issues we might not have time to spot.

Earlier in the cycle, we would generally welcome patches for any type of bug, though again, brand new contributors are likely to have a harder time with critical issues than more experienced contributors. So what you try to do during these events really should be based on who the participants are and what your desired outcome is.

Doug


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