Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-18 Thread Hellmuth Michaelis

From the keyboard of David O'Brien:
 On Sun, Mar 17, 2002 at 10:48:53AM +0100, Hellmuth Michaelis wrote:
  Not taking into account (good) technical reasons, i am quite a bit 
  concerned about the increasing tendency to a) use private repositories
  instead of the one and only repository every committer is able to see and
  use and b) and/or use other version control systems instead of the one
  and only every committer is able to use.
 
 Is this for the use of Perforce in this DP snapshot, or in general?

In general.

If there is a way to use the FreeBSD repository with cvs and any other tool
and each user of each tool sees everything which each user of any other tool
also sees, then i'm fine - no problem. As far as i understand, this is not
the case.

So someone or group who wants to use another tool makes a snapshot of the
cvs repository, converts it for their favorite tool and starts to hack
on the newly created tool-specific repository. But the cvs repository users
can't see anything going on there and might be told: don't touch whatever
code in the cvs repository, we are working on it in our tool specific
repository. This is - IMHO - not good for working _together_.

Once i was told hey, commit to -current, all is fine with this. If its
broken for some days thats ok. Its no problem at all, all changes can
be reversed, but at least its in the tree and everyone can see it and
work on it. If someone later finds a better solution, it will be replaced
but in the meantime we got a bit more forward and this is what i like 
in FreeBSD development.

If i had to vote on that, i'd vote for: 

1) the only thing which is relevant is FreeBSD's cvs repository. If 
person A wants to commit solution A into it, commit it; if person A
does not, has not or does not (now) want to commit it then person B
should be allowed to commit solution B in any case at any time (by 
respecting the committers guidelines, good taste and common sense).

2) cvs is FreeBSD's tool to handle the repository. It allows us to
work together on the repository to solve problems together. If there
is a better tool to do the job, either make shure users of all tools
see the same repository at all times, or make shure all developers
can use the new tool and switch tools or leave everything as it is.

I have read core's recent statement on (part) of this subject and i'm
glad about it. I have nothing against (how should i ..) private 
repositories as long as they are not used to prevent others to commit,
work, go forward and collaborate. I hope we will not divided in 
committers using tool A on repository A, tool B on repository B and/or
tool C on repository C with each group yelling at each other to wait
because group X is working on a solution which will make it shortly
into the other repositories.

Again, these are just my 0.0002 EUR ...

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread David O'Brien

On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
 I hate this whole direction.
 
 I think it's an incredibly bad idea that we are not going
 to be able to reproduce what went onto any given CDROM in
 ten years.

The source will be on the CDROM.  Nor is there any major importance to
DP1.  Are you also upset that you cannot reproduce the July 17th, 1998
-CURRENT snapshot CD from WC?

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Maxim Sobolev

On Sat, 2002-03-16 at 21:53, David O'Brien wrote:
 On Sat, Mar 16, 2002 at 04:43:47PM +0200, Maxim Sobolev wrote:
   primary goals in all of this are (1) to provide a usable preview of
   the 5.0-CURRENT code, and (2) to minimize the impact on -CURRENT
   developers.  After evaluating several different options, using
   Perforce was deemed the best tool for the job.
  
  Could we have commit logs from the commits into that branch be sent to
  cvs-all, because otherwise most of the developers would be unable to
  see what's going on there, which IMO is not a good thing.
 
 Why do we care?  I already see the logs for -current.
 I don't really care what the RE's have to do in their branch to add the
 release-related things.

To see exactly what features and added into/removed from release.

-Maxim




signature.asc
Description: This is a digitally signed message part


Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Murray Stokely

On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
 I think it's an incredibly bad idea that we are not going
 to be able to reproduce what went onto any given CDROM in
 ten years.

   I agree that it is very important to be able to reproduce official
releases of FreeBSD N years down the road.  However, that has never
been a requirement of snapshot CDs.  We have never even tagged the
tree for previous snapshots.  We are actually moving more in the
direction you advocate by at least moving the snapshot production into
Perforce so that more developers can participate.  The release
engineers would prefer to do this in CVS, but that is not advisable
for the reasons Peter outlined in his mail.  The source distribution
is included in the output of make release for a reason.  If you have
a technical solution to the problems that Peter raised, then I'm sure
[EMAIL PROTECTED] would like to hear about them.

