[Rear-users] SF.net SVN: rear:[727] trunk/usr/share/rear/doc/Rear-release-notes.txt

Gratien D'haese 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
> release.

Hum, not fully agree. The list of complete functionality
should be part of
the 'rear concept guide'. Release notes normally list up
the differences
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
> include
the various information that is now inside the release notes.
> (eg.
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:

OpenSuse 12.1
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 
> releasing.

We may not wait too long as rear-1.11.0
will not work on F16. So I expect a bug report
any time.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pikachu.3ti.be/pipermail/rear-users/attachments/20111117/9b91f488/attachment.html 

More information about the rear-users mailing list