Re: Assigning issues
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. 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. 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. 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 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. 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-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Assigning issues
On 27 February 2015 at 19:52, Michael Osipov micha...@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-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Re: Assigning issues
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. 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. Those who want elaborate organizational processes and bureaucratic protocols are welcome to run for the European Parliament. Oleg - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
Assigning issues
Oleg, is there any reason why you don't assign issues to yourself if you planning to fix/already fixed them? Michael - To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
