On 2016-04-06 10:25, Arun Raghavan wrote:
On Tue, 2016-04-05 at 19:28 +0300, Tanu Kaskinen wrote:
On Mon, 2016-04-04 at 13:35 +0530, Arun Raghavan wrote:
On 4 April 2016 at 13:01, David Henningsson <[email protected]> wrote:
On 2016-04-04 04:51, Arun Raghavan wrote:
On Sat, 2016-04-02 at 17:19 +0300, Tanu Kaskinen wrote:
On Thu, 2016-03-31 at 10:55 +0530, Arun Raghavan wrote:
We have two opposing axes to optimise along. The first is code quality,
as you point out. The other is developer motivation.
My feeling is that being able to work on things and push them out
without a long wait would help us feel more productive and motivated to
work on all aspects of the project.
With the current system, I think we're spending more and more time
reviewing things and waiting for reviews.
Having the ability to work on things and push them out provides a much
shorter path between "this is something I'd like to do" and "this thing
is done". This allows for a positive feedback loop, and I think that
will bolster our motivation to perform reviews, bug triaging, and
everything else.
That sounds like a plausible theory, although I don't personally feel
demotivated by the large amount of time it takes for my own patches to
get merged. If you really think that your review bandwidth increases if
your own patches go through faster, it seems to me that I could
prioritize reviewing your patches over others, and that way get more
reviews from you. What do you think?
I think that a this would help, but I fear that this does not do
enough. My preference is still the relaxed (but still existent) review
process that I outlined before, so that we have /some/ hope of catching
up on the patch and bug backlog over time.
Perhaps we can give it a try what I'd proposed for a couple of release
cycles and evaluate how things stand?
For me, the demotivator has been when we disagree on things, if someone
wants my patch written in another way: I can then choose either to rewrite
my code to someone else's liking even though I like it better the way it is
(which is demotivating), or I can choose to respond back which can lead to
long discussions, which is in itself demotivating and time consuming.
I don't know if there exists a good solution to that problem, but I've been
thinking along the lines of having areas of responsibility, where one is
effectively dictator for some pieces of the code, and someone else is
dictator for other pieces, etc.
I think there are ways to short-circuit long discussions, such as
setting aside some time for real-time discussion on IRC.
And perhaps it does make sense to take on more autonomy for certain
areas if that helps us work better. Note that my review proposal does
overlap with your suggestion in that non-external-facing changes can
be done more autonomously.
I'm not sure David's proposal overlaps with your proposal. David didn't
explicitly say whether these dictators themselves should still have
their own patches in their own area reviewed. I understood David's
proposal only as a tool to make it easier to decide things when there
are disagreements, so it wouldn't imply a right to skip reviews.
You're right, and it's quite possible I interpreted David's suggestion
differently from what he meant.
It's not a finished thought, but maybe the amount of review dictators
need for their own area is something like: simple patches can go
straight in, medium patches can have what we have today for simple
patches (i e wait a week, if there is no reviews then pushing can be
okay), and difficult world-changing patches should have a pair of extra
eyes.
And what patches are "simple", "medium" and "difficult" would be a
learning / gut feeling thing.
I quite like the general idea of having a dictator to resolve
disagreements, but it's not obvious how the code base could best be
divided. I don't myself have any particular desire to be the dictator
for any part of the code, but I don't have a problem with taking that
role either if it's given to me.
I guess the idea isn't different from subsystem maintainers in Linux,
but I'm not sure we're a large enough project to be able to divide up
responsibilities quite like that. Maybe there's a way to do it in a way
that makes sense, though.
As for Tanu's suggestion (to prioritise Arun and see if that helps) vs
Arun's (every committer is free to push their own stuff), I prefer
evaluating Tanu's, as I see a risk with Arun's proposal that committers will
spend more time on their own stuff rather than reviewing, if the former is
what gives that positive feedback loop.
To me, the latter gives a stronger positive feedback loop than the
former, because you're still waiting for a few days at least for each
patch set.
Does it really demotivate you if your patches take a few days to get
reviewed? I can understand that it's frustrating if reviews take weeks
or even months, but I have trouble imagining a few days of review delay
being a problem.
It does take away from the development flow, because it becomes hard to
continue working on a thing until there's a review (because otherwise
you're spending significant effort on rebasing). So instead of focusing
on a problem and completing it to your satisfaction, there's a waiting
period where you do other things, and when things are finally reviewed,
you've lost some amount of context and motivation.
If reviews are done within a week, then rebasing is not much of a
problem. Combine this with being less picky about patches and you get a
workflow that hopefully means that the local branch you worked on can be
simply be merged to master. Hence you can get some of the "this is done"
feeling when coding is done already.
You didn't directly address my earlier point of reviews saving time. I
hesitate to accept your proposal because I believe that reviews save
time overall (our time and our users' time), since there are fewer bugs
to investigate and fix later. Do you believe differently?
I thought I did, but to be explicit -- I have a different perspective
on this. I think we're balancing code quality vs. developer motivation,
and with the current resources that we have, the negative impact on
developer motivation is higher than the positive impact on code
quality.
From a broader perspective, therefore, I think our current process is
harming our ability to sustain the project.
I know you said you don't feel that much of a loss of motivation from
the waiting period, but I think that being able to go from "I want to
do this" to "this is done" much more quickly than now would actually
have a positive impact.
OTOH; the demotivation by suddenly discovering that your code / use case
broke because someone (who was not considering your particular use case)
pushed a patch is diminished if there are reviews. Hence the one week
"notice period".
Committers spending more time on their own stuff is something that can
just as well happen now
It doesn't make sense to spend more time on your own stuff, though, if
you produce patches faster than they get reviewed.
Sure, but this is also part of the problem. Even if you want to spend
more time on your own stuff, you end up not doing so because you're
waiting for your existing work to be completed.
And in the mean time, you can review some patches from other people? :-)
// David
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
