> 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 th
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 m
> 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 men
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'
> 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
+---[ 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|
> 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.
> 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.
> Otherwise, I tend to agree with your basic premise that it is process
> and not tools at the heart of this
: 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
: for
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
supp
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
Hi Folks,
Before I address Robert's questions directly I'd like to make a few
comments.
Now, I'm not a committer, I'm a newbie as far as working on FreeBSD
itself goes, but I've been a faithful consumer of this stuff since early
NetBSD days
and was runing Free around 2.2.7. I a
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 inf
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
>>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 per
>>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 mode
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 relativel
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 happen
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 infrastruc
>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 re
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
Apparently a number of people missed this post, so I'm resending. To
recap: this is an attempt to brainstorm for ideas about how we can improve
our use of version control, while responding to concerns about access the
resulting work. The goal is to formulate a set of guidelines based on
whateve
22 matches
Mail list logo
