Mark Linimon wrote:
But, in the real world of software engineering, He Who Breaketh It,
Must Fixeth It.
Your mileage may vary.
Yes it vaires. In the real world He Who Reaketh It, will hire
someone who known what he is doing to fix the problem...
___
On Wed, 14 Jan 2004, Poul-Henning Kamp wrote:
cut
/cut
I think for now the important thing is to get the people interested
on this collected on a mail-alias, and for them to discuss how the
can work together to make something happen. After that, try to define
something closer.
What about
On Mon, 12 Jan 2004, Robert Watson wrote:
I think the right strategy is to follow the minimalist approach now
(adopt the disk(9) API, rather than having Vinum generate character
devices) so that swap works on Vinum again, and so that when UFS moves
to speaking GEOM there's no loss of
In message [EMAIL PROTECTED], Lukas Ertl writes:
On Mon, 12 Jan 2004, Robert Watson wrote:
I think the right strategy is to follow the minimalist approach now
(adopt the disk(9) API, rather than having Vinum generate character
devices) so that swap works on Vinum again, and so that when UFS
On Wednesday, 14 January 2004 at 22:32:32 +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Lukas Ertl writes:
On Mon, 12 Jan 2004, Robert Watson wrote:
I think the right strategy is to follow the minimalist approach now
(adopt the disk(9) API, rather than having Vinum generate
In message [EMAIL PROTECTED], Greg 'groggy' Lehey
As much as I would hate to see RF and Vinum disappar from our
source tree, maybe what we need to do is to kick them both into
training-camp in p4 while you and Greg look the other way.
Hmm. I can't see why they have to disappear from the
In message [EMAIL PROTECTED], Mark Linimon writes:
But, in the real world of software engineering, He Who Breaketh It,
Must Fixeth It.
If we are talking paid jobs, yes, then you can make rules like that
because with the salary you control resource allocation and
prioritization.
My real life
I forgot to mention on rather important factor in this equation:
Er, this is the *only* important factor. IMHO, it made most of the
previous conversation be completely off-the-rails.
If nothing happens, vinum is going to break even more very soon.
No ... if you do a commit that changes the
If vinum means a lot to you, you should do something to get it above
that threshold: start debugging/coding, learn to code if need be,
donate money so somebody else can code if you can't do anything
else.
I don't use vinum so I have no stake in this.
OTOH I'm not announcing changes which
On Mon, Jan 12, 2004 at 11:00:34AM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Mark Linimon writes:
But, in the real world of software engineering, He Who Breaketh It,
Must Fixeth It.
If we are talking paid jobs, yes, then you can make rules like that
because with the
In message [EMAIL PROTECTED], John Hay writes:
But, in the real world of software engineering, He Who Breaketh It,
Must Fixeth It.
...
In a free software project, you can take any rule like that an put
it anywhere you like, in any font, size and color of your choice
and it still wont work.
On Mon, 12 Jan 2004, Mark Linimon wrote:
If nothing happens, vinum is going to break even more very soon.
No ... if you do a commit that changes the code assumptions upon which
vinum was built, vinum will break. vinum is not going to magically
break by itself.
This gets back to a
In message [EMAIL PROTECTED], Alexander Leidinge
r writes:
I'm a little bit confused. I've read Pouls mail as an suggestion to
remove vinum from -current and let people modify it in the perforce
repository. If I got this wrong, please tell me and everything is fine,
but if I got it right, do you
On Sunday, 11 January 2004 at 12:08:24 +0100, Alexander Leidinger wrote:
On Sun, 11 Jan 2004 15:46:49 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
[missing attribution to phk]
I'd say lets kick them both into perforce and let whoever wants
their hands have a go at them.
For some
In message [EMAIL PROTECTED], Greg 'groggy' Lehey
writes:
As much as I would hate to see RF and Vinum disappar from our
source tree, maybe what we need to do is to kick them both into
training-camp in p4 while you and Greg look the other way.
Hmm. I can't see why they have to disappear from
On Sun, 11 Jan 2004 15:46:49 +1030
Greg 'groggy' Lehey [EMAIL PROTECTED] wrote:
Hmm. I can't see why they have to disappear from the source tree, and
I don't see why Scott or I should have to look the other way. I don't
know about RAIDFrame, but Vinum still works for the most part:
[...]
Poul-Henning == Poul-Henning Kamp [EMAIL PROTECTED] writes:
Poul-Henning In message [EMAIL PROTECTED],
Poul-Henning Greg 'groggy' Lehey writes:
Poul-Henning The reason I say this is that neither of you have the
Poul-Henning time needed, and whoever picks up may have ideas, even
Poul-Henning
David Gilbert wrote:
In the p4 tree, we can easier add new talent to our developer
force and I am pretty sure that some sort of merry band of
developers would form around both RF and vinum there.
... now I thought I followed this list relatively well, but can
someone point me at what 'p4' is?
p4
On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED],
Alexander Leidinger writes:
fine, but if I got it right, do you (Greg) agree to remove it from
-current?
My proposal is to do just that with both vinum and raidframe until
one or possibly both are up to full
On Sun, 11 Jan 2004, Andreas Braukmann wrote:
On 01/11/04 12:13:36 +0100 Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED],
Alexander Leidinger writes:
fine, but if I got it right, do you (Greg) agree to remove it from
-current?
My proposal is to do just that with both vinum
On Sun, Jan 11, 2004 at 12:13:36PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Alexander Leidinge
r writes:
I'm a little bit confused. I've read Pouls mail as an suggestion to
remove vinum from -current and let people modify it in the perforce
repository. If I got this
In message [EMAIL PROTECTED], Narvi writes:
oh yes - and please fix disklabel to support an arbirtary number of file
system per a disk or slice in the process, because otherwise it will
not be converting many setups.
We need to move to a different labeling format because bsdlabel has
a number of
On Sunday, 11 January 2004 at 0:12:57 +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Scott Long writes:
All,
I started RAIDframe three years ago with the hope of bringing a proven
and extensible RAID stack to FreeBSD. Unfortunately, while it was made
to work pretty well on
23 matches
Mail list logo
