Re: Repo user

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Repo user

Han-Wen Nienhuys
Erlend Aasland escreveu:
> Hello Han-Wen,
>
> I've registered with username eaa on repo.or.cz <http://repo.or.cz>. Can
> you set me up with push access?

Hi,

it's done. We don't have much of a policy for branches at the moment,
but here's an overview of what we currently have

  - cvs-head : hourly sync of CVS HEAD
  - cvs-lilypond_2_8 : hourly sync of CVS lilypond_2_8
  - master : default branch for development.

notes:

  * There are more branches, but they're currently unused.

  * don't push into CVS branches. This either breaks our sync cron job,
or your changes will be discarded (I think the latter, but am not sure).

  * if unsure of a change, just push into a new branch. With the last
releases of GUB, it's easy to build from separate branches.

Creating a new branch goes like

    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
        my-branch:refs/heads/new-remote-branch

Then  you can push with

    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
        my-branch:new-remote-branch



I have two proposals for organizing branches, I hope Johannes (our
resident GIT guru) will weigh in on what's best


  * have a debian-like: stable, unstable, exp

where features start out in the exp branch, and
   go into unstable after initial testing. Every once in a while, we
sync unstable to stable, and build a GUB release. We could have
autobuild cron daemons that automate testing on unstable and exp, so we
know when is a good time to sync.

  * have developer centered branches,

    master, master-hanwen, master-jan, master-eea, etc.

   and a build-meister who will pull in changes from different
developers to synthesize a new release which will be the basis for the
official GUB builds.

Of course, this requires that we have someone who volunteers to be a
build-meister. At present, master equals master-hanwen , and I'm the
build meister. However, I wouldn't mind at all if someone else took over
this job. All it requires is regular access to a fast linux running
machine for running GUB.



Johannes?















--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repo user

Han-Wen Nienhuys
Erlend Aasland escreveu:
> Hello Han-Wen,
>
> I've registered with username eaa on repo.or.cz <http://repo.or.cz>. Can
> you set me up with push access?

Hi,

it's done. We don't have much of a policy for branches at the moment,
but here's an overview of what we currently have

  - cvs-head : hourly sync of CVS HEAD
  - cvs-lilypond_2_8 : hourly sync of CVS lilypond_2_8
  - master : default branch for development.

notes:

  * There are more branches, but they're currently unused.

  * don't push into CVS branches. This either breaks our sync cron job,
or your changes will be discarded (I think the latter, but am not sure).

  * if unsure of a change, just push into a new branch. With the last
releases of GUB, it's easy to build from separate branches.

Creating a new branch goes like

    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
        my-branch:refs/heads/new-remote-branch

Then  you can push with

    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
        my-branch:new-remote-branch



I have two proposals for organizing branches, I hope Johannes (our
resident GIT guru) will weigh in on what's best

  * have a single branch: master

more or less the current model. Everyone hacks on the same thing: this
is less confusing, but makes it more difficult to build reliable
releases quickly. New features tend to creep in when we're busy doing
build fixes (for getting the release out of the door), potentially
wrecking the stability of the GUB releases. This is what happened
yesterday with the quarter rest BPB-bug.

  * have a debian-like: stable, unstable, exp

where features start out in the exp branch, and
   go into unstable after initial testing. Every once in a while, we
sync unstable to stable, and build a GUB release. We could have
autobuild cron daemons that automate testing on unstable and exp, so we
know when is a good time to sync.

  * have developer centered branches,

    master, master-hanwen, master-jan, master-eea, etc.

and a build-meister who will pull in changes from different developers
to synthesize a new release which will be the basis for the official GUB
builds.


Of course, this requires that we have someone who volunteers to be a
build-meister.  It requires regular access to a fast linux running
machine for running GUB, and some affinity with compiling packages. Most
of the grunt work has already been done by Jan & me.

  * have functionality centered branches,

    master, master-doc, master-streams,

