On 4/17/13 9:44 AM, Fernando Lozano wrote:
> 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
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
As a software developer myself, I can see how this is hard to follow,
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
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
Principal Software Engineer
JBoss by Red Hat