[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed git migration plan



On Wed, Aug 27, 2014 at 9:40 AM, Raphael Hertzog <hertzog@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


Reply to: