kicad-doc-devs team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

FWIW, I would help write documentation for the bleeding edge code that I
work on, if there were a branch to do it in.
I don't want to do that today without a branch because I don't want to
manage carefully writing the documentation to apply to both 5.1 and
bleeding edge.
I agree with Carsten's suggestions regarding the use of branches.

-Jon

On Wed, May 6, 2020 at 2:33 PM Carsten Schoenert <c.schoenert@xxxxxxxxxxx>
wrote:

> Hello Marco,
>
> Am 06.05.20 um 11:59 schrieb Marco Ciampa:
> > This issue:
> >
> > https://gitlab.com/kicad/services/kicad-doc/-/issues/773
> >
> > is directly related to our lack of manpower or really to our lack of
> courage?
> >
> > Lets fork the docs and purge the 5.* docs from 6.* new features info.
> >
> > For what I see docs are already frozen and that can be a reason.
> >
> > Making cherry-picks here and there between the two branches should not be
> > a big deal...
> >
> > What do you think?
>
> having just one branch for all the development directions can't be the
> right way.
>
> Uses branches within git is easy and costs quite nothing.
>
> Drop all non relevant branches within the Gitlab instance for kicad-doc.
> I see e.g. branches like dynamic_version_info, zh_po_hack,
> github/fork/*. I've no idea waht they are for, other users for sure also
> don't know why they are here.
>
> Specify the branch structure so contributors see were they are. E.g. use
> master' for the documentation of the current upstream behaviour, use
> 'release-5.1' for the current stable release tree, once KiCad 6.0 got
> the final release create a new branch 'release-6.0' on top of the
> 'master' branch.
>
> All contributions need to be done by direct commits of people who have
> commit access or by *fast-forward* merge requests.
>
> Keep the structure clean and simple and document this.
>
> I've lost finally the interest to work on the documentation due the
> above reasons. But the main reason in my eyes for the outdated
> documentation is the lack of people who are willing to write some
> bleeding edge documentation. I'm not a native English speaker, I'd be
> the wrong person for doing anything on this.
>
> --
> Regards
> Carsten
>
> --
> Mailing list: https://launchpad.net/~kicad-doc-devs
> Post to     : kicad-doc-devs@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-doc-devs
> More help   : https://help.launchpad.net/ListHelp
>