this is much like the previous option. However, I would probably go mad
if I worked on several branches at the same time.





Johannes?



--
  Han-Wen Nienhuys - [hidden email] - http://www.xs4all.nl/~hanwen


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repo user

Werner LEMBERG
In reply to this post by Han-Wen Nienhuys

>   - master : default branch for development.

Most of the fixes I'm going to supply are clean-ups and no actual new
code.  Is it correct that I shall apply them to `master'?  And how
will those patches be forwarded to the CVS?  Is there a script I shall
call to do it?  For me, it looks a bit like black art currently...


    Werner


_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Reply | Threaded
Open this post in threaded view
|

Re: Repo user

Johannes Schindelin
In reply to this post by Han-Wen Nienhuys
Hi,

On Tue, 7 Nov 2006, Han-Wen Nienhuys wrote:

> it's done. We don't have much of a policy for branches at the moment, but
> here's an overview of what we currently have
>
>  - cvs-head : hourly sync of CVS HEAD
>  - cvs-lilypond_2_8 : hourly sync of CVS lilypond_2_8
>  - master : default branch for development.
>
> notes:
>
>  * There are more branches, but they're currently unused.
>
>  * don't push into CVS branches. This either breaks our sync cron job, or your
> changes will be discarded (I think the latter, but am not sure).

I think they will be discarded _when_ the file was changed in CVS, but I
am not totally sure. It could be that a conflict is introduced ("<<<<<")
and committed, which would be really bad.

If you want to make sure that nobody pushes into the cvs branches, you can
have a hook: if .git/hooks/update is executable, it will be executed
before updating. So, something like

-- snip --
#!/bin/sh

case "$1" in refs/heads/cvs*) exit 1;; esac
exit 0
-- snap --

should work. (This is untested, but I have a similar script preventing
simultaneous updates.)

>  * if unsure of a change, just push into a new branch. With the last releases
> of GUB, it's easy to build from separate branches.
>
> Creating a new branch goes like
>
>    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
>        my-branch:refs/heads/new-remote-branch
>
> Then  you can push with
>
>    git push  git+ssh://repo.or.cz/srv/git/lilypond.git \
>        my-branch:new-remote-branch
>
>
>
> I have two proposals for organizing branches, I hope Johannes (our resident
> GIT guru) will weigh in on what's best
>
>
>  * have a debian-like: stable, unstable, exp
>
> where features start out in the exp branch, and   go into unstable after
> initial testing. Every once in a while, we sync unstable to stable, and build
> a GUB release. We could have autobuild cron daemons that automate testing on
> unstable and exp, so we know when is a good time to sync.
>
>  * have developer centered branches,
>
>    master, master-hanwen, master-jan, master-eea, etc.
>
>   and a build-meister who will pull in changes from different developers to
> synthesize a new release which will be the basis for the official GUB builds.
>
> Of course, this requires that we have someone who volunteers to be a
> build-meister. At present, master equals master-hanwen , and I'm the build
> meister. However, I wouldn't mind at all if someone else took over this job.
> All it requires is regular access to a fast linux running machine for running
> GUB.
>
>
>
> Johannes?

Sorry, I had to take some days off in order to stay sane. Got a nice tan
at the same time.

So, here is my take: it depends on the people, and what they want to do.

For example, if you want to try a super-cool feature, which will not be
finished in a couple of days, but more like a month, you should definitely
start a new branch. (You can merge/rebase with/onto master easily.)

However, if you want to interact a lot (which includes testing by
interested parties), you should stay Debian-ish.

Git does not limit you in any way here, you can even mix both approaches.

Having said that, in my experience it is easier to maintain the Debian-ish
development style, and only occasionally throw in a little side
development.

Ciao,
Dscho



_______________________________________________
lilypond-devel mailing list
[hidden email]
http://lists.gnu.org/mailman/listinfo/lilypond-devel