[Top][All Lists]
[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