On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel
Nik Clayton wrote:
On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that
On Sun, Aug 20, 2000 at 12:14:05PM +, Nik Clayton wrote:
On Mon, Jun 19, 2000 at 11:53:30AM -0700, Jason Evans wrote:
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and
On Thu, Jun 22, 2000 at 01:56:56PM -0700, Greg Lehey wrote:
On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
Using a non opensource commercial version control system is just
to ask for bad carma, extended murphy fields and whatnot in an
opensource volounteer project...
I would like to understand the discussed weakness of cvs regarding
branches.
Could someone explain it (in private) or point me to a
"Daniel C. Sobral" wrote:
"Jordan K. Hubbard" wrote:
Everyone talks about using bitkeeper but none of the people who
recommend it have ever actually tried to use it for anything.
Before such recommendations will bear weight, this needs to
change. :)
OCVS? (Or was it OVCS? I can
On Thu, 22 Jun 2000, Greg Lehey wrote:
On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
http://apollo.backplane.com/FreeBSDSmp/
Your
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
http://apollo.backplane.com/FreeBSDSmp/
Your first patchset contains only i386 code.
What is the timeframe for alpha relative to i386?
Will each i386 code step
On Thursday, 22 June 2000 at 10:07:38 -0700, Matthew Dillon wrote:
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
http://apollo.backplane.com/FreeBSDSmp/
Your first patchset contains only i386 code.
What is
"Jordan K. Hubbard" wrote:
Everyone talks about using bitkeeper but none of the people who
recommend it have ever actually tried to use it for anything.
Before such recommendations will bear weight, this needs to
change. :)
OCVS? (Or was it OVCS? I can never recall...)
--
Daniel C.
On Tue, Jun 20, 2000 at 09:41:57AM +0200, Poul-Henning Kamp wrote:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
I'm at USENIX right now, so I'm a bit strapped for time to work on this.
Still, I plan to email a brief summary of the meeting
More over, unlike other big project like CAM, this baby is going to
touch the gut of the OS.
It might be possible however for individual projects to move into a
separate branch.
Nick
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it
CAM is not a valid example. It only touched the disk subsystem.
Merging back changes in blocks might not be possible. As Matthew
mentioned, Chuck's experience should be taken for a fact.
And bounding the amount of breakage is almost impossible without
squeezing the people doing the SMP work
[EMAIL PROTECTED] said:
:- "CVS branches suck" is the reason I belive.
Bitkeeper?
--
Robert Withrow -- (+1 978 288 8256)
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Tuesday, 20 June 2000 at 9:41:57 +0200, Poul-Henning Kamp wrote:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
I'm writing up a detailed trip report for my company. I can't see why
I shouldn't forward it to the SMP list as well, but I
On Tuesday, 20 June 2000 at 12:57:41 -0600, Warner Losh wrote:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
I think core has approved in principle, and several core members
were present at the meeting (at least peter, dg, gibbs, dfr), that
being said, I think we need to see some
On Tuesday, 20 June 2000 at 11:16:24 +0200, Martin Cracauer wrote:
In [EMAIL PROTECTED], Poul-Henning Kamp wrote:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Who was there, anyway?
From my trip report. This can hardly be confidential.
Everyone talks about using bitkeeper but none of the people who
recommend it have ever actually tried to use it for anything.
Before such recommendations will bear weight, this needs to
change. :)
- Jordan
[EMAIL PROTECTED] said:
:- "CVS branches suck" is the reason I belive.
In message 12213.961613148@localhost "Jordan K. Hubbard" writes:
: Everyone talks about using bitkeeper but none of the people who
: recommend it have ever actually tried to use it for anything.
: Before such recommendations will bear weight, this needs to
: change. :)
In that case, I'd
It seems Warner Losh wrote:
In message 12213.961613148@localhost "Jordan K. Hubbard" writes:
: Everyone talks about using bitkeeper but none of the people who
: recommend it have ever actually tried to use it for anything.
: Before such recommendations will bear weight, this needs to
:
At 9:34 PM +0200 2000/6/21, Soren Schmidt wrote:
Using a non opensource commercial version control system is just
to ask for bad carma, extended murphy fields and whatnot in an
opensource volounteer project...
Has anyone given any thought to what it would take to create an
open
Eivind Elkund was talking about doing something like
this. He had a pretty nice document about it,
too. If I recall, the name was "OVCS: Open Version Control System"
Perhaps someone could fill in the blanks? I couldn't
find the document at the address I thought it was kept,
Has anyone given any thought to what it would take to create an
open source version of something similar to perforce? ;-)
Clearly you have. :-). We await your submissions with baited breath...
M
--
Mark Murray
Join the anti-SPAM movement: http://www.cauce.org
To Unsubscribe: send
At 11:09 PM +0200 2000/6/21, Mark Murray wrote:
Has anyone given any thought to what it would take to create an
open source version of something similar to perforce? ;-)
Clearly you have. :-). We await your submissions with baited breath...
If you're waiting for me on this,
At 5:00 PM -0400 2000/6/21, Dan Papasian wrote:
Eivind Elkund was talking about doing something like
this. He had a pretty nice document about it,
too. If I recall, the name was "OVCS: Open Version Control System"
Hmm. So far, Google hasn't been particularly useful in trying to
On Wed, 21 Jun 2000, Mark Murray wrote:
Has anyone given any thought to what it would take to create an
open source version of something similar to perforce? ;-)
Clearly you have. :-). We await your submissions with baited breath...
I have mixed feelings about that. The Perforce
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Can we get to see the slides ?
Audio ?
Video ?
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD coreteam member | BSD since
In [EMAIL PROTECTED], Poul-Henning Kamp wrote:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Who was there, anyway?
Martin
--
%
Martin Cracauer [EMAIL PROTECTED]
Martin Cracauer wrote:
In [EMAIL PROTECTED], Poul-Henning Kamp wrote:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
Who was there, anyway?
Yeah, those of us who couldn't make it are kinda (to say the least)
interested in what was
In message [EMAIL PROTECTED] Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months). A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either stick closely to that tag until
: the kernel
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: Am I the only person who miss a brief document which tells what
: the outcome of the meeting was ?
:
: Can we get to see the slides ?
:
: Audio ?
:
: Video ?
I know that I'd love to see this. Steve Passe also is interested.
Warner
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months). A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete info before
: we pull the lever, just so we know
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] Poul-Henning Kamp writes:
: I think core has approved in principle, and several core members
: were present at the meeting (at least peter, dg, gibbs, dfr), that
: being said, I think we need to see some more concrete
:: the kernel stabilizes, or expect large doses of pain. This tag will be
:: laid down as soon as June 26, 00:00 PST, with a minimum 24 hour warning
:: beforehand.
:
:Thanks for the fair warning. Now don't do it. Has core approved
:this? I don't think so, I've seen nothign from them about
On Tue, Jun 20, 2000 at 08:49:27PM +0200, Poul-Henning Kamp wrote:
So: No I don't like -current being toast anymore than you do, but
I don't think there is a viable alternative.
Not even a seperate repository, as was done (briefly) for newbus?
Of course, maybe that was done so briefly
In message [EMAIL PROTECTED] Matthew Dillon writes:
: The problem is that the changes are simply too extensive to be able
: be able to split them off then merge them back into 5.x N months later.
: Creating another branch will tripple the workload on anyone doing
: merge work.
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
This sounds odd at first glance, but it means that others are forced
to MFC into the smp branch - if they don't they lose.
Anybody that's not confident to be able to merge
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
I believe that Jason Evans already sent a message summarizing the
meeting, and Matt Dillon's webpage gives a pretty good summary of
In message [EMAIL PROTECTED], Brian Somers writes:
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
"CVS branches suck" is the reason I belive.
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED]
In message [EMAIL PROTECTED], Jonathan Lemon writes:
In article local.mail.freebsd-current/[EMAIL PROTECTED] you write:
Am I the only person who miss a brief document which tells what
the outcome of the meeting was ?
I believe that Jason Evans already sent a message summarizing the
meeting, and
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
This sounds odd at first glance, but it means that others are forced
to MFC into the smp branch - if they don't they lose.
Anybody that's not confident to be able
Although I would not like to put it as strongly as Warner does, I would
like to ask how the decision makers expect the rest of the project to
progress (the other 30 or so kernel committers) in a reasonable, not
too time consuming way.
Will there be a general mechanism for making patchsets
What about doing the changes on a branch with the understanding that
the branch will *replace* HEAD when it stabilises ?
This sounds odd at first glance, but it means that others are forced
to MFC into the smp branch - if they don't they lose.
Anybody that's not confident to
Warner Losh writes:
In message [EMAIL PROTECTED] Jason Evans writes:
: Summary: -current will be destabilized for an extended period (on the order
: of months). A tag (not a branch) will be laid down before the initial
: checkin, and non-developers should either stick closely to that tag
Summary: -current will be destabilized for an extended period (on the order
of months). A tag (not a branch) will be laid down before the initial
checkin, and non-developers should either stick closely to that tag until
the kernel stabilizes, or expect large doses of pain. This tag will be
laid
At 11:53 AM -0700 2000/6/19, Jason Evans wrote:
Last week, approximately 20 BSD developers got together and discussed how
to move FreeBSD's SMP support to the next level. Our effort will be
largely based on the work that has been done in BSD/OS, which should make
things go much more
On a totally non-technical, but somewhat related note, can anyone
give me any kind of idea how often relatively "large scale" changes
like this typically occur with FreeBSD?
IIRC, this is the biggest operation of its sort since 2.1.
Can't comment on anything before then, I wasn't
:Summary: -current will be destabilized for an extended period (on the order
:of months). A tag (not a branch) will be laid down before the initial
:checkin, and non-developers should either stick closely to that tag until
:the kernel stabilizes, or expect large doses of pain. This tag will be
On Mon, Jun 19, 2000 at 05:34:47PM -0700, Matthew Dillon wrote:
Ok, I have put up a web page that will track my efforts.
http://apollo.backplane.com/FreeBSDSmp/
On this page, you say:
The algorithms described on this page are essentially the BSDI algorithms
plus accomodations
:On this page, you say:
:
: The algorithms described on this page are essentially the BSDI algorithms
: plus accomodations we disussed at the Yahoo SMP meeting. However, I did
: not do a direct port. I did a from-scratch rewrite because, simply put,
: it was easier for me. The variables are
51 matches
Mail list logo
