AFAIU, the source tree is jboss-eap, which is not accessible for the reporter. 
So the reporter cannot make the transition from Resolved to Closed.

All would be good if the reporter can verify the patch before it goes in the next EAP release, can he?

On Apr 17, 2013, at 12:57 PM, Heiko Braun <hbraun@redhat.com> wrote:

I think what Darran is trying to say, is that any EAP issue needs to have an upstream issue first anyway.
That mean you can verify it against the community builds.

On Apr 17, 2013, at 12:55 PM, Thomas Diesler <thomas.diesler@jboss.com> wrote:

The upstream process is fine.

This thread is about bugs reported against EAP 6.1.0.Alpha1

On Apr 17, 2013, at 12:47 PM, Darran Lofthouse <darran.lofthouse@jboss.com> wrote:

All issues should be going upstream first anyway into what is currently marked as AS8 if that is what you mean?


On 17/04/13 11:16, Thomas Diesler wrote:
Hi Darran,

this does not work. There is no living soul in QA that could verify my patch and guarantee that it works for the reporter. For good reason, we distinguish between Resolved/Closed - only the reporter of an issue can make the transition from Resolved to Closed.

I'd say this process is broken.

I suggest we do all work in jboss-as until an issue is not only Resolved but also Closed. Closed issues can be picked up by QA and the associated commits cherry-picked and whatever other voodoo they do in their non-public systems.

As it stands now the reporter has to wait until the next EAP release before he can know whether his issue is truly fixed. That is obviously broken, isn't it?

cheers
--thomas

On Apr 17, 2013, at 10:20 AM, Darran Lofthouse <darran.lofthouse@jboss.com> wrote:

Thomas - to get it into EAP it must have also had a BZ which means it
would be verified by QE.

Regards,
Darran Lofthouse.


On 17/04/13 09:12, Thomas Diesler wrote:
Folks,

when I resolve a bug for EAP, how can the reporter verify that the patch is working so that the issue can be closed?

cheers
--thomas
xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx




xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx 



_______________________________________________
jboss-as7-dev mailing list
jboss-as7-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev


xxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thomas Diesler
JBoss OSGi Lead
JBoss, a division of Red Hat
xxxxxxxxxxxxxxxxxxxxxxxxxxxx