On Wed, 27 Feb 2002, George V. Neville-Neil wrote:
I think we need to avoid the concept of imposing some modicum of
structure. If we create structure it is because we need it. Just like
software. There was a good comment recently about software gets
created to scratch an itch. I'd say
What I mean by imposing structure is:
- Identify patterns of development and structure that seem to have evolved
naturally as part of the maturing of the FreeBSD Project
- Determine which patterns tend to result in the most productive and
parallel development efforts, not to mention
On Thu, 28 Feb 2002, George V. Neville-Neil wrote:
What I mean by imposing structure is:
- Identify patterns of development and structure that seem to have evolved
naturally as part of the maturing of the FreeBSD Project
- Determine which patterns tend to result in the most
Certainly -- the intent that I expressed in my original e-mail was to fish
for people's thoughts on the issue, which would then be codified in some
form. I'm interested in hearing a little more back on how people feel
about the notion of how larger projects should coordinate work given the
My general opinion is that a developer should not claim ownership of
anything, it should simply be apparent from the traffic the developer
posts to the public lists, discussion, and his commits. This implies
that the developer is only actively working on one thing at a time,
In message [EMAIL PROTECTED], M. Warner Losh writes:
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
One of the disagreements that seems to be evolving is whether or not the
project formally supports a task-oriented structure. A couple of people
have asserted that people might claim tasks (such as myself) and by virtue
of claiming the task, be provided with some notion of ownership that is
: My feeling has always been that imposing some modicrum of structure is
: important: to avoid people stepping on toes, people can announce what
: they're working on, and expect that others might avoid replicating the
: work, or at least be communicated with before it happens. The rationale
:
In addition to process it might be attitude.
It might be a stretch but they are kind of the same.
Good processes come from good attitude. It is extraordinarily
hard for most people (especially smart people) to be introspective
on such questions when they think they already have the answer.
+---[ George V. Neville-Neil ]--
| In addition to process it might be attitude.
|
|
| So, how do we get our attitudes adjusted before hitting a wall,
| as many companies I've worked for did?
Alcohol and a cam-corder d8)
--
Totally Holistic Enterprises Internet|
One of the disagreements that seems to be evolving is whether or not the
project formally supports a task-oriented structure. A couple of people
have asserted that people might claim tasks (such as myself) and by virtue
of claiming the task, be provided with some notion of ownership that is
PROTECTED]
Subject: Discussion of guidelines for additional version control mechanisms
In the past week, a number of comments have been made both for and against
additional version control mechanisms being used to supplement the FreeBSD
Project official CVS server. Proponents of additional
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
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 anyone care if someone is
tracking their own personal work using
In the past week, a number of comments have been made both for and against
additional version control mechanisms being used to supplement the FreeBSD
Project official CVS server. Proponents of additional mechanisms, such as
It's my view that work that happens outside of our official CVS repo
On Tue, 26 Feb 2002, Robert Watson wrote:
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
On the other hand, you could easily argue that the expectations might be
much lower for smaller pieces of work. For example, the move to td_ucred
required a substantial amount of infrastructure,
David Greenman wrote:
In the past week, a number of comments have been made both for and against
additional version control mechanisms being used to supplement the FreeBSD
Project official CVS server. Proponents of additional mechanisms, such as
It's my view that work that happens
On Tue, 26 Feb 2002, Julian Elischer wrote:
On the other hand, you could easily argue that the expectations might be
much lower for smaller pieces of work. For example, the move to td_ucred
required a substantial amount of infrastructure, but the patches
themselves are relatively sane
Anyway, my point is that the Perforce repo itself isn't the problem. The
problem is that people are maintaining private patch sets for long periods
and making claims to the areas that their patches cover. Step-wise evolution
is the only way to go in this distributed development model and
Some things are too impractically large to do incrementally and are an
all-or-nothing thing. I recall seeing your early VM commits which were huge,
you had been working on for months, and were not incremental things.
Actually, most VM system work that was done was developed over a period of
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
That would be me...
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
in around August or
mechanisms (fwd)
In-Reply-To: p05101402b8a1ffde0552@[128.113.24.47]
Message-ID: [EMAIL PROTECTED]
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
At 6:55 PM -0800 2/26/02, Julian Elischer wrote:
(1) The timeout begins when
On Tue, 26 Feb 2002, Robert Watson wrote:
On Tue, 26 Feb 2002, Julian Elischer wrote:
On the other hand, you could easily argue that the expectations might be
much lower for smaller pieces of work. For example, the move to td_ucred
required a substantial amount of
At 7:27 PM -0800 2/26/02, Julian Elischer wrote:
On Tue, 26 Feb 2002, Garance A Drosihn wrote:
That would be me...
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
In the past week, a number of comments have been made both for and against
additional version control mechanisms being used to supplement the FreeBSD
Project official CVS server. Proponents of additional mechanisms, such as
Perforce, have pointed out that CVS doesn't provide the necessary tools
In message [EMAIL PROTECTED], Robe
rt Watson writes:
Question 1: How should the presence of on-going work in an external
repository be announced to the broader community?
On the project.freebsd.org web-page and the regular status emails
generated from the contents of that web-page.
Question 2:
25 matches
Mail list logo
