On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Egor Pasko wrote:
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps
though. I wonder
Egor Pasko wrote:
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Egor Pasko wrote:
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Egor Pasko wrote:
On the 0x223 day of Apache Harmony Geir Magnusson, Jr. wrote:
Egor Pasko wrote:
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
Geir Magnusson Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps though.
I wonder if we should just open things up a bit and let any user modify
a JIRA and see what happens.
+1 Provided we don't
Tim Ellison wrote:
Geir Magnusson Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps though.
I wonder if we should just open things up a bit and let any user modify
a JIRA and see what happens.
+1
Egor Pasko wrote:
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps
though. I wonder if we should just open things up a bit and let any
user modify a
Alexey Petrenko wrote:
So I think that *require* from issue creator to check the fix *before*
not the best solution.
Since noone on earth can prevent you from submitting your patch to a new JIRA
and link
it to the original one, this is not a *real* requirement. I guess this is just
a hint to
On the 0x221 day of Apache Harmony Alexei Fedotov wrote:
Guys,
I was trying to compare public announcements of new patches with
private ones. The point of announcing new patches on harmony-dev@ is
the following: anyone is welcome to verify a new patch.
If no volunteers are willing to do
Guys,
I was trying to compare public announcements of new patches with
private ones. The point of announcing new patches on harmony-dev@ is
the following: anyone is welcome to verify a new patch.
If no volunteers are willing to do so, then a committer or a bug
submitter will do the job.
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps though.
I wonder if we should just open things up a bit and let any user
modify a JIRA and see what happens.
geir
Sian January wrote:
Hi,
I have just
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps
though. I wonder if we should just open things up a bit and let any
user modify a JIRA and see what
15 Nov 2006 11:31:39 +0600, Egor Pasko [EMAIL PROTECTED]:
On the 0x222 day of Apache Harmony Geir Magnusson, Jr. wrote:
I thought we had it configured that when a JIRA is modified, the
reporter is notified directly... I'm not sure that really helps
though. I wonder if we should just open
Sian,
This is a good catch. I have the following justification for 3. I
think it is better process when a bug submitter validates a patch
*before* commit to ensure that it is good. Also it validates the patch
*after*. This worth to be requested via public alias.
Why a bug submitter should do a
From the one hand, fix checking by issue creator is good...
But from the other hand, bug submitter could be a person who is using
Harmony snapshot and does not know how to apply the patch and build
Harmony...
It is also possible that issue creator is not subscribed to Harmony dev list...
So I
14 matches
Mail list logo
