Questions/comments on diagrams as of June 28

[ldimaggi]

I had some review comments on the diagrams as they existed on June 28 - not sure about the best method to report these - see text added to attached images. Thx!

[aslakknutsen]

• The receiver in the Scheduler is a service.
• Feedback on the notification received sounds like a likely feature yes. I know Android/Ios can give the 'has read' notification feedback. We can build similar into web ui etc.
• Yes, a WorkItem change history is a requirement, but not currently built into the model.
• Yes, a Project needs some form of Release/Version built into it. Not included currently.
• In the first version we will assume a non-bi-directional relationship with the remote issue. The remote issue is the authoritative source, we're just reading the info. In later versions we probably need to support some sort of bi-bidirectional.

[maxandersen]

I don't follow you when you say a workitem may apply to multiple projects ? it is kinda assumed one workitem is a max in one project, but ofcourse can be linked to others...

[aslakknutsen]

Who says that where?

[tsmaeder]

I would assume we need a point where we can configure which planning processes, which types of workitem, etc. we want to use. The "project" seems an obvious point to be that point of configuration, but that would limit work items to projects where their work item type is supported.

[aslakknutsen]

@tsmaeder To some extent, they will/can be compatible on Field level even if they are different WITD

[maxandersen]

Who says that where?

@ldimaggi on the diagram "the same workitem may have to apply to multiple projects"

[maxandersen]

To some extent, they will/can be compatible on Field level even if they are different WITD

This is btw. one of the reasons I think it is important we get a set of fields and relationships that aren't custom/dynamic early on (i.e. assignee, estimate, iteration, ..) which we know can/should be possible to move over easily and have it only be truly custom fields that might have to have some custom logic applied to be moved/copied over. Jira does similar and its support for moving issues between system are pretty excellent.

[maxandersen]

@ldimaggi btw. these kind of questions are great, but I think the discussions are better if you open an issue pr topic rather than multiple topics in one.

[aslakknutsen]

This is btw. one of the reasons I think it is important we get a set of fields and relationships that aren't custom/dynamic early on (i.e. assignee, estimate, iteration, ..)

If by Field you mean FieldTypes, then yes I agree.

[aslakknutsen]

@ldimaggi on the diagram "the same workitem may have to apply to multiple projects"

Ah, missed the end of the sentence when I skimmed it again.

I understand the question, but currently, it's a bit hard to discuss because we haven't really defined what e.g. a Project mean.

Is Red Hat a 'Project'? Is DevTools a Project? is ALMighty a Project?

If ALMighty is a Project, then does someone 'own' us, eg, an Org? Is Red Hat an Org? is DevTools an org? is ALMighty it's own org?

If ALMighty is a project, how can DevTools plan us?

How can Todd get an overview of his visions?

How can Jim? at Red Hat get an overview of the 'global' vision?

What happens when an existing 'Project' becomes part of 'the something larger'?

Maybe being able to get an overview to plan a sprint etc is simply an 'Auth' request to the 'Project' from another 'Project' to 'view/plan' their Items ?

Do we participate in 'some other projects' 6 months goal? Do we participate in a 'remote sprint' ?

[maxandersen]

If by Field you mean FieldTypes, then yes I agree.

not sure that is what I mean - I mean fields not having to be stored inside a blob and/or require dynamic calculation to query.

[aslakknutsen]

Not sure why the storage model matters.I don't really see what the difference between a Table with an Assignee column and a Table with a JSON object with an Assignee Field. The column could still be nil. You need to deal with the value either way.

Enforcing 10 certain Fields to exist in all Workitems seems strange, but that can be done regardless of it being stored in a Column or in a JSON.

[tsmaeder]

@maxandersen the fields stored in a json field in Postgres are indexable, so you will have fast searches for them (says the doc). If that turns out to be true in real life, it really doesn't make a differenc how it's stored in the db.

[maxandersen]

It des for plugins and other work that need/want to query/join with the data for data mining etc.

Unless postgres found the magic silver bullet then the performance will be worse - just like new String("blablah") is about the same as "blablah".intern() but which you choose actually has massive impact on memory consumption when the system gets bigger.

Anyway, lets see how it scales, but if we have to several layers of API to simply query based on which assignee and if the data honor role based security I believe we are going to have a bad day :)

[aslakknutsen]

@maxandersen Highly unlikely that anyone outside of core will have direct DB access.We need a Query abstraction between Core and Others either way. So Core can change without all plugins/users have to and not to expose the complexity of the storage out to everyone.

[tsmaeder]

I would expect us to have a query compiler (for small values of compiler) that takes care, for example of handling well known fields (that we might store differently from others, if performance requires it). I have had good experiences with this in other projects.

[aslakknutsen]

@tsmaeder Yeah, even just to simplify the language..

SELECT WorkItem
WHERE WorkItem BelongsTo Build
AND Build.Failed
AND Build.TriggeredBy = current_user
LIMIT last_week

[ldimaggi]

Sorry to be slow in following up on the comments/questions - I was out all last week. When I asked about one work item being applied to multiple projects, I was thinking in terms of integrations between projects. For these integrations, a work item would either apply to multiple projects, or have multiple/duplicate work items, one for each of the integrated projects.

[aslakknutsen]

@ldimaggi A seemingly similar 'multi project' situation for a WorkItem would be in the 'upstream bug' that needs fixing in both upstream project and downstream product. This is today worked around by cloning the upstream bug to the downstream project. Not sure multiple owners of the same WorkItem is the correct solution, but it would be nice to have some form of system understanding of it.