Adrian Brock wrote: Who has to do that is the JBoss XB developer, not Jay, as they may have the proper testing procedure. Alternatively, he can let it go through a complete QA cycle first, inside a CP release, if he feels confident the changes are absolutely backwards compatible. The product line is not using update1. When it does, it will be based on the opinions of the developers that work on the product and it will be fully tested by the QA department (and jbossxb developers if that is deemed necessary). So, contrary to what you say, the -brew versions are much safer than binaries that have not been properly QAed. Furthermore, adding <compatible> lines or not is a developers procedure, has NOTHING to do with how it was built.

Adrian Brock wrote: What prevents him to do this? He has the sources (doesn't even need to go look for it in the upstream repository, the source tar ball is in the src subdirectory of the thirdpart repo as well). So he can do the above as always. Ah, but here is where the symbiosis exist. Both sides by themselves have limited testing capabilities, but when they join forces we can have rock solid open source software. By QAing the produced libraries, the EAp project does some level of testing that could not be done by the "Average Joe Developer". On the other hand, by exposing to the world the -brew builds in the community branches as well, it gets exposed to real time situations that QA can't reproduce. As the fixes flow from both sides, based on both test paradigms, the software evolves to greater stability. "Internal" is having builds done in people's machines, which I can't reproduce. When we tried to reproduce the binaries used in JBoss AS some time ago, we found out that we did not know what the sources where, which patches had been applied and so one (ask Ryan). Now people can reproduce any -brew build they want, all info is available (we are working on improving even further the contents of the thirdparty repo to make it even easier). Using the machines in the RH intranet is as unaccessible as your laptop is the the rest of us. It does not make any difference where it is built -- having the sources and info to reproduce is all that matters for Open Source. This said, some folks from the MEAD project are preparing our publicly accessible version of Brew, called Koji. This is the same process that the Fedora community followed and the community there is really happy with their setup. Regards, Fernando

Adrian Brock wrote: The builds can handle source zips as well. Contrary to this junk OSes that you mentioned above, Linux has a working zip ;-) We just grabbed the tar balls because nobody ever complained before. We can try and standardize on zip tar balls for the future. We are still way ahead of the non-brew builds that have no source at all. For then, people have to go upstream to grab the sources, which they can still do for the -brew builds, the tar ball there is just a nicety. No, that is and must be a reduced JAR with just the source code to be loaded into Eclipse. We once put a complete upstream source ball there and people complained (explained to us how it was used etc). An artifact of the size of the original distribution tar balls which some upstream communities fill with JARs and such would make filling the local thirdpart a pain. We have two sources there, for different purposes. The one in lib is for some "JBoss Eclipse Effort" (or whatever Scott calls it), the one under 'src' is for re-building the binaries, complete, with everything (sometimes with dependency JARs). I don't understand what you mean. Only a few non-brew things in the thirdpart repo had the src jar for Eclipse. That has been preserved in the -brew ones. Not a single one has been lost. If you want that support please ask the developers of that component, we will follow suit. So you do with non-brew builds. Why have you mixed up the issues then? Leave -brew or non-brew out of it. It has no connection whatsoever. At the contrary: you know _exactly_ what changed, as anything (including any patches) used to build is included. Also, the original repository tag is also documented so, as before, one can go and use FishEye or whatever in the original source code repo. Exactly as before. Nobody is preventing you to go to svn.jboss.org. Where do you thing the sources came from? The tar balls are unaltered svn exports from the tag. Who said you can't? You could not on the days of the undocumented came from nowhere binaries that used to be uploaded, without any documentation, in the repository.jboss.org. It is named 1.3.4 because the sources were obtained with: http://gee.cs.oswego.edu/dl/classes/EDU/oswego/cs/dl/current/concurrent-1... Again, what is the difference w.r.t. to whre it is built? Anyone that grabbed a source tar ball from the upstream community called concurrent-1.3.4-src.tar.gz would assume that it is their 1.3.4. And AFAIK it should be. (We are going to add the exact commands used to download, and the commands used to build, like 'ant dist' or whatever is used, to the README.txt under 'src', to make it even easier). That depends on the component developers. We have no blank commit accesses. Some create a tag for us and we use it. Some just give us a patch to fix the problem and promise to include it in a future release (many times it is a backported patch). You will have to argue with each of them if you want a tag. We can just ask. Again, wrong kind of source, wrong place. See above. We always include the full source tar ball under 'src.. for the Exlipse one, we follow the component lead. They include, we include. We are considering adding it ourselves, but ideally that should be produced with the original component build (by 'ant dist' or whatever is used).