The one reason I am leery of relying solely on autowatch (and dropping
participants) is that I am pretty sure that autowatch is not
retro-active. Meaning if you have commented on a issue and have been
receiving continuing notifications there is a danger you will no longer
get notifications. U
On 25 Jan 2013, at 1:41 PM, Steve Ebersole wrote:
> testcase reminder should be fixed now.
Thanks. Works.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
testcase reminder should be fixed now.
On Mon 25 Mar 2013 07:28:13 AM CDT, Steve Ebersole wrote:
> The field collects "participants" (creator, assignee, commenters).
> There is then a rule in the notification scheme which says that all
> participants should get notified.
>
> Autowatch is a little
The field collects "participants" (creator, assignee, commenters).
There is then a rule in the notification scheme which says that all
participants should get notified.
Autowatch is a little different than. Autowatch says to add a person
to the issue's watcher list when they comment on an iss
On 24 Jan 2013, at 8:25 PM, Steve Ebersole wrote:
> I am looking into the problem of hibernate-issues no longer getting Jira
> notifications. One possible reason is the use of the custom
> "Participants" field in our notification scheme. I am wondering if we
> ought to remove that rule from
I am looking into the problem of hibernate-issues no longer getting Jira
notifications. One possible reason is the use of the custom
"Participants" field in our notification scheme. I am wondering if we
ought to remove that rule from the notification scheme. Atlassian have
added an "autowatch
Well at this point I believe they are. The only ones *not* converted were:
1) Hibernate Shards
2) z - Hibernate 1.2
3) z - Hibernate 2
4) z - Hibernate Annotations
5) z - Hibernate Entity Manager
And I do not really see moving these, unless someone had a particular reason
why they shoud.
On Mo
+1 to move all the remaining projects to the new scheme.
Commons annotations cannot be ingested by core. It's a HSearch dependency and
HSearch is moving towards no runtime dependency on Core.
On 19 mars 2011, at 18:43, Steve Ebersole wrote:
> I moved Core, Java Persistence API and Metamodel Gen
Done did do it...
On Monday, March 21, 2011, at 02:00 pm, Max Rydahl Andersen wrote:
> tools should move to participant too.
>
> /max
>
> On Mar 19, 2011, at 11:06, Hardy Ferentschik wrote:
> >> 1) Tools
> >> 5) Shards
> >
> > Not sure about this ones
> >
> >> 2) Bean Validation
> >> 3) Bean V
Hi,
the workflow looks like this:
* A new issue is created -> the issue is in state "open"
* Work begins -> perform workflow action "start progress" -> issue is in
state "coding in progress"
* Work is done -> perform workflow action "attach pull request" (enter the
number of the pull request) ->
tools should move to participant too.
/max
On Mar 19, 2011, at 11:06, Hardy Ferentschik wrote:
>
>> 1) Tools
>> 5) Shards
> Not sure about this ones
>
>> 2) Bean Validation
>> 3) Bean Validation TCK
> But these two can be changed as well
>
>> 4) Commons Annotations (on a side note did we ever
> 1) Tools
> 5) Shards
Not sure about this ones
> 2) Bean Validation
> 3) Bean Validation TCK
But these two can be changed as well
> 4) Commons Annotations (on a side note did we ever decide on dropping this
> dep
> in core?)
No official decision, but I would like to drop it.
--hardy
___
I moved Core, Java Persistence API and Metamodel Generator then to use the
participant-based scheme. The ones still using the default notification
scheme are:
1) Tools
2) Bean Validation
3) Bean Validation TCK
4) Commons Annotations (on a side note did we ever decide on dropping this dep
in co
So what are the states involved in the custom workflow? Transitions?
On Saturday, March 19, 2011, at 09:30 am, Gunnar Morling wrote:
> Hi,
>
> while talking about JIRA configuration another thing came into my mind,
> which relates to the issue workflow.
>
> For Seam's JIRA Dan set up an enhance
Hi,
while talking about JIRA configuration another thing came into my mind,
which relates to the issue workflow.
For Seam's JIRA Dan set up an enhanced workflow, which provides a closer
integration with GitHub pull requests. For one there is a dedicated issue
field "pull request", but also the is
Right, for HV that notification scheme is used and I consider it useful,
too.
Gunnar
2011/3/19 Hardy Ferentschik
> I think it makes sense for all projects. I think Validator and Search are
> using it already.
> I not they should at least in my opinion.
>
> --Hardy
>
> On Fri, 18 Mar 2011 19:13
I think it makes sense for all projects. I think Validator and Search are
using it already.
I not they should at least in my opinion.
--Hardy
On Fri, 18 Mar 2011 19:13:01 +0100, Steve Ebersole
wrote:
> I will be changing Hibernate Core JIRA project to use the
> participant-based
> notific
I will be changing Hibernate Core JIRA project to use the participant-based
notification scheme. Should I change over any other projects while I am in
there?
What is participant-based notification? Basically, any participant (reporter,
assignee and all commenters) is automatically notified on
18 matches
Mail list logo
