dolfin team mailing list archive

[Florian Rathgeber <florian.rathgeber@xxxxxxxxx>]

On 26/03/13 17:02, Anders Logg wrote:
> On Tue, Mar 26, 2013 at 04:23:30PM +0000, Florian Rathgeber wrote:
>> On 26/03/13 16:11, Anders Logg wrote:
>>> On Tue, Mar 26, 2013 at 04:04:27PM +0000, Florian Rathgeber wrote:
>>>> On 26/03/13 15:55, Garth N. Wells wrote:
>>>>> On Tuesday, 26 March 2013, David Ham wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> I imagine that Florian will have something to say about this,
>>>>> but the ffc pyop2 branch may be an issue here.
>>>>> lp:~mapdes/ffc/pyop2
>>>>>
>>>>>
>>>>> This may be fine because I don't believe that we're planning
>>>>> to prune/rewrite the FFC history at this stage (I think that
>>>>> it's required, but it's easier to delay until later compared to
>>>>> the DOLFIN repo). We need Florian to tell us if this will
>>>>> work.
>>>>
>>>> As I mentioned earlier there is also the route of importing the
>>>> feature branch into the non-filtered repository (where the marks
>>>> files are "intact") and then transplanting the branch (with all
>>>> its history etc.) to the rewritten repository via a git rebase.
>>>> It's a bit more laborious and you should know what you're doing,
>>>> but I've done it before. We've rewritten both the OP2 and the
>>>> PyOP2 repositories halfway through the project. It's just not
>>>> something I would want to ask a git novice to do by themselves.
>>>
>>> I would say it's up to you. I don't care much about the history of
>>> feature branches and no one else has indicated that it is important
>>> to provide a route for converting feature branches. So if it is
>>> important to the ffc/pyop2 branch, I can follow your instructions.
>>>
>>> But I would assume that requires merging the ffc/pyop2 branch
>>> *now*, before the conversion, and it might not be ready?
>>
>> No, I can do that later. The reason the branch isn't quite ready is
>> that we don't (yet) have tests for the features we're adding so it
>> would be hard for the FFC developers to notice if they break anything
>> for us post merge. We're passing the existing FFC test suite though.
> 
> ok. So is it ok for your branch if we just do the conversion without
> the marks files?

Having the marks file will definitely speed things up in case we're not
rewriting FFC. But if we're deciding to filter FFC and therefore
invalidate the marks files I can do without, yes.

>> But there is another option to get round the entire problem: simply
>> importing *all* feature branches before doing the filtering. That
>> should (unproven claim, I'll need to read the docs) be scriptable
>> through the launchpad API and the branch import script that I've
>> already written. But I was assuming you didn't want to necessarily
>> migrate all the branches, so I didn't focus on this option in prior
>> discussions.
> 
> That sounds like a very bad idea. I assume at least half of those
> branches will never get merged.

I assumed you would say that, hence I didn't suggest it earlier. However
there is another option: not pushing the repo with *all* the branches to
Bitbucket, but keeping it (read-only) on the FEniCS web server, so
anyone who would like to import and continue working on their feature
branch can pull it from there instead of migrating themselves.

>>> For the FFC branch, I would like to strip out all the old .h
>>> reference files. Then add them back again right after the
>>> conversion.
>>
>> That is certainly doable, but so far my impression was that Martin
>> objected to this plan?
> 
> We just made a release so I think we are quite comfortable that things
> are working at the moment. If we pass all our regression tests
> now. Then convert the repository, copy back the references, we should
> not need to step back and look for errors introduced previous to the
> conversion. I think what Martin objected to was moving the references
> outside of the repository and I agree on that. So we strip the
> repository from the references and do the conversion, then add back
> the references.

That's doable. We could even define a cut-off point (like 60 days) for
which to keep the references and remove everything prior to this point.

> Another option would be to wait with stripping data from the FFC
> repository until a new a better test suite is in place, but that
> requires going through this process again at a later time. I'd rather
> have it done now and just move on.

I'd advise against doing the rewrite at a later point. We could only do
it for OP2 because we were in a much more "controlled environment" where
we knew all the contributors.

Would it then make sense to use the 1.2 release as the base for the
conversion for all FEniCS components?

Florian

> --
> Anders

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature