Re: How does team maintenace of python module works?
[Barry Warsaw, 2013-02-14]
> Switching to git or any other dvcs isn't going to happen just by asking for
> it. Someone would have to step up and actually do a lot of hard work to make
> it happen. Look at all the work done by upstream Python to get it onto
> Mercurial. It was *a lot* of work, making sure the conversions were high
> fidelity, that documentation was good, that the workflow made sense for the
> use cases, that newbies to distributed vcs were guided through the concepts
> and common practices, etc. etc. The folks who cared deeply about Mercurial
> made a long term commitment to ensuring a smooth transition. That was an
> argument that I lost, but I have to hand it to the winning side - minor rough
> edges and initial problems aside, it's a system that is working very well for
> the community today.
>
> So if some percentage of team members really really want to switch to git,
> step up and do enough of the work on spec (i.e. no guarantees) so that you
> have something that is convincing. It doesn't have to have all the rough
> edges polished off, but I do think it needs to very clearly demonstrate enough
> of a win over svn for the team (or a majority of them) that it would be a good
> switch. Please also do be respectful of the concerns of the detractors and
> opponents, and try to address them as best you can.
+1
I can help those who want to migrate all our packages to Git (as it's my
favourite VCS) and at the same time I (as an admin) will (and already
did in the past) ask anyone who doesn't keep a team package in SVN to
remove DPMT/PAPT from Maintainer/Uploaders (until we officially migrate
to something else).
One of the main points of these teams is to allow other members easy
access to debian directory / keep track of VCS changes (which I fail to
do lately, but did send some replies from -commits mailing list in the
past). Keeping package files somewhere where other team members might
not have write access or would have to do some extra work to find its
location is just not acceptable IMHO.
Providing a script (mr?) that will download/update all packages
(or only one of them, and no, debcheckout is not enough, think about
write access) from various VCSs using just one command might be an option
but only if top contributors (that sponsor uploads or commit changes
also in packages without their name in debian/control) don't mind using
it. [and please please please don't ask for such workflow without showing
the code]
--
Piotr Ożarowski Debian GNU/Linux Developer
www.ozarowski.pl www.griffith.cc www.debian.org
GPG Fingerprint: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645
Reply to: