[Qgis-community-team] Transifex and doc 1.8

[Nathan Woodrow]

Richard,

If you are talking about having a different github repo for each release
that would be really ugly and I'm not to keen of that idea.  git has the
branching and tagging stuff for a reason and there isn't reason that we
can't use it here for this. This would also make tracking version changes
really hard.

My suggestion is to have a branch for each release with a tag at each minor
release on that branch, master is always kept up to date with what is in
dev, and a branch is made at release time.

We can provide shell scripts for people to clone the repo and checkout the
most current release to work on.  So in the upcoming 2.0 case we could have
a script that clones the repo and sets the branch to master, people can
work on that until we release 2.0 at which point someone creates a 2.0
branch a "Switch to 2.0" shell/batch script.

Deploying to the webserver is easy git archive --format zip --output
/full/path/to/zipfile.zip 2.0  and just unpack it on the webserver.  This
would be much easier then having different repos to clone and export from.

git is just part of our workflow now and IMO should be used for this.  The
main thing is just abstracting away a lot of the git mess into simple to
run scripts.

- Nathan


On Mon, Apr 1, 2013 at 7:17 PM, Richard Duivenvoorde <richard at duif.net>wrote:

> On 01-04-13 10:50, Paolo Cavallini wrote:
>
>  I understand the reasoning, and I agree that wating translators time
>> wouold be a huge
>> mistake. I think the approach Diethard suggest will put serious
>> limitation to the
>> flexibility of the process. I think it is quite common for translators to
>> find
>> mistakes in the sources, and waiting the next release to fix them is an
>> heavy burden.
>> Could we think of a backporting system?
>>
>
> I proposed this earlier, but to be honest, I have the feeling that a
> translating process is not fitting in the normal github source code model.
>
> I think it would be easier to NOT create github branches for every major
> (I mean 1.8 2.0 etc) version, but just copy the documentation tree (or at
> least the desktop-appliation/python cookbook/**otherversionspecificedoc
> sources) and have a copy for every version in master in Github.
>
> -1- This makes it voor Github novices easier to see there are more
> versions of the docs in the tree (as they SEE 1.8 2.0 and master in their
> clone/checkout).
> -2- This makes it easier to deploy everything at once on the webserver also
>
> Downside is:
> -1- we have to update the scripts to handle this every version
> -2- there is a lot of redundancy in sources of the desktop
>
> But it makes the proces easier and more transparant for non coders, and
> also easier to do parallel translation/fixing of docs for older versions.
>
> Feel free to disagree and tell me :-)
>
> Regards,
>
> Richard
>
> ______________________________**_________________
> Qgis-community-team mailing list
> Qgis-community-team at lists.**osgeo.org<Qgis-community-team at lists.osgeo.org>
> http://lists.osgeo.org/**mailman/listinfo/qgis-**community-team<http://lists.osgeo.org/mailman/listinfo/qgis-community-team>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-community-team/attachments/20130401/6b4561a9/attachment.html>