<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Having some mail client issues. Resending.<br>
<br>
On 02/11/2010 11:17 AM, Susan Lauber wrote:
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">The time rapidly
approaches when we need to start updating the guides for a new
version. In this example - start work on F13 version of the guides.
<br>
Basically - I wanted to know where to start contributing changes
intended for the F13 version on guides. And where to point new
contributors as well.
<br>
<br>
In the meeting tonight, a discussion started about branching
philosophies.
<br>
#action laubersm Bring branching topic to docs list to decide how we
want to do this going forward, and record it for posterity.
<br>
<br>
I have looked at a couple of guides in git. They seem to have a
master, F11, F10, etc, and various F??-tx branches.
<br>
I think we generally agree that the F??-tx branches are for the
translation teams.
<br>
The rest seems to indicate a need for a F12 branch and then master
becomes F13.
<br>
But when should the F12 branch appear so that work on F13 can begin?
<br>
<br>
I did not look at all the guides - there may be other schemes in use
already.
<br>
<br>
So I see 2 major parts to the question:
<br>
1. Is this the branching scheme that works best for Fedora Docs group
and guides?
<br>
What are the alternatives?
<br>
pros/cons? etc
<br>
<br>
</blockquote>
The alternative is not branching. Just to build and forget. This isn't
the kindest approach and goes against some of the theory of open
source.
<br>
<br>
I would say branch at release. We do not have the resources to maintain
old forks of books but we should keep the source for posterity.
<br>
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">2. WHEN do we
branch?
<br>
</blockquote>
<br>
I would argue for at the date of translation string freeze. Only
critical updates (like an error which causes users to delete their root
partition) found in translation should get updated after that point.
<br>
<br>
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">Should the F12
branch been made at release of F12 so that master moves to the next
version right away?
<br>
</blockquote>
<br>
It should be made at translation. I would argue for having master to
just keep going. This allows for continual development. I know how much
some people <b class="moz-txt-star"><span class="moz-txt-tag">*</span>hate<span
class="moz-txt-tag">*</span></b> RAD, agile or SCRUM approaches but
unless I get three major contributors that is the only feasible
approach to take. Fedora continually changes during a release. It is
not the same Fedora by the end of the 6 months when the next one starts
coming out and the documentation is usually out of date for most
interfaces of developed projects.
<br>
<br>
I would argue here for a master/lastest branch and then legacy
branches.
<br>
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">If so, how do we
handle mid release updates to a guide?
<br>
</blockquote>
<br>
We should have a master or latest branch and some method for pushing
more frequent updates. The present method, with the CVS/php/voodoo
monstrosity is a failure. It takes days to push a book and
translations. This is not a conductive environment for updating
documentation. I know someone will respond with the "Zikula is coming"
or some such but this is really holding us back. Is there anything
stopping Infrastructure just giving us limited access to puppet so we
can push updates in a more timely and effective fashion?
<br>
<br>
Until something changes in Infrastructure do not expect <b
class="moz-txt-star"><span class="moz-txt-tag">*</span>any<span
class="moz-txt-tag">*</span></b> mid release updates, ever. It is too
much work and takes a fanaticism and commitment which I certainly lack.
Masochism is not everyone's idea of a good time.
<br>
<br>
<blockquote type="cite" style="color: rgb(0, 0, 0);">Should master stay
the current version until the next release alpha? Which is about now.
<br>
Or even longer?
<br>
<br>
</blockquote>
Master should just go with the latest and greatest. I think this is one
of Fedora's strengths which the Documentation Project should latch onto
and hold for dear life. We can channel the energy which most people,
including myself, love about Fedora and open source; the life which
drives continual change. People want to document new features and
technologies far more than they want to do many other things. We need
to channel this energy into our docs. We need people working on
documenting the latest and greatest bits of code. Master should be as
fast as the writers want to ride the lightning, if that is Rawhide, so
be it. I am presently intending to go this direction with the
Virtualization Guide.
<br>
<br>
Chris
</body>
</html>