This is just as I understand things.

Tapestry is test-driven, maybe all we lack is some communication around
tests' code coverage... Any feature in Tapestry is fully tested and then
the status of a release is the seen stability of the API and feature
set. The closer of the release's intended feature set, the closer of the
release.

As I say quite frequently, we were on production since Tapestry
4.0-alpha-3 and never had major bugs that we couldn't work around. Just
cosmetic improvements.

I see no better quality procedure than test-driven development with 100%
code coverage. Anyway, having the release vote just a few days avec the
rc-1 is quite... strange.

Le lundi 12 décembre 2005 à 09:50 -0500, Cliff Zhao a écrit :
> I like to know whether the Tapestry project has a quality policy about the
> stages of releases.
> 
> I understand that this is an open source project. It is different on many
> aspects with commercial products. Having said that, IMO, quality is a key
> component to every project/product. The quality can not be achieved by one
> or two smart people. It also needs a system/process. In every project I
> worked on, there is a criteria for entering a new stage, no matter what it
> was called; it may be beta/RC, or ST, AT. And the criteria is clear, and
> include statistics such as the number of new bugs, the number of bugs
> outstanding, etc. it aslo includes the status of documentation (user guide,
> installation guide, system test plans, etc). Design walkthroughs/code
> walkthroughs, you name it. A good idea/design from a smart people also
> benefit from the walkthroughs (based on my past experience). Some time,
> people brought in scenerios the author had never thought of.
> 
> I don't know whether Tapestry has any quality procedures. While, I followed
> up the mail-list quite awhile. My feeling is that Tapestry has no quality
> procedures.
> 
> I like to hear opinions from the Tapestry inner circle.
> 
> Best Regards,
> 
> 
> 
> On 12/12/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote:
> >
> > Erik Hatcher wrote:
> > >
> > > On Dec 11, 2005, at 2:00 PM, Jeff Lubetkin wrote:
> > >
> > > Jeff - this is a classic, and often annoying, response....
> > >
> > >     How about rather than holding an internal validation class, you
> > > write up the details as patches to Tapestry's documentation and submit
> > > them?  Then next time your developers need documentation, you can say
> > > RTM that you helped write.  :)
> > >
> > >     Erik
> > Hi again Erik :P. Rather you have a classic, and often annoying response
> > to the response. I don't know about Jeff, but usually, when I write a -1
> > to something like this is a "team" based approach. Is that, as a team
> > member of Tapestry, I would find the framework as lacking without proper
> > documentation.
> >
> > Howard called for a vote, that's a vote. Patches come later of course.
> >
> > --
> > Ing. Leonardo Quijano Vincenzi
> > DTQ Software
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to