Pending Jason's meeting with Nick to discuss

What is the intended difference between a project and a model?

We need concept like board to define what device needs to be in the lab and how we approach testing.  Family is a top level group.  Model is too fine grain that we do not run our manual test on all models.  We need some grouping in the mid level to tell us how similar they are so that we can test them as a group.  So far we figure out that OEM/ODM pair is a good indication of model grouping for testing purposes.  This help us to reduce manual testing and possible units deployed in the lab.

For example, a "project" may be "lenovo robo", while the project's models are robo, robo360. There's only one eng team working on these, one place for feedback and bugs to go, one POC for bugs, one factory line. They'd likely share qual results, etc.

I think this needs a design proposal, covering the pieces affected by project. It's easy to add project to the master config. The question is what does it affect?

- feedback
- buganizer
- goldeneye
- something else?

We have never actually implemented this, but we could. It seemed like we already had a way to group things:

1. Feedback reports allow adding multiple match terms, so we can just add each model as a separate term, so that all feedback goes to the same group.
2. Project tracker allows you to create a project with any name you like, so you can in fact create a project there. There is no way to specify which models are in a project at present, but people can just 'know' the mapping

GoldenEye could potentially group models by project.

Overall we just haven't done this because we don't fully understand what would change.

we need something like this.  I don't care what we call them, i think project is fine.  Basically as stated in previous comment, we need a way to define grouping for testing in the lab and manual testing.  For coral we group them by OEM/ODM (see go/coraltest) to reduce testing.  

+sjg@ to start a design doc, there are lots of bits and piece that we need to change to make this work.  It will effect everything as stated in c#8: dogfood, device distribution, lab setup, feedback, bug filing (hotlist in bug), 

How doe one update the project with additional model (some interface via GE) ?  Can I move one model from one project to the next ?

feedback should figure out model and project and update detail in bug.  Hotlist need to change so that we can refer by project in addition to model ?

Also should we allow one model to be on multiple project ? if not we need a system to detect that to avoid human error. 

Yes, I think a design doc and a few meeting is warranted. 

'Project' (this bug) is for the requirements laid out in #c7.

The testing solution is going to be called something else, has been proposed to various folks as a part of the scaling infrastructure initiative (go/cros-infra-recs), and is pending leadership decision on staffing and organization. It won't be a manual grouping but the test results could roll up into 'project' after-the-fact. Should know about that soon. See this heading for the testing plan: https://docs.google.com/document/d/18v-4yzYFycswiaA7hk1w3ybYpaCuLxrgVxOBK-rtRSU/edit#heading=h.6vva11elwpmn

If that doesn't pan out, we can explore a quicker solution that is perhaps more manual.

Note that we still need "project" to disambiguate which OEM is responsible for external testing, as well as NPI and manual testing. go/cros-infra-recs only covers a the subset of testing run by the autotest lab.

Should we have a property which indicates which OEM is responsible for external testing? Or will 'project' handle that case and anything else that comes along.

Also, before break, I added a test-label attribute that can be used to potentially group different models together from a lab testing perspective.

E.g. robo/robo360 could be grouped as just robo in the lab if that's the desired behavior

This is short term and not fully in context of some of the longer term proposals.

As of now I think we'll try to use model to indicate project until there's some other plan.

We previously discussed merging robo+robo360 and nasher+nasher360 but it seemed too disruptive this pate in the project.

this doesn't merge them.  it's just a feature to treat them as the same from a testing perspective.

this isn't going to be implemented as part of unified builds.

this will be impl'd as part of the core config layer 

please make comments in:
go/cros-domain-model
go/cros-infra-arch