- Murray



msg36234/pgp0.pgp
Description: PGP signature


Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Terry Lambert

David O'Brien wrote:
 On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
  I hate this whole direction.
 
  I think it's an incredibly bad idea that we are not going
  to be able to reproduce what went onto any given CDROM in
  ten years.
 
 The source will be on the CDROM.  Nor is there any major importance to
 DP1.  Are you also upset that you cannot reproduce the July 17th, 1998
 -CURRENT snapshot CD from WC?


I have to say that I feel incredibly strongly about this
issue, and so I'm going to argue passionately.  Please bear
with me...


Taking your example, yes.  ISO images by date should be reproducible
using the date stamp.

If the July 17th, 1998 -CURRENT snapshot CD from WC has
things on it that didn't come as a result of merely a straight
build as of a datestamp, then we've lost some of our history.

In that case of that version, it's likely that if anything
was done in a Mickey Mouse way, it was that the X11 distribution
or some of the DOS programs or whatever were copied from another
CDROM.  That is, at least in theory, reproducible, though a heck
of a lot more inconvenient than a list of what was done in the
README.CDROM file in / on the thing would have made it.


In the transient Perforce branch case, when the branch
goes away, it's unreproducible completely.  Any of the
changes that were necessary to make the thing compile, or
to back out broken code are lost.  It's now inpossible to
identify, from records, what the release engineers found to
be broken enough that it had to be backed out or patched
around, and it loses the back out and the patches.

I'm not entirely sure that the resulting image will in fact
be on the cdrome; even if it were, the results are not
diff'able against the repository without a huge amount of
manual effort.

Basically, we're losing history, and, unlike the July 17th,
1998 -CURRENT snapshot CD from WC case, which is barely
acceptable to lose, since it is repo + reproducible deltas,
it becomes repo + unreproducible deltas.

I would have liked it if a tag had been laid down immediately
after the BSDCon Developer's Summit, and then moved forward
or backware on a filed basis, with a branch tag at freeze
equal to the moving tag, checked out, with any additional
changes after the freeze done in the context of the branch
tag, so that they're recoverable.

It seems to me that, at worst, this is being done to prove
to the heathens that use of Perforce is a bad idea.  It
certainly is, if history is going to be lost, but that's not
a result of the tool, here, it's a result of intention.

At best, Perforce is being used because the release engineers
have less power over branching in the CVS repository than the
core team *should* be loaning them.

Either way, it's bad news when it won't be possible to
reproduce an official code cut -- even if it's not a
release -- from the repository.


What is a repository good for, if you can't recover your
history from it?  The way Linux is developed, they release
code that's not recoverable from a repository, ony from
the release materials themselves.  They have no repository
because they *intentionally* have no perception of history.


Actually, it's possible to lay down a tag in the past: do
a checkout of the sources as of the day after the BSDCon
Developer's Summit (or whatever feature freeze date is right
for the preview), and then lay down a tag on the code checked
out as of that timestamp.

