-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/24/2010 12:54 AM, Ruediger Landmann wrote:
> On 06/24/2010 01:04 PM, Eric "Sparks" Christensen wrote:
>>
>> So your release is based on localization.
>
> Pragmatically, yes.
>
> But it's really more that the change of state from "draft" to "we assure
> you readers out there that this works for F14" coincides with the change
> of state from "not ready for translation" to "ready for translation".
>
> However, because "ready for translation" is a harder, more visible
> change of state (and one that impacts directly on our colleagues),
> "ready for translation" is a really good indicator that the other change
> of state ("this works for F14") has taken place.
But things change...
>
>> So if something changes in
>> the release after Fedora is released we really can't update the guides
>> because it would break translations.
>>
>
> Correct. Any string change, no matter how minor, breaks every single
> translation of that document. We just don't have the bandwidth to
> accommodate that.
>
> Obviously, if we discover a severe problem in a F13 doc (for example
> something that tells users to do something really harmful) then we
> actually *want* to break any translations of that; but this is where we
> have to work closely with L10N.
>
> This all means that anyone can check out the source for themselves at
> any time and build the doc in any language on which translators have
> finished their work.
Well, I don't think that we should be making available incorrect
information. If the information is wrong it should be fixed!
>
>> So does this mean we should release the F14 versions immediately
>> following the F13 release and update the F14 regularly throughout
>> development?
>>
>
> Exactly the opposite.
>
> All development work should always take place in the "master" (Git) or
> "trunk" (SVN) of the document and we shouldn't publish anything for F14
> until we've had a chance to test it against the alpha.
And this goes against our "release early, release often" 'policy'.
Right now, under your plan, we release twice a year and have a six-month
turn around for fixing bugs. That's not acceptable in my opinion.
Things change and we need to be flexible with that but if we aren't
giving our readers a chance to properly review our new guides then we
aren't getting the feedback we need. If we aren't going to fix bugs
then... well, I'm going to fix my bugs.
If we get the POT files in the hands of the translators as soon as
possible... right now... then they should have ample time to get the
big stuff done which allows them to fix the smaller bugs right around
release time.
>
>> How do you handle bugs in the F13 versions?
>>
>
> If it's a particularly severe bug, we fix it in the F13 branch, notify
> Localization, and republish; breaking all translations in the process.
>
> If it's not severe, we fix it in "master" or "trunk". The fix will never
> be published for F13, but will appear in the F14 guide (assuming that
> the surrounding content is still relevant).
What do you consider severe? A bug means, usually, incorrect or
incomplete information which sounds pretty severe to me.
>
>>> If the guide is verified against F13 to a point where we can take the
>>> "Draft" watermarks off it and hand it over to translators, then we can
>>> release for F13.
>>>
>> Okay, but what if everything is good for F13 but the guide is incomplete?
>>
>
> If we're happy to freeze development at a particular point for F13,
> there should be no reason why we couldn't branch a mostly complete
> document for F13, hand it over for translation, take the "draft"
> watermark off it, and release it mid-cycle. Development then continues
> in the "master" or "trunk" as usual. The same is true for guides not
> completed in time for GA.
>
> If you don't feel that a guide is at a point where it makes sense to
> freeze it, or where you wouldn't be happy to ask translators to put
> their time and effort into it, this is a symptom that it's not ready for
> release as anything but "Draft Documentation" yet.
>
> Cheers
> Rudi
>
> PS -- one small correction; last time, I suggested that a guide
> shouldn't be branched until Beta. While this is true in a perfect world,
> we probably really do need to branch during Alpha so that we give
> translators enough time to do their work. Changes in the F14 branch
> between alpha and beta will sometimes be necessary, but as always, we
> would try to avoid changing existing strings wherever possible. Note
> that we need to make changes during alpha and beta in two places:
> "master" and F14. This is where "git cherry-pick" comes in very handy.
I really don't like freezing the guides...
- --Eric
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iQIcBAEBAgAGBQJMI0qLAAoJEDbiLlqcYamxahcQAL4j5ezst32yw1249rlW5mUT
Cly+hebALt1ojIuKEGeo++q6k+SAYK/Bx7lcEwZCWwOygg0XrQIYWVuuZFHsGnwv
NC6DNoUcucv9MM0ffZNnfTRjJQ/Fdw1z+YdOyA0eHxp06uLN3LyvVprPKC3foDn4
tlouWft5GUg6Vzg4l1qTm3fMZrFo9X2Lp5GzJA6/q9LGS12VZVbg8B/WOWWLBI6U
AaxOtmSun4IN9lfsCDFmU+1CVIjyQ4nFmC+xsvoMb4V1KVA4fk/nqhnsevBPOQUw
uXXZosCCHZ1P+uNCCAebCiS/h8vpnyCQtWBcgj6wXnMf5Uxr1v8St94HSsG+SBhe
7nQdBcGeyC5OH866zJ/xNWiIas+jB3dV9/3jzs+qQqDitryb9dsxIO8Jfp3iosuC
M6UEfOxnN8fEO3txtWMyiq+Vo0/MfaGwuLN6iOijuTEoI0HFE6J2ycrkMUGBp2QZ
ge3neF6GVij8n8heFe0TShX7Kc0ZFsw9cs7l2SqYox3+V9roGhyPCwA7GCi16o9P
AGAeermKJlyTnBd3xgQ4cOiVGmueeIhvfUbKVj2fYRUNUNVVPBJCdItLu4JddbUQ
1yO0dMUmGiad+4H/j+3nz5hmXP34m3YifT+5EEqDJkHnjft944GFNEzb9Svp4Ze8
Fi+23HM++0FGqlpAw14a
=Lk1D
-----END PGP SIGNATURE-----
--
docs mailing list
docs@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/docs
