All, I looked at the current issue list. It doesn't seem like any of the existing issues on google code have a component defined at all. So I don't think the current components make a difference.
~Michael On Mar 25, 2011, at 8:22 PM, Alex North wrote: > Dave's suggestions sound good. Another piece of code that runs both client > and server is the comms protocols. Let's either roll that into model "Wave > Model & Protocols" or add a new component for "Protocols". > > On 23 March 2011 20:20, David Hearnden <hearn...@google.com> wrote: > >> -1 for "Logic". >> >> Grouping by service/component and roughly aligning with the code's package >> structure makes a lot of sense to me. >> >> James' categories SGTM. I'd add two more: >> >> Web Client >> >> Federation >> >> Server (i.e., serving the wave protocol) >> >> Extensions >> >> + Wave Model >> >> + Search/Indexing >> >> "Wave Model" is for components in wave.model.* (like OT, documents, etc) >> that are both client and server, and don't fit any of the other categories. >> >> I think that "Search/Indexing" also should be separated from the wave >> protocol part of the server. >> >> I'd anticipate possible further breakdown of some parts, e.g. >> >> Web Client - Editor >> >> Web Client - Wave Panel >> >> or >> >> Server - Front End >> >> Server - Wave Storage >> >> Server - Concurrency Control >> >> but those are fine-grained enough that it makes sense to create them on >> demand if that's relatively painless in JIRA. >> >> -Dave >> On Wed, Mar 23, 2011 at 3:16 PM, James Purser <jamesrpur...@gmail.com >>> wrote: >> >>> Sure, >>> >>> I'd probably suggest something like the following then: >>> >>> Web Client >>> Federation >>> Server >>> Extensions >>> >>> >>> On Wed, Mar 23, 2011 at 3:13 PM, Michael MacFadden < >>> michael.macfad...@gmail.com> wrote: >>> >>>> James, >>>> >>>> I suggest, we break the conversation in to two parts. If setting up >> the >>>> components to be the same allows an easier import, then lets do that as >>> part >>>> of the import exercise, which we will talk about next. Even if we do >>> that, >>>> the next question would be, what do we really want the components to >> be. >>> I >>>> would like to focus on that for the moment. When we discuss the import >>> was >>>> can talk about using the existing components as a start. >>>> >>>> Of course there is nothing that saw we can't use the existing >> components >>> as >>>> the to-be-state as well. >>>> >>>> ~Michael >>>> >>>> On Mar 22, 2011, at 9:04 PM, James Purser wrote: >>>> >>>>> Sounds like a good start. Then we can look at changing things to make >> a >>>> bit >>>>> more sense with regards to WIAB. >>>>> >>>>> On Wed, Mar 23, 2011 at 3:02 PM, Michael MacFadden < >>>>> michael.macfad...@gmail.com> wrote: >>>>> >>>>>> James, >>>>>> >>>>>> I looked and it seems like the Google Issue Tracker has: >>>>>> >>>>>> UI >>>>>> Logic >>>>>> Persistence >>>>>> Scripts >>>>>> Docs >>>>>> >>>>>> Is this what you are suggesting? >>>>>> >>>>>> ~Michael >>>>>> >>>>>> >>>>>> On Mar 22, 2011, at 8:55 PM, James Purser wrote: >>>>>> >>>>>>> For the moment, might be best to replicate what the Google Issues >>>> tracker >>>>>>> has so that we can import the old issues and then take it from >> there. >>>>>>> >>>>>>> On Wed, Mar 23, 2011 at 2:53 PM, Michael MacFadden < >>>>>>> michael.macfad...@gmail.com> wrote: >>>>>>> >>>>>>>> We can redefine them as we see fit, and it fairly easy to do bulk >>>>>> changes >>>>>>>> on existing issues to re-assign components. >>>>>>>> >>>>>>>> >>>>>>>> On Mar 22, 2011, at 8:05 PM, David Hearnden wrote: >>>>>>>> >>>>>>>>> Are those components something that can be refined later? i.e., >>>> could >>>>>> we >>>>>>>> start with high-level categories, and later refine them as needed? >>> Or >>>>>> are >>>>>>>> those categories set in stone at setup time? That might strongly >>>>>> influence >>>>>>>> the component list. >>>>>>>>> >>>>>>>>> (I've never used JIRA) >>>>>>>>> >>>>>>>>> -Dave >>>>>>>>> >>>>>>>>> On Wed, Mar 23, 2011 at 2:02 PM, Michael MacFadden < >>>>>>>> michael.macfad...@gmail.com> wrote: >>>>>>>>> All, >>>>>>>>> >>>>>>>>> I am starting to set up Jira. Typically one of the first things >> to >>>> be >>>>>>>> done is to define the components. These components would be ones >>> that >>>>>> we >>>>>>>> would want to target issues to. I would like to get some input on >>>> what >>>>>> the >>>>>>>> components should be. Things to keep in mind: >>>>>>>>> >>>>>>>>> 1) How granular do we want to be. Would "server" and "web >> client" >>>>>>>> suffice, or do we need things like the wave panel vs the wave list >>> vs >>>>>> the >>>>>>>> profile management section etc. >>>>>>>>> >>>>>>>>> 2) What naming convention would we use? There is only really >> one >>>>>> level >>>>>>>> of components, no nesting. So we might have things like Web >> Client >>> - >>>>>> Wave >>>>>>>> Panel and Server - Mongo DB Persistence, etc. >>>>>>>>> >>>>>>>>> 3) The point of defining components is so that the groups of >>> people >>>>>> who >>>>>>>> typically work on those components can filter the issue list based >>> on >>>>>> those >>>>>>>> components. While the architecture might logically be broken down >>> in >>>> to >>>>>>>> certain components, if it doesn't improve our ability to manage >> the >>>>>> issues, >>>>>>>> then they don't have to line up 1 to 1. >>>>>>>>> >>>>>>>>> >>>>>>>>> Suggestions and input would be great. One small request, lets >> try >>> to >>>>>>>> stay at a high level here and not go down rabbit holes discussing >> a >>>>>>>> particular possible component as nauseum. Thanks. >>>>>>>>> >>>>>>>>> ~Michael >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> James Purser >>>>>>> Collaborynth >>>>>>> http://collaborynth.com.au >>>>>>> Mob: +61 406 576 553 >>>>>>> Wave: ja...@collaborynth.com.au >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> James Purser >>>>> Collaborynth >>>>> http://collaborynth.com.au >>>>> Mob: +61 406 576 553 >>>>> Wave: ja...@collaborynth.com.au >>>> >>>> >>> >>> >>> -- >>> James Purser >>> Collaborynth >>> http://collaborynth.com.au >>> Mob: +61 406 576 553 >>> Wave: ja...@collaborynth.com.au >>> >>
