lilypond-devel
[Top][All Lists]
Advanced

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

Re: GOP-PROP 12: keep master in ready-to-release state


From: Janek Warchoł
Subject: Re: GOP-PROP 12: keep master in ready-to-release state
Date: Wed, 14 Sep 2011 11:26:11 +0200

2011/9/14 Graham Percival <address@hidden>:
>> >This could reduce the pain of git master getting broken from time
>> >to time – if everybody worked on separate branches, and those
>> >branches were only pulled to master when it compiled correctly,
>> >then master would never be broken! In theory, at least.
>>
>> I'm pretty sure most developers do their work in
>> separate branches anyway, albeit on local branches.
>
> I'm not at all certain about that

I do all my work in separate branches; nothing ever touches master
unless it's being pushed.  Currently i have 12 branches and i don't
remember when i had less than 5.  Having things flying in master
causes trouble :)

>> >This proposal would require that all main developers have more
>> >than basic familiarity with git, but I think there’s enough help
>> >out there – I’m particularly impressed by the tutorials on
>> >http://github.com.
>>
>> Again I'm pretty sure all main developers already have
>> a good familiarity with git.
>
> Do I count as a "main developer"?

Uh??  Can you rephrase the question?
:)

> because I don't know enough git to do this stuff.

That's a surprise.

> I'm not saying that I can't learn, and if the proposal is accepted
> I certainly *will* learn.  But right now I don't have the
> familiarity with git to be comfortable with making+merging
> branches, with only pushing changes from one branch, etc.
> I'm pretty certain that Janek and Phil are in the same situation.

I haven't figured out how to push stuff from a local non-master branch
to remote master, but besides that i feel quite comfortable branching
around.

>> If git itself is to be used I think it would be better to have
>> a single "staging" branch in which patches could be placed
>> prior to merging into master.  The reg tests and doc builds
>> could then be run just once prior to merging, rather than
>> separately on each patch.
>
> This is certainly possible.  I could easily automate this process,
> too.  Actually, regardless of where this proposal ends up, I think
> I'll make that a priority for this week.
> - 24-hour automatic building of master (make, make test, make doc)
> - 24-hour automatic building of dev/staging, followed by
>  automatically merging those patches with master

+1

Overall, proposal LGTM.

cheers,
Janek



reply via email to

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