Fedora-trans-list Digest, Vol 63, Issue 6
John J. McDonough
wb8rcr at arrl.net
Wed May 6 11:37:18 UTC 2009
----- Original Message ----- Date: Wed, 6 May 2009 00:19:45 +0200
From: Xavi Conde <xavi.conde at gmail.com>
Subject: Re: Release-note is long and hard for translating
> I see translating release notes as a long term useless effort
To a degree, you are right. Release notes have decreasing utility with
time. But then, so does everything else. The thing that makes the release
notes different than, say, the Installation Guide is that it is (or should
be) 100% new each release.
> I don't see any benefit for the user in knowing that openjdk was
> upgraded to XXX, rarely it will urge him to install Fedora.
This is the real problem. Every change is important to somebody, otherwise
it wouldn't be there. A lot of people are out there waiting for this
particular bug to be fixed, and when it is fixed in the upstream, most
people aren't going to want to compile it from source. So they wait until a
distro has the fixed version. Same with new features in some app or
another. Those features are there because somebody needs them. Those
somebodys are looking for the feature they need.
The problem is that the market is so diverse. We like to highlight
"important" features, but they are important only to us. I would argue that
the only F11 feature that is interesting to a large fraction of users is the
20 second boot, and even there, many people don't reboot for months at a
time, so it is really a non-event. Yes, there are features that are really
cool, but each has a pretty small audience.
That's why I am suggesting that we list ALL the changes, and pick a very few
to highlight. the list would make it easier for people looking for a
particular version to see whether it is there. The list, probably a table,
would consist of the name of the package, the old and new version numbers,
and a link to the upstream notes. None of that would need to be translated.
The description of the small number of cool features would need to be
translated, but that should reduce the amount that needs to be done to a
fraction of what it is today.
That still leaves the question of just how much prose do we want to have,
and how do we select the important changes. I think we often miss the boat
here. The release notes really do need to highlight any case where the user
needs to take action as a result of upgrading, especially if that action has
to occur before the upgrade. We don't do that very well now, and when we
do, it is only for the "important" applications.
But important to who? We are pretty careful, for example, of documenting
any special actions for MySQL or PostgreSQL database upgrades. These are
high profile applications. But I would argue that relatively few people
actually use them. The change is important for those who do use them, and
you could argue that when they are used, they tend to be used in highly
visible situations, but the audience is pretty small.
I don't know how we make these calls. I have some thoughts on ways to help,
but so far I haven't thought of anything that would get us a large fraction
of the way to where I would like us to be. We need a lot of dicsussion
between now and F12 to zero in on the right answer, so I am disappointed
that there has been little discussion on
We really need the discussion. Perhaps some of that will happen at FUDcon.
More information about the trans