How to verify a patches for non-public AS

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Fernando Lozano
Hi,

> The fix should be fixed in the upstream AS7 project at the same time or
> earlier, so the reporter can verify there. Granted, there can be
> relevant differences between upstream and EAP. For the reporter to
> verify against EAP itself they'll need to wait for the EAP beta or
> whatever that contains the fix.
If that's true (All fixes from Red Hat Customer Support on the internal
EAP three shoud be applied to the public AS trunk also) it's great news
for the community. But is it true? Is that a commitment from Red Hat, or
is that an optional, internal policy that some developers may choose to
ignore?

As a software developer myself, I can see how this is hard to follow, as
each issue may generate differente fixes for different source trees (as
and eap) and each one would have to be tested alone. I'd guess most
fixes are done and tested only on the eap tree and the as tree never
sees them. :-(

Of course a new AS release cycle would start from the latest EAP tree,
but then, is anyone from Red Hat actually migrating / adapting fixes
from the current production EAP to the AS source tree? If they are
really doing this, are the fixes goin to the same AS branch as the
inicial EAP release, or are they going to the AS trunk, and so the AS7
tree never sees fixes from EAP6, as they would be going to the AS8 tree?


[]s, Fernando Lozano

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Jaikiran Pai
In reply to this post by Thomas Diesler
On Wednesday 17 April 2013 08:12 PM, Thomas Diesler wrote:


Yes, thats it. I provide a patch to the best of my knowledge and there is no way to verify that patch until it is part of a release.
Not even in a testcase?

-Jaikiran



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Thomas Diesler
testcase is fine if there is a convention that a resolved issue can be closed when it passes a given test case. If I write the testcase I test what I patch, which is not the same as the reporter verifying the patch and making the transition from resolved to closed. 

On Apr 17, 2013, at 4:45 PM, Jaikiran Pai <[hidden email]> wrote:

On Wednesday 17 April 2013 08:12 PM, Thomas Diesler wrote:


Yes, thats it. I provide a patch to the best of my knowledge and there is no way to verify that patch until it is part of a release.
Not even in a testcase?

-Jaikiran



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




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Thomas Diesler
let me add that the reporter can't even see my test case
 
On Apr 17, 2013, at 4:48 PM, Thomas Diesler <[hidden email]> wrote:

testcase is fine if there is a convention that a resolved issue can be closed when it passes a given test case. If I write the testcase I test what I patch, which is not the same as the reporter verifying the patch and making the transition from resolved to closed. 

On Apr 17, 2013, at 4:45 PM, Jaikiran Pai <[hidden email]> wrote:

On Wednesday 17 April 2013 08:12 PM, Thomas Diesler wrote:


Yes, thats it. I provide a patch to the best of my knowledge and there is no way to verify that patch until it is part of a release.
Not even in a testcase?

-Jaikiran



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



_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

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




_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Brian Stansberry
In reply to this post by Fernando Lozano
On 4/17/13 9:44 AM, Fernando Lozano wrote:

> Hi,
>
>> The fix should be fixed in the upstream AS7 project at the same time or
>> earlier, so the reporter can verify there. Granted, there can be
>> relevant differences between upstream and EAP. For the reporter to
>> verify against EAP itself they'll need to wait for the EAP beta or
>> whatever that contains the fix.
> If that's true (All fixes from Red Hat Customer Support on the internal
> EAP three shoud be applied to the public AS trunk also) it's great news
> for the community. But is it true? Is that a commitment from Red Hat, or
> is that an optional, internal policy that some developers may choose to
> ignore?
>

I'm an engineer; I can't make corporate commitments. All I can do is
tell you what we do now, which is based on an internal policy, not just
a whim. Before merging a fix into the eap branch we verify that either
an equivalent fix has been made in upstream master, or that somehow the
fix is irrelevant to master. Merges into EAP require a review, same as
merges into upstream master, and enforcing this policy is part of the
review process.

> As a software developer myself, I can see how this is hard to follow, as
> each issue may generate differente fixes for different source trees (as
> and eap) and each one would have to be tested alone. I'd guess most
> fixes are done and tested only on the eap tree and the as tree never
> sees them. :-(
>

Your guess is incorrect. :)

And yes, maintaining two separate branches is a lot of work!

> Of course a new AS release cycle would start from the latest EAP tree,
> but then, is anyone from Red Hat actually migrating / adapting fixes
> from the current production EAP to the AS source tree? If they are
> really doing this, are the fixes goin to the same AS branch as the
> inicial EAP release, or are they going to the AS trunk, and so the AS7
> tree never sees fixes from EAP6, as they would be going to the AS8 tree?
>

The AS project is only maintaining the master branch, which targets AS8.

>
> []s, Fernando Lozano
>


--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

jtgreene
Administrator
In reply to this post by Brian Stansberry
Can we please take this internal Red Hat process discussion off the community list? I am sure that 99% of our external subscribers would rather not get spam about this kind of thing, and much rather see technical topics :)

On Apr 17, 2013, at 9:25 AM, Thomas Diesler <[hidden email]> wrote:

