On 01/22/2014 12:24 PM, Barry Warsaw wrote: > Do you really think that it's unfeasible for git proponents on this team to > find the necessary resources to plan an orderly en mass transition? It might > indeed be so, we're all busy. But let's hopefully all agree that the end goal > is to have all team-maintained packages in the same vcs.
I can't answer this question, as I can't speak for the others, and I don't have time myself. > So let's say we have to move packages slowly. I want to make sure there's a > team commitment (and especially from the git proponents) that we'll have a > deadline at which all remaining packages will be switched. I *really* want to > avoid the typical long tail where packages just linger under svn and bit rot. > (E.g. long tail conversions to dh_python2.) Well, if we decide to move slowly things to Git, then the packages that will stay in the SVN repo will be those largely unmaintained... > So I would be in favor of an experiment. Pick 5 packages that are > representative of team packages, that can be updated and uploaded by anyone on > the team, and that see regular but not too often new upstream releases. I'd > happily volunteer one of my packages if that helps. Well, if the team decides to move to Git, then I would put *ALL* of the python module packages I maintain for OpenStack directly within the DPMT. That's a consequent list of about 50 python modules: http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org The only reason they are maintained within the OpenStack team is because I don't want to be forced to use SVN, and I think it's safer than in collab-maint where so many people have commit access (which means they can rm -rf...). > The most important thing though is to *document* in detail *on the wiki* how > to work with those packages in git. I agree that documenting the workflow is very important. I have described my workflow here for OpenStack: http://openstack.alioth.debian.org/ I wish to continue using this git based workflow whenever possible, and use the pristine-tar workflow when there's no upstream git. > Be opinionated, like the way we are with > the LibraryStyleGuide. Don't worry if others disagree with you - we can hash > out best practices in this mailing list over time, but it's really important > to put a stake in the ground. If you can't decide which of two ways is > better, do one package one way and another the other way. I do believe in freedom as well! :) > On Jan 22, 2014, at 11:51 AM, Thomas Goirand wrote: >> Yes, because someone found it useful to disable the git area in the team >> repo on Alioth [1] !!! And this drove people to collab-maint. This was >> predictable, predicted, and unavoidable. > > I don't know if my proposed experiment means re-enabling git on the team repo I believe it does. > or doing the experiment on collab-maint. Any non-DD will have to request for access to collab-maint. This is unnecessary, potentially dangerous, and administratively heavy to do that. > But then my question is: how closely does your vision of the team git repo > overlap with general Debian initiatives like dgit and source branches? It > might be nice if they align rather closely. I don't think this is related. I see dgit as a tool to use only if the package isn't maintained using Git... Cheers, Thomas -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52df7328.8040...@debian.org