commit policy (was: Re: SGML configuration patch)

Francis J. Lacoste francis.lacoste at Contre.COM
Tue Jun 19 17:42:03 CEST 2001


I'm also more favorable to intensive bug fixing one week before fixing
approach. (And I'll need an accound on FreeBSD, OpenBSD and Solaris for
that.)

I would amend the commit policy to : "Make sure your changes run before
commiting and documentation should be updated ASAP. Try not to break
things for other platform though." :-)

While intense development continue, we should also try once in a while
(once a week) the current tree on the supported platform to see what is
broken.

Testing changes on all platform and waiting for documentation to be 
up-to-date before commiting isn't very practical. This will slow down
collaboration because changes will be delayed to the others.
(We could be stricter on the documentation issue though if this becomes
 a problem: documentation always lagging to much behind.)

On Mon, Jun 18, 2001 at 04:12:43PM +0200, Egon Willighagen wrote:
> > > I would propose (see "release schedule" message) that the last week
> before a
> > > release
> > > is used for extensive testing... at the CDK project
> > > (www.sf.net/projects/cdk/) we use a set
> > > of tests that must be fullfilled before a release is done... i think
> this is
> > > more usefull than to test
> > > each bug patch/new code on all platform every day you work...
> >
> > A test suite would be very usefull indeed.  Francis, didn't you suggest
> > this earlier?
> 
> Mmm... i guess i missed some messages lately... :)
> 

I think this message wasn't send to people or development. It was in a message
where I discussed suggestions to improve LogReport and where I could be
useful to the project.

We need a somewhat stable infrastructure before writing the tests though.

-- 
Francis J. Lacoste
francis at Contre.COM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
Url : http://lists.logreport.org/pipermail/development/attachments/20010619/8806d407/attachment.bin 


More information about the Development mailing list