Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Am 22.01.2014 08:28, schrieb Thomas Goirand: 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. sure, so you are proposing something which you don't want to finish, just pursuing a rather selfish interest of using git yourself. You did try this with the debian-java team as well. 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... and these will be magically maintained when converted to Git? please don't be silly. unmaintained packages are not a property of the used VCS. And you said you don't have time to spend on these yourself. 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...). apparently these were first needed for openstack. so it seems to make sense to maintain these over there. Matthias -- 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/52dfadf0.9080...@debian.org
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 01/22/2014 07:39 PM, Matthias Klose wrote: Am 22.01.2014 08:28, schrieb Thomas Goirand: 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. sure, so you are proposing something which you don't want to finish, just pursuing a rather selfish interest of using git yourself. You did try this with the debian-java team as well. I don't think so. I don't maintain any Java package. 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... and these will be magically maintained when converted to Git? I guess, not more than with SVN... please don't be silly. I don't think I have. You are making wrong assumptions here, I believe. unmaintained packages are not a property of the used VCS. Agreed!!! And you said you don't have time to spend on these yourself. 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...). apparently these were first needed for openstack. so it seems to make sense to maintain these over there. That's truth only for a subset of them, not all of them. Many are of general purpose. 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/52dfca83.7020...@debian.org
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 15 January 2014 02:29, Chow Loong Jin hyper...@debian.org wrote: On Tue, Jan 14, 2014 at 04:51:20PM +0100, Olivier Berger wrote: Now, if you both want to track upstream sources from origin/master on local upstream/ branch and svn's trunk on local master branch, then, yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges now and then. git import-orig --filter=debian helps to avoid nasty merges, as long as you don't make changes to the upstream sources directly inside your packaging branch -- there shall be no conflicts if upstream does not touch debian and you do not touch the upstream sources. gbp-pq is also wonderful for maintaining quilt patch series. My preference lately is strongly with: dgit + git-dpm (for patch management). git-dpm does not polute repository with branches of any sort, it simply maintains a round-trip-safe conversion from debian/patches to a branch and back again. (Something very similar to Mercurial Queues but done nicer and more specific to debian packaging) I haven't yet found a way to use dgit/git-dpm against svn repository. I'm thinking to simply do dsc-import on the svn side, after I generate an upload with dgit/git-dpm. Once the kinks are worked out, and some sort of forest (mr or repo) management is in place we can start opening up an outstanding git powered workflow. -- Regards, Dimitri. -- 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/canbhlugki6ptvmhd6qihm80hhgr0mbgypc2aa+cvpmjr9gp...@mail.gmail.com
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 01/14/2014 09:24 PM, Alexandre Rossi wrote: I also found out that some packages maintained by the team are hosted on alioth in collab-maint (src: bugz, dajaxice). 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. In fact, using collab-maint is something that I would advise right now if nothing moves in this team. On 01/14/2014 09:55 PM, Piotr Ożarowski wrote: I reported bug reports, thanks Why doing this? It doesn't make sense. It seems obvious to me that the person using collab-maint do want to use Git. Don't force them back to SVN please, it wouldn't be nice to them, especially if our plan is to migrate away from it at some point. I don't see this as a bug, I see it as a problem in the Python team, unless the Git repo is reactivated, and the person who deactivated it doesn't do it again. On 01/14/2014 10:31 PM, Barry Warsaw wrote: I need to spend more time playing with git-bp, but last time I looked at it (cannot remember which package), I had a lot of trouble unless the package repo was organized Just Right. One nice thing about svn-bp is that it pretty much just works with a checked out working directory, even when you have local uncommitted changes (--svn-ignore-new). Probably you're not used enough with Git, because for what I'm doing, it pretty much just work with a checked out working directory with Git as well. On 01/14/2014 10:31 PM, Barry Warsaw wrote: git-bp OTOH required a specific set of branches inside the repo to stitch everything together and if those were missing, it failed miserably. It all depends how you do it. If you base your Git packaging on tags, and not using branches, which means having a debian/gbp.conf that configures this, then it's really strait forward. On 01/14/2014 10:31 PM, Barry Warsaw wrote: I've mostly made my peace with git, so in theory I wouldn't be opposed to the team switching There's been a vote that we should switch already. I don't think it's a good idea to express oneself about liking or not Git: we agreed we should switch to it. , but I still think it's not a good idea to have some team packages in git and the bulk in svn. I value the ability to use the same tools and workflows for all team maintained packages. Now, this could be back on the table: it's been months that we've talked about it, and nothing is happening, because nobody has time. So the only way I see to switch is to do it slowly, having both SVN and Git for some time. Other teams have reported that it worked for them, so I don't see why it wouldn't for python modules. By the way, something like mr (from Joey Hess) could help regarding mass commits. On 01/14/2014 11:09 PM, Hans-Christoph Steiner wrote: I'm a fan of a gradual transition like this, with people switching or setting up git repos as they can. I'm not a fan of it (it'd be IMO better to completely switch), but I don't see any other practical way to move forward right now. On 01/14/2014 11:51 PM, Olivier Berger wrote: It more or less requires only 2 branches : upstream (when you want to track upstream sources) and master (or debian) for the packaging source. Hum... I'd say that *your workflow* requires it, but git-buildpackage itself doesn't. You don't have to do this way. Everything can be contained in a single branch if you use tags. Also, if you don't use tags, and prefer to use upstream tarballs, then I think you're much better off using pristine tar (and git-import-orig). Also, I don't like using debian and master for branch names. These express nothing. It's much better to use unstable-debian and upstream-debian for example. As a reference, here's a debian/gbp.conf for tags: [DEFAULT] debian-branch = debian/unstable upstream-tag = %(version)s And here's one for pristine-tar: [DEFAULT] upstream-branch = upstream-unstable debian-branch = debian-unstable pristine-tar = True I also always add in my debian/gbp.conf: [git-buildpackage] export-dir = ../build-area/ to make sure no contributors dirties the git with build files (yes, you can do that in your ~/.gbp.conf, and the system configuration file in /etc, but the point here is to make sure *everyone* uses the build-area). Thomas [1] I know who it is, though I don't think it is useful to tell who. -- 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/52df4045.6080...@debian.org
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On Wed, Jan 22, 2014 at 11:51:33AM +0800, Thomas Goirand wrote: On 01/14/2014 10:31 PM, Barry Warsaw wrote: I need to spend more time playing with git-bp, but last time I looked at it (cannot remember which package), I had a lot of trouble unless the package repo was organized Just Right. One nice thing about svn-bp is that it pretty much just works with a checked out working directory, even when you have local uncommitted changes (--svn-ignore-new). Probably you're not used enough with Git, because for what I'm doing, it pretty much just work with a checked out working directory with Git as well. git-buildpackage has a few misbehaviors by default: the fact that it builds in place by default instead of exporting to a separate dir is annoying (--git-export-dir=../build-area/), and that you have to pass it extra options when you're building from a branch named 'debian' (--git-debian-branch=branch_name). IIRC there are subtle differences in behavior between --svn-ignore-new and --git-ignore-new, but I don't remember now what they are. Its pristine-tar handling is pretty solid, though. On 01/14/2014 10:31 PM, Barry Warsaw wrote: git-bp OTOH required a specific set of branches inside the repo to stitch everything together and if those were missing, it failed miserably. It all depends how you do it. If you base your Git packaging on tags, and not using branches, which means having a debian/gbp.conf that configures this, then it's really strait forward. Yes, having to edit debian/gbp.conf on a per-branch basis to even get the package to build is an annoying misfeature. Also, I don't like using debian and master for branch names. These express nothing. It's much better to use unstable-debian and upstream-debian for example. As a reference, here's a debian/gbp.conf for tags: [DEFAULT] debian-branch = debian/unstable upstream-tag = %(version)s And here's one for pristine-tar: [DEFAULT] upstream-branch = upstream-unstable debian-branch = debian-unstable pristine-tar = True I also always add in my debian/gbp.conf: [git-buildpackage] export-dir = ../build-area/ to make sure no contributors dirties the git with build files (yes, you can do that in your ~/.gbp.conf, and the system configuration file in /etc, but the point here is to make sure *everyone* uses the build-area). Right... these are things the end user (or the package maintainer) should not have to configure :) But I don't think the DPMT should wait for these buglets to be fixed in git-buildpackage before switching to git. (Not that my opinion matters anyway. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On Jan 21, 2014, at 08:05 PM, Steve Langasek wrote: git-buildpackage has a few misbehaviors by default: the fact that it builds in place by default instead of exporting to a separate dir is annoying (--git-export-dir=../build-area/), and that you have to pass it extra options when you're building from a branch named 'debian' (--git-debian-branch=branch_name). IIRC there are subtle differences in behavior between --svn-ignore-new and --git-ignore-new, but I don't remember now what they are. That's my vague recollection too. Right... these are things the end user (or the package maintainer) should not have to configure :) But I don't think the DPMT should wait for these buglets to be fixed in git-buildpackage before switching to git. (Not that my opinion matters anyway. :) Agreed. We have precedence here too: there were annoying buglets in the Python helpers, which we documented around until they were fixed[*]. We can do the same thing here too, because wikis. Cheers, -Barry [*] like having to explicitly loop through Python versions until pybuild came along. :) signature.asc Description: PGP signature
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-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
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote: I've used git-buildpackage with git-svn on submodules of the DPMT SVN repo without too many difficulties so far. I need to spend more time playing with git-bp, but last time I looked at it (cannot remember which package), I had a lot of trouble unless the package repo was organized Just Right. One nice thing about svn-bp is that it pretty much just works with a checked out working directory, even when you have local uncommitted changes (--svn-ignore-new). git-bp OTOH required a specific set of branches inside the repo to stitch everything together and if those were missing, it failed miserably. I could be totally wrong about that, or I could have just been using the tool incorrectly. I've mostly made my peace with git, so in theory I wouldn't be opposed to the team switching, but I still think it's not a good idea to have some team packages in git and the bulk in svn. I value the ability to use the same tools and workflows for all team maintained packages. I'm not motivated enough to do any work on such a transition itself, so I think those who really want to switch to git need to work out a plan. That would include test repos, documentation updates, transition plans, educating team members, fielding questions, fixing problems, etc. I would personally be supportive, and would be willing to review material and test out recipes. But I think this is going to require a few committed people to do some heavily lifting over an extended period of time to make sure such a transition was smooth and so that everyone on this team was comfortable with the new way of doing things. That's just my opinion, of course. -Barry -- 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/20140114093100.3da46...@anarchist.wooz.org
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
On 01/14/2014 09:31 AM, Barry Warsaw wrote: On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote: I've used git-buildpackage with git-svn on submodules of the DPMT SVN repo without too many difficulties so far. I need to spend more time playing with git-bp, but last time I looked at it (cannot remember which package), I had a lot of trouble unless the package repo was organized Just Right. One nice thing about svn-bp is that it pretty much just works with a checked out working directory, even when you have local uncommitted changes (--svn-ignore-new). git-bp OTOH required a specific set of branches inside the repo to stitch everything together and if those were missing, it failed miserably. I could be totally wrong about that, or I could have just been using the tool incorrectly. I've mostly made my peace with git, so in theory I wouldn't be opposed to the team switching, but I still think it's not a good idea to have some team packages in git and the bulk in svn. I value the ability to use the same tools and workflows for all team maintained packages. I'm not motivated enough to do any work on such a transition itself, so I think those who really want to switch to git need to work out a plan. That would include test repos, documentation updates, transition plans, educating team members, fielding questions, fixing problems, etc. I would personally be supportive, and would be willing to review material and test out recipes. But I think this is going to require a few committed people to do some heavily lifting over an extended period of time to make sure such a transition was smooth and so that everyone on this team was comfortable with the new way of doing things. That's just my opinion, of course. -Barry I know what you mean about it having a brittle setup, but git-buildpackage has improved a lot over the past couple of years. One key thing that helps when using git-buildpackage in a team setting (pkg-multimedia is a good example) is having a standard debian/gbp.conf that configures everything in a standard way for that team. For example, it would be great to include a debian/gbp.conf that sets up the git-svn stuff and check that into svn projects. Then people can easily use git-buildpackage and still commit to svn repos. .hc -- 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/52d55426.6030...@at.or.at
Re: Using git-svn and gbp for DPMT - Was: Re: Joining the DPMT and git.debian.org access
Barry Warsaw ba...@debian.org writes: On Jan 14, 2014, at 02:40 PM, Olivier Berger wrote: I've used git-buildpackage with git-svn on submodules of the DPMT SVN repo without too many difficulties so far. git-bp OTOH required a specific set of branches inside the repo to stitch everything together and if those were missing, it failed miserably. I could be totally wrong about that, or I could have just been using the tool incorrectly. It more or less requires only 2 branches : upstream (when you want to track upstream sources) and master (or debian) for the packaging source. But for repos of DPMT which won't track upstream code in the SVN, you only need to manage the debian/ subdir on the master branch which correspons to the trunk, so that means that git svn clone --std-layout basically sets things up for you. Now, if you both want to track upstream sources from origin/master on local upstream/ branch and svn's trunk on local master branch, then, yes, a debian/gbp.conf comes handy, and you'll have to do nasty merges now and then. In any case, reading http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html more or less covers all the cases I've played with so far, AFAICT. YMMV ;-) Best regards, -- Olivier BERGER http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8 Ingenieur Recherche - Dept INF Institut Mines-Telecom, Telecom SudParis, Evry (France) -- 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/877ga2v9xj@inf-8660.int-evry.fr