Author: kwade
Update of /cvs/fedora/web/html/participate/roadmap
In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv15400/web/html/participate/roadmap
Modified Files:
index.php
Log Message:
Applying patch from bz#189069
Index: index.php
===================================================================
RCS file: /cvs/fedora/web/html/participate/roadmap/index.php,v
retrieving revision 1.1.1.1
retrieving revision 1.2
diff -u -r1.1.1.1 -r1.2
--- index.php 30 Mar 2005 17:47:24 -0000 1.1.1.1
+++ index.php 13 Oct 2006 17:20:34 -0000 1.2
@@ -1,166 +1,10 @@
-<?
-include("site.inc");
+<?php
+//
+// Easily-changeable template for redirection.
+//
-$template = new Page;
-$template->initCommon();
+$NEWURL="http://fedoraproject.org/wiki/RoadMap";;
-$template->options["selected"]="Roadmap";
-
-$template->displayHeader();
-
-?>
-
-<h1>Roadmap</h1>
-
-<h2>What should you expect from the new <? print "$PROJECT_NAME"; ?>?</h2>
-
-<p>
-Openness. Participation. Quality. Change. Disagreement.
-Opportunity. Community.
-</p>
-
-<h2>What does that mean, in concrete terms?</h2>
-
-<p>
-Here is our roadmap;
-it describes both our near and longer term plans, not in terms
-of specific development decisions, but in general direction.
-</p>
-
-<p>
-With minimal necessary exceptions (such as information from partners
-under NDA), Red Hat's own internal development on
-<? print "$RELEASE_NAME"; ?> will be done, starting immediately, on public mailing lists.
-One of the reasons for Red Hat's success has been an open process
-for making engineering decisions; our engineers have been welcome
-to take opposing points of view in development discussions and
-to argue passionately for their point of view. Now, with Red Hat
-development going on in public, Red Hat developers will be arguing
-their points of view on public mailing lists. (If you never saw
-conflicting points of view from Red Hat developers on these public
-lists, you would know that the lists were a sham!) Be aware, when
-reading or participating in these open lists, that because of these
-differences of opinion, any individual Red Hat developer is not
-stating company policy. Red Hat policy will be described as such.
-</p>
-
-<p>
-Red Hat will retain editorial control over the <? print "$RELEASE_NAME"; ?>.
-This is not a free-for-all. However, as a company heavily invested
-in and depending on open source software, Red Hat has also always
-depended on the control of others over their projects. Red Hat
-does not directly control the Linux kernel, GNOME, KDE, Emacs, GCC,
-glibc, and so forth — though by participating in their development
-we influence them.
-</p>
-
-<p>
-Red Hat is merging this community effort with the pre-existing Fedora
-Linux project. This increases the scope of the project from a
-distribution that enables third-party repositories to a project
-which encompasses a core distribution and other components. The
-core distribution will be called <? print "$RELEASE_NAME"; ?> and
-will be managed by a steering committee primarily comprised of
-Red Hat employees. The project will also host add-on repositories
-of packages that are not part of the distribution but are still
-hosted on the same site and are intended to integrate properly into
-the core distribution. The add-ons will be managed by an advisory
-committee comprised of Red Hat employees and other Linux developers,
-particularly those involved in the pre-existing Fedora Linux project.
-</p>
-
-<p>
-Red Hat has, in the past, retained a high degree of control over
-packaging, though even there we have accepted and integrated into
-our distribution many packages created by, and patches to the
-packaging for, many open source software products. Red Hat will,
-based on community members' participation in the development process,
-start to allow community members outside of Red Hat to share more
-direct control over packaging in the future. This will be done
-subject to Red Hat's policies. We have not had to write all these
-policies down in the past; internal training has created a culture
-that promotes unwritten policies. Documenting these policies as
-conflict arises will help internal and external developers produce
-a consistent set of packages. Consistency is important both between
-packages in a single release and in respect to the
-<a href="/about/history/">history of Linux at Red Hat.</a>
-</p>
-
-<p>
-Consistency is important to Red Hat not only because of our
-committment to a consistent distribution provided by
-<? print $THE_PROJECT_NAME; ?>, but also because the bits created as
-<? print $RELEASE_NAME; ?> will be the source of Red Hat's Enterprise and
-retail products.
-</p>
-
-<p>
-<? print "$RELEASE_NAME"; ?> will be done as time-based releases (that is,
-a time will be set for feature freeze, and an intended schedule
-for release, at the beginning of the project cycle) of
-<? print "$RELEASE_NAME"; ?>, and will not
-require consensus to make a release. The
-<a href="/participate/schedule/">schedule</a> will be defined
-at the beginning of the process, and published for all to see.
-All of the test releases will be made public;
-there will be no more "Alpha" or "Private Beta" releases made for
-<? print "$RELEASE_NAME"; ?>. For each new release, the
-<a href="/participate/schedule/">schedule</a> will be created in
-public, with public comment.
-</p>
-
-<p>
-The <? print "$RELEASE_NAME"; ?> releases will not be sold through the
-retail channel as a shrinkwrapped box; the design of the project,
-with the potential for short release cycles, less certainty in
-release date (more public testing of release candidates means more
-likelihood of delaying a release), and so forth
-make it a poor match for the retail channel. Further information
-on the retail product line will be forthcoming
-this fall. <? print "$RELEASE_NAME"; ?> releases
-will be available as ISO images for both CDs and DVDs; may be sold
-online as physical media; may be distributed at Linux User Groups,
-in magazines, in books, and at trade shows; and will be actively
-pushed into content sharing networks such as BitTorrent. Not every
-distribution mechanism will necessarily be used for every release;
-for example, not every release will show up at a trade show.
-However, each of these is a candidate, and some, including online
-ISO images, will be available for all releases.
-</p>
-
-<p>
-Two mechanisms will exist for contributing to the <? print "$RELEASE_NAME"; ?>.
-The most obvious one is integration: packages built, maintained, fixed,
-or otherwise contributed by third parties included in <? print "$RELEASE_NAME"; ?>.
-This will be primarily limited to changes to existing packages for the
-first release of <? print "$RELEASE_NAME"; ?> but will be
-expanded as our community grows, particularly as we merge with the
-pre-existing Fedora Linux project. The second mechanism is
-external package repositories. The
-<a href="/projects/config-tools/redhat-config-packages.php">redhat-config-packages</a>
-program will have support enabled for accessing external repositories of
-arbitrary packages not associated with Red Hat.
-</p>
-
-<p>
-This change will be evolutionary, not revolutionary. You will
-initially see a relatively small number of changes: public discussion
-of changes and development, public test releases, a public
-schedule, a public roadmap. In future releases, the changes
-will grow. Starting with the first release of
-<? print "$RELEASE_NAME"; ?>, you will see new feature updates as well as security
-updates, and you will see the new feature updates qualified in a
-public beta process. In general, you will see much more aggressive
-change to the distribution. Red Hat will incorporate more external
-contributions of code and documentation. Some changes we don't
-yet know — we can only assume that the community of users and
-developers will make recommendations for changes we have not yet
-envisioned or considered.
-</p>
-
-
-<?
-
-$template->displayFooter('$Date$');
+include("redirect.inc");
?>
