geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <david.blev...@visi.com>
Subject Re: Geronimo ORB progress
Date Fri, 18 Nov 2005 10:56:19 GMT
Ok either averaging 4 hours of sleep this week is getting to me or  
Alan started speaking another language deceptively like English but  
where you agree with people by disagreeing with them.  My wife speaks  
this language fluently.

On Nov 17, 2005, at 2:18 PM, Dain Sundstrom wrote:
> +1 Using JIRA for tracking progress of the ORB would be great.
>
> We already have a CORBA component, so I suggest you create an "Add  
> an ORB implementation" issue that can be the parent of all the tasks.

On Nov 17, 2005, at 3:19 PM, Lars Kühne wrote:
>
> Done, GERONIMO-1198

On Nov 17, 2005, at 5:24 PM, Alan D. Cabrera wrote:
>
> Lars,
>
> I think that we should make focused jira issues rather than a  
> single umbrella issue that tracks all work on the CORBA server.  
> [blah blah blah] File sub-tasks for the patches that you are  
> submitting.


On Nov 17, 2005, at 10:18 PM, Lars Kühne wrote:
>
> Alan,
>
> as Dain suggested this issue is meant to serve as a parent issue  
> for individual subtasks (or rather "incorporates" links?).


On Nov 18, 2005, at 12:47 AM, Alan D. Cabrera wrote:
>
> [snip] I do not believe that there is a need to capture the  
> hierarchy of the architecture in Jira.  A flat list of Jira issues  
> with sub-tasks that track individual patches for that issue should  
> be fine..


The part that really gets me rolling on the ground... hierarchies are  
ok just as long as you refer to them as being "flat" lists with sub- 
lists.  That's like saying, "We're not so much walking as we more  
sort of moving our shoes from one place to another while they happen  
to be on our feet."  I guess the zen is in the spaces between the words.

Considering a Jira Task Issue contains all the same data as a Jira  
Issue Sub-Task, I bet you $50 they are the same thing but with a  
couple GUI screens cut out and defaults filled in for convenience.

Just couldn't bite my tongue on this one ... (assuming that  
expression even works for text).

OK, I definitely need sleep.

-David


On Nov 18, 2005, at 12:47 AM, Alan D. Cabrera wrote:

> Lars Kühne wrote, On 11/17/2005 10:18 PM:
>
>> Alan D. Cabrera wrote:
>>> On Nov 17, 2005, at 3:19 PM, Lars Kühne wrote:
>>>>> On 11/17/05, *Dain Sundstrom* <dain@iq80.com  
>>>>> <mailto:dain@iq80.com>> wrote:
>>>>>     We already have a CORBA component, so I suggest you create  
>>>>> an "Add an
>>>>>     ORB implementation" issue that can be the parent of all the  
>>>>> tasks.
>>>>>
>>>>
>>>> Done, GERONIMO-1198
>>>
>>> I think that we should make focused jira issues rather than a  
>>> single umbrella issue that tracks all work on the CORBA server.   
>>> Ideally, people would put their stake in the ground by writing  
>>> about the architectural bit that they are going to implement in  
>>> the wiki.  Then follow up with a a single Jira issue that  
>>> basically marks the bit that you are going to implement.   File  
>>> sub-tasks for the patches that you are submitting.
>>>
>>> WDYT?
>>
>>
>>
>> Alan,
>>
>> as Dain suggested this issue is meant to serve as a parent issue  
>> for individual subtasks (or rather "incorporates" links?). This,  
>> together with using the CORBA component, is meant to serve as a  
>> simple method for filtering for individual work items that are  
>> open. Inidividual sub-issues would be stuff like "implement  
>> ORB.resolve_initial_reference", "allow JMX monitoring of property  
>> xyz", "add unit tests for ValueType mashalling" or "document  
>> configuration properties".
>
> The problem is that keeping track of the patches, and they will be  
> more than one for any issue, becomes a problem because they are  
> tossed in one bucket of attachments.  I do not believe that there  
> is a need to capture the hierarchy of the architecture in Jira.  A  
> flat list of Jira issues with sub-tasks that track individual  
> patches for that issue should be fine..
>


>> I have never used a Wiki as a collaboration tool, so maybe I don't  
>> know what I'm missing. Right now I wouldn't know what to write  
>> about the above sub-issues, as most of it isn't really  
>> "architectural" - it's described in the CORBA spec and somebody  
>> just has to do it.
>
> That's ok.  There's no point in excessive bureucracy, I would just  
> file a Jira issue in this case.  However, the reason that I wanted  
> to use the wiki was to use that as an informal organization  
> mechanism.  I would hate for you and others to start working on the  
> same thing at the same time.
>
>> For the trickier parts of an ORB a Wiki would certainly be a good  
>> idea to achieve some high level implementation idea before actual  
>> coding starts. However, I typically write an implementation  
>> overview (responsibility of each package and how they work  
>> together) in javadoc overview and package docs.
>>
>> Do you use javadoc in geronimo land or do you write everything in  
>> the Wiki? What about end user docs, would they belong in src/ 
>> xdocs, so they are easy to distribute with releases, or would that  
>> go into the Wiki, so they are easier to edit for non-committers?
>
> We haven't discussed that at any length, iirc.  I personally would  
> prefer everything to go into the wiki.
>
>
> Regards,
> Alan
>
>
>


Mime
View raw message