Merge pull request #1721 from jonboulle/master

*: add maintenance warnings

Author: jonboulle

CONTRIBUTING.md

@@ -1,90 +1 @@
-# How to Contribute
-
-CoreOS projects are [Apache 2.0 licensed](LICENSE) and accept contributions via
-GitHub pull requests.  This document outlines some of the conventions on
-development workflow, commit message formatting, contact points and other
-resources to make it easier to get your contribution accepted.
-
-# Certificate of Origin
-
-By contributing to this project you agree to the Developer Certificate of
-Origin (DCO). This document was created by the Linux Kernel community and is a
-simple statement that you, as a contributor, have the legal right to make the
-contribution. See the [DCO](DCO) file for details.
-
-# Email and Chat
-
-The project currently uses the general CoreOS email list and IRC channel:
-- Email: [coreos-dev](https://groups.google.com/forum/#!forum/coreos-dev)
-- IRC: #[coreos](irc://irc.freenode.org:6667/#coreos) IRC channel on freenode.org
-
-Please avoid emailing maintainers found in the MAINTAINERS file directly. They
-are very busy and read the mailing lists.
-
-## Getting Started
-
-- Fork the repository on GitHub
-- Read the [README](README.md) for build and test instructions
-- Play with the project, submit bugs, submit patches!
-
-## Contribution Flow
-
-This is a rough outline of what a contributor's workflow looks like:
-
-- Create a topic branch from where you want to base your work (usually master).
-- Make commits of logical units.
-- Make sure your commit messages are in the proper format (see below).
-- Push your changes to a topic branch in your fork of the repository.
-- Make sure the tests pass, and add any new tests as appropriate.
-- Submit a pull request to the original repository.
-
-Thanks for your contributions!
-
-### Coding Style
-
-CoreOS projects written in Go follow a set of style guidelines that we've documented 
-[here](https://github.com/coreos/docs/tree/master/golang). Please follow them when 
-working on your contributions.
-
-### Format of the Commit Message
-
-We follow a rough convention for commit messages that is designed to answer two
-questions: what changed and why. The subject line should feature the what and
-the body of the commit should describe the why.
-
-```
-scripts: add the test-cluster command
-
-this uses tmux to setup a test cluster that you can easily kill and
-start for debugging.
-
-Fixes #38
-```
-
-The format can be described more formally as follows:
-
-```
-<subsystem>: <what changed>
-<BLANK LINE>
-<why this change was made>
-<BLANK LINE>
-<footer>
-```
-
-The first line is the subject and should be no longer than 70 characters, the
-second line is always blank, and other lines should be wrapped at 80 characters.
-This allows the message to be easier to read on GitHub as well as in various
-git tools.
-
-## Adding Tests
-
-Ideally most functionalities should be covered by both unit tests and
-functional tests. This means, every time when you add a new functionality,
-you should also add unit tests, which is stored in *SRC_test.go*, as well as
-a [functional test](./functional/README.md), located under directory
-*./functional/*.
-
-Note that when adding a unit test under a new directory, you need to make sure
-that the new directory must be added to *TESTABLE* in [./test](./test). Without
-doing that, CI cannot run the new unit tests at all. Even build errors cannot
-be automatically detected.
+fleet is no longer developed or maintained by CoreOS. If you are interested in the future of the project and taking over stewardship, please contact [email protected]

Documentation/achtung.png

@@ -17,7 +17,7 @@ CPU usage from parsing all D-Bus messages when interacting with systemd.
   - a) parsing the JSON-encoded representations (stored in etcd)
   - b) parsing the unit file itself (using go-systemd)
 
-- The agent deals very poorly with inconsistent read/write latencies with etcdal
+- The agent deals very poorly with inconsistent read/write latencies with etcd
   (*what is the actual behaviour?*)
 
 ## Improvements

Documentation/fleet-scaling.md

@@ -1,2 +1 @@
-Jonathan Boulle <[email protected]> (@jonboulle)
-Nick Owens <[email protected]> (@mischief)
+fleet is no longer developed or maintained by CoreOS. If you are interested in the future of the project and taking over stewardship, please contact [email protected]

MAINTAINERS

@@ -1,3 +1,7 @@
+## <img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"><img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"><img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"> Deprecation warning <img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"><img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"><img src="Documentation/achtung.png" alt="WARNING" width="30" height="30"><a name="deprecation-warning"></a>
+fleet is no longer developed or maintained by CoreOS. CoreOS instead recommends Kubernetes for all clustering needs.
+The project exists here for historical reference. If you are interested in the future of the project and taking over stewardship, please contact [email protected]
+
 # fleet - a distributed init system
 
 [![Build Status](https://travis-ci.org/coreos/fleet.png?branch=master)](https://travis-ci.org/coreos/fleet)
@@ -9,12 +13,11 @@ fleet ties together [systemd][coreos-systemd] and [etcd][etcd] into a simple dis
 
 ## Current status
 
-fleet has seen production use for some time and is largely considered stable.
-However, there are known [scalability limitations][fleet-scaling] with its architecture.
-As such, it is not recommended to run fleet clusters larger than 100 nodes or with more than 1000 services.
-The fleet project is being maintained for bug fixes but the existing maintainers do not intend to add additional major features or significantly rework fleet to address these limitations.
+The fleet project is [no longer maintained](#deprecation-warning).
 
-If you are a developer and wish to help maintain fleet and improve its scalability, please email the [maintainers][maintainers].
+As of v1.0.0, fleet has seen production use for some time and is largely considered stable.
+However, there are [various known and unresolved issues](https://github.com/coreos/fleet/issues), including [scalability limitations][fleet-scaling] with its architecture.
+As such, it is not recommended to run fleet clusters larger than 100 nodes or with more than 1000 services.
 
 ## Using fleet
 
@@ -63,9 +66,9 @@ After you have machines configured (check `fleetctl list-machines`), get to work
 
 ### Building
 
-fleet must be built with Go 1.4+ on a Linux machine. Simply run `./build` and then copy the binaries out of `bin/` directory onto each of your machines. The tests can similarly be run by simply invoking `./test`.
+fleet must be built with Go 1.5+ on a Linux machine. Simply run `./build` and then copy the binaries out of `bin/` directory onto each of your machines. The tests can similarly be run by simply invoking `./test`.
 
-If you're on a machine without Go 1.4+ but you have Docker installed, run `./build-docker` to compile the binaries instead.
+If you're on a machine without Go 1.5+ but you have Docker installed, run `./build-docker` to compile the binaries instead.
 
 ## Project Details
 
@@ -78,10 +81,6 @@ See the [API documentation][api-doc] for more information.
 
 See the [releases tab][releases] for more information on each release.
 
-### Contributing
-
-See [CONTRIBUTING][contributing] for details on submitting patches and contacting developers via IRC and mailing lists.
-
 ### License
 
 fleet is released under the Apache 2.0 license. See the [LICENSE][license] file for details.