Re: How does team maintenace of python module works?
On Feb 19, 2013, at 09:42 PM, Thomas Kluyver wrote:
>After that it gets tricky, because we'd knock E out next, but the I'm not
>sure where the votes counted for E (Scott & Barry) should be reallocated.
If it makes things easier, I am essentially sided with Piotr. The fact that I
don't like git much is immaterial - I want a dvcs and don't have the time to
put into a bzr or hg migration. I don't have time to put into a git migration
either, but it seems like you've got that covered. :)
So I still think it comes down to, them that does the work gets to decide, but
there *is* work to do. It's clear we don't want multiple vcses. So I think
you have an opportunity to convince us by:
* Doing a test migration and putting a test repo up so we can play with it and
see what it's like.
* Figure out whether full-source or debian/ only works better (maybe give us
both repos so we can play with them and discuss the pros and cons from
actual working examples).
* Put together draft policy and documentation to describe a workflow for team
maintenance of packages under git, including branching, pull requests, code
review, quilt integration, package building, etc.
* Work out how upstreams that are under other vcses would work.
* Provide a plan for a smooth flag day transition if/when consensus is reached.
* Gather feedback, fix problems, rinse and repeat.
Once people are comfortable with how a git-based team repository would work, I
suspect you'll find more consensus to switch.
Cheers,
-Barry
Reply to: