commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sarah Murray <sarahkm1...@gmail.com>
Subject Re: [VOTE] Release BCEL 6.0 based on RC3
Date Fri, 06 Mar 2015 21:05:33 GMT
Sorry for the frustration I expressed. It was probably not the most
constructive way to voice my opinion.

A well described bug with a patch and a test case tends to get committed very
> quickly.


I'm not sure you've looked at the issue tracker lately. This really isn't
true as far as I can see, which is the cause of my exasperation. We're
blocking on a release until issues are resolved. But no one with commit
access is accepting changes, so we've just stalled out.

If you think some of the BCEL bugs are in this state and being over looked
> feel free to add a "What else is needed to get this committed?" question
> on the bug.


I'm happy to do this, but I think it'd be more annoying than helpful. Most
BCEL bugs I've seen are in this state. Putting the same comment on every
bug doesn't seem helpful. Of the four issues marked to 6.0, three of them
are stalled on having someone review and commit the patches:

   - 187 <https://issues.apache.org/jira/browse/BCEL-187> - has a test
   case. no committer review for 2 months
   - 188 <https://issues.apache.org/jira/browse/BCEL-188> - has a test
   case. no committer review for 2 months
   - 183 <https://issues.apache.org/jira/browse/BCEL-183> - has a test
   case. no committer review for 3 months

We don't have suppliers and customers at the ASF. We have a community. Everyone
> has a part to play.


The problem is that there's one area where help is really lacking and the
community can't contribute there because not everyone has the commit access
that's needed to get things flowing again. Perhaps we could add more
committers since it's currently a bottleneck? I've seen that work really
well when other projects either start to get overwhelmed or fizzle out.
E.g. Mark and Jerome both have submitted numerous high quality patches and
seem to be well-regarded members of the community. Can we give them commit
access? If we're nervous about maintaining high code quality we can add
guidelines such as there must be a test case for any commit and you can't
commit your own code - someone else needs to review it.

There was talk of an alpha release and it seems like folks are in favor of
it. Is there anything I can help to do with regards to that?

--S.


On Fri, Mar 6, 2015 at 12:10 PM, Mark Thomas <markt@apache.org> wrote:

> All,
>
> This is a community of volunteers. If you want to see something happen,
> demanding that other people do something is not the way to achieve your
> aims. At best your demands will have no impact. At worst, they will
> irritate folks that might have otherwise done the very thing you want to
> see happen.
>
> If you want to see a BCEL release then the best thing you can do is
> pitch in and help. Jira shows 49 open BCEL issues 4 of which are tagged
> for 6.0.
>
> Take a look at those 4 issues. What needs to be done to resolve them? Is
> a patch required? Is a review required? Would a test case that
> demonstrates the issue help (answer "yes!" unless one already exists).
>
> A well described bug with a patch and a test case tends to get committed
> very quickly. If you think some of the BCEL bugs are in this state and
> being over looked feel free to add a "What else is needed to get this
> committed?" question on the bug.
>
> Of the other 45 issues which ones need to be fixed in 6.0? 6.x? 7.0? I'd
> me amazed if all of those 45 were valid. Which ones can be closed? If
> you need versions created in Jira, ask. If you need more karma to assign
> issues to versions, ask. If you aren't sure what criteria should be used
> to decide which version to assign issues to, ask. Better still propose
> some criteria to start the discussion.
>
> We don't have suppliers and customers at the ASF. We have a community.
> Everyone has a part to play.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message