[Rear-users] SF.net SVN: rear: trunk/usr/share/rear/doc/Rear-release-notes.txt
gratien.dhaese at it3.be
Thu Nov 17 14:52:44 CET 2011
On Thu, 17 Nov 2011 13:46:32 +0100 (CET), Dag Wieers
> On Tue, 15
Nov 2011, gdha at users.sourceforge.net wrote:
>> The first draft of the
Release Notes for 1.12.0. Please send your
>> remarks ASAP as the release
of 1.12.0 is coming (soon).
>> Any blocking items? The only failing
component is btrfs, but it is
>> marked as experimental (so we're
> The remarks I have:
> - The release notes currently is
the document with the most value to
> end-users looking for information.
But especially the older release
> information contains data that is no
longer correct. (e. NETFS_URL=)
I do try to point out what became obsolete
(perhaps I missed some)
> So I would prefer to get rid of the older
release information and
> simply provide 2 chapters: one with a list of the
> functionality and the second, with the new functionality in
Hum, not fully agree. The list of complete functionality
should be part of
the 'rear concept guide'. Release notes normally list up
between the releases and issues + work-arounds.
> - I'd
like to include a Rear documentation file in AsciiDoc that we can
collaborate on. I will try to do this this evening. There we can
the various information that is now inside the release notes.
configuration examples and use-cases)
If you are referring to an enhanced
configuration examples guide then I
fully agree we could do a better
> - We haven't decided what we would test before doing a new release.
> has now come up a few times. I would propose we make a list of
scenarios (these could match the documented use-cases) and a matrix of
distributions vs scenarios. For each new release, these can then be
tested and filled out in the matrix.
What have I done so far:
15/16 with BACKUP=NETFS (NFS/CIFS/file/USB) and BACKUP=RSYNC
rc1 with BACKUP=NETFS (CIFS) and btrfs
> From the documentation we can
then refer to this matrix that after a
> release continuous to grow. One
possibility is that we put the release
> version inside of the matrix
indicating this release was the last one
> tested for a
> This would make it more clear what has been
tested by others.
> I don't want to block any pending release, however I
hope we can decide on
> the above and implement something pragmatic for
this release, before
We may not wait too long as rear-1.11.0
will not work on F16. So I expect a bug report
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the rear-users