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

[Kiu Leung <kleung@xxxxxxxxxx>]

Mr. Pingel:

Sure, I will do that after lunch, but since this is only my second week of the project, I might not
be able to clearly describe how Koji works, so please forgive me for that.

Thanks for the quick reply!

Ken Leung

----- Original Message -----
From: "Steffen Pingel" <steffen.pingel@xxxxxxxxxxx>
To: "Mylyn versions project" <mylyn-builds-dev@xxxxxxxxxxx>
Sent: Thursday, July 28, 2011 11:41:00 AM
Subject: Re: [mylyn-builds-dev] Ken's suggestions as well as questions about Mylyn Builds Connector



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 

_______________________________________________
mylyn-builds-dev mailing list
mylyn-builds-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/mylyn-builds-dev