Re: SVN -> GIT mass conversion

[Roland Fehrenbacher <rf@q-leap.de>]

>>>>> "C" == Charles Plessy <plessy@debian.org> writes:

Hi Charles,

thanks for your comments.

    C> Le Tue, Mar 24, 2015 at 06:02:49PM +0100, Roland Fehrenbacher a
    C> écrit :
    >>
    >> while porting DebMed packages to Qlustar, we started a mass
    >> conversion of SVN to GIT package repositories. Since at the
    >> St. Malo sprint I got the impression that having as much as
    >> possible of the DebMed stuff managed via GIT would be desirable
    >> in general, we'd also start creating new repos for these packages
    >> on alioth that would allow to fully switch to GIT for these
    >> packages at a certain date. The goal of this is to standardize
    >> DebianMed on GIT entirely.

    C> there is also an effor to propose a standard layout in Debian in
    C> general.  It is work in progress, but you can have a look at
    C> http://dep.debian.net/deps/dep14/ and at mailing list archives
    C> after searching with DEP-14 (or variations with/without hyphen
    C> etc.) as a keyword.

    C> (In my understanding, here "standard" means normalising minor
    C> difference between similar layouts, not forcing everybody to use
    C> the same layout.)

Good to know. As far as I can see, the standard git-buildpackage
structure is not incompatible with the proposal, even though the branch
names are slightly different. Should be fairly straightforward to adjust
to an agreed upon debian-wide standard later on. Would wait until that
will have appeared.

    C> In Debian Med, I have experimented on alternative layouts that
    C> follow directly upstream's Git repository instead of usign the
    C> source tarball as an intermediate.  I prefer that way, but I will
    C> be short of time to keep all my packages up to date just by
    C> myself in the near future, so if my Git layout is on your way to
    C> do good team work, do not hesitate to migrate it to a more
    C> standard one.

I've already noticed. We do something similar and I think that's the way
to go for "upstream managed by GIT" projects. When I'll get around
thinking some more about this I'll post my ideas, so maybe we can agree
upon a common structure/workflow.

    C> (Two main reasons why I will lack time are a) still being a young
    C> parent and b) still spending most of my "Debian" time learning
    C> Haskell to rewrite the Umegaya system in a hopefully bug-free
    C> way.)

Enjoy the time with your kids :)

Best,

Roland

-------
http://www.q-leap.com / http://qlustar.com
          --- HPC / Storage / Cloud Linux Cluster OS ---