Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
First, I apologize for introducing bias towards a solution. I wasn't trying to do that, I was just trying to remember off the top of my head what the issues were. Please feel free to edit that entry and fix it :-) (You can note that you did this in the "change log" box that comes with the editing). I don't know if a "Wiki" is a good way to keep track of these things, unless we set up a wiki section which is only editable by committers + selected others. I don't want to be worrying about others changing what we've put up in lists of things to remember :-) Instead of a wiki - we could have a section of our web page that serves this purpose - that would of course only be updatable by committers. Finally, I agree Jira's not the place for discussion of these items. I only put this up in Jira as a reminder list of things we should get around to discussing at some point. I agree discussions should occur on the mailing lists. -Marshall Adam Lally wrote: I don't think Jira is the place to put architectural discussions like "index everything" (not sure what that even means) or an implementation for singletons, where I think the name is already misleading (because it's about a problem that is real, but points at a solution that I happen to disagree with). These are good points, but maybe the answer is just to be careful to record what the real problem is in the JIRA issue and try not to introduce a bias towards a particular solution. If it's a real problem, then I think it's appropriate to have an issue opened for it. Also maybe the JIRA "Wish" category is for things that some particular person (whether developer or user) would like to see. It's still appropriate to have the discussion on the dev-list and ultimately decide to reject (or modify) the idea. And sure, we can refrence the mail archive when we decide to close or edit the JIRA issue. If we don't do this, then we'll need a Wiki or something to keep track of these things, and I don't see the benefit of that. -Adam
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
I don't think Jira is the place to put architectural discussions like "index everything" (not sure what that even means) or an implementation for singletons, where I think the name is already misleading (because it's about a problem that is real, but points at a solution that I happen to disagree with). These are good points, but maybe the answer is just to be careful to record what the real problem is in the JIRA issue and try not to introduce a bias towards a particular solution. If it's a real problem, then I think it's appropriate to have an issue opened for it. Also maybe the JIRA "Wish" category is for things that some particular person (whether developer or user) would like to see. It's still appropriate to have the discussion on the dev-list and ultimately decide to reject (or modify) the idea. And sure, we can refrence the mail archive when we decide to close or edit the JIRA issue. If we don't do this, then we'll need a Wiki or something to keep track of these things, and I don't see the benefit of that. -Adam
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
Adam Lally wrote: On 11/14/06, Thilo Goetz <[EMAIL PROTECTED]> wrote: I'm sort of thinking along the same lines. I would not have thought of using Jira like this -- which is not to say that this is wrong in any way, it's just not what I understood by an issue tracking system. To my mind, things go into Jira if it's either a bug, or some new feature that has previously been discussed on uima-dev. I think that a "feature request" in JIRA could be opened by a user who wants that feature. It doesn't need to have been discussed on uima-dev. I think I basically agree with Marshall that we can use JIRA to keep track of any kind of issue that we think needs to be addressed, even if there's no consensus on how it should be addressed at the time. (Even for a bug, there might not be a consensus on how to fix it.) -Adam I don't think Jira is the place to put architectural discussions like "index everything" (not sure what that even means) or an implementation for singletons, where I think the name is already misleading (because it's about a problem that is real, but points at a solution that I happen to disagree with). The discussion of these things needs to happen on the mailing list anyway. What are we going to do then, paste the whole mail trail into Jira? Reference the mail archive? I still don't think this is a good idea. --Thilo
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
On 11/14/06, Thilo Goetz <[EMAIL PROTECTED]> wrote: I'm sort of thinking along the same lines. I would not have thought of using Jira like this -- which is not to say that this is wrong in any way, it's just not what I understood by an issue tracking system. To my mind, things go into Jira if it's either a bug, or some new feature that has previously been discussed on uima-dev. I think that a "feature request" in JIRA could be opened by a user who wants that feature. It doesn't need to have been discussed on uima-dev. I think I basically agree with Marshall that we can use JIRA to keep track of any kind of issue that we think needs to be addressed, even if there's no consensus on how it should be addressed at the time. (Even for a bug, there might not be a consensus on how to fix it.) -Adam
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
Thilo Goetz wrote: To my mind, things go into Jira if it's either a bug, or some new feature that has previously been discussed on uima-dev. I guess I'm biased by my CMVC past. I would expect things in Jira that have a clear resolution: a bug gets fixed, a feature implemented. I guess I think these things all need a clear resolution. General items for discussion should be put forward on the mailing list and discussed there. Once we're agreed how to do things, that's when we should open a Jira issue. I was trying to address the problem of having some spot where everyone could look and remember what (some of) the pending issues to work on, are. I think either the Website (we could have a page devoted to this) or Jira would do. Jira has the advantage of things like priorities, comments, reporting, etc. I've seen Jira used for things other than bugs. -Marshall
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
Adam Lally wrote: On 11/14/06, Marshall Schor <[EMAIL PROTECTED]> wrote: I like the idea of a category for these. It looks like we cannot add categories? It would be nice if there were an additional column we could use to select these out. What do these really have in common that merits a category? "Architectural cleanup" seems quite vague. Some of these just seem like "feature requests" (e.g. "index for everything", configuration of remote components) or "wishes" (not clear what the distinction should be, I guess wishes are more vague). Others are decisions that need to be made (e.g. type merging, Sofas-views), probably the decisions need to be made on the dev list but JIRA could have a "Task" reminding us that we need to have the discussion; then the task could become an feature request (or an "improvement") once the decision has been made? -Adam I'm sort of thinking along the same lines. I would not have thought of using Jira like this -- which is not to say that this is wrong in any way, it's just not what I understood by an issue tracking system. To my mind, things go into Jira if it's either a bug, or some new feature that has previously been discussed on uima-dev. I guess I'm biased by my CMVC past. I would expect things in Jira that have a clear resolution: a bug gets fixed, a feature implemented. General items for discussion should be put forward on the mailing list and discussed there. Once we're agreed how to do things, that's when we should open a Jira issue. Other opinions? Has anybody observed how other Apache projects are handling this? --Thilo
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
On 11/14/06, Marshall Schor <[EMAIL PROTECTED]> wrote: I like the idea of a category for these. It looks like we cannot add categories? It would be nice if there were an additional column we could use to select these out. What do these really have in common that merits a category? "Architectural cleanup" seems quite vague. Some of these just seem like "feature requests" (e.g. "index for everything", configuration of remote components) or "wishes" (not clear what the distinction should be, I guess wishes are more vague). Others are decisions that need to be made (e.g. type merging, Sofas-views), probably the decisions need to be made on the dev list but JIRA could have a "Task" reminding us that we need to have the discussion; then the task could become an feature request (or an "improvement") once the decision has been made? -Adam
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
I have no objection to individual Jira issues. I thought they could be "sub tasks" of this task, and we would have some place where all of them were collected, but I can see that would be a "maintenance" problem. I like the idea of a category for these. It looks like we cannot add categories? It would be nice if there were an additional column we could use to select these out. The customize navigator shows lots of additional columns, but again, none of them seem to be part of our Jira instance. -Marshall Thilo Goetz wrote: +1, see my reply to the documentation issues (hadn't read this then). --Thilo Adam Lally wrote: Is this the right way to do this? Alternatively we could enter each of these as a separate JIRA issue, perhaps intially of type "Wish". That way we could assign them different priorities and attach separate comments to them, attach them to releases/roadmaps, etc. With everything as one JIRA issue, when you edit the description as you did just now, I have to try to go through manually and figure out what has changed. -Adam On 11/14/06, Marshall Schor (JIRA) wrote: Placeholder for Architectural Cleanups / Changes Key: UIMA-18 URL: http://issues.apache.org/jira/browse/UIMA-18 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Priority: Minor This is a place to list architectural cleanup issues. Edit this to fix / augment. Perhaps sub-tasks of this can be particular issues we decide are being worked on. 1) Index for everything (needed for simple access to singletons) 2) Simple access for singletons 3) Deciding about Sofa names and View names, (not)having a 1-1 correspondence between sofas and views. 4) Removing/reducing type system augmentation via merging 5) Begin able to configure remote components 6) Adding "session" caching for remote components 7) Supporting operations over sets of multiple CASes with more than just external resources 8) Integrating OSGi enablement 9) Integrating Eclipse launch support 10) Eclipse integrated CAS viewers/explorers 11) (Eclipse) Debugging support for complex flows 12) CAS difference capturing and exploring -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
Is this the right way to do this? Alternatively we could enter each of these as a separate JIRA issue, perhaps intially of type "Wish". That way we could assign them different priorities and attach separate comments to them, attach them to releases/roadmaps, etc. With everything as one JIRA issue, when you edit the description as you did just now, I have to try to go through manually and figure out what has changed. -Adam On 11/14/06, Marshall Schor (JIRA) wrote: Placeholder for Architectural Cleanups / Changes Key: UIMA-18 URL: http://issues.apache.org/jira/browse/UIMA-18 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Priority: Minor This is a place to list architectural cleanup issues. Edit this to fix / augment. Perhaps sub-tasks of this can be particular issues we decide are being worked on. 1) Index for everything (needed for simple access to singletons) 2) Simple access for singletons 3) Deciding about Sofa names and View names, (not)having a 1-1 correspondence between sofas and views. 4) Removing/reducing type system augmentation via merging 5) Begin able to configure remote components 6) Adding "session" caching for remote components 7) Supporting operations over sets of multiple CASes with more than just external resources 8) Integrating OSGi enablement 9) Integrating Eclipse launch support 10) Eclipse integrated CAS viewers/explorers 11) (Eclipse) Debugging support for complex flows 12) CAS difference capturing and exploring -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Created: (UIMA-18) Placeholder for Architectural Cleanups / Changes
+1, see my reply to the documentation issues (hadn't read this then). --Thilo Adam Lally wrote: Is this the right way to do this? Alternatively we could enter each of these as a separate JIRA issue, perhaps intially of type "Wish". That way we could assign them different priorities and attach separate comments to them, attach them to releases/roadmaps, etc. With everything as one JIRA issue, when you edit the description as you did just now, I have to try to go through manually and figure out what has changed. -Adam On 11/14/06, Marshall Schor (JIRA) wrote: Placeholder for Architectural Cleanups / Changes Key: UIMA-18 URL: http://issues.apache.org/jira/browse/UIMA-18 Project: UIMA Issue Type: Improvement Reporter: Marshall Schor Priority: Minor This is a place to list architectural cleanup issues. Edit this to fix / augment. Perhaps sub-tasks of this can be particular issues we decide are being worked on. 1) Index for everything (needed for simple access to singletons) 2) Simple access for singletons 3) Deciding about Sofa names and View names, (not)having a 1-1 correspondence between sofas and views. 4) Removing/reducing type system augmentation via merging 5) Begin able to configure remote components 6) Adding "session" caching for remote components 7) Supporting operations over sets of multiple CASes with more than just external resources 8) Integrating OSGi enablement 9) Integrating Eclipse launch support 10) Eclipse integrated CAS viewers/explorers 11) (Eclipse) Debugging support for complex flows 12) CAS difference capturing and exploring -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
