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.
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.
// David
_______________________________________________
pulseaudio-discuss mailing list
pulseaudio-discuss@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
