>From my point of view, having strict filters showing information of a particular types in a particular places is better than having to read everything mixed in one place.
I also read the whole dev-list, but I'd prefer to have information that is simple marks and notifications to be sorted out of that have-to-read flow and be represented in a form easily browsable. And in my opinion, JIRA interface is much more comfortable for that purpose than mail readers. I may be wrong, of course. Vasily -----Original Message----- From: Alexey Petrenko [mailto:[EMAIL PROTECTED] Sent: Thursday, December 28, 2006 3:58 PM To: [email protected] Subject: Re: Re: How to mark ready-to-integrate JIRAs? 2006/12/28, Zakharov, Vasily M <[EMAIL PROTECTED]>: > What I propose is a simple tag, like [fix_available] or such, > added to a JIRA comment. It's no more difficult than adding > the same tag to a mail subject. There is no such strong restrictions for dev list because I, for example, reads almost all dev messages. That's not true for commits list. SY, Alexey > -----Original Message----- > From: Alexey Petrenko [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 28, 2006 3:39 PM > To: [email protected] > Subject: Re: Re: How to mark ready-to-integrate JIRAs? > > 2006/12/28, Zakharov, Vasily M <[EMAIL PROTECTED]>: > > Adding a mark to a JIRA comment sends a mail to commits list, > > and may be easily filtered out of "ALL the JIRA traffic". > Right. > But in this case ALL the contributors should use exactly the same > phrase in comment. This could be not so easy. > > > > > And as these messages are only interesting to committers, > > I think it's more convenient to have them in commits list, > > not the dev-list. > > > > Also, that way you can search in JIRA database, in addition > > to mail. > > > > Vasily > > > > > > -----Original Message----- > > From: Alexey Petrenko [mailto:[EMAIL PROTECTED] > > Sent: Thursday, December 28, 2006 3:27 PM > > To: [email protected] > > Subject: Re: Re: How to mark ready-to-integrate JIRAs? > > > > 2006/12/28, Zakharov, Vasily M <[EMAIL PROTECTED]>: > > > > > > > You can skip, comitters do not skip, you are happy. Unbelievable? > > > I have nothing against the [tag] idea, I just wonder how would it > > help. > > > What would be the difference of reading such marks and reading > > > harmony-commits list? :) > > It's easy... commits list receives ALL the JIRA traffic. But messages > > which needs additional community attention will be sent to dev. And > > number of such issues is much less then ALL. > > > > SY, Alexey > > > > > -----Original Message----- > > > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Egor Pasko > > > Sent: Thursday, December 28, 2006 8:05 AM > > > To: [email protected] > > > Subject: Re: How to mark ready-to-integrate JIRAs? > > > > > > On the 0x24D day of Apache Harmony Vasily M. Zakharov wrote: > > > > > maybe we adopt a new [tag] for traffic? > > > > > > > > It seems to me, everybody would soon skip it without looking. > > > > > > You can skip, comitters do not skip, you are happy. Unbelievable? > > > > > > > And those few who wouldn't, read harmony-commits list anyway and > see > > > any > > > > changes occuring. > > > > > > > > It's better not to write a mail at all, than write it marking > "this > > is > > > > non-important message, > > > > don't read it" - the result is the same, but the traffic is higher > > and > > > > more time is spent. > > > > And we already have a list for such "non-important" messages, > > > > harmony-commits. > > > > > > > > Vasily > > > > > > > > > > > > -----Original Message----- > > > > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED] > > > > Sent: Thursday, December 28, 2006 1:00 AM > > > > To: [email protected] > > > > Subject: Re: How to mark ready-to-integrate JIRAs? > > > > > > > > > > > > On Dec 27, 2006, at 4:14 PM, Zakharov, Vasily M wrote: > > > > > > > > > Hi, all, > > > > > > > > > > There're many issues in our JIRA that can be closed or > integrated > > > > > with no much effort. Issues with simple patches but with no > > > > > "patch available" flag set, "Won't Fix" issues, non-bug > > differences > > > > > are all good examples. > > > > > > > > > > And closing an issue (in a right way) is always good as it > allows > > > > > that issue to be forgotten and put off everybody's mind - one > > > problem > > > > > less to think of. > > > > > > > > > > But we have no effective instrument for a contributor to attract > > > > > a committer's attention to a particular small issue. > > > > > > > > The dev list? Please? > > > > > > > > > > > > > > For now the only way to do that is writing to the dev-list, > > > > > which is not very effective - we already have traffic high > enough. > > > > > Moreover, that information is only relevant to committers, who > are > > > > > minority (though very important) in the list - all other > > > contributors > > > > > would read such a message for nothing, wasting their time. > > > > > > > > Not true! There are lots of benefits to this kind of thing, such > as > > > > raising more public awareness about the issue, let people with > ideas > > > > review and comment, etc > > > > > > > > > > > > > > The other way used now to attract a committer's attention, is > > > setting > > > > > "Patch available" flag. But I can only set it on my own issues, > > > > > and setting it is probably not appopriate for "Won't Fix" > issues. > > > > > > > > > > Probably we could introduce some keyword, for example, > > > FIX_AVAILABLE, > > > > > that contributors could add to their comments to the respective > > > JIRAs > > > > > and committers could search for using conventional JIRA search? > > > > > > > > > > This way the committers' reaction to patches could be faster and > > > > > choosing the right issue to put efforts to would be more > > > well-founded > > > > > and information-based for committers. > > > > > > > > > > What do you think? > > > > > > > > I'm going to be a stick in the mud here - the best way to get > > > > people's attention should be dev list - maybe we adopt a new [tag] > > > > for traffic? > > > > > > > > geir > > > > > > > > > > > > > > Vasily Zakharov > > > > > Intel Enterprise Solutions Software Division > > > > > > > > > > -- > > > Egor Pasko > > > > > >
