fenics team mailing list archive

[Martin Sandve Alnæs <martinal@xxxxxxxxx>]

I also think that for small safe fixes that have passed the tests,
merging into master and skipping next is fine. It is crucial though
that the tests have passed before pushing the merge, otherwise
we won't be able to keep master green.

But shouldn't the fix branch be kept for a while and not deleted right away?

E.g. if the next branch is reset and topic branches are merged into
next again, the fix might be needed?

E.g. if I have a topic branch in progress that will take a while, I may
need to merge just the fix into my topic branch without getting all of
master, but might not see that at the moment the fix is merged into master.

There might be an awful lot of fix branches though...
Maybe if we have a convention for the naming of issue branches,
e.g. fix-issue-#, then the branch list will be more readable even if long.
That has the advantage of making an easy connection to issue and fix.

Also note that you won't see the remote branches by default, so a long
remote branch list only clutters the display of all remote branches,
not the 'git branch' display:

martinal@martinal-mac:~/dev/fenics/temp$ git clone
git@xxxxxxxxxxxxx:fenics-project/ufc.git
Cloning into 'ufc'...
remote: Counting objects: 3228, done.
remote: Compressing objects: 100% (1171/1171), done.
remote: Total 3228 (delta 1754), reused 3197 (delta 1738)
Receiving objects: 100% (3228/3228), 452.16 KiB | 298 KiB/s, done.
Resolving deltas: 100% (1754/1754), done.
martinal@martinal-mac:~/dev/fenics/temp$ cd ufc/
martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch
* master
martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch -a
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/maint
  remotes/origin/master
  remotes/origin/next
martinal@martinal-mac:~/dev/fenics/temp/ufc$ git checkout -b maint origin/maint
Branch maint set up to track remote branch maint from origin.
Switched to a new branch 'maint'
martinal@martinal-mac:~/dev/fenics/temp/ufc$ git branch
* maint
  master


Martin


On 24 April 2013 11:17, Garth N. Wells <gnw20@xxxxxxxxx> wrote:
> On 23 April 2013 22:10, Johan Hake <hake.dev@xxxxxxxxx> wrote:
>> How do we think about small 1 commit fixes? Should these first be pushed
>> to next?
>
> I think 'next' might be overkill for this. What about a 'fix' branch,
> merge into master and delete the 'fix' branch?
>
>> Do we have a buildbot testing the next branch?
>>
>
> If we have the resources, it would be good to test both master and
> next, with the intention that master is almost always green, and next
> we try to keep green but not minding if it sometimes fails.
>
> Garth
>
>> Johan
>>
>> On 04/23/2013 10:06 PM, Anders Logg wrote:
>>> Dear all,
>>>
>>> A couple of developers told me last week they were waiting for the
>>> dust to settle before jumping in and working actively with the new
>>> code repositories. I think the dust has now settled (with yet another
>>> rewrite of the FFC repository yesterday) and it's safe to jump in.
>>>
>>> As before, please read up on
>>>
>>>    http://git-scm.com/book
>>>    https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
>>>    https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git
>>>
>>> One thing I would suggest now is that core developers publish branches
>>> they intend to merge as part of the main repositories (as opposed to
>>> storing them in personal repositories). It makes it easier for others
>>> to follow the development. Note e.g. that PETSc has 66 branches at the
>>> moment. Examples would be the UFL repository which could have the
>>> following branches:
>>>
>>>   master
>>>   next
>>>   martinal/subdomains
>>>   martinal/signatureopt
>>>   logg/tuplenotation ;-)
>>>
>>> Issues we still need to discuss (please jump in) are:
>>>
>>> - Moving questions to stackexchange (comment on previously suggested
>>>   instructions)
>>>
>>> - Updating the information on the web pages (please help out)
>>>
>>> --
>>> Anders
>>>
>>> _______________________________________________
>>> Mailing list: https://launchpad.net/~fenics
>>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fenics
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~fenics
>> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fenics
>> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~fenics
> Post to     : fenics@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fenics
> More help   : https://help.launchpad.net/ListHelp