← Back to team overview

dolfin team mailing list archive

Re: Merge problems

 

On Sun, Feb 06, 2011 at 09:55:09PM +0000, Garth N. Wells wrote:
>
>
> On 06/02/11 21:52, Anders Logg wrote:
> > Can we revert back to running with 2 processes?
>
> I'd rather not. I got the buildbot green today with 3 processes, so it
> defeats the purpose of separate branches we go and break it again.

Even better!

> > At least for a week or
> > so until we have (1) settled in on the new repository organization and
> > (2) finished the 0.9.10 release. My buildbot is currently red which
> > makes me reluctant to merge although I believe my branch is clean.
> >
>
> The main branch is green with 3 processes, so it sounds like you need to
> do some debugging.

Should be enough to do pull + push. :-)

--
Anders


> Garth
>
> >> On Fri, Feb 4, 2011 at 10:41 AM, Anders Logg <logg@xxxxxxxxx> wrote:
> >>> Are the buildbots essentially green now? One of them reports green
> >>> while the others have timed out.
> >>
> >> Yes, they are essentially green. Some of them are timing out because
> >> they run the unittests in parallel with 3 processes.
> >>
> >> Johannes
> >>
> >>>
> >>>
> >>> On Fri, Feb 04, 2011 at 09:18:12AM +0000, Garth N. Wells wrote:
> >>>>
> >>>>
> >>>> On 03/02/11 22:57, Marie E. Rognes wrote:
> >>>>>
> >>>>> On 3. feb. 2011, at 22:21, Anders Logg <logg@xxxxxxxxx> wrote:
> >>>>>
> >>>>>> [\snip]
> >>>>>>
> >>>>>> Any thoughts?
> >>>>>>
> >>>>>
> >>>>> How about some or all of these:
> >>>>>
> >>>>> 1. Not introducing separate developer branches
> >>>>>
> >>>>> 2. Establishing a subset of tests that take a few minutes to run, so that we actually bother to run a set of tests before pushing to the main branch
> >>>>>
> >>>>
> >>>> On my computer, the tests are pretty fast. Building the C++ demos is
> >>>> slow because the test won't build in parallel (using -jX doesn't help
> >>>> when building tests). Maybe Johannes could look at this?
> >>>>
> >>>>> 3. Making the test script more intelligent so that only the tests affected by the changes in code are run
> >>>>>
> >>>>> 4. Focusing on separating larger changes out into feature-branches (as before instead of personal-developer-branches)
> >>>>>
> >>>>
> >>>> We didn't really do point 4 consistently before. For me, the idea is to
> >>>> do more or what is suggested under point 4, but rather than registering
> >>>> a new branch every time I work on something I have a permanent 'sandbox'
> >>>> that I'm free to break.
> >>>>
> >>>> My take is that it's fine for the code in personal repositories to fail
> >>>> the tests, which is inevitable when implementing bigger changes. What it
> >>>> should do is avoid the problem that we've had when the buildbot is red
> >>>> for days or weeks - one things breaks the buildbot, and before it's
> >>>> fixed a bunch of other problems have been introduced.
> >>>>
> >>>> Garth
> >>>>
> >>>>>> Is here a way to merge via (A)?
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>>
> >>>>> _______________________________________________
> >>>>> Mailing list: https://launchpad.net/~dolfin
> >>>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>>> More help   : https://help.launchpad.net/ListHelp
> >>>>
> >>>> _______________________________________________
> >>>> Mailing list: https://launchpad.net/~dolfin
> >>>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>>> Unsubscribe : https://launchpad.net/~dolfin
> >>>> More help   : https://help.launchpad.net/ListHelp
> >>>
> >>> _______________________________________________
> >>> Mailing list: https://launchpad.net/~dolfin
> >>> Post to     : dolfin@xxxxxxxxxxxxxxxxxxx
> >>> Unsubscribe : https://launchpad.net/~dolfin
> >>> More help   : https://help.launchpad.net/ListHelp
> >>>



References