Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
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-devel@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
Reply to: