Adjust 'How to contribute instruction'

[klemmster]

https://www.libavg.de/site/projects/libavg/wiki/Patches

20

[klemmster]

@uzadow I'd propose this model:

http://nvie.com/posts/a-successful-git-branching-model/

where everybody can create features-branches and open pull-request to the developer branch.

Maintaining archlinux compatibility of stable-releases where mesa or ffmpeg/libavg regularly break is a hassle right now, because patches are usually just applied on top of current svn. Git-flow put's an end to that.

[uzadow]

Sounds good in principle. In general, 'everybody can create features-branches and open pull-requests' is what git is about, right? I'm not sure we should fix all the details yet, however - we need to build experience using git in our situation first. Also, how does the release tarball stuff work? Do you need the distinction between develop and master branches for this? Otherwise, I think it's overkill.

[klemmster]

Ulrich von Zadow notifications@github.com schrieb:

Sounds good in principle. In general, 'everybody can create features-branches and open pull-requests' is what git is about, right?

Or at least what github is about, yes

I'm not sure we should fix all the details yet, however - we need to build experience using git in our situation first.

Of course

Also, how does the release tarball stuff work?

When you tag a commit, github packs the repro automatically and makes it available for download in the release tab.

Do you need the distinction between develop and master branches for this? Otherwise, I think it's overkill.

No, but it isn't overkill anyhow: The current stable libavg release doesn't build on arch any more. The patch went on top of trunk and therefore I've to keep the patch around and apply it manually in the package. In the past stable and trunk diverted so much that patching required too much manual work to keep up with the changes. Using the above model would make it easier to maintain a stable version that still compiles on rolling distros by applying patches to the master (and development) branch and just do minor release bumps.

Hope my point is understandable.

— Reply to this email directly or view it on GitHub.

[uzadow]

I still don't see why we need to have separate trunk/development branches. In the current svn, we have release branches. Couldn't you just apply the ArchLinux patch to release/1.8.x and tag that? Needs no change to current repository organization (so the repo history makes more sense) and allows multiple releases to be supported concurrently, should we ever need that.

[klemmster]

We can also continue to have release-branches and tag sub-releases, I guess. The importer currently converts the release branches to tags and deletes the branches. (in git, tags are pretty much just 'immutable' branches, pointers in history) (you can recover the branches later by checking out the tag in a 'new' branch)

Maintaining multiple releases would pretty much lead to this figure: https://stackoverflow.com/questions/3419689/understanding-git-cherry-pick/3420792#3420792

and using release - branches also makes the developer responsible to take care things don't break later on (http://makandracards.com/makandra/1182-git-advisory-for-cherry-picks-to-production-branches)

It's a matter of taste I guess.

[klemmster]

https://www.libavg.de/site/projects/libavg/wiki/Contribute