In message: [EMAIL PROTECTED]
George V. Neville-Neil [EMAIL PROTECTED] writes:
: The problem here is process. The FreeBSD project now has more than
: 12 core members and more than 12 committers. With any number larger
: than 12 it is VERY HARD to reach consensus on anything.
In message: [EMAIL PROTECTED]
George V. Neville-Neil [EMAIL PROTECTED] writes:
: There are only only 8 core team members, unless you mean something
: different by core here than [EMAIL PROTECTED]
:
: I guess I was going based on the meeting I attended back at BSD Con.
The last
In message: [EMAIL PROTECTED]
George V. Neville-Neil [EMAIL PROTECTED] writes:
: So, how do we get our attitudes adjusted before hitting a wall,
: as many companies I've worked for did? It comes back to agreeing
: on a process by which we work. We have one now, it may not all
: be
Hi Folks,
I've put up the following TWiki page:
http://www.neville-neil.com/twiki/bin/view/Freebsd/DevelopmentProcess
as a scribbling area for a possible set of rules/practices that we can use
to address the issues raised in this discussion.
For those not familiar with TWiki who want
At 4:53 PM -0500 2/26/02, Robert Watson wrote:
The purpose of this message is to initiate a serious discussion
of what guidelines might be put in place to help facilitate the
use of additional version control mechanisms [...]. I've mixed
in some suggested things to think about as possible
At 6:55 PM -0800 2/26/02, Julian Elischer wrote:
(1) The timeout begins when contention occurs, of the lock has been
declared. This means that if you seriously intend to do some work,
you can say I'm going to do the work, but you don't risk losing the
lock until someone
In message: p05101401b8a1ee73f02d@[128.113.24.47]
Garance A Drosihn [EMAIL PROTECTED] writes:
: I think the main issue here is how long the real repository can be
: locked while waiting for some change to show up. If work can
: keep going into the main repository, then what does
In message: [EMAIL PROTECTED]
Robert Watson [EMAIL PROTECTED] writes:
: I meant lock in the sense of expecting no one to make any major
: changes in the same area of code. I seem to remember you asking for
: such a lock (to use the term loosely) in July, and the KSE work going
:
