--1UWUbFP1cBYEclgG
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 22, 2004 at 08:49:46AM -0500, Tim Kelly wrote:
> Hi Bill,
>=20
> > > Can the port freeze below 2.0 -release, and then get pulled up
> > > later?
> >=20
> > Ports don't freeze, so I don't fully understand your question.
>=20
> I was thinking along the lines of not pulling up, kind of a "de facto"
> freeze. However...
>=20
> > We certainly can pull fixes into the 2.0 branch after 2.0 ships. These
> > fixes will then show up in 2.1. However what we have now will be 2.0.
> > The only chance we can add fixes is if there's an RC6. I have no idea
> > if there will be one. While one would be good for macppc, 2.0 happens
> > for all ports at once. So any delay to fix things here delays
> > everything.
>=20
> the greater concern is ensuring that this port doesn't hold up the rest
> of the development effort. Not that my opinion matters, but I would
> argue against an RC6. If the decision is made to make this -release,
> make it -release and get it out the door :-)

This action is what will most likely happen. So 2.0 will ship with the=20
warts we've been describing.

> Would it be possible to introduce a (possibly macppc specific) cvs tag
> that is not as cutting edge as -current but contains officially included
> fixes?

cvs has tags and branches. Branches are threads of development, and you=20
can think of the whole project as a tree (in which case the "branch" term=
=20
makes more sense). Tags are labels applied to specific revisions of files.=
=20
The main thing about branches is that they are a form of tag that moves=20
(well, there is an implicit tag that references the latest revision on a=20
branch).

What ends up being "2.0" will be a tag on the 2.0 development branch. That=
=20
branch separated from current back in I think it was March. The point is=20
that 2.0 separating from -current is a very past thing, not a future=20
thing.

We can change -current willy-nilly and 2.0 won't be affected. Conversely,
if we make a change to -current, we have to take special steps to cause
the change to show up on the 2.0 branch. The 2.0 cycle has had a lot more=
=20
stuff from -current get pulled into it, so it is much closer to -current=20
than other releases have been at release. The only things that we don't=20
want to pull into a branch are ones that will bump the kernel version. We=
=20
want life on a release branch to be much more incrimental than life on=20
-current.

> Is there a scheduled deadline for a beta for 2.1? Say about three months
> after 2.0 -release is tagged (or arbitrarily, March 1, 2005)? I believe
> with the current work effort and reinvigoration of the list that many of
> the issues can be resolved in that time, which would give a lot more
> lead time to lock down 2.1, as least as far as macppc is concerned.

No 2.1 release date has been set. However once 2.0 is out the door, we can=
=20
start pulling fixes from -current into the 2.0 branch immediately.

Take care,

Bill

--1UWUbFP1cBYEclgG
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFBoitEWz+3JHUci9cRAmJqAJ9o0f/dbV2BNb8u9K8ktwO5BNFrYACffdOb
RsrWz/jFRjO2XlKj2RmjTy0=
=2j2r
-----END PGP SIGNATURE-----

--1UWUbFP1cBYEclgG--