I don't understand the use of Perforce, in this case, unless
it's as a strawman to try and prove all fish are trout because
one fish is a trout (Perforce is a bad idea in all cases
because it's a bad idea in this case).


If my position is unsupportable in everyone's opinion, so
be it: I would like an official policy statement on what
will, guaranteed, be reproducible from the repository, when
it comes to officially sanctioned distributions, like a
-RELEASE CDROM, or like a Developer's Preview.


In that case, I'll basically ignore anything that isn't in
that list.


This developer's preview, if it's not reproducible, isn't
going to be delta-able, and so won't be improvable: if I
have a problem with it, and fix the problem, there's not
going to be a delta against the repository from which I
can derive a patch for inclusion in FreeBSD going forward.

If the purpose of this release is to get developers hacking
on the code and fixing problems prior to 5.0-RELEASE, it
*really* needs to be hackable for it to be hacked on.

Otherwise, all it's going to do is be confusing when things
work in the developer's pre-release because they were fixed
in a now non-existant branch, and don't work in -current...
NOT because the were broken in -current between the
pre-release and the time they were attempted in -current,
but because they NEVER worked in -current in the first place.

If that's going to be the case, then I have to say that
everyone will be better off if they ignore the CDROM of
the Developer's pre-release, and stick with -current,
since 

Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Terry Lambert

Murray Stokely wrote:
 On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
  I think it's an incredibly bad idea that we are not going
  to be able to reproduce what went onto any given CDROM in
  ten years.
 
I agree that it is very important to be able to reproduce official
 releases of FreeBSD N years down the road.  However, that has never
 been a requirement of snapshot CDs.  We have never even tagged the
 tree for previous snapshots.  We are actually moving more in the
 direction you advocate by at least moving the snapshot production into
 Perforce so that more developers can participate.  The release
 engineers would prefer to do this in CVS, but that is not advisable
 for the reasons Peter outlined in his mail.  The source distribution
 is included in the output of make release for a reason.  If you have
 a technical solution to the problems that Peter raised, then I'm sure
 [EMAIL PROTECTED] would like to hear about them.

Minimally, pick a date, and then do a CVS diff against that
date, and include it on the CDROM.

Max wants the commit messages to the developers pre-release
to go to an archived mailing list for similar reasons, it
seems to me.

Without the deltas against something that is fixed in the
repository going forward, it's simply not going to be a
useful exercise, since it's not going to be possible to
make changes without a crib-sheet of how to wave the dead
chicken over the source code.

Erasing the crib-sheet is a really bad idea.


Imagine that you have the developer's prerelease, and you
have a bug (because you're a developer who's using the
pre-release).

Now say you have become involved in the process, because the
pre-release has done it's job.  You want to fix the bug.

In order to do this, you are going to need the delta against
the developer's prerelease source tree.  To get this, the
process is:

1)  Before you make any changes, copy /usr/src to /usr/src.org
OR
mv /usr/src/usr/src.new
reinstall /usr/src using /stand/sysinstall
mv /usr/src /usr/src.org
mv /usr/src.new /usr/src

2)  Make your changes

3)  Run diff -cr /usr/src/org /usr/src

4)  Now, figure out how to apply these diffs to the CVSup
image of the -current CVS tree for some checked-out
version of -current
AND
Pray to God that the code your changes are in are not
in code where changes were backed out or made by the
release engineers for the developer's pre-release
OR
Install -current somewhere, with -current sources,
hoping that it runs at all, and the release engineering
work for the developer's prerelease was useless in your
case, so that -current runs for you without trouble so
that you can make your changes against -current, instead,
so that it's possible to submit them back to the project
and have them have meaning, in the larger scheme of things.

It's really, really not happy for the CDROM to have no relevence
to the developement process, if the entire purpose of the CDROM
is to get more people involved in the developement process.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Murray Stokely

On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote:
 Minimally, pick a date, and then do a CVS diff against that
 date, and include it on the CDROM.

  I would be happy to do this.  I checked out a copy of the CVS tree
right before we made the Perforce branch so that we could tag it later
if absolutely necessary.

 Max wants the commit messages to the developers pre-release
 to go to an archived mailing list for similar reasons, it
 seems to me.

  I have emailed Peter about this.  I don't think the messages should
go to cvs-all, because I don't think most people want to see them.
But I do think that they should be available for people like Max.  Max
was CCed on my message to Peter.

 Now say you have become involved in the process, because the
 pre-release has done it's job.  You want to fix the bug.
 
 In order to do this, you are going to need the delta against
 the developer's prerelease source tree.  To get this, the
 process is:

  1)  Mount your DP1 CD, and view the diff.

  - Murray



msg36241/pgp0.pgp
Description: PGP signature


Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Hellmuth Michaelis

From the keyboard of Murray Stokely:

 tree for previous snapshots.  We are actually moving more in the
 direction you advocate by at least moving the snapshot production into
 Perforce so that more developers can participate.

