I'm thinking it's unhealthy to have over 1000 JIRAs patch available.
Reviewers should be more welcome and should review patches from
everywhere to increase developers and future reviewers.
I'm not completely sure patch managers will make it healthy, however,
changing the process (and this discussion) would help improving our
mindsets.
@Committers: Let's review more patches!
@Developers: You can also review patches you are interested in. Your
comments will help committers to review and merge them.
(As you can see, the above comments don't have any enforcement.)
Regards,
Akira
On 2/4/15 13:52, Karthik Kambatla wrote:
+1 to patch managers per component.
On Wed, Feb 4, 2015 at 12:29 PM, Allen Wittenauer <a...@altiscale.com> wrote:
Is process really the problem? Or, more directly, how does any of
this actually increase the pool beyond the (I’m feeling generous today) 10
or so committers (never mind PMC) that actually review patches that come
from outside their employers on a regular basis?
Process might not be the source of the problem, however process will help
with alleviating the current situation.
It would definitely help to increase the number of active committers. Might
not be very hard to add committers, but I don't know of a way to make them
active.
To put this in perspective, there are over 1000 JIRAs in patch
available status across all three projects right now. That’s not even
counting the ones that I know I’ve personally removed the PA status on
because the patch no longer applies...
On Feb 4, 2015, at 12:10 PM, Chris Douglas <cdoug...@apache.org> wrote:
Release managers are just committers trying to roll releases; it's not
an enduring role. A patch manager is just someone helping to track
work and direct reviewers to issues. The job doesn't come with a hat.
We could look into a badge and gun if that would help.
Badge and gun will ensure a single patch-manager per component.
This doesn't require a lot of hand-wringing or diagnosis. If you're
concerned about the queue, then start trying to find reviewers for
viable patches.
We should also close issues that require too much work to fix, or at
least mark them for "Later". Not every idea needs to end in a commit,
but silence is frustrating for contributors. -C
+1.
On Wed, Feb 4, 2015 at 10:24 AM, Colin P. McCabe <cmcc...@apache.org>
wrote:
I wonder if this work logically falls under the release manager role.
During a release, we generally spend a little bit of time thinking
about what new features we added, systems we stabilized, interfaces we
changed, etc. etc. This gives us some perspective to look backwards
at old JIRAs and either close them as no longer relevant, or target
them for the next release (with appropriate encouragement to the
people who might have the expertise to make that happen.)
best,
Colin
On Mon, Feb 2, 2015 at 2:03 PM, Mai Haohui <ricet...@gmail.com> wrote:
+1 on the idea of patch managers. As the patch managers should have
good expertise on the specific fields, they are more productive on
reviewing the patches and driving the development on the specific
fields forward.
~Haohui
On Mon, Feb 2, 2015 at 12:55 PM, Chris Nauroth <
cnaur...@hortonworks.com> wrote:
I like the idea of patch managers monitoring specific queues of
issues,
perhaps implemented as a set of jira filters on different values for
the
component or label fields. Right now, looking at the whole HADOOP
backlog
is daunting. Using separate filtered review queues could help each
reviewer focus and parallelize the work.
Going back to the topic of tooling, I just learned that multiple
Apache
projects have expressed interest in Gerrit recently. I've never used
Gerrit and so can¹t speak in favor or against it, but I think
consistency
across Apache has benefits. Issue INFRA-2205 has the discussion. The
issue is closed, but there is recent discussion in the comments.
https://issues.apache.org/jira/browse/INFRA-2205
Chris Nauroth
Hortonworks
http://hortonworks.com/
On 2/2/15, 3:56 AM, "Chris Douglas" <cdoug...@apache.org> wrote:
Many projects have unofficial "patch managers":
http://cp.mcafee.com/d/avndxMs73gsrhojju7f9TsdTdETsuK-MOOMrhKUqem76kkkPqdT
7HLIcILCQrK6zB5ByVEVKrJ3mURCj1heIpRwoH4HjBPpeIpRwoH4HjBPvKLKeSovW_8ELfK6zB
zHTbFICzBPAQrICzBNXBHFShhlKCNOEuvkzaT0QSyrhdTVeZXTLuZXCXCM0qQqEdSB0zmBenPU
pgDIvbGX3ifG_2v0U35JDoCnlS6AvyrnlH0KxVAL7VJNwnu7cLCzALq6JNHcCsjH6to6aNaQVs
54ZgHlrJmSNf-00CS4QSjobZ8Qg1rpS9Cy2fCpuod42QqS-B3qr1LpPX92TieQHh
People who go through outstanding issues, ensuring that each has
reached a stable state, or at least a willing reviewer. -C
On Mon, Feb 2, 2015 at 3:45 AM, Steve Loughran <
ste...@hortonworks.com>
wrote:
Given experience of apache reviews, I don't know how much time to
spend
on it. I'm curious about Gerrit, but again, if JIRA integration is
what
is sought, Cruicible sounds better.
Returning to other issues in the discussion
1. Improving test times would make a big difference; locally as
well as
on Jira.
2. How can we clear through today's backlog without relying on a
future
piece of technology from magically fixing it?
For clearing the backlog, I don't see any solution other than
"people
put in time". I know its an obligation for committers to do this,
but I
also know how little time most of us have to do things other than
deal
with our own tests failing. As a result, things that aren't viewed
as
critical get neglected. Shell, build, object stores, cruft cleanup,
etc,
I think people that care about these areas are going to have to get
together and sync up. For some of the stuff it may be quite fast
‹people
may not have noticed, but a few of us have brought the build
dependencies forward fairly fast recently, with a goal of Hadoop
branch-2/trunk being compatible with recent Guava versions and java
8.
I've been doing some S3/object store work the last couple of
weekends;
that's slow as test runs take 30+ minutes against the far end, test
runs
jenkins doesn't do. If anyone else wants to look at the fs/s3 and
fs/swift queue their input is welcome.
And of course AW went through the entire backlog of shell stuff & a
lot
of the not-in-branch-2 features.
So where now? What is a strategy to deal with all those things in
the
queue?
