[jboss-dev] Re: [Fwd: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer exception when getting keys, values, or entry's in the ConcurrentHashmap]

[Fernando Nasser]

Adrian Brock wrote:
> Look, you're missing the whole point of the 
> jboss.org/EAP seperation.
> 
> Average Joe Developer (not Redhat) that wants to fix a bug
> isn't going to know about CP releases or have access to the QA
> department.
> 
> His procedure is to create update1, see that JBossXB needs
> to be tested and if he wants to test it himself, he
> downloads JBossXB and runs its testsuite.
> 

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.


> That we do more than this for EAP is a different issue.
> 

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.


> When JBoss is developed by only Redhat employees I'll agree
> with you. Since hopefully that is never going to happen
> we need to remove all this "Redhat internal procedure"
> from the open source project.
> 

"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


> On Fri, 2007-12-14 at 09:10 -0500, Fernando Nasser wrote:
>> Adrian Brock wrote:
>>> Copying to the main dev-list.
>>>
>>> Yes, you can change it. But ideally you should test it first.
>>> i.e. checkout the jbossxb 1.0.0SP1 tag 
>>> and modfiy the build to use update1
>>>
>>> That's what compatiblity means. ;-)
>>>
>> 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.
>>
>>
>>> This clearly wasn't done for the brew release
>>> since there's no maven release for that.
>> 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).
>>
>>> Which is another reason why brew is bad.
>>>
>> 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.
>>
>>> http://repository.jboss.com/maven2/oswego-concurrent/concurrent/
>>>
>>> On Wed, 2007-12-12 at 16:41 -0500, Jay Howell wrote:
>>>> Hey Adrian,
>>>> I've made a new version of the concurren 
>>>> lib(https://svn.jboss.org/repos/repository.jboss.org/oswego-concurrent/1.3.4-jboss-update1) 
>>>> , and I've changed my build-thirdparty.xml file, but I also need to add 
>>>> an entry in the jbossxb(component-info.xml) to establish compatibility.  
>>>> The current version that is current in branch 4.2 for jbossxb is 
>>>> 1.0.0.SP1.  My question is, Do I need to make a new version of jbossxb, 
>>>> or can I check the compatibility changes in for 1.3.4-jboss-update1into 
>>>> jbossxb 1.0.0SP1?  I see that the entry that put the compatibility entry 
>>>> in for 1.3.4-jboss(1.0.0.GA_CP01-brew) was just added to that version 
>>>> and a new version(directory) was not added.  I can easily either make a 
>>>> new version(called ???) or I can just change the version that's there.
>>>>
>>>> Thanks, Jay:)
>>>> email message attachment (Re: [JBoss JIRA] Commented: (JBAS-5072) Fix
>>>> null pointer exception when getting keys, values, or entry's in the
>>>> ConcurrentHashmap)
>>>>> -------- Forwarded Message --------
>>>>> From: Jay Howell <jhowell at redhat.com>
>>>>> To: Adrian <abrock at redhat.com>
>>>>> Subject: Re: [JBoss JIRA] Commented: (JBAS-5072) Fix null pointer
>>>>> exception when getting keys, values, or entry's in the
>>>>> ConcurrentHashmap
>>>>> Date: Wed, 12 Dec 2007 15:04:59 -0500
>>>>>
>> _______________________________________________
>> jboss-development mailing list
>> jboss-development at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-development