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/
Reply to: