Hi Mikael, please find my answers inline.
> > I understand. I would have been happy in the past when a client had as much > > knowledge and structure than we already have. Under "Project goal" we now > > have about 300 words. So we could add more. > Well, It wouldn't be really part of the goal, more how to reach that > goal. The "timeframe" question is possibly where it should go. Or if > you consider that the planning is a goal itself, it could be put here. The timeframe question accepts only a number. I.e. we can't plan there. > > What do you have in mind? > Something that breaks a big, risky thing to a set of smaller, manageable > ones. Something showing that the main problems (or some of them at > least) have been identified and that we have a path to solve them one by > one. > > > Like adding > > more bullet points to each item in the form of: > > - rebase existing implementation to current master > > - identify missing requirements > > - add tests for missing requirements > > - implement missing requirements to pass tests. > > ... > Well, this is a bit too general to be useful. Mhh, I don't suppose that the planning will be evaluated by software specialist. I therefore propose not to be too technical, but to stay on a project manager level. So how about we enumerate the bullets so that we then can put a project/milestone structure under each one like this (PD: person day): 1.M1 assess open issues and refine planning (1-3 PDs) 1.M2 rebase to current master and adapt to recent changes in gfortran (1-3 PDs) 1.M3 identify missing requirements ... I need input here from Nicolas as I don't have an overview of what is needed. Therefore I am quite general. > > > Or are your targeting a more time based approach like: > > Milestone 1: shared mem coarrays merge to master in week 2 of project > > Milestone 2: finish research on general way for doing remote coarray > > access in alien structures to finish in week 1 of project > > ... > Maybe, but I would not emphasize the time constraints that much. I understand. But for our own planning we need a rough estimate. Therefore putting numbers to each milestone, will help a lot in planning. > I have done it below for the scalarizer simplification, which is what > for which the picture is the most clear in my mind regarding what to do > and how to do it. > Here it is, with the expected number of weeks (that's 3 days for me) to > do it: > - Add optional scalarization block. (1 week) > - Setup multiple expression usage (in case of multiple loops) in a > more clear way. (3 weeks) > - Move array and loop bounds setup to an opaque "start scalarization" > function (3 weeks) > - Make scalarization independant on previous setup of array > information and move setup code from "start scalarization" to "finish > scalarization" (5 weeks) > - Initialize array information inside the gfc_conv_expr* functions and > remove preliminary walking of expressions (4 weeks) > > I hope that's not too technical to be put in the application form. :-) Removing technical speech is not the problem... But I like the plan although I wouldn't know what to do in each case. > > Mikael Morin @ ??? -- Maintained/Contributed to the scalarizer. Experienced > > in gfortran development and component dependencies. > > > I'm not affiliated to any company, university or organization. Just > myself. :-) Sorry, I did not mean any insult. What do you prefer? "not affiliated" or "private", ...? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de