Re: Draft for release policy pending feedback

--===============4188476252868365==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-Z/HTodkwO76d/Z8iv8+y"


--=-Z/HTodkwO76d/Z8iv8+y
Content-Type: text/plain; charset=iso-8859-13
Content-Transfer-Encoding: quoted-printable

On Sun, 2003-08-31 at 06:26, Frantz Dhin wrote:
> Zynot has a 9-12 months release cycle.

I think this is too long for a release cycle. I think 6 months would be
better.

> The arch leads are release managers of each new version of Zynot. They
> maintain different release schedules for each arch. However, their
> effort is coordinated and major releases within each arch should not
> differ from the agreed release date by more than 1-2 months. The
> version numbers follow each other. One arch is not required to wait
> for another arch to be 100% done before releasing.

I totally disagree with this. This is basically what Gentoo does. x86
releases and the other arch can release when they get around to it. We
need to be better then that. In addition, once we deploy Openlean, team
resources should be shifting to needed areas. Meaning that if x86
development team is ready they need to help out cris, ppc, sparc, etc...
as arch specific tasks will be easily seen within the openlean toolkit.
Granted, you might not expect an x86 developer to fix cris specific
bugs, but they can help out with areas that they can... eg.
documentation.

This leads to another issue... what is required to become an officially
supported arch with zynot. I envision a certain set of requirements to
be an officially supported arch. I've nothing specific atm but will
propose something in he near future.

> The arch leaders gather on a meeting well in advance of a release and
> agree on which features to offer and which package versions to freeze
> for future release. As a result of these meetings, each arch leader
> maintains a road map towards release that is public. It should show
> dates for alphas, betas, release candidates planned as well as final
> release date.

right, which should eventually be represented in the openlean toolkit

> The version numbering should reflect to the consumer how well this
> release of Zynot will interoperate with earlier releases and how much
> of an advantage it is to upgrade. As we are not a desktop-centric
> distribution our policy on version numbers will differ from that of
> RedHat and Mandrake since these mainly follow the release cycle and
> version numbering of KDE and Gnome.

OK

> The arch leaders identify a number of products that are relevant for
> Zynot to offer. This could be a Zynot workstation, a Zynot webserver,
> a Zynot database server, a Zynot development workstation and much
> more. All packages needed to offer each product are provided as
> binaries. Everything that runs on top such as irc clients, media
> players and office suites are offered as ebuilds only.

Rather then binaries I'd prefer to see one tarball. A stage4 if you
will... where you untar and reboot. I like the *BSD method in this
regard.

> Not all products will make sense on all arches. It is up to the arch
> leader to decide what should be offered within his arch. Preferably
> this should be decided based on community feedback and needs. The arch
> lead should note in his public roadmap which products will be offered.

right, in fact i see arch's offering basic products at first and
building on that over time to offer more products. This could be
incorporated into the above idea of setting roadmaps.

> The binary packages are frozen. No version bumps will happen unless
> there is a new release of Zynot. The packages provided as ebuilds only
> can freely be updated by the maintainers at their leisure. Security
> updated binary packages are of course an exception from this rule.=20

Yes, but there is nothing preventing a user from upgrading themselves.
These binaries as you call them will have ebuilds in /usr/portage..
otherwise we would need to rework all of our ebuilds to not depend on
the 120 or so packages that consists of our base system.

> Zynot must support a migration path going 2 versions back. If Zynot
> has released a v1.0 and a v2.0 then upgrades to v3.0 from BOTH these
> version should be supported and painless. The lifecycle of v1.0 ends
> when v3.0 is released. We will then no longer offer security fixes or
> backports of these for v1.0.=20

True, unless someone is willing to pay for it :)

> Thorough and well-tested documentation for =B4upgrading to Zynot vX.X=A1
> should be ready on the release date. The documentation must also, of
> course, go 2 versions back.

Yes, i agree. I'd like to see our install/upgrade documentation follow a
release cycle too. Having it constantly changing doesn't help support
legacy users.


--=20
Jack Morgan					The Zynot Foundation
pub  1024D/620F545F 2002-06-18 Jack Morgan <[email protected]>
Key fingerprint =3D B343 94EB 0658 E19B D91D  7EA5 15E1 FD24 620F 545F

--=-Z/HTodkwO76d/Z8iv8+y
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/V3iJFeH9JGIPVF8RApx3AKCPF4e27k+vz/umtKYaNQtcN7ReigCggPUA
8phzYAJPitGKpmLxsotju3o=
=iJrE
-----END PGP SIGNATURE-----

--=-Z/HTodkwO76d/Z8iv8+y--


--===============4188476252868365==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
zynot-dev mailing list
[email protected]
http://lists.zynot.org/mailman/listinfo/zynot-dev

--===============4188476252868365==--