cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Cocoon is not gump! ( was RE: [VOTE] preservation policy for third-party snapshot sources)
Date Tue, 29 Jun 2004 08:24:51 GMT
Antonio Gallardo wrote:

>Ralph Goers dijo:
>>Sylvain made it pretty clear that snapshots wouldn't be used in formal
>>Cocoon releases, so this procedure would never apply to those. In the past
>>this hasn't been followed.
>I disagree. Contrary to what you wrote. The rule was followed as long as
>we can. We try the most we can to stick to a released version. If you
>compare the lastest cocoon releases with older ones, you will see that we
>are distributing more released jars than before.

That's why this source-preservation thing only applies to very 
exceptional cases where we need a fix in a 3rd party library that's not 
yet included in an official release.

>Of course, this no a 100% applied rule to all jars, because some jars
>takes longer or have diferent cycles of releases. As a sample take the
>jexl. They never released a version. What we do is just to bundle a CVS
>version of that. And we stick to them as longer as we can.
>And yes, there are some exceptions to the rule. We use "common sense"
>while deciding when we can broke this rule. Sample:
>When an important bug is fixed on a 3rd party jar (from our POV) that has
>a current released version that seems to be important to us, we can
>repleace it with a CVS version that include the fix. Of course we often
>ask to the list. A lazy vote is done before updating it.
>>If that happens in the future I would want the snapshot
>>source with the release.
>Already was told that a date with minute precision is enough to get the
>right code from a CVS. If I ned to choice between adding 8-bytes to a jar
>name and adding 500 kB into the same jar. I prefer the 1.

Considering how discussion goes around this problem, I'm starting to 
consider David's proposal as the only compromise that will stop these 
useless frictions.

>As a Cocoon user I really don't care if the problem is at x line inside a
>3rd party lib. To me is enough to know that the fuunction f() in the 3rd
>party lib is not making the right work. How the function f() works it is
>up to the 3rd party jar developers.

C'mon Antonio! As a software developper, your goal is to build an 
application that works. And if you depend on that f() function and need 
to release to the customer, you will certainly get your hands dirty in 
the 3rd party code. That's one of the biggest advantages of opensource: 
you can fix it yourself.

>If people really care, we will had fixed all the problems in xalan, xerces
>and so on. And AFAIK, they have a big bug list now. They use Cocoon (or
>Xalan, Xerces and expect that the right community fix it). I understand
>this POV, because there is people with more experience than "this" user
>that can fix the bug without breaking other parts of the system.
>Now, the more experienced users (and developers?):
>They already have a lot of related project in the hard disk. They have the
>sources on the disk. They care to go into the f() function and discover
>why it does not work as expected. This kind of users are very few. I can
>include myself here. I have lot of sources of 3rd party jars in the PC. If
>I choose to follow the 3rd party jar, I prefer to follow it in the right
>community and tell them if there is a problem and perhaps how to fix it.

Who said the contrary? Nobody ever talked about forking 3rd party libraries!

>Also is important to note that, Cocoon often is ranted because our
>distribution is bigger than the any J2SDK! And adding java files to 3rd
>party libs will dramatically increase the size of the distrbution. This
>will be a really bloat to us.

Again and again and again: THIS IS ONLY ABOUT SNAPSHOTS OF 3RD PARTY 

So yes, the *cvs update* size may be bigger. But not the official distro.

Sylvain, getting bored.

Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message