commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [Math] "due-to" attribute in "changes.xml"
Date Thu, 31 Oct 2013 16:35:50 GMT
On 10/31/2013 05:18 PM, Gilles wrote:
> On Thu, 31 Oct 2013 15:53:29 +0000, sebb wrote:
>> On 31 October 2013 14:24, Gilles <gilles@harfang.homelinux.org> wrote:
>>> On Thu, 31 Oct 2013 13:37:02 +0000, sebb wrote:
>>>>
>>>> On 31 October 2013 13:26, Gilles <gilles@harfang.homelinux.org> wrote:
>>>>>
>>>>> Hello.
>>>>>
>>>>> Are there criteria about filling the "due-to" attribute of an issue
>>>>> record in the "changes.xml" file?
>>>>>
>>>>> Current practice seems that reporting an issue does not by itself
>>>>> warrants such an attribution.
>>>>> Indeed, as I understand it, the attribute is a place-holder for when
>>>>> an issue is fixed by a contributor who hasn't commit access. IMHO,
>>>>> this implies that the reporter (or another contributor) provided a
>>>>> patch or non-trivial insights that led to the fix.
>>>>>
>>>>> IOW, when a developer with commit access fixes a bug or implements a
>>>>> feature request mostly by himself, the name of the original reporter
>>>>> should not appear in the release notes, as if he were the contributor.
>>>>
>>>>
>>>> The person who raised the bug still took the trouble to do so.
>>>
>>>
>>> My question is still: is it sufficient?
>>> Without filing a bug report, the reporter is harming himself.
>>
>> Not necessarily. I've certainly reported bugs that don't affect me.
>>
>>> Also, some reports are only feature requests. I deem it quite unfair
>>> that
>>> the release notes would contain lines such as
>>>  * MATH-123456789: Algorithm Xxx implemented. Thanks to <reporter>.
>>
>> So?
> 
> It's just false.
> 
>> They still made the effort.
>> Maybe they did not provide a patch (yet) because it was not clear
>> whether it would be accepted or not.
>> And then the issue got fixed before they had a chance to provide the
>> patch.
> 
> Do we need to find corner cases just to not address the broader issue?
> 
>>
>> The JIRA issue itself provides very little clue as to how much effort
>> the person has expended.
> 
> Really?
> Attached patches are certainly more telling than a "Thanks to" line...
> 
>> But regardless, does it matter? It's probably quite a big step for
>> some people to file the JIRA.
> 
> Did I deny that?
> How is it related to what I asked?
> 
>>
>> But one can of course add comments to the due-to text which can be
>> used to clarify the perceived level of contribution.
> 
> That's what I'm suggesting: a fair report.
> So, is it possible to specify "Reported by" and "Fixed by"? That would be
> quite fine.
> 
> I repeat: up until recently I never noticed undue (IMHO) attributions.
> That would mean that the practice was _not_ as you seem to describe.
> Why would my question be met with dismissing comments?
> There is a field in "changes.xml": how and when do we fill it?
> I thought I knew (by looking at what others did) and now I see that it
> does not fit in some cases. Thus I ask for clarification.
> 
> Why does this have to be controversial?

I do not read any controversial comments here. You started a thread with
a specific question, and people answered with their opinion about this
topic. Here is mine:

I did not make a difference between a simple reporter and a contributor
that also provides a patch. In case the patch is provided by a different
person than the original reporter, I added both.

Actually I think that a person who raised the interest on a specific
feature / topics, which then really gets included in the software is
also worthwhile to mention as it really helps improve our software. E.g.
most of the things I did were related to feature requests by other
people and I am quite happy about that, because I know that somebody
really wants to use this feature.

If there should be two separate fields (reporter, patch-provider) or
just one, hmmm it depends on personal preference imho. I am fine with
just one field, but would not have a big problem if we have separate ones.

Thomas

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message