Not taking into account (good) technical reasons, i am quite a bit 
concerned about the increasing tendency to a) use private repositories
instead of the one and only repository every committer is able to see and
use and b) and/or use other version control systems instead of the one
and only every committer is able to use.

Just my 0.0002 EUR ..

hellmuth
-- 
Hellmuth MichaelisTel   +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbHFax   +49 40 55 97 47-77
Oldesloer Strasse 97-99   Mail  hm [at] hcs.de
D-22457 Hamburg   WWW   http://www.hcs.de

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Annelise Anderson

On Sun, 17 Mar 2002, David O'Brien wrote:

 On Sat, Mar 16, 2002 at 02:08:51PM -0800, Terry Lambert wrote:
  I hate this whole direction.
  
  I think it's an incredibly bad idea that we are not going
  to be able to reproduce what went onto any given CDROM in
  ten years.
 
 The source will be on the CDROM.  Nor is there any major importance to
 DP1.  Are you also upset that you cannot reproduce the July 17th, 1998
 -CURRENT snapshot CD from WC?
 
If a tag was laid down can't it be retrieved indefinitely? A non-branching
tag?  What am I missing?

Annelise

-- 
Annelise Anderson
Author of:   FreeBSD: An Open-Source Operating System for Your PC
Available from:  BSDmall.com and amazon.com
Book Website:http://www.bittreepress.com/FreeBSD/introbook/ 




To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Murray Stokely

On Sun, Mar 17, 2002 at 02:13:16AM -0800, Annelise Anderson wrote:
  The source will be on the CDROM.  Nor is there any major importance to
  DP1.  Are you also upset that you cannot reproduce the July 17th, 1998
  -CURRENT snapshot CD from WC?
  
 If a tag was laid down can't it be retrieved indefinitely? A non-branching
 tag?  What am I missing?

  Tags were never laid down in the past.

  - Murray

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread David O'Brien

On Sun, Mar 17, 2002 at 02:13:16AM -0800, Annelise Anderson wrote:
 
 If a tag was laid down can't it be retrieved indefinitely? A non-branching
 tag?  What am I missing?

The tag will create a point in time in the CVS repository that cannot be
ever changed.  This is a restriction that we've always assumed does not
exist on the HEAD until a .0 release.  We have always been free to do
repository reorganizing until the .0 release.  A tag that should always
produce the same thing, breaks our SOP[*] and was one of the concerns of
[EMAIL PROTECTED]

-- David

[*] standard operating procedure

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread David O'Brien

On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote:
 Imagine that you have the developer's prerelease, and you
 have a bug (because you're a developer who's using the
 pre-release).
 
 Now say you have become involved in the process, because the
 pre-release has done it's job.  You want to fix the bug.
 
 In order to do this, you are going to need the delta against
 the developer's prerelease source tree.  To get this, the
 process is:
 
 1)Before you make any changes, copy /usr/src to /usr/src.org
   OR
   mv /usr/src/usr/src.new
   reinstall /usr/src using /stand/sysinstall
   mv /usr/src /usr/src.org
   mv /usr/src.new /usr/src
 
 2)Make your changes
 
 3)Run diff -cr /usr/src/org /usr/src
 
 4)Now, figure out how to apply these diffs to the CVSup
   image of the -current CVS tree for some checked-out
   version of -current

And just HOW is this different from previous snapshot CD's?  You have the
source tarball w/no CVS/ directories.  To fix your bug, you have to do
these SAME exact steps.  I see ZERO difference.  You imply that maybe
RE's fixed some bug in only the code for the CD and not in the CVS tree.
Maybe you don't know that only pieces of bits that are CVS will be in the
src tarball.  Thus just like any snapshot CD source, you have to figure
out if someone in has backed out a change in the CVS repo, etc..  Again,
NO change from the past.

Geez people.  It was nice in the past when the snapshot CD's were done by
a private company where none of us got to see how it was produced.  Now
that the process is more open, people want to try to railroad the effort.
And people wonder why many companies and organization have real concerns
about opening up source bases and procedures

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread David O'Brien

