Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <38178.10.0.0.5.1088490202.squirrel@10.0.0.5>
In-Reply-To: <6.1.2.0.2.20040628182631.024712c0@mail.dslextreme.com>
References: <40E01FE8.7060005@apache.org>
    <OF2310A7DC.E899F652-ONC1256EC1.004D1445@sundn.de>
    <6.1.2.0.2.20040628182631.024712c0@mail.dslextreme.com>
Date: Tue, 29 Jun 2004 00:23:22 -0600 (CST)
Subject: Cocoon is not gump! ( was RE: [VOTE] preservation policy for
     third-party snapshot sources)
From: "Antonio Gallardo" <agallardo@agssa.net>
To: dev@cocoon.apache.org
User-Agent: SquirrelMail/1.4.3a-0.f1.1
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Importance: Normal

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.

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.

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.

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.

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.

>  For stuff still in dev I'm not sure it
> matters whether the source goes out or not since it is pretty risky to
> deploy such a thing in production.

This is very relative idea. In some cases a non released version can be
more stable than the released version. Anyway, it is OT.

BTW, a philosophical question: How we will do that?
If we stripping a jar before ditribution means that we will not distribute
the real CVS. And that is a problem....

To summarize: Cocoon is not gump!

Best Regards,

Antonio Gallardo