hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: Assigning issues
Date Sat, 28 Feb 2015 00:03:58 GMT
On 27 February 2015 at 19:52, Michael Osipov <michaelo@apache.org> wrote:
> Am 2015-02-27 um 11:28 schrieb Oleg Kalnichevski:
>>
>> On Thu, 2015-02-26 at 21:16 +0100, Michael Osipov wrote:
>>>
>>> Oleg,
>>>
>>> is there any reason why you don't assign issues to yourself if you
>>> planning to fix/already fixed them?
>>>
>>
>> What would be the benefit of that other than extra noise on the mailing
>> list? For the past ten years I cannot think of a single case of multiple
>> people racing to commit a fix for an issue.
>

+1

> There is no need to have all tickets sent to the ML at all. You can always
> subscribe to a JIRA query. It will have the same effect.

Huh?
Surely that requires extra work to set up.

> At Apache Maven, we aren't only a few people so there is a vital case for
> that. It is a clear indication that someone feels responsible for this issue
> and will take care of. The reporter in turn will be informed about that.

The Maven project is a very different beast.

We don't tend to bother with assignments on Commons either, even
though it is a bigger project.
But then most people only work on a few components.

>> I also no point in raising tickets for stuff like HTTPCLIENT-1621,
>> HTTPCLIENT-1622 and similar. Just fix the damn thing, commit the fix,
>> add an entry to release notes if it is news worthy and move on.

I disagree that 1621 and 1622 are too trivial to need JIRAs; they both
potentially affect the API.

But there will be some changes (Javadoc fixes/spelling errors etc)
that can just be fixed.

>
> I have a different, broader view on that. While you might think this is
> useluess or too much, you have to think from the opposite side:
> When I plan to upgrade any dependency in my POM, I check the changelog in
> JIRA first. Everything is documented as an issue, I do *not* need to read
> the Subversion/Git log for that.

Agreed it should not be necessary to read SCM history te get such info.
In fact I would say that commit log messages should be considered
ephemeral - they mainly have use in explaining the commit message.
Comments that are needed to understand the code should be in the code
or other docs, not in the log message.

> It is simple: documentation, predictability and open communication to the
> community.
>
> Moreover, I tend to forget stuff if I do not file an issue for that.
>
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
> For additional commands, e-mail: dev-help@hc.apache.org
>

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


Mime
View raw message