Will we get EAP 6.1.1 ?

[fsl]

Hi there,

I see there's already an EAP 6.1.1 release available to subscribers, but no binaries for the community -- the latest one on jboss.org is EAP 6.1.0.

I though it was a Red Hat promise to post all binaries for the community, so we don't have to build AS 7.x updates from sources. It looks like someone forgot abou the community site, I understand how people are so busy with new Java EE, new Fedora and etc, but please don't let us community users down. :-)

So, any plans (and timeframe) for putting this download on the community site? Or will Red Hat again leave community users again with no updated binaries, no big fixes? :-(

I hope we do not need to discuss again how the latest development release (Wildfily 8.0.0) won't serve community users as well as updates for the "stable" comunity releases. ;-)

[]s, Fernando Lozano

[jaikiran]

It's already answered here JBoss EAP 6.1.1 not on download page?

[jaikiran]

Fernando Lozano wrote:

I hope we do not need to discuss again how the latest development release (Wildfily 8.0.0) won't serve community users as well as updates for the "stable" comunity releases. ;-)

I don't know what you mean there. But WildFly is and will continue to be the community edition with frequent releases.

[fsl]

My understanding of the thread you linked to is: the community  gets no bug fixes for AS7 from now on, and don't even have the option of building those from the sources -- unless and when Red Hat releases an EAP 6.2, 6.3, ...

Put in another way: the community doesn't get any access, not even source, to 6.1.y., 6.2.y, etc. Those patches / tags / branches are not in the community sources repo, and we don't have acces to the EAP source repo.

It's like part of AS/EAP is closed source. :-( IMHO, not a way to expand the community, which shrinked significantly since Red Hat brought JBoss. Please educate me if my understand was faulty.

While those 6.1.y patches are applied to Whildfly, if you run AS7 (or EAP 6.1.0 from the community) you may want/need the bugfixes but not the new features (and risk for incompatibilities) that Wildfly brings in. That's what I didn't wanted to discuss again. :-( It's not fair: Red Hat wants the community help to debug newer EAP releases, but when they go production level ("productized") Red Hat limits its support for the community. It's not as bad as it was during the EAP5 days, but still not good.

This also let me woried about the Wildfly "frequent releases". Will they stop when Wildfly becomes EAP7? Will then the community be denied access to (some) Wildfly bugfixes?

[jaikiran]

You have too many questions in that posts and valid ones (most of which have already been answered in various other threads), but anyway I or someone else would have answered it again here. But it's really tiring to keep refuting incorrect accusations like:

It's like part of AS/EAP is closed source. :-(

IMHO, not a way to expand the community, which shrinked significantly since Red Hat brought JBoss.

It's not as bad as it was during the EAP5 days, but still not good.

There is no conspiracy going on here. It's plain and simple - there's a fast paced community binary free to use anywhere by anyone and there's a productized commercial binary, certain versions of which are made available for free under some restrictions and certain other versions of which are made available as paid subscription. Why would you want a paid subscription and not pay for it and why is it a bad thing if it's a paid subscription?

[fsl]

No conspiracy seen, IMHO it's just a matter of conflicting interests: Red Hat wants paying customers, but the commuity wants continued access to the code they helped mature and improve. I understand very well how subscription works and how it's supposed to be justified, but I can't agee the way it's applid to JBoss AS/Wildfly and I guess I'm not the only one in the community.

Please, no false accusations from either side. Nothing I sad is wrong or innacurate AFAIK, and a defensive posture from Red Hat empolyees or fans won't help either.

1. If the comunity doesn't have access to the sources for 6.1.1 as part of AS7 source repos, they are indeed closed sources. Having they only on the Wildfly sources repos (where they had to be modified for a different code base, if they were compatible with the new code base) is a way to make it very hard for the community to apply then to AS7.

2. EveroyoneI talk (outside Red Hat) agrees the community lost many good people and they say the cause is Red Hat policies regarding AS / EAP binaries. Red Hat should work on bringing them back, not dismissing their statements as false. I see many people using Glassfish, Websphere Community and TomEE where they usued to deploy JBoss AS. :-(  I'd like that to change. It's not about they think Glassfish and etc are better, it's they think they'll get bugfixes from then but not from JBoss AS.

3. During the EAP5 days there were no EAP binaries for the communiy, and the AS binaries weren't updated. That's a simple fact. Nowadays EAP 6.x.0 binaries are posted to the community, which is an improvement, but do not solves (1) entirely.

Red Hat gets free help from the community during early development, it should pay back by giving access to the sources and binaries produced afterwards, of course without support. There's much more value from the subscription besides access to bug-fixes. If Red Hat can't show this to customers and has to "close" bug fixes sources, I guess it's a problem with either Red Hat sales or support services, but the community should' be spoiled because of that.

It works the way I'd like with RHEL, so we have CentOS and similars. But AFAIK there's no way to create a "CentBOSS" because the sources are not available. But if I'm mistakes and the sources for EAP 6.1.x are available somewhere with public access, please enlightnen me.

You don't have to agree with me that the community should get sources and binaries for EAP 6.1.1. But you cant accuse me of making "incorrect accusations".

You (and bobody else) also didn't answered the important question: Are EAP 6.1.1 sources available for the community to download, and not as part of Wildfly? Where? The answer could make my claim about "part closed source" incorrect. But as I have not found those sources, and nobody told me where I can get them, I suppose I'm right.

PS: I am a big Red Hat fan and supporter, not only for JBoss AS, but also for many other products and open source projects. But this won't keep me from keeping an unbiased judgement. As a community member and IT pro my interests are not allways aligned with Red Hat ones, as they won't be allways wih other companies and communities. Nothing wrong with that.

[ctomc]

There ware many many many threads about sources of EAP.

in short sources are always available on red hat's ftp server ftp://ftp.redhat.com/redhat/jbeap/

one of more recent threads about this: Re: Re: Building EAP6 from source

--

tomaz

[fsl]

Thanks for the pointers. The site ftp://ftp.redhat.com/ seems to be offline. :-( But I hope it'll be back son.

I have not read it all, but it seems it's still very very hard to build EAP from sources. That's an argument for 6.1.x binaries on the community site.

[jaikiran]

Fernando Lozano wrote:

Thanks for the pointers. The site ftp://ftp.redhat.com/ seems to be offline. :-(

I've raised an internal ticket to see what's wrong.

[jaikiran]

Fernando Lozano wrote:

it should pay back by giving access to the sources and binaries produced afterwards, of course without support.

Although it's already been mentioned a lot of times earlier, I would just like to clarify, one more time, a few points about the EAP6 and WildFly community split and why demands like "Red Hat should payback users by making available EAP6 binaries for free" are invalid:

- JBoss EAP is based on a paid model. Certain versions of JBoss EAP are made available for free so that a certain set of users who have the intention of paying for subscription at a later point of EAP release will find moving their applications from a development environment (the free EAP Alphas for example) to production environment (the paid subscription for the Final EAP versions) easier. This way they won't have to run into any kind of trouble they might find trying to use the community edition WildFly (previously known as JBoss AS) for development and then moving to paid EAP versions.

- JBoss EAP is not for users who want the binaries of all versions to be freely available. It doesn't cater to that set of users. If users want all binary versions to be free, they should stick with the community versions (WildFly). And yes, it's a fact that WildFly releases are faster paced and will also includes some new features along with bug fixes in released versions. If a certain set of users don't like to use newer versions of community releases (WildFly) because of the presence of new features, then the option is to go the JBoss EAP paid subscription route since that's meant to cater to the needs of users who don't want new fast paced new features to possibly affect the stability of releases.

[jaikiran]

jaikiran wrote:

Fernando Lozano wrote:

Thanks for the pointers. The site ftp://ftp.redhat.com/ seems to be offline. :-(

I've raised an internal ticket to see what's wrong.

The ftp server issue has been fixed and it's accessible now.

[fsl]

Thanks for clarifications and lokking after the ftp server issue. I'm well aware of Red Hat business model. I work using RHEL and EAP subscriptions, but I'm also a user of Fedora, CentOS and JBoss AS/Wildfly, among other products. I do recomend EAP and RHEL subscriptions to many customer who buy my services. I argue with then about the value of having a subscription and so access to Red Hat Support Services. But I also recognize scenarios where Fedora, CentOS, AS7 or Wildfly would be a better fit.

My complain is: if JBoss AS and Wildlfy were exactly like Fedora, all would be fine. It would be even better if EAP where like RHEL. But they aren't.

Let's see recent JBoss AS/EAP history:

1. There's a new AS generation: new internal architecture (JMX Microkernel > JBoss Microcontainer > JBoss Modules) or a new Java EE Spec. Those happen within a few YEARS interval

2. Then the community side has intense development, and many alpha,RC,beta and CR releases. Everyone is excited with the new features

3. Then the community code matures, Red Hat releases a new EAP product and start selling subscriptions. Red Hat employees start working on the internal, "production" branches and prioritising paying customers. Nothing wrong with that!

4. After a while, development on the community side stops. No new releases, either binary or source. Community gets stuck with old dependencies (like old hibernate, cxf and mojarra) and has to live with bugs already solved on the EAP branches or on the upstream projects, like Tomat and JGroups

5. If the community doesn't get lucky, and there isn't either a new Java EE release, or a new AS reachitecture, it may spends years living with old code and old dependencies

On the other side, if you are a Fedora user, you know you'll get two or three new releases each year, and you know you'll get almost daily package updates from yum. Even if you don't want to migrate to the latest release, you'll still get package updates -- bug fixes, stability fixes, and performance fixes, sometimes even new features -- for the previous release. You won't get stuck with old code and dependencies for years to come.

Of course each new Fedora release can have improvements that break compability and even imature code that causes instability, like when it moved to PulseAudio and Gnome 3. But for the most time you know you can move to the latest release (or wait for the next) and live with that -- your Apache web service, Samba server, PostgreSQL database and most server-side or user-level packages won't break nor become unusable. And more importantly, you won't get stuck with an old Firefox, LibreOffice or Gimp release. You'll still get recent GCC, Java, PHP, Python and Eclipse improvements. Most of the times you can even isolate the "breaking" updates using alternative packages from Fedora itself, for example, moving Gnome 3 for KDE or XFCE.

If a Fedora user really thinks he needs more "stability", he can use CentOS and similars. He won't have to wait for a new RHEL 6.x release to get improvements, because Red Hat releases updated SRPMs for each package fix and CentOS compiles that, so yum will update your CentOS release to be, most of the time, at the same level as the latest RHEL fixes.

For what I understand of your explanations and other discussions, there would NOT be possible to have a CentAS, because there's no acess to fixes between point releases for the community. That would be fine for most community users IF we could expect Wildfly (and current AS7) to continue getting frequent updates like Fedora gets. But they don't. Today we get **some** AS7 updates as EAP6.x comunity downloads, and we don't know if Wildfly will continue to have frequent updats once its productized. AFAIK Wildfly won't.

For me, Fedora uses who help improve what will become the next RHEL are paid back as frequent package releases that go on even when there is a newer Fedora release. And they are also paid back as RHEL SRPM packages the community can use to have something equal do RHEL (CentOS, White Box, etc) without having to pay for Red Hat Support Services.

But JBoss AS/Wildfly users do not get those things back. They help improve the code (as testers, bloggers, application developers) and awareness of the next EAP product, but then they are forced to pay for Red Hat Support Services if they want later bug fixes. IMHO that is not fair. And you can talk to any Java developer to see how this has hurt JBoss EAP mindshare. How they started to look after Glasdish, TomEE, Resing and others after Red Hat brough JBoss Group.

The fact is, as far as I understand: JBoss AS/Wildfly users DON'T have access to all sources, like Fedora and RHEL/CentOS users do have. Even if we get updated EAP 6.x.y sources on ftp.redhat.com they are not updated at each SP or patch released to EAP customers. Fedora and RHEL/CentOS users go get those in-between updates.

Is there at least a commitment to continue releasing Wildfly sources and binaries, or will it "freeze" like AS7, AS5 and AS4?

Is the current "workaround" of providing EAP 6.x binaries to the community only a temporary measure, so the community gets involved with Wildfly, and in the future, after Red Hat releases EAP7, will we stop getting EAP 6.x, and worse, never get EAP 7.x without a subscription?

I do concede that current AS7 situation is a big improvement over AS4 and AS5 situation. Having community EAP 6.x binaries is better than not having those (as it was the case with AS4 and 5). But if would be only fair to community users having get 6.x.y binaries and sources, not only as source tarballs on the ftp server, after release, but also as a set of continuous updates like Red Hat does for Fedora and RHEL.

[marklittle]

"Is there at least a commitment to continue releasing Wildfly sources and binaries, or will it "freeze" like AS7, AS5 and AS4?"

Yes. WildFly will move forward at a much faster rate than AS6 and AS7 have done. Of course it will increment version numbers as it does so, so WF8, WF9 etc.

"Is the current "workaround" of providing EAP 6.x binaries to the community only a temporary measure, so the community gets involved with Wildfly, and in the future, after Red Hat releases EAP7, will we stop getting EAP 6.x, and worse, never get EAP 7.x without a subscription?"

What we're doing with product binaries for free will continue and we already have extended it to other products/projects. It's not specific to EAP.