[Architecture] FLUID-4819 and the transformation work
antranig.basman at colorado.edu
Fri Mar 15 09:06:39 UTC 2013
Hi Kasper - I have issued a pull request containing this work under FLUID-4921 at
https://github.com/fluid-project/infusion/pull/270 - this branch is directly descended from the one you were
working on at San Diego so you should be able to merge up to it without problems. Note that this is still
behind the FLUID-4929 branch in the review queue but since the more substantial Uploader refactoring has
been reverted out it should pass through relatively easily.
On 14/03/2013 14:41, Kasper Galschiot Markus wrote:
> Fantastic - that's better news than I even dared hope for! Thanks so
> much antranig!
> On 3/14/13 9:25 PM, Antranig Basman wrote:
>> Hi Kasper, yes, I think this is feasible - sorry to create this
>> snarlup in the workflow. Still ahead of FLUID-4916 (I think you meant)
>> in the pull queue is FLUID-4929
>> https://github.com/fluid-project/infusion/pull/267 but this requires
>> only minor tweaks to get it ready for review - I think it should be
>> pretty easy to prepare a "pure FLUID-4918" which just consists of the
>> framework improvements in that branch minus the uploader rewriting
>> that could be reviewed separately. I should be able to get this ready
>> this evening.
>> On 14/03/2013 13:12, Kasper Galschiot Markus wrote:
>>> Hi Antranig,
>>> We have the pre-pilot testing coming up in exactly one week, and as you
>>> can probably imagine I'm in wild panic again :)
>>> One of the fundamental things that the pre-pilots are depending on, are
>>> the use of the extensions of the model transformations done in and post
>>> San Diego. This is in turn dependent on your FLUID-4819 work. From last
>>> we talked, it sounded like there was still some work to be done on that
>>> branch to get the uploader working properly.
>>> At the architecture meeting we talked about the possibility of splitting
>>> up that branch - one with the basic framework enhancements you've done
>>> and that are ready for review, and one with the uploader work. This
>>> would allow Colin to review and push the things that my model
>>> transformation work depend on soon, and in turn allow me to do a pull
>>> request for my transformation work to make it into the trunk.
>>> Does this sound feasible/sensible to you?
>>> PS: just to continue the chain of dependencies; once the model
>>> transformation makes it in, the solution registries need to be updated
>>> and tested with the new settings/transformations - which in turn might
>>> expose some shortcomings of my current transformations that'd need to
>>> get fixed.
>> Architecture mailing list
>> Architecture at lists.gpii.net
More information about the fluid-work