OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: How to Contribute to the DocBook Project on GitHub?


Thomas Schraitle <tom_schr@web.de> writes:
> thanks to the release of the new DocBook XSL stylesheets and the
> move from SourceForge to GitHub. Great to see this!

I've no converted the 'docbook' user to an organization. That means we
can have teams of developers working on different parts of the
project.

> === 1. How to contribute?
> What is the preferred method in regards to collaboration for
> DocBook@GitHub? I can think of some scenarios:
>
> a. Move all(?) DocBook users on SourceForge to GitHub and give them
>    write permissions
> b. Only a handful of users get write permissions, others have to create
>    pull requests
> c. Something completely different?

I propose that several of us get write permissions to the repos. Now
that we're an org, we can have different teams for different repos.

I propose that everyone, those with write access and everyone else,
submit pull requests for changes. I think that's a nice clean model
and it encourages collaboration and code review.

> === 2. Branching model for DocBook?
> Does the DocBook project has decided yet about a branching model?
>
> For example, some projects consider the master branch as "holy" and
> only stable releases are published. Others create features in a special
> branch and merge them into master after the feature is finished. Some
> project use a develop branch etc. So there are almost endless
> possibilities with Git in comparison to SourceForge.
>
> Speaking of a develop branch: In this regard, I made some good
> experiences with GitFlow[1]. It's "a collection of Git extensions to
> provide high-level repository operations for Vincent Driessen's
> branching model[2]" according to its home page.
>
> What do you think? :)

I think gitflow is nice. I also think that with a bunch of folks
coming over from SourceForge without a lot of git experience, it's
going to be painful to impose a single model. There's plenty to learn
already.

Here's what I do:

1. Fork docbook/repo
2. In ndw/repo, I create a 'dev' branch
3. I do most of my work in 'dev'
4. When I'm ready to release a feature, I squash things down to
   a reasonable number of commits and make a pull request to
   'master' on docbook/repo
5. On docbook/repo, we can get some review or we can be bold
   and just accept the request
6. When it's time to do a release, tag the 'master' branch and
   make the release.

I'll be working to make the release part automatic with Travis CI, but
that's not fully automated yet for all projects.

> -----
> [1] https://github.com/petervanderdoes/gitflow-avh
> [2] http://nvie.com/git-model

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | Art happens--no hovel is safe from
http://www.oasis-open.org/docbook/ | it, no prince may depend upon it,
Chair, DocBook Technical Committee | and vastest intelligence cannot
                                   | bring it about.--J. M. Whistler

Attachment: signature.asc
Description: PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]