Re: Proposed git migration plan
Hi Sandro, On Wed, Aug 27, 2014 at 09:13:32AM +0100, Sandro Tosi wrote: On Mon, Aug 25, 2014 at 10:00 PM, Barry Warsaw ba...@debian.org wrote: Here's the page I mentioned regarding a *proposed* transition plan to using git for team packages. It's more or less a brain dump right now, and don't feel like you need to read it before the DC14 session. https://wiki.debian.org/Python/GitPackaging nothing against your effort or experiments (I really appreciate it), but I still don't see what is the advantages of moving to Git. [...] Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop I really use this all the time, as I often work in the train. It's not only local commits, it's also log, blame, diff,... Having said that, I use git-svn and hgsubversion with the packages I work on in the debian python team so that I can actually work like that. What this lacks is... is there anything else so attractive about git? ... semi-automatic handling of debian/patches. I'm tired of refreshing and deleting patches from debian/patches with every new upstream release. As far as I've seen, git-dpm and gbp pq automate most of it and only ask you when the patch conflicts, which is exactly the only time when you need human intervention. The tools should take care of the rest (refreshing patches, dropping patches that are now applied upstream), and it's something that, as far as I know, can already be done with git workflows. Cheers, Javi signature.asc Description: Digital signature
Re: Proposed git migration plan
❦ 27 août 2014 18:11 -0700, Nikolaus Rath nikol...@rath.org : 2. Sometimes I make repeated mistakes when building a package; under subversion I have to make a new commit for each one before testing. Why is that? I'm testing my uncommitted changes with svn-buildpackage --svn-ignore-new --svn-builder=pdebuild and it seems to work very well. I am also missing the ability to rewrite history from git. Of course, you can use --svn-ignore-new but usually, you do not check everything before each commit. You have different things to check: does the package build, does it pass lintian, does it contain everything expected, does it work? Working offline and rewriting history allows one to do many changes and fix them once errors are discovered. There are also situations where you just cannot tests your change. For example, if you are offline with missing dependencies. Or over an expensive Internet mobile plan. You can still do a lot of work with git and test that when home and fixing the individual commits. -- panic (No CPUs found. System halted.\n); 2.4.3 linux/arch/parisc/kernel/setup.c signature.asc Description: PGP signature
Re: Proposed git migration plan
Hi Barry, thanks for your work! On Mon, Aug 25, 2014 at 10:00 PM, Barry Warsaw ba...@debian.org wrote: Here's the page I mentioned regarding a *proposed* transition plan to using git for team packages. It's more or less a brain dump right now, and don't feel like you need to read it before the DC14 session. https://wiki.debian.org/Python/GitPackaging nothing against your effort or experiments (I really appreciate it), but I still don't see what is the advantages of moving to Git. It seems to me like very vocal Git fanatics, who refuse to touch any package which is not maintained in Git (-.-), are pushing and pushing to that VCS without any clear advantage. Upstream releases history? why do we need to care, we are packagers we should care about packaging commits history. ultimately, you'll always have to deal with tarballs, so we need a tool to import released tarballs in a VCS and then another tool to re-generate the tarball from the VCS again? seems kinda twisted to me :) And no, not the whole programming world is using Git for upstream code (sometimes we're not even able to teach upstream to use proper versions), so the usual mantra I can pull from upstream repo and be happy ever after is kinda weak. Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop is there anything else so attractive about git? If we don't define *upfront* what are the problems we currently have and that we want to solve, then we're just proposing a technical exercise without a real gain. and I cant stress this point never enough. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAB4XWXzM8nDbwLBnTMbjTc_T+MMqWWQiQjDKeS0R=yjhh6y...@mail.gmail.com
Re: Proposed git migration plan
Hi Sandro, On Wed, 27 Aug 2014, Sandro Tosi wrote: It seems to me like very vocal Git fanatics, who refuse to touch any package which is not maintained in Git (-.-), are pushing and pushing to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. Upstream releases history? why do we need to care, we are packagers we should care about packaging commits history. Because your packaging decisions are not influenced by upstream changes? from the VCS again? seems kinda twisted to me :) And no, not the whole programming world is using Git for upstream code (sometimes we're not even able to teach upstream to use proper versions), so the usual mantra I can pull from upstream repo and be happy ever after is kinda weak. Not everybody is using git but I think that you should face it, most of the upstreams projects do. is there anything else so attractive about git? It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... And handling security updates in svn is a pain because you can't commit localy and push only when the security update is disclosed publicly. etc. All those are real problems for real people doing packaging work. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827084040.gc23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
Le 26/08/2014 20:36, Hans-Christoph Steiner a écrit : * the git-buildpackage workflow is really quite wonderful and reasonably flexible, I highly recommend it, and I think it will improve the productivity of this team. Hello, At Wikimedia we solely use git-buildpackage. DD Michael Prokop wrote a set of script that let you easily build the package using Jenkins which can be made to poll the git repo, and hence build your package when a commit is pushed: http://jenkins-debian-glue.org/ Coupled with a pre review software such as Gerrit, that let one propose a patchset, have the build result displayed and iterate until the patch is ready to land in the branch. That is a huge time saver for us. -- Antoine hashar Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd9713.8050...@free.fr
Re: Proposed git migration plan
Le 27/08/2014 10:13, Sandro Tosi a écrit : snip Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop As a side effect, that also mean you don't have to use a potentially lagged network connection when doing simple operations. There is nothing I hate more than waiting for network when using the commands log, commit or blame. is there anything else so attractive about git? Cheap local branches which let you pill up work in progress patches / rewrite without having to keep several copy of the same svn repo. The branches in git are just a name pointing to a commit in the tree. The stash, which let you save your uncommited changes and come back to them later (think of it as lightweight branches). That is really nice when you have to interrupt your workflow, stash it, handle the interrupt, reapply your stash and resume work. Tags can be signed with gpg. They are a pointer to a commit just like branches, and hence don't force you to do a full copy to create a tag. Switching between branches is a breeze and does not need network access either. If we don't define *upfront* what are the problems we currently have and that we want to solve, then we're just proposing a technical exercise without a real gain. and I cant stress this point never enough. I agree there, would be nice to list the problems with svn. But I guess most of them are related to svn being a bad (and slow) CSV system. -- Antoine hashar Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd99c2.5040...@free.fr
Re: Proposed git migration plan
Le 25/08/2014 23:00, Barry Warsaw a écrit : Here's the page I mentioned regarding a *proposed* transition plan to using git for team packages. It's more or less a brain dump right now, and don't feel like you need to read it before the DC14 session. https://wiki.debian.org/Python/GitPackaging Food for thought and discussion. From another reply: have you guys considered using a pre commit workflow review system ? In such a system developers propose their change in a gate and they are reviewed/approved before landing in the branch. That let anyone propose a change without potentially breaking the master branch used to build package from. The well known example are GitHub pull requests. OpenStack and Wikimedia foundations are using Gerrit. It is an open source java application developed by Google to develop the Android SDK. It is interface is not the best, but it handles that pre commit review workflow very well. -- Antoine hashar Musso -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd9a95.7090...@free.fr
Re: Proposed git migration plan
On Wed, Aug 27, 2014 at 9:40 AM, Raphael Hertzog hert...@debian.org wrote: Hi Sandro, On Wed, 27 Aug 2014, Sandro Tosi wrote: It seems to me like very vocal Git fanatics, who refuse to touch any package which is not maintained in Git (-.-), are pushing and pushing to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. like true contributors are those using svn right now. and what about the majority of contributors now? we should change just because maybe, eventually, if we're lucky we'll attract more contributors? saying I won't contribute to your team if you don't move to Git is IMHO arrogance and against team work (but we know. I'm different :) ) python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. ditto in my first message :) Upstream releases history? why do we need to care, we are packagers we should care about packaging commits history. Because your packaging decisions are not influenced by upstream changes? i don't follow? is that an advantage of having the upstream source code in the Debian packaging repository? from the VCS again? seems kinda twisted to me :) And no, not the whole programming world is using Git for upstream code (sometimes we're not even able to teach upstream to use proper versions), so the usual mantra I can pull from upstream repo and be happy ever after is kinda weak. Not everybody is using git but I think that you should face it, most of the upstreams projects do. i dont think so. It might be true for the big projects, but look at the vast majority of the packages in DMPT/PAPT, they are small modules/apps how many of them are using git? I wont say most more few of them. is there anything else so attractive about git? It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... branches exist in svn too (I admin they are harderd than git tho) and security updates always evolve in 2 separate ways than current development (in fact, I think you're referring to update in stable, so you'll have a branch for stable and trunk, which likely are at 2 different versions, evolving indipendently. I did that for matplotlib, and it's doable) And handling security updates in svn is a pain because you can't commit localy and push only when the security update is disclosed publicly. that's true indeed. etc. All those are real problems for real people doing packaging work. you skipped the part of what are the problems the teams is facing with svn we want to solve with git, while it seems you're talking about your experience with Django alone, which is important of course but not necessarily representative of a huge amount of packages in our teams. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxxkqjpqxbxhv1kzd8ule-n2zjwczi3r7fc_hj08ueu...@mail.gmail.com
Re: Proposed git migration plan
On Wed, Aug 27, 2014 at 9:41 AM, Antoine Musso has...@free.fr wrote: Le 27/08/2014 10:13, Sandro Tosi a écrit : snip Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop As a side effect, that also mean you don't have to use a potentially lagged network connection when doing simple operations. There is nothing I hate more than waiting for network when using the commands log, commit or blame. I rarely need to use log, and I used to work on the svn repo on a 56k lines no later than 2 years ago, so I know what means a slow network. Still I was able to do quite a lot of work. would it be possible having the whole history of packages in git? i highly doubt so :) is there anything else so attractive about git? Cheap local branches which let you pill up work in progress patches / rewrite without having to keep several copy of the same svn repo. The branches in git are just a name pointing to a commit in the tree. The stash, which let you save your uncommited changes and come back to them later (think of it as lightweight branches). That is really nice when you have to interrupt your workflow, stash it, handle the interrupt, reapply your stash and resume work. Tags can be signed with gpg. They are a pointer to a commit just like branches, and hence don't force you to do a full copy to create a tag. Switching between branches is a breeze and does not need network access either. I was referring to attractive features of git in regarding to Debian packaging If we don't define *upfront* what are the problems we currently have and that we want to solve, then we're just proposing a technical exercise without a real gain. and I cant stress this point never enough. I agree there, would be nice to list the problems with svn. But I guess most of them are related to svn being a bad (and slow) CSV system. well, let's first see the list of problems/features we have/want and then let's talk later of the solutions to them, not the other way around Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAB4XWXy3gJfOMAdys=LjXPK=rtjdv1ux-lfg3fmdkbyiin6...@mail.gmail.com
Re: Proposed git migration plan
On Wed, 27 Aug 2014, Sandro Tosi wrote: like true contributors are those using svn right now. and what about the majority of contributors now? we should change just because maybe, eventually, if we're lucky we'll attract more contributors? saying I won't contribute to your team if you don't move to Git is IMHO arrogance and against team work (but we know. I'm different :) ) Please don't try to split contributors in two camps. I do continue to use svn-buildpackage for the few django extensions that I maintain in python-modules. And even if I moved python-django to git, I'm still a team contributor even if I touch only a small subset of packages. Because your packaging decisions are not influenced by upstream changes? i don't follow? is that an advantage of having the upstream source code in the Debian packaging repository? Yes, I regularly use git log on upstream metadata files to see whether we missed some new (optional) dependencies and stuff like that. Not everybody is using git but I think that you should face it, most of the upstreams projects do. i dont think so. It might be true for the big projects, but look at the vast majority of the packages in DMPT/PAPT, they are small modules/apps how many of them are using git? I wont say most more few of them. No point in arguing here (I don't have time to do a proper analysis and come up with figures). That said in my experience, most new stuff I tend to package are actually maintained in github or a similar service. The fact that we are grabbing .tar.gz on pypi means that we might also not be directly aware that the tarball is generated out of a git repository. It's 200% more easy to manage multiple branches and merge them properly. Most of the average python modules will not need multiple branches but for things like python-django, we do need multiple branches... and the fact that svn is such a pain means that the security updates were not managed in svn for example... branches exist in svn too (I admin they are harderd than git tho) and security updates always evolve in 2 separate ways than current development (in fact, I think you're referring to update in stable, so you'll have a branch for stable and trunk, which likely are at 2 different versions, evolving indipendently. I did that for matplotlib, and it's doable) I said 200% more easy, I know that they are doable, but it's just painful... All those are real problems for real people doing packaging work. you skipped the part of what are the problems the teams is facing with svn we want to solve with git, while it seems you're talking about your experience with Django alone, which is important of course but not necessarily representative of a huge amount of packages in our teams. And? If we want a single VCS then we must cater to the most demanding use cases. Obviously svn-buildpackage is just fine for small packages with a single branch and no patches... Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827091911.ge23...@x230-buxy.home.ouaza.com
Re: Proposed git migration plan
On 2014-08-27 at 10:40:40 +0200, Raphael Hertzog wrote: On Wed, 27 Aug 2014, Sandro Tosi wrote: It seems to me like very vocal Git fanatics, who refuse to touch any package which is not maintained in Git (-.-), are pushing and pushing to that VCS without any clear advantage. You might dismiss those people but you're speaking of true contributors that you're aleniating here. If we really want to stay an all-inclusive team we should use what the majority of (possible) contribtuors prefer to use. python-modules is about the only team I'm part of that is not yet using git. It's an annoyance to have to continue to use svn-buildpackage when I only use git everywhere else. This is expecially true for *new* contributors, who are more likely to be used to the git workflow and in a situation where they have to learn new skills (svn and svn packaging) that are only used in this team (or just do their packaging elsewhere). -- Elena ``of Valhalla'' -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827091901.gb6...@virginsteele.home.trueelena.org
Re: Proposed git migration plan
Hi Sandro, I rarely need to use log, and I used to work on the svn repo on a 56k [..] that you rarely use log is (a) not relevant to the people who would use it and (b) quite possibly highly influenced by the fact that svn log is so slow and painful. Remember that the tool can shape the user. Cheap local branches which let you pill up work in progress patches / rewrite without having to keep several copy of the same svn repo. The branches in git are just a name pointing to a commit in the tree. The stash, which let you save your uncommited changes and come back to them later (think of it as lightweight branches). That is really nice when you have to interrupt your workflow, stash it, handle the interrupt, reapply your stash and resume work. Tags can be signed with gpg. They are a pointer to a commit just like branches, and hence don't force you to do a full copy to create a tag. Switching between branches is a breeze and does not need network access either. I was referring to attractive features of git in regarding to Debian packaging these *are* things that are attractive for packaging work. * I use branches extensively when experimenting with changes to packaging. What gets pushed might not look like that was what happened, but the branch was there along the way. * I use stash quite a lot to be able to better articulate the work I'm doing in commits and as testing smaller changes. I even used it the other day in my little case story on git-buildpackage. * (signed tags are probably an inherently good thing, but are really only nice to have for us at this stage) * Because I use branches a lot, I switch between them, rebase work and merge it quite a lot. well, let's first see the list of problems/features we have/want and then let's talk later of the solutions to them, not the other way around This discussion has been had many times before over many years. Of late, the difficulty in switching VCS has been the blocker. I don't think there are many people who are unconvinced that switching makes sense from a technical or workflow perspective. I also don't think there are many people who are interested in rehashing the entire discussion yet again. It's almost as boring as systemd discussions. Fundamentally, one of the problems is svn. Even if you don't want the thigns git offers, just use git as a new version of svn spelt differently, then you'll still be able to work effectively on packages and you only have two new commands you need to use (assuming you aren't already using debcheckout and debcommit, of course). Subversion lacks features that make packaging work much easier to do. The tools shape what you do -- you said that you don't use branches or log much and that's going to be partly because they are so crap in svn. In the past, I didn't use these features either when I was only using svn. Now I know they are useful things, I use them quite a lot because they are so easy and efficient in git. When I go back to working on svn projects, I realise how much the tool is deficient and how much the deficiencies of the tool lead to deficiencies in process. Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ltkaj1$gs8$1...@ger.gmane.org
Re: Proposed git migration plan
This discussion has been had many times before over many years. Of late, the and it was never driven by the problems we have, but just by oh look how cool git is, everybody else is using it, and i'm too lazy to learn a new tool arguments. difficulty in switching VCS has been the blocker. I don't think there are many people who are unconvinced that switching makes sense from a technical or workflow perspective. I also don't think there are many people who are interested in rehashing the entire discussion yet again. It's almost as boring as systemd discussions. sure, do as you want, git is a great DVCS, and all the other teams are using it Subversion lacks features that make packaging work much easier to do. The tools shape what you do -- you said that you don't use branches or log much and that's going to be partly because they are so crap in svn. In the past, OTOH don't assume I never used git for packaging; even in that case I rarely *need* to use log; regarding branching it might be useful for huge changes (even if I consider it only useful when developing, not packaging) but the majority - come on - of those dont require branching (or do you branch to change Standard-Versions, or to update debian/watch?). turning down my arguments because your wf is flawed because you use crappy tool is kinda weak but I'll accept it. Regards, -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cab4xwxyatibd22rs7j-7pdebjbzjn6z+cazzskua538yrix...@mail.gmail.com
Re: Proposed git migration plan
On Aug 27, 2014, at 10:30 AM, Antoine Musso wrote: Coupled with a pre review software such as Gerrit, that let one propose a patchset, have the build result displayed and iterate until the patch is ready to land in the branch. I personally love such gated systems when working on software. They might also be a good value for packaging work, if they can do things like run lintian and DEP-8 tests too. Sometimes it's necessary to bypass such gates, e.g. security releases. Once we're converted to git, exploring these other options would be nice, IMHO. One thing at a time though. :) -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827075445.4424d6c4@anarchist
Re: Proposed git migration plan
On 2014-08-27 01:41, Antoine Musso wrote: Le 27/08/2014 10:13, Sandro Tosi a écrit : snip Offline commits? how many time (for real..) you badly needed it? i guess so few that if you (for one time) just do a big commit instead of a storm of micro commit the world wont stop As a side effect, that also mean you don't have to use a potentially lagged network connection when doing simple operations. There is nothing I hate more than waiting for network when using the commands log, commit or blame. This annoys me to no end as well. is there anything else so attractive about git? Cheap local branches which let you pill up work in progress patches / rewrite without having to keep several copy of the same svn repo. The branches in git are just a name pointing to a commit in the tree. I would really like to emphasize this one. The ability to work locally, then rewrite that work, and only *then* publish it is invaluable to me. When implementing a feature, I don't need to share the history of all mistakes I made with the world, because to everyone else but me, those are just noise polluting the history and unnecessarily complicating it. Instead, I implement the feature locally, and when it works as intended, I rewrite the entire history so that it is clean and comprehended, and only *then* do I push. The stash, which let you save your uncommited changes and come back to them later (think of it as lightweight branches). That is really nice when you have to interrupt your workflow, stash it, handle the interrupt, reapply your stash and resume work. Tags can be signed with gpg. They are a pointer to a commit just like branches, and hence don't force you to do a full copy to create a tag. Switching between branches is a breeze and does not need network access either. If we don't define *upfront* what are the problems we currently have and that we want to solve, then we're just proposing a technical exercise without a real gain. and I cant stress this point never enough. I agree there, would be nice to list the problems with svn. But I guess most of them are related to svn being a bad (and slow) CSV system. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fdfb50.3000...@kvr.at
Re: Proposed git migration plan
Hi Sandro, On Aug 27, 2014, at 09:13 AM, Sandro Tosi wrote: nothing against your effort or experiments (I really appreciate it), but I still don't see what is the advantages of moving to Git. There's moving to git and moving to a dvcs - slightly different, but related issues. For me, moving to a true dvcs has overwhelming benefits, some of which aren't clear until you've immersed yourself in the dvcs world. Cheap branches, off-line work (e.g., Debconf attendance sometimes involves long airplane rides :), the ability to push branches for easy review, mentorship, sponsorship by others (a *huge* win IMHO). svn just makes so many of those things too painful that we don't do them. git would not have been my top choice for a dvcs, but let's face it, it's won. As sad as it is for me personally, network effects win, and adopting the most popular of the current crop of dvcses will attract (or at least not repel ;) new contributors to the team. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140827083845.775a631d@anarchist
Re: Proposed git migration plan
On 27 August 2014 18:13, Sandro Tosi mo...@debian.org wrote: is there anything else so attractive about git? I can think of two benefits off the top of my head. 1. Subversion tags don't work for me. I think this is because I have deleted files since the last tag, I posted a message here, nobody was able to help. So I don't always do it when I should. Only a small thing, but one that annoys me. Actually I find the whole idea of tags in subversion very clumsy to use in any meaningful way. 2. Sometimes I make repeated mistakes when building a package; under subversion I have to make a new commit for each one before testing. Under git, I can test it with a local commit, and amend the commit if required before pushing it. 3. With git it is rather obvious when there is a new upstream branch (git fetch will tell you). With subversion, it is easy to miss, I think it requires manual checking. Recently, I have duplicated efforts to support Python3 in a package because I didn't notice it was committed in another branch. Oh, wait, that was three. So sorry. Also, sometimes I find subversion can be very slow when it needs to access the remote server. I am sure there are more reasons, these are the ones that have annoyed me recently. Unlike some, I am happy to continue using subversion. However I feel I could do a better, more professional job with git. -- Brian May br...@microcomaustralia.com.au
Re: Proposed git migration plan
Brian May br...@microcomaustralia.com.au writes: 2. Sometimes I make repeated mistakes when building a package; under subversion I have to make a new commit for each one before testing. Why is that? I'm testing my uncommitted changes with svn-buildpackage --svn-ignore-new --svn-builder=pdebuild and it seems to work very well. Best, -Nikolaus (who wishes for a decent mercurial-buildpackage) -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87wq9tmn97@vostro.rath.org
Re: Proposed git migration plan
I think this plan makes a lot of sense. I'll just throw in my two bits for a couple of other points: * the git-buildpackage workflow is really quite wonderful and reasonably flexible, I highly recommend it, and I think it will improve the productivity of this team. * Vcs-Git and Vcs-Browser should use the HTTPS link by default. This helps protect the privacy of people who might want to contribute. Perhaps where you are this is not a concern, but there are many parts of the world where the government actively monitors all internet traffic, and Debian should be aware that trivial changes like this can be quite helpful for people in such situations. HTTPS is fully supported on alioth and the HTTPS Vcs-Git link is included at the bottom of every cgit page: For example, see the bottom of this: https://anonscm.debian.org/cgit/python-modules/packages/python-django.git/ You'll find this: https://anonscm.debian.org/git/python-modules/packages/python-django.git * please don't ban mirrors or pull requests from other services. I agree that non-free services should not be encouraged, but banning them is counter-productive since they have the vast majority of the mindshare of free software developers. .hc Barry Warsaw wrote: Here's the page I mentioned regarding a *proposed* transition plan to using git for team packages. It's more or less a brain dump right now, and don't feel like you need to read it before the DC14 session. https://wiki.debian.org/Python/GitPackaging Food for thought and discussion. -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fcd3ab.9000...@at.or.at
Re: Proposed git migration plan
On Aug 26, 2014, at 02:36 PM, Hans-Christoph Steiner wrote: I think this plan makes a lot of sense. I'll just throw in my two bits for a couple of other points: Cool. * the git-buildpackage workflow is really quite wonderful and reasonably flexible, I highly recommend it, and I think it will improve the productivity of this team. Do you have experience with git-dpm, and if so can you provide some comparisons between the two regimes? * please don't ban mirrors or pull requests from other services. I agree that non-free services should not be encouraged, but banning them is counter-productive since they have the vast majority of the mindshare of free software developers. I wouldn't necessarily ban non-free services, buy I also wouldn't require team maintainers to use them. We can leave that to individual discretion. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140826183545.2b867113@anarchist
Re: Proposed git migration plan
Hi Barry, thanks for this write-up. An open question remains what to do about the current history that is in svn. My experience of doing this is as follows: * For many repos, svn-all-fast-export does an excellent job of turning a complete svn history into something that looks identical to what git- buildpackage would have made on its own. * For some repos, (especially when there were missing tags) svn-all-fast- export requires some additional grafts to be added and then the git history reworked. Of course, any conversion utility would require this -- it depends how ideally accurate you want your history to be, and given that the current history in svn can be incorrect, being overly picky is perhaps unwise. * And then for some repos, the conversion with svn-all-fast-export is an utter trainwreck and I was not able to work out why. (I did quite a lot of poking around and was unable to determined whether it was because I was using a newer svn than on previous conversions or because retagging had happened in that repo). I eventually gave up and used git-import-dscs -- debsnap. That said -- all the above experience was with full-source svn repos. I would anticipate that the debian/-only repos would be easier to migrate as they are much simpler, but then the new git repo would also be debian/-only. A minor git dance to import the next upstream source would be needed. I've not even contemplated how you'd go about adding historical upstream sources to the git repo. cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/ltjdto$aft$1...@ger.gmane.org
Re: Proposed git migration plan
Hi Stuart,
On Aug 27, 2014, at 11:57 AM, Stuart Prescott wrote:
I eventually gave up and used git-import-dscs -- debsnap.
That said -- all the above experience was with full-source svn repos. I would
anticipate that the debian/-only repos would be easier to migrate as they are
much simpler, but then the new git repo would also be debian/-only.
I just tried this one of of my simple packages (cov-core, a fairly new package
with only two upstream releases in Debian). In svn it's a debian/-only
package but after the g-i-d the git repo ended up full source (yay!). Then I
did a `git-import-orig --uscan` and it seemed to work just fine. I wish g-i-o
would automatically run {git-,}dch with a d/changelog entry of New upstream
release.
-Barry
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140826191242.23e843c0@anarchist
Re: Proposed git migration plan
Hi Barry,
I eventually gave up and used git-import-dscs -- debsnap.
That said -- all the above experience was with full-source svn repos. I
would anticipate that the debian/-only repos would be easier to migrate as
they are much simpler, but then the new git repo would also be
debian/-only.
I just tried this one of of my simple packages (cov-core, a fairly new
package
with only two upstream releases in Debian). In svn it's a debian/-only
package but after the g-i-d the git repo ended up full source (yay!).
Then I
did a `git-import-orig --uscan` and it seemed to work just fine.
sure -- git-import-dscs will make full source repos for you, but it is not
converting svn repos to git repos which is what I was really talking about
there... it's throwing away the svn repo and making a new git repo with some
sparse, condensed history in it. If the real history needs to be preserved,
then a helper like svn-all-fast-export, git-svn or similar is needed and
that won't on its own make full source repos.
I wish
g-i-o would automatically run {git-,}dch with a d/changelog entry of New
upstream release.
Yes, and that should be fairly easy to implement too. (Interestingly, I
always passed --svn-noautodch to svn-bp as I found that particular feature
exceedingly annoying but that is of course at build time not at upgrade
time)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/ltjhr3$kbg$1...@ger.gmane.org
Re: Proposed git migration plan
On 2014-08-26 20:04, Stuart Prescott wrote: I eventually gave up and used git-import-dscs -- debsnap. That said -- all the above experience was with full-source svn repos. I would anticipate that the debian/-only repos would be easier to migrate as they are much simpler, but then the new git repo would also be debian/-only. I just tried this one of of my simple packages (cov-core, a fairly new package with only two upstream releases in Debian). In svn it's a debian/-only package but after the g-i-d the git repo ended up full source (yay!). Then I did a `git-import-orig --uscan` and it seemed to work just fine. sure -- git-import-dscs will make full source repos for you, but it is not converting svn repos to git repos which is what I was really talking about there... it's throwing away the svn repo and making a new git repo with some sparse, condensed history in it. If the real history needs to be preserved, then a helper like svn-all-fast-export, git-svn or similar is needed and that won't on its own make full source repos. If the goal is source-ful branches (which I'm hoping), there's a tradeoff to consider here: (a) either have that sparse, condensed history, but that would also be a history from which past packages can be recreated, as for each tag, there would be the debian source and the upstream source, or (b) have the full history as produced eg by git-svn, but without the connection to the upstream source. After all, the svn repos were kept sourceless. -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53fd5c65.4080...@kvr.at
Proposed git migration plan
Here's the page I mentioned regarding a *proposed* transition plan to using git for team packages. It's more or less a brain dump right now, and don't feel like you need to read it before the DC14 session. https://wiki.debian.org/Python/GitPackaging Food for thought and discussion. -Barry signature.asc Description: PGP signature
