[Architecture] [Ux] Concerns about remaining PCP/PMT work
antranig.basman at colorado.edu
Mon Sep 15 07:05:43 EDT 2014
Hi there Boyan - we have been working feverishly on getting our test infrastructure fixed up, including over
the Cambridge architecture meeting we had this week. Unfortunately each new bit of progress has so far
revealed some further broken architecture. I think we are on the upward swing and have a solid foundation to
build on now but a good collection of our basic tests still need to be rewritten. I'll be away in the US for
the next week which will be slowing the work down, but I am still expecting to meet up with Steve Githens
for some working sessions in which we can make more progress. I'm sorry about the state of the pull
requests, and we are aiming to reopen trunk as soon as we can. I would expect at the absolute outside we
will do this before the end of 2 weeks.
On 12/09/2014 14:24, Boyan Sheytanov wrote:
> Hi Colin,
> Thank you for the prompt reply. Responses inline.
> On Fri, Sep 12, 2014 at 4:03 PM, Colin Clark <colinbdclark at gmail.com <mailto:colinbdclark at gmail.com>> wrote:
> Hi Boyan,
> Thanks for your comments. Responses inline.
> On Sep 12, 2014, at 11:21 AM, Boyan Sheytanov <bsheytanov at asteasolutions.com
> <mailto:bsheytanov at asteasolutions.com>> wrote:
> > 1. There are pull requests pending review for GPII-539 Correct LifecycleManager's update method to apply live updates from PCP via Websockets:
> > • universal/pull/251 - finalized 28 days ago
> > • prefsEditors/pull/66 - confirmed as ready for merge by Justin on Jul 9
> > I know there is a lot of work on your plate (26 open pull requests for universal and 7 for prefsEditors, among other repos and new tasks) but at the same time feel that pull request review should take priority over development tasks. Quite a few of the PCP work depends on the pull requests mentioned above. While I realize work can continue off the corresponding branches while the pulls get merged, this adds some development overhead, and more importantly - makes it hard to judge where we are with the implementation and how that might affect the Year 3/review plan. Can we put the pulls referenced above high on your radar?
> I also agree that pull requests should be prioritized very highly on everyone's to do list. Currently,
> however, we have realized that our unit and acceptance testing infrastructure has some subtle bugs that
> causes our tests results to be unreliable. It's pretty problematic--sometimes tests appear to pass when
> they have actually failed. These bugs were largely introduced into the system last January when a few of
> us were rushing to get a fully integrated system ready in time for the last EC review. Given this, we
> have some concerns about being able to reliably code review and validate pull requests without rock
> solid tests.
> At the moment, 100% of Antranig's attention is focused on addressing the test failure issues and
> ensuring that our testing infrastructure is reliable and accurate. In your opinion, do you think we
> should be reviewing and merging pull requests without being able to accurately verify that they don't
> break or regress the system? Can you suggest any approaches that we could take which would make your
> lives easier while also ensuring that our code quality improves, rather than risking that it might get
> worse? Thoughts and alternatives are very much appreciated.
> I knew there were problems with failing tests, but didn't realize their severity. I agree with you that no
> pull requests should be merged until the testing infrastructure is brought back to a reliable state. Right
> now I cannot think of a way to ease development while this gets fixed -- but an estimate of when that will
> happen would be much appreciated.
> > 2. It seems to me that the PCP-MM communication, which is a key feature of the system, got lost among other tasks. Could we dig it up and see where we are on that? Alex is working on the PCP part, but is there someone responsible on the MM part?
> I know it probably seems like those issues have been lost in the shuffle. Luckily, they're still very
> high on our radar. One of the areas where Antranig has discovered instability in our system is in our
> current integration with Socket.io. While addressing the bugs that cause our WebSocket-based tests to
> fail, he's also been doing extensive research into the nature of the communication mechanism between the
> PCP and the Flow Manager. It's going to take time to sort through the issues and implement something
> that works, but it's an active area of focus. If you'd like more details about this work, or would like
> to contribute to it, please feel free to join next week's architecture meeting.
> Thanks for the update. Alex or I will try to join the meeting.
> > 3. What is the demonstration scenario for PCP for the Year 3 EC review? There are a number of questions related to that in the last PCP/PMT meeting minutes, but no answers. Can someone answer them?
> As best as I know, this is still being determined. Several of us are currently in Cambridge at a face to
> face meeting to discuss what will be feasible from a technical perspective, and the scenario is still
> being discussed and strategized at the technical and project coordination level. We all need to know
> what use cases we'll be developing for, so I hope we'll have more details soon.
> Great, hope you have a productive (and fun) meeting in Cambridge!
> Boyan Sheytanov
> Lead Systems Engineer
> Astea Solutions AD
> /The information in this e-mail and any accompanying files is intended only for the recipients named above.
> This message may contain CONFIDENTIAL INFORMATION THAT IS LEGALLY PRIVILEGED. If you are not an intended
> recipient, you may not download, copy, disseminate, distribute or use in any way the information in this
> e-mail. Any of these actions can be a criminal offense. If you have received this e-mail in error, please
> notify *Astea Solutions AD*immediately by reply e-mail, and delete this e-mail and any copies of it./
More information about the Architecture