Open Stack

On Thu, Dec 14, 2017 at 10:09 AM, Thierry Carrez <thierry at openstack.org>
wrote:

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

Like others said, I don't see how slowing down the number of releases will
help those people to catch up with the project updates since features
should in theory be delivered at the same pace (if we don't loose developer
interests in developing features, which is one of my concerns).
Struggling with managing your day-to-day work really means you're in
trouble, and you need to find ways to prioritize your tasks, IMHO. Be
verbose, talk to your manager, try to find how you can increase time for
OpenStack. And yes, it's hard and I'm personnally facing problems too.


- 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 do intermediary releases, it doesn't really solve the problem either,
right?
There are actually two separate concerns from what I can read :
 - release coordination (tagging a milestone or branching a release)
 - governance and community coordination (electing a PTL or organizing a
PTG)


The former concern does seem to me less impactful now because thanks to a
couple of major improvements with Zuul and release management, we're less
depending on humans. And, again, doing intermediary releases would still
burn people's time, right ?
The latter is really a specific problem tied to a specific group of people
(namely the PTLs and the election team). Couldn't we rather review what
those people need to do and how we can help them to reduce the burden ?


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

Well, I do feel that if we decide to go with a 1-year timeframe for a
"coordinated" release, it would highly raise the price of that release.
Imagine what it means for someone who really desperately want to integrate
a feature that require some kernel update and fancy network driver thingy.
If you loose the target, you're a dead man for 1 year. Of course, you can
target an intermediary release but since we only "coordinate" yearly, how
can you be sure that packagers will ship your feature from that
intermediary release ?

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

--
> Thierry Carrez (ttx)
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171214/89ab2a08/attachment-0001.html>