On Sat, Apr 16, 2011 at 01:32:31PM +0200, Luca Barbato wrote: > We should focus on what we provide first, then how we are organized and > then on which is our origin.
I agree that this needs to be split somehow, it's hard to review. > --- a/src/about > +++ b/src/about > @@ -9,57 +9,46 @@ href="http://ffmpeg.org";>FFmpeg</a> codebase, but goes its > own way these > > +<h2>Releases</h2> > > +<p> We are committed to provide major releases yearly and point releases > +at least on a quaterly rate. We try to maintain at least two major release > +at time (currently 0.5 and 0.6), while developing the next one (0.7). </p> I'd drop the numbers from here, we would have to exchange them all the time. What's the current timeframe for major releases? Reinhard seemed to want a quicker cycle than once per year. nit: Please format newly-added paragraphs <p> ... </p> > +<p> Point releases will contain mostly bugfixes and performance improvements. > +The API and ABI will remain stable and only few features might get added. > +The focus is to provide a stable foundation. We suggest distributions to > +provide point releases.</p> We encourage distributions to follow point releases. > +<h3>Major releases</h3> > > +<ul> > + <li> All the deprecated functions will be removed </li> > + <li> Libraries and headers might get added or removed </li> > + <li> The behaviour of the provided tools will change </li> > +</ul> Drop the spaces and add periods. Behavior may change, it's not sure that it will always change. > +<p> In order to make the transition as smooth as possible, the removal of > +deprecated function can span more than whole release cycle.</p> deprecated functions can span more than one release cycle > +<p> Currently 0.7 will replace and deprecate most of the buffered and > +unbuffered IO subsystem functions, the 0.6 compatibility will be preserved > +until the 0.8 release. </p> These are details that belong on the news page and IIRC are already mentioned there. > +<p> Our master branch should be always in an almost stable condition, we should almost always be in > +<p> If you are not represented yet in <a href="http://fate.libav.org"; > title="FATE Automated Testing Environment">FATE</a> and you have the > resources to provide > +reports please contact us. </p> It's not clear what "you" is here - talk about your system, your OS, your CPU, whatever.. nit: Shorten these long lines. > @@ -68,15 +57,28 @@ instance, most of the ffmpeg-mt work has been merged into > Libav <a > + > +<p> We are not afraid to overhaul radically our code in order to provide a > +better foundation for future works and we prefer to spend effort to get > +clean code right instead of piling up special cases and heuristics. </p> radically overhaul, future work > +<p> We are patient enough to track bugs and corner cases until they are > +completely solved </p> . > +<p> With the help of our users we try to improve the experience of using > +both the libraries and the tools </p> . > +<p> We try to focus both on real world issues as well on experiments that > +might lead to new interesting outcomes. </p> as well as > @@ -181,3 +183,55 @@ Plus, we expect everybody to not > While we hope to keep disciplinary action to a minimum, repeated violations > of > this policy will result in offenders getting temporarily or permanently > removed > from our communication channels. > + > +<h1>History</h1> It's hard to see the changes here - maybe we should get the above part finished first. Diego _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
