Re: [mylyn-builds-dev] Ken's suggestions as well as questions about Myly

[Steffen Pingel <steffen.pingel@xxxxxxxxxxx>]

No worries about asking questions. Your input is very valuable and we'll try our best to answer them.

On Thu, Jul 28, 2011 at 5:17 PM, Kiu Leung <kleung@xxxxxxxxxx> wrote:

First of all, I noticed that there is a getter/setter pair method for
culprit in the IBuild interface and I am not sure what that is.  My first
guess is, its a blame list to store the users who caused a build/test fail?

Yes, that is the intention. AFAIK, the information is not shown in the UI so far but it's likely that the framework will use it in the future.

 

I also found that there is a list of status code defined in the Mylyn Builds core
Eclipse project.  I believe I will have some problem translating them to Koji
because some of them are not applicable to Koji and at the same time, Koji has a
few status codes that are not defined in Mylyn Builds.  My suggestion to this situation
is, it might be better if we can move the responsibility of providing status code
as class constants (instead of enum), as well as the corresponding icon for each of
the status codes to the connector project (instead of embedding the status codes into the
core of Mylyn Builds).  This way, I think developers should feel much comfortable.

Can you file a bug and describe which status codes you would need? 

One of the important goals of the framework is to provide a strong data model that contains meaningful information about builds regardless of the specific system. This sometimes requires connectors to map values but in turn has the benefit of a consistent UI across connectors. Before we consider supporting connector specific status code I would like to understand better what is missing and whether we can extend the framework to provide a common abstraction.

 

Also, I think the way Koji handles its tasks is very different than Hudson.  In Koji,
there is no build numbers because all builds and their subsequent builds will be treated
as unrelated tasks.  

Can you file a bug and describe the Koji structure? It sounds quite different from Hudson and we'll probably need changes to the data model to support that.

 

This will translate into a situation where Mylyn Builds expects certain
data (like IArtifact, build number, culprit, etc.) that the developer is fill in to provide because his/her
target build system web service is unable to provide.  So I wonder if there is anyway we can detect
the existence of the data defined by Mylyn Builds?  If the data is not available, certain type of
exception (maybe FeatureUnsupportedException?) will be thrown so Mylyn Builds can ignore those fields?

The data model is based on EMF and it should be fine to leave fields empty if the corresponding information is not available. We may want to make changes to the UI implementation to allow more customization of the editor (e.g. to hide sections) or fix cases where the UI assumes that values are set but generally objects don't need to have all fields set.

Steffen

-- 
Steffen Pingel
Committer, http://eclipse.org/mylyn
Senior Developer, http://tasktop.com