On Sun, Mar 17, 2002 at 12:56:42AM -0800, Terry Lambert wrote:
 It seems to me that, at worst, this is being done to prove
 to the heathens that use of Perforce is a bad idea.  It
 certainly is, if history is going to be lost, but that's not
 a result of the tool, here, it's a result of intention.
 
 At best, Perforce is being used because the release engineers
 have less power over branching in the CVS repository than the
 core team *should* be loaning them.

So you would like to screw the project just out of principle?
I know you know enough about CVS to know the limitations that laying
down this tag would have on the ability to do repository surgery.


 Either way, it's bad news when it won't be possible to
 reproduce an official code cut -- even if it's not a
 release -- from the repository.
 
 What is a repository good for, if you can't recover your
 history from it?  The way Linux is developed, they release
 code that's not recoverable from a repository, ony from
 the release materials themselves.  They have no repository
 because they *intentionally* have no perception of history.

Thanks for your input.  If this will be the result of DP snapshots,
you've now convinced me to strongly object to them.  I had reservations
about us doing such an official snapshot and the impact it has on the
CVS repo and developer code slush restrictions.  Next time I will voice
them.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Garance A Drosihn

At 1:15 AM -0800 3/17/02, Murray Stokely wrote:
On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote:
  Minimally, pick a date, and then do a CVS diff against that
  date, and include it on the CDROM.

   I would be happy to do this.  I checked out a copy of the CVS tree
right before we made the Perforce branch so that we could tag it later
if absolutely necessary.

I think this is a good and useful idea.  Thanks.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Garance A Drosihn

At 8:35 AM -0800 3/17/02, David O'Brien wrote:
My earlier concerns about the use of Perforce were when a developers
expected other developers to use Perforce for _shared_ development.
Or that tried to claim that their code was published if it was
in the Perforce depot on Freefall.

Exactly my concerns, too.

In this use of Perforce for a -CURRENT snapshot; I don't see how
people can bitch and bitch about it.  No committer or developer
has EVER had CVS access or sight of the source used in previous
snapshot CDROMs.  So people are loosing nothing.  Perforce is just
a tool to assist Murray and Co. in making this snapshot CD.

I agree completely.  I have no concerns about them using perforce
in this manner.  Whatever makes their lives easier in getting out
this developer's preview is fine by me.

The other reason to NOT do this in the CVS repository is that it
will help deemphasize that the DP is NOT a RELEASE.  People should
not be CVSup'ing hoping to get just that point in time,

To speak about my own bias on this process, I agree completely with
this sentiment.  Four weeks from now, no one should care about the
particular second in time they used to create this rough snapshot.
I see this as more of a dry run for the *process* of creating a
release of 5.0.  It will give us a convenient bootstrap CD for those
who want to try out 5.0, and who also want a bootable CD to do a
clean install of something in 5.0, because they want to play
with it a little.  Anyone who thinks they are going to start
tracking current had better *track* current, and not depend on
this particular CD.  It is not a release.

That describes my opinion on what I expect from this developer's
preview.  I admit that I am not comfortable with using perforce
(or subversion, or etc) in some other situations, but I think
it is perfectly reasonable in this situation.

