## Auto-converted by kwiki2moinmoin v2005-10-07
Make a long-term "server" release, similar to what we do now, and a "desktop" release.

This proposal is similar to or incorporates parts of DebianInstallerReleasesAreDebianReleases, FixedReleaseDate, PartialReleasesFullRelease and SubProjectPerStabilityLevel.

It is mostly unlike ReleaseWhenReady (except insofar as the "server" release tries to incorporate some leeway time to allow the release to be as ready as possible), DropStableJustUseTesting, ReleasesOnlyCore, and ReleasePerSubsystem.

 * "server" and "desktop" may be misleading names as they'll both contain servers (Apache, BIND, etc.) as well as X and other desktop applications. This is not ReleasePerSubsystem - both releases will contain essentially the same software, just on different release and security support timelines.  Compare to RHEL vs Fedora - perhaps names like "enterprise" and "workstation".  We can always choose more appropriate names.

 * The "server" release should be similar to what Debian releases now, but release 12-18 months, with a long period of security support for each release.  We can give ourselves some leeway (12-18 months) to try and do our best to ReleaseWhenReady, but to remain viable and best serve our users, we must release every 1.5 years.

 * The "desktop" release should release every six months, with a shorter period of security support for each release.  This is very similar to DebianInstallerReleasesAreDebianReleases.  Also, this is very similar to Ubuntu - we should work more closely with Ubuntu or even pool efforts, without dropping packages Ubuntu currently isn't incorporating.  This is not LetUbuntuReleaseForUs - Debian needs to release and we need to make viable desktop releases - this is just a call to learn from and work more closely with Ubuntu.

 * If we make point releases of the "desktop" release, our policy should be less like our conservative requirements for current stable releases and more like backports.org, again perhaps working more closely or officializing this effort (FormaliseBackports).

 * Releases freeze and release in a time-based fashion, NOT "when they're ready".  More so for the desktop release - the "server" release should have more leeway but still should release every 18 months maximum.

 * If something isn't ready to release (by definition, RC bugs), and can't be fixed in time for the freeze, it is removed or rolled back to the version from the previous stable at the beginning of the freeze.

 * Like DebianInstallerReleasesAreDebianReleases, keep debian-installer and testing in a releasable state as much as possible.

 * (Perhaps only for the "desktop" release) Bugs currently considered RC (including FTBFS) that do not affect x86, amd64 or powerpc (+ sparc, alpha?) shall no longer be considered RC.{{{
  
  Justification: Learn by example.  Even the ["NetBSD"] project
  doesn't release every arch, every release, and they have a
  single source tree!  Nothing prevents the motivated
  maintainers of other architectures from keeping them bug free
  and in sync, but it doesn't serve our users to delay a
  release for them.
}}}

See ReleaseProposals for alternatives.