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
