tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Mattmann <chris.mattm...@jpl.nasa.gov>
Subject Re: [jira] Reopened: (TIKA-11) Consolidate test classes into a src/test/java directory tree.
Date Thu, 13 Sep 2007 13:21:22 GMT
Hi Thilo,

 It's a quality control issue -- as noted by Jukka in a later email, the
responsibility of closing an issue, or re-opening it for that matter, rests
in the hands of committers, the ones with write access to the code. This
ensures that there is some level of quality control for the system, and that
contributors, who each may be working on the same patch, don't attach a
patch for a particular issue, mark the issue as closed, then have someone
else come along, reopen the issue because they feel their patch is "better",
then have the original guy who closed it close the issue again (clearly, he
feels that his original patch was "better"), and so on and so forth. Believe
it or not, I've seen this happen: not necessarily in the Apache community,
but in practice. It's also worth noting that many of the JIRA workflow steps
blast out quite a few emails to the mailing lists, which could be construed
as spam to some people.

 That's why certain checks and balances are in place in most OS
organizations like Apache, and that's why there is a fairly well-defined
organizational structure, e.g., "contributors", "committers", a "PMC", etc.,
for all projects. I'm not saying that contributors can't be a part of the
process. To me, contributors should be able to "Create New Issues", "Attach
patches" to issues, comment on them, and so forth. In some rare occasions,
given permission by the committers, I could see a contributor given
permission to re-open an issue, especially a high priority one, and
especially if the regular committers are busy focused on other things. But
this surely didn't constitute that case. I guess the general rule of thumb
should be to have patience, and to work within the process. It's qualities
like that, and like Jukka said in another email, the ability to communicate
effectively (which working within the process demonstrates), that define the
role of being an Apache committer.

 My 2 cents :)



On 9/13/07 1:11 AM, "Thilo Goetz" <twgoetz@gmx.de> wrote:

> Hi Chris,
> Chris Mattmann wrote:
>> Keith,
>>  Please don't reopen issues without consenting the development list.
>> Ideally, the developers are the ones with permissions to orchestrate the
>> JIRA process. If you had waited a bit, you would have seen that I fixed this
>> issue in r575093, without the need to reopen the issue for this minor
>> modification.
>> Thanks,
>>   Chris
> that's one way of looking at this.  The other is,
> Keith opened an issue, it was closed as fixed, and
> things still didn't work.  It seems natural to me
> to reopen the issue, I would have done the same
> thing.  So you fixed it and closed the issue again,
> perfectly normal Jira workflow, wouldn't you say?
> Just my 2c.
> --Thilo

Chris Mattmann, Ph.D.
Key Staff Member
Modeling and Data Management Systems Section (387)
Data Management Systems and Technologies Group

Jet Propulsion Laboratory            Pasadena, CA
Office: 171-266B                        Mailstop:  171-246

Disclaimer:  The opinions presented within are my own and do not reflect
those of either NASA, JPL, or the California Institute of Technology.

View raw message