-- 
Garance Alistair Drosehn=   [EMAIL PROTECTED]
Senior Systems Programmer   or  [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Poul-Henning Kamp

In message p05101511b8bab342dc49@[128.113.24.47], Garance A Drosihn writes:
At 8:35 AM -0800 3/17/02, David O'Brien wrote:
My earlier concerns about the use of Perforce were when a developers
expected other developers to use Perforce for _shared_ development.
Or that tried to claim that their code was published if it was
in the Perforce depot on Freefall.

Exactly my concerns, too.

I have just started two days ago using P4 to track the sparc64 stuff
and confidently say that contrary to the ill effects I hear people
complain about I have yet to see any signs of hair-loss, lack of
sleep, early aging, republicanism or uncontrollable urges to go to
Tenerife.

I can think of many things wrong with P4 and with having a parallel
environment to our CVS tree.

But I also think having a P4 tree where people can colaborate beats
not having it by a large margin.

So could I suggest that the people who are so much against P4 tell
us what the alternative they want us to use is ?

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Terry Lambert

Garance A Drosihn wrote:
 At 1:15 AM -0800 3/17/02, Murray Stokely wrote:
 On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote:
   Minimally, pick a date, and then do a CVS diff against that
   date, and include it on the CDROM.
 
I would be happy to do this.  I checked out a copy of the CVS tree
 right before we made the Perforce branch so that we could tag it later
 if absolutely necessary.
 
 I think this is a good and useful idea.  Thanks.

Yes, thanks, Murray.  Without something like this, I think
the CDROM will be worse than useless.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-17 Thread Robert Watson


On Sun, 17 Mar 2002, Terry Lambert wrote:

 Garance A Drosihn wrote:
  At 1:15 AM -0800 3/17/02, Murray Stokely wrote:
  On Sun, Mar 17, 2002 at 01:08:43AM -0800, Terry Lambert wrote:
Minimally, pick a date, and then do a CVS diff against that
date, and include it on the CDROM.
  
 I would be happy to do this.  I checked out a copy of the CVS tree
  right before we made the Perforce branch so that we could tag it later
  if absolutely necessary.
  
  I think this is a good and useful idea.  Thanks.
 
 Yes, thanks, Murray.  Without something like this, I think the CDROM
 will be worse than useless. 

One reason for deciding to abandon the original CVS idea was that the
release engineering team was informed that there were on-going
repocopies/removes/renames that would result in tagging causing long term
problems.  I.e., there's stuff in the repository that is destined to
magically disappear since it's never hit a stable branch (beta versions
of compilers and so on.  In tagging the tree, we'd be (in essence)
asserting that those transient bits of history would stick around to make
the tag useful later.  I don't mind tagging the tree with the
understanding that if you check it out later, it will be known not to
build due to a missing compiler, as long as people understand that. :-)

Robert N M Watson FreeBSD Core Team, TrustedBSD Project
[EMAIL PROTECTED]  NAI Labs, Safeport Network Services



To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-16 Thread Maxim Sobolev

On Sat, 2002-03-16 at 13:18, Murray Stokely wrote:
   Thanks for your cooperation in keeping -CURRENT relatively stable
 over the past week.  Due to a request from the CVS administrators, we
 are performing the code branch in the Perforce depot under
 //depot/releng/5_dp1/.  Commits to this Perforce branch require re
 approval.
 
   This is not going to be a supported branch.  It is solely a work
 area for the release engineers to tweak the release documentation,
 back out recent problematic changes, merge in a conservative set of
 new changes, and otherwise perform quality assurance work.  Our two
 primary goals in all of this are (1) to provide a usable preview of
 the 5.0-CURRENT code, and (2) to minimize the impact on -CURRENT
 developers.  After evaluating several different options, using
 Perforce was deemed the best tool for the job.

Could we have commit logs from the commits into that branch be sent to
cvs-all, because otherwise most of the developers would be unable to
see what's going on there, which IMO is not a good thing.

Thanks!

-Maxim



signature.asc
Description: This is a digitally signed message part


Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-16 Thread David O'Brien

On Sat, Mar 16, 2002 at 04:43:47PM +0200, Maxim Sobolev wrote:
  primary goals in all of this are (1) to provide a usable preview of
  the 5.0-CURRENT code, and (2) to minimize the impact on -CURRENT
  developers.  After evaluating several different options, using
  Perforce was deemed the best tool for the job.
 
 Could we have commit logs from the commits into that branch be sent to
 cvs-all@, because otherwise most of the developers would be unable to
 see what's going on there, which IMO is not a good thing.

Why do we care?  I already see the logs for -current.
I don't really care what the RE's have to do in their branch to add the
release-related things.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message



Re: HEADS UP: -CURRENT Feature Slush is OVER

2002-03-16 Thread Terry Lambert

Wow.

I hate this whole direction.

I think it's an incredibly bad idea that we are not going
to be able to reproduce what went onto any given CDROM in
ten years.

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message