lilypond-devel
[Top][All Lists]
Advanced

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

GOP-PROP 11: git repositories (probable decision)


From: Graham Percival
Subject: GOP-PROP 11: git repositories (probable decision)
Date: Wed, 14 Sep 2011 23:33:46 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

I've made a few clarifications to the original proposal, but
nothing substantial is changed.

http://lilypond.org/~graham/gop/gop_11.html

** Proposal summary

Our source code hosting is confused: some branches of lilypond
savannah are confusing and should removed, while other parts of
our source code aren’t in a repository at all!

I propose:

    * Reserve the savannah lilypond.git repository for logical
      branches of master.
    * Create separate savannah lilypond/foo.git repositories for
      other material, notably lilypad-macos, lilypad-windows,
      archive-web.
    * We add an additional website-media repository for material
      such as our pdf publications (e.g., Erik’s thesis, Han-Wen
      and Jan’s papers), the compiled ly-examples/, and generated
      pictures/.
    * Since GUB is used by other projects, it will remain in its
      current repository on github. 

** Rationale

Most of the open-source world abandoned keeping source code
primarily in tarballs about 10 years ago. But as far as I know,
the official version of the windows lilypad application is a
tarball on http://lilypond.org/download/gub-sources/lilypad/!
(thankfully Patrick has a mirror of them in
http://github.com/pnorcks just in case something bad happens).

On the other side of things, some material in the savannah
lilypond repository are misleading. We don’t use the web branch
any more; that material is part of master. The CG doesn’t point
people at the web branch, but it’s still a tempting target for
well-meaning contributors to work on, and we’ve had 2 or 3 people
send us beautiful (yet heartbreaking) patches for that completely
obsolete branch. I don’t want this to happen again.

Another hope is that if we clean up our repositories, we may be
able to encourage more use of branching.


** Proposal details

I think the “remove non-logical branches” is fairly clear. The
main repository would remain as:

git://git.sv.gnu.org/lilypond.git

I can easily get additional repositories created, namely:
        
git://git.sv.gnu.org/lilypond/lilypad-macos.git
git://git.sv.gnu.org/lilypond/lilypad-windows.git
git://git.sv.gnu.org/lilypond/website-media.git
git://git.sv.gnu.org/lilypond/archive.git

I think that having an official place for the pdfs will not be a
problem. Some people may disagree with having the compiled
ly-examples/ and pictures/, though. I think this is warranted due
to the pain that uploading these manually causes. I only do it
manually 2 or 3 times a year; keeping them in a separate
repository would allow anybody to push an update. There’s no
security concerns with such an upload of pdf and pngs. Also,
having this media stored somewhere would make it significantly
easier for relative linux newcomers to start working on the “full”
website.

The ikebana branch will be migrating to Han-Wen’s github account.


** Unchanged branches

  master
  release/unstable
  lilypond/translation
  stable/*
  dev/*
  cvs/master
  tarball/master

The last two aren’t particularly relevant these days, but they
don’t do any harm.


** Other information

Old info here:
http://code.google.com/p/lilypond/issues/detail?id=980

We will not attempt to standardize on directory locations; in
fact, we will remove (most) references to $HOME/lilypond-git.
Instead, we will use $LILYPOND_GIT and possibly
$LILYPOND_WEBSITE_MEDIA.
http://code.google.com/p/lilypond/issues/detail?id=1236 

Cheers,
- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]