> Again, how can a reporter verify a patch that I cannot apply to the jboss-as code base?
> It's a patch for the OSGi 4.2 Framework that nowadays only exists in jboss-eap, AFAIK.  
>
> On Apr 17, 2013, at 4:22 PM, Brian Stansberry <[hidden email]> wrote:
>
>> Any fix in EAP has a bugzilla behind it, and QE verifies all bugzillas before they are closed.
>>
>> The fix should be fixed in the upstream AS7 project at the same time or earlier, so the reporter can verify there. Granted, there can be relevant differences between upstream and EAP. For the reporter to verify against EAP itself they'll need to wait for the EAP beta or whatever that contains the fix.
>>
>> On 4/17/13 3:07 AM, Thomas Diesler wrote:
>>> Folks,
>>>
>>> when I resolve a bug for non-public AS, how can the reporter verify that the patch is working so that the issue can be closed?
>>>
>>> cheers
>>> --thomas
>>>
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

jtgreene
Administrator
In reply to this post by Thomas Diesler
This is another example of an internal Red Hat process discussion that has no business on a list thats supposed to be about technical design and community releases.

On Apr 17, 2013, at 5:16 AM, Thomas Diesler <[hidden email]> 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 <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>>
>> _______________________________________________
>> jboss-as7-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> JBoss OSGi Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
>
>
>
>
> _______________________________________________
> jboss-as7-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Fernando Lozano
In reply to this post by Brian Stansberry
Hi Brian,

Thanks for clarifying the issues. In summary, the current process Red
Hat follows is that fixes to EAP6 are applied also to AS trunk (which is
now AS8), not to AS7 branches. I can check the fix worked by getting the
latest sources from AS8, hoping there isn't any new code in AS8 which
interferes with my test cases.

But in the event AS8 gets productized and we have an EAP7 release based
on it, EAP6 will still be supported for some time. Fixes applied to EAP6
will then:

a) Continue to be applied to AS8 trunk;
b) Wait for a new comunity development series, that is, AS9, and them be
applied there alongside fixes to EAP7;
c) Never be applied to the AS tree, which would get only fixes for EAP7,
and then I'll have to wait for a new EAP6 source zip on ftp.redhat.com;
d) Red Hat will decide what to do during EAP7 alphas.

Please correct me if I'm wrong, today I as a customer have no way to get
sources from EAP4 or EAP5 to check a fix, I have to wait for the
EAP4.x/5.x release and corresponding source zip. I hope things improve
from EAP6 to EAP7+.


[]s, Fernando Lozano

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Fernando Lozano
In reply to this post by jtgreene
Hi Jason,

> Can we please take this internal Red Hat process discussion off the community list? I am sure that 99% of our external subscribers would rather not get spam about this kind of thing, and much rather see technical topics :)
>
While I understand and agree that Red Hat internal processes are
off-topic in this mailing list, the thread started with a question that
affects jboss users and customers: how (and when and where) fixes to EAP
lands on AS.

I hope I'm not the only customer in this list who would like to be able
to check a fix to an issue before the next EAP release. :-)


[]s, Fernando Lozano

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

jtgreene
Administrator


On Apr 17, 2013, at 11:42 AM, Fernando Lozano <[hidden email]> wrote:

> Hi Jason,
>
>> Can we please take this internal Red Hat process discussion off the community list? I am sure that 99% of our external subscribers would rather not get spam about this kind of thing, and much rather see technical topics :)
>>
> While I understand and agree that Red Hat internal processes are
> off-topic in this mailing list, the thread started with a question that
> affects jboss users and customers: how (and when and where) fixes to EAP
> lands on AS.
>
> I hope I'm not the only customer in this list who would like to be able
> to check a fix to an issue before the next EAP release. :-)
>

If you want the details, the easiest way to know that is to look at the bugzilla list for the release:

For example:

https://bugzilla.redhat.com/buglist.cgi?classification=JBoss&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&version=6.1.0&product=JBoss%20Enterprise%20Application%20Platform%206

--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Fernando Lozano
Hi,

>> I hope I'm not the only customer in this list who would like to be able
>> to check a fix to an issue before the next EAP release. :-)
> If you want the details, the easiest way to know that is to look at the bugzilla list for the release:
>
> For example:
>
> https://bugzilla.redhat.com/buglist.cgi?classification=JBoss&query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=POST&bug_status=MODIFIED&bug_status=ON_DEV&bug_status=ON_QA&bug_status=VERIFIED&bug_status=RELEASE_PENDING&bug_status=CLOSED&version=6.1.0&product=JBoss%20Enterprise%20Application%20Platform%206
This tells me someone else verified. It won't help me if I'm the issuer
and I want to check the fix works for my particular case, to give
feedback if not.

The only way I can check for myself, **before the next release**, is
either to get a "nightly" build, which AFIK aren't availabe for EAP, or
grab the sources and compile myself, which is also not possible with
EAP. Using the AS trunk is not ideal, but better than wait the next EAP
release.


[]s, Fernando Lozano

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
Reply | Threaded
Open this post in threaded view
|

Re: How to verify a patches for non-public AS

Marek Neumann
In reply to this post by Fernando Lozano
On 04/17/2013 06:42 PM, Fernando Lozano wrote:
While I understand and agree that Red Hat internal processes are 
off-topic in this mailing list, the thread started with a question that 
affects jboss users and customers: how (and when and where) fixes to EAP 
lands on AS.

I hope I'm not the only customer in this list who would like to be able 
to check a fix to an issue before the next EAP release. :-)
+1 Fernando!

Marek

_______________________________________________
jboss-as7-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
12