[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: