[openstack-dev] [all] Switching to longer development cycles
thierry at openstack.org
Thu Dec 14 09:09:21 UTC 2017
Matt Riedemann wrote:
> On 12/13/2017 4:15 PM, Thierry Carrez wrote:
>> Based on several discussions I had with developers working part-time on
>> OpenStack at various events lately, it sounded like slowing down our
>> pace could be helpful to them and generally reduce stress in OpenStack
>> development. I know people who can spend 100% of their time upstream can
>> cope with our current rhythm. I just observe that we have less and less
>> of those full-time people and need to attract more of the part-time one.
>> If this proposal is not helping developers and making OpenStack
>> development less painful, I don't think we should do it:)
> Given I have the luxury of working mostly full time upstream, I've
> obviously got a skewed perspective on this whole discussion.
> I am interested in which part time developers are having issues keeping
> up and how, i.e. are these core team members that don't feel they can be
> good core reviewers if they aren't around enough to keep up with the
> changes that are happening? I could definitely see a case like that with
> some of the complicated stuff going on in nova like the placement and
> cells v2 work.
There was two kind of feedback.
- People who would like to get more involved (and become core
developers) but can't keep up with what's happening in their project or
reach the review activity necessary to become core developers. A number
of projects are struggling to recruit new core reviewers, so I think
reducing expectations and slowing down the pace could help there.
- People in projects that are more mature (or packaging projects) where
the process overhead (coordinated releases, elections, PTG
preparation...) ends up representing a significant chunk of the work.
For those it felt like longer cycles would reduce that overhead and give
them more time to do real work.
> If we're talking about part time contributors that are contributing bug
> fixes here and there, docs patches, random reviews, I'm not sure how
> this is substantially better for them.
No, I'm more talking about someone who can dedicate one day per week to
OpenStack development, and who currently struggle to be part of a team
where everyone has to be >80% to keep up with the rhythm.
> We've said in this thread that project teams are encouraged to still do
> intermediate releases, often. And we're still going to be working on
> features, so how does that help slow things down for the part time
My hope is that by reducing the "coordinated release" pressure, we'd
encourage project teams to adopt a rhythm that is more natural for them.
Some teams would still be pretty active with lots of intermediary
releases, while some others would have an easier time.
> If *everyone* must slow down then that's going to be a problem I think,
> unless we do something like alternating intermediate releases where
> there are new features and then only bug fixes, something like that - up
> to the discretion of each project team as they see fit.
> I haven't seen anyone mention this yet either, but if "slowing down"
> begins to look like we're entering maintenance mode, I don't think
> that's going to attract new developers and it's likely to mean long-time
> key maintainers are going to lose interest and start looking elsewhere
> to scratch their itches. It's hard to say what would happen. I can
> certainly keep myself busy with docs patches and bug fixes until the
> cows come home.
All good points.
It feels like we have to dive deeper into the consequences in terms of
release cadence (intermediary/coordinated) and in terms of stable branch
maintenance before we can make a call.
Thierry Carrez (ttx)
More information about the OpenStack-dev