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
