We could also follow how zeromq does things and simply not have branches in the main repos, using forks instead for maintenance releases. It does not help with the fact that we'd be back in charge of cherry picking fixes for bugfix releases though.
But I honestly don't mind too much, happy to leave the branch workflow to people more experienced with git then me. Floris On 19 Jun 2015 09:28, "Florian Bruhin" <m...@the-compiler.org> wrote: > * holger krekel <hol...@merlinux.eu> [2015-06-18 05:47:26 +0000]: > > Would it make sense to consider "master" to become the new "bug fix > branch" > > and have a "pytest-2.9" then where we collect new features? This way > > the default is to do bugfixes which might be easier for newcomers to > > the project. > > Another possibility (GitLab flow[1]) would be to make all commits to > master, and then cherry-pick bugfixes to a, say, pytest-2.7 branch. > > That's what I use for my project, and I'm quite happy with it. It > means a bit more work for maintainers (as they have to cherry-pick > things), but it takes the "burden" of deciding/knowing which branch to > use from the contributors. > > [1] https://about.gitlab.com/2014/09/29/gitlab-flow/ > > Florian > > -- > http://www.the-compiler.org | m...@the-compiler.org (Mail/XMPP) > GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc > I love long mails! | http://email.is-not-s.ms/ > > _______________________________________________ > pytest-dev mailing list > pytest-dev@python.org > https://mail.python.org/mailman/listinfo/pytest-dev > >
_______________________________________________ pytest-dev mailing list pytest-dev@python.org https://mail.python.org/mailman/listinfo/pytest-dev
