[Zope-dev] DISCUSS: Community checkins for CVS

[Joachim Werner]

> I imagine that the group will decide rules on peer reviewing.  For
> comparison, the Mozilla group has very elaborate rules for checkins,
> while Python has pretty much an innocent until proven guilty culture.
> (That is, you check something in, and if somebody complains, it gets
> removed.)

> I don't think it is worthwhile trying to form these rules a priori.

That's fine. I just wanted to put it onto the agenda ...

> > We need rules like "NO FIXES BETWEEN FINAL BETA AND RELEASE" (Absolutely
no
> > fixes I mean) -- and those rules should apply to everybody.

> Again, we'll let the rules come out of the group.  For instance, what if
> an Emacs #foo.py# accidentally got checked in?  Would you really require
> another beta release for that?  Betas are a cost incurred by hundreds of
> people around the world.

My personal opinion is that, apart from the version number, a final beta
should be exactly the same as the actual release. Accidentally checked-in
stuff can cause accidents. So there is some reason for a careful release
policy.

But in your specific case, if the "final" beta that should lead to a release
has been actually released (and tagged in the CVS), how should somebody be
able to check something into it afterwards? That could only happen if there
are problems with the CVS configuration and usage I guess ...

> Ahh, the "it's the Wiki's fault" argument.  I just checked the zip
> mailing list archive.  9 messages since Aug 1st.  So neither email nor
> Wiki are good choices.  Can you point to an example of a process that
> worked better for designing APIs?

I don't blame the Wiki in general. Wikis (together with mailing lists) are a
good start. Sometimes we'd just need real meetings on real conferences I
guess ...

Joachim