You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Mark Brouwer <ma...@cheiron.org> on 2007/01/04 11:33:18 UTC
Components for JIRA
I think it is worth to have a component named 'Website' at this point in
JIRA. I'm not sure whether a separate component 'Governance' is worth
it, or that we can keep track of these things under Website.
--
Mark
Re: Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Geir Magnusson Jr. wrote:
> In harmony, we have one called "contibutions" that make it easy to see
> what external "bulk" contirbutions have been offered... If people like
> that, maybe you should make that too...
Do you mean with bulk contributions the initial seeds and complete
projects that come from the outside. If so, I'm in favor. But I think
even a substantial amount of work that is related to an issue for any
other component should be attached to that issue.
--
Mark
Re: Components for JIRA
Posted by Phil Steitz <ph...@gmail.com>.
On 1/4/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
>
> On Jan 4, 2007, at 10:59 PM, Phil Steitz wrote:
>
> > On 1/4/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
> >>
> >> Yep
> >>
> >> On Jan 4, 2007, at 1:08 PM, Craig L Russell wrote:
> >>
> >> > You might consider a JIRA component called "web site and
> >> > infrastructure" that covers several categories of non-code issues.
> >> >
> >
> >
> > I have prepared a patch to the web site doing mostly s/STATUS/JIRA,
> > but also
> > expressing what seems to be the consensus view that all significant
> > code or
> > doco changes should be tracked via JIRA tickets.
>
> I'd hardly call it a consensus view.
Ack. Just wanted to get something out there for people to react to. The
wording may be stronger than some would like, which is fine - we can adjust,
the the patch gives us something concrete to work from.
> That ticket should
> > logically be opened under a component such as Craig describes
> > above. Any
> > objections to my creating a JIRA component called "web site and
> > infrastructure"?
>
> None whatsoever.
Done.
In harmony, we have one called "contibutions" that make it easy to
> see what external "bulk" contirbutions have been offered... If
> people like that, maybe you should make that too...
Also done. We can edit / remove if there are objections or better ideas on
where to put this stuff.
Phil
Re: Components for JIRA
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Jan 4, 2007, at 10:59 PM, Phil Steitz wrote:
> On 1/4/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>>
>> Yep
>>
>> On Jan 4, 2007, at 1:08 PM, Craig L Russell wrote:
>>
>> > You might consider a JIRA component called "web site and
>> > infrastructure" that covers several categories of non-code issues.
>> >
>
>
> I have prepared a patch to the web site doing mostly s/STATUS/JIRA,
> but also
> expressing what seems to be the consensus view that all significant
> code or
> doco changes should be tracked via JIRA tickets.
I'd hardly call it a consensus view.
> That ticket should
> logically be opened under a component such as Craig describes
> above. Any
> objections to my creating a JIRA component called "web site and
> infrastructure"?
None whatsoever.
In harmony, we have one called "contibutions" that make it easy to
see what external "bulk" contirbutions have been offered... If
people like that, maybe you should make that too...
geir
>
> Phil
Re: Components for JIRA
Posted by Phil Steitz <ph...@gmail.com>.
On 1/4/07, Geir Magnusson Jr. <ge...@pobox.com> wrote:
>
> Yep
>
> On Jan 4, 2007, at 1:08 PM, Craig L Russell wrote:
>
> > You might consider a JIRA component called "web site and
> > infrastructure" that covers several categories of non-code issues.
> >
I have prepared a patch to the web site doing mostly s/STATUS/JIRA, but also
expressing what seems to be the consensus view that all significant code or
doco changes should be tracked via JIRA tickets. That ticket should
logically be opened under a component such as Craig describes above. Any
objections to my creating a JIRA component called "web site and
infrastructure"?
Phil
Re: Components for JIRA
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
Yep
On Jan 4, 2007, at 1:08 PM, Craig L Russell wrote:
> You might consider a JIRA component called "web site and
> infrastructure" that covers several categories of non-code issues.
>
> Craig
>
> On Jan 4, 2007, at 2:33 AM, Mark Brouwer wrote:
>
>> I think it is worth to have a component named 'Website' at this
>> point in JIRA. I'm not sure whether a separate component
>> 'Governance' is worth it, or that we can keep track of these
>> things under Website.
>> --
>> Mark
>
> Craig Russell
> Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
> 408 276-5638 mailto:Craig.Russell@sun.com
> P.S. A good JDO? O, Gasp!
>
Re: Components for JIRA
Posted by Craig L Russell <Cr...@Sun.COM>.
You might consider a JIRA component called "web site and
infrastructure" that covers several categories of non-code issues.
Craig
On Jan 4, 2007, at 2:33 AM, Mark Brouwer wrote:
> I think it is worth to have a component named 'Website' at this
> point in JIRA. I'm not sure whether a separate component
> 'Governance' is worth it, or that we can keep track of these things
> under Website.
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: [PROPOSAL] Components for JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I see, but sometimes a component is at the class level I guess
Seems rare.
> and a complete package name is too wide
For the most part we've found it adequate to stop at top-level packages
within our namespaces. And it's easy to adopt abbreviation of the
few package prefixes (e.g., com.sun.jini -> csj).
oar_outrigger is shorter than "Outrigger implementation". :)
- Bob
Re: [PROPOSAL] Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I know Bob and I don't find it very intuitive.
>
> Dunno how to respond further to that.
>
I thought it was wise to call it something you couldn't held me
accountable for, saves us both a lot of time ;-)
>
>> I always used 'any' to
>> browse or search with a proper keyword. For example sometimes I was
>> curious to see what kind of issues where against the specs, sometimes I
>> was just interested in implementation details. Going through that pull
>> down menu to select all the relevant packages was one bridge too far.
>
> I haven't actually used JIRA yet, so I can't comment on its search
> capabilities. Yes, there are many possible axes that one might want
> to search and/or organize on; that fact shouldn't preclude us from
> picking one.
>
>> Can you also explain the advantage of such a granular level.
>
> A typical mode of operation for someone working on a given component
> is to filter down to just the issues for that component, and
> Java package is a good match for component in the starter kit.
> More often than not when reporting a bug you know what package it's in;
> having to figure out how that package maps to some other component
> naming scheme just adds complexity (which is why, as I recall, we
> migrated away from earlier component naming and to package names).
I see, but sometimes a component is at the class level I guess and a
complete package name is too wide. Just searching on a package name or
class name will result in too much garbage i JIRA. But if component is
important I suggest creating a custom field called component (JIRA is
very easy to customize) where we enter the package name or class name,
this component can be individually searched.
The advantage is that the average user who really shouldn't know about
com.sun.jini.outrigger can submit its issue against "Outrigger
implementation". The developer who inspects the issue can then assign
the component and will make all the correction to priority etc.
You can even go wild with process flows to separate between issue
submitted by users and those dealt with by developers, etc. But I think
given the number of issues submitted in the past that is a bit over the top.
--
Mark
Re: [PROPOSAL] Components for JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Nigel Daley wrote:
> Bob, perhaps it would be useful to post all the categories (and
> subcategories?) that you currently have in BugTraq.
Absent interest in using package names, I cease.
- Bob
Re: [PROPOSAL] Components for JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> With the custom field I told about we can also make it a list with a
> fixed set of options to choose from.
Don't spend time on this just on my account.
- Bob
Re: [PROPOSAL] Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Nigel Daley wrote:
> Perhaps the package names worked well for the engineers that originally
> wrote the code and were the ones filing the bugs. In addition, the
> packages for the most part delineated code ownership by engineers. I
> think package names as JIRA categories have issues, however, in this new
> context.
>
> - pkg names can change
> - to encourage bug filing by the largest possible
> audience, I wouldn't want to assume a submitter knows
> the pertinent package(s)
> - a bug can cross package boundaries
> - there is no code ownership, per se
And it is a list to pick your component from, that means a lot of
scrolling which ain't very user friendly.
With the custom field I told about we can also make it a list with a
fixed set of options to choose from.
> However, I suspect it would be easier for the conversion process if the
> old categories matched the new ones. Is that part of the reasoning with
> sticking to the current categories?
Sounds reasonable. It is very easy in JIRA to 'delete' components and
have all the issues moved over to another component.
BTW and for the mentors, what are the permissions a committer has with
regard to the various JIRA 'administration' tasks?
--
Mark
Re: [PROPOSAL] Components for JIRA
Posted by Nigel Daley <nd...@mac.com>.
Perhaps the package names worked well for the engineers that
originally wrote the code and were the ones filing the bugs. In
addition, the packages for the most part delineated code ownership by
engineers. I think package names as JIRA categories have issues,
however, in this new context.
- pkg names can change
- to encourage bug filing by the largest possible
audience, I wouldn't want to assume a submitter knows
the pertinent package(s)
- a bug can cross package boundaries
- there is no code ownership, per se
However, I suspect it would be easier for the conversion process if
the old categories matched the new ones. Is that part of the
reasoning with sticking to the current categories?
Bob, perhaps it would be useful to post all the categories (and
subcategories?) that you currently have in BugTraq.
Cheers,
Nige
On Jan 5, 2007, at 11:06 AM, Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I know Bob and I don't find it very intuitive.
>
> Dunno how to respond further to that.
>
>> I always used 'any' to
>> browse or search with a proper keyword. For example sometimes I was
>> curious to see what kind of issues where against the specs,
>> sometimes I
>> was just interested in implementation details. Going through that
>> pull
>> down menu to select all the relevant packages was one bridge too far.
>
> I haven't actually used JIRA yet, so I can't comment on its search
> capabilities. Yes, there are many possible axes that one might want
> to search and/or organize on; that fact shouldn't preclude us from
> picking one.
>
>> Can you also explain the advantage of such a granular level.
>
> A typical mode of operation for someone working on a given component
> is to filter down to just the issues for that component, and
> Java package is a good match for component in the starter kit.
> More often than not when reporting a bug you know what package it's
> in;
> having to figure out how that package maps to some other component
> naming scheme just adds complexity (which is why, as I recall, we
> migrated away from earlier component naming and to package names).
>
>> For some parts I don't see harm in it (when we consider each net.jini
>> package a separate spec), but if somebody (also the uninformed
>> user) has
>> a problem against Outrigger, he or she would like to assign to
>> Outrigger, the notion of a package name is not very helpful for
>> such a
>> person.
>
> Anyone dealing with outrigger, even a user, has to know about the
> com.sun.jini.outrigger package name.
>
> - Bob
Re: [PROPOSAL] Components for JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I know Bob and I don't find it very intuitive.
Dunno how to respond further to that.
> I always used 'any' to
> browse or search with a proper keyword. For example sometimes I was
> curious to see what kind of issues where against the specs, sometimes I
> was just interested in implementation details. Going through that pull
> down menu to select all the relevant packages was one bridge too far.
I haven't actually used JIRA yet, so I can't comment on its search
capabilities. Yes, there are many possible axes that one might want
to search and/or organize on; that fact shouldn't preclude us from
picking one.
> Can you also explain the advantage of such a granular level.
A typical mode of operation for someone working on a given component
is to filter down to just the issues for that component, and
Java package is a good match for component in the starter kit.
More often than not when reporting a bug you know what package it's in;
having to figure out how that package maps to some other component
naming scheme just adds complexity (which is why, as I recall, we
migrated away from earlier component naming and to package names).
> For some parts I don't see harm in it (when we consider each net.jini
> package a separate spec), but if somebody (also the uninformed user) has
> a problem against Outrigger, he or she would like to assign to
> Outrigger, the notion of a package name is not very helpful for such a
> person.
Anyone dealing with outrigger, even a user, has to know about the
com.sun.jini.outrigger package name.
- Bob
Re: [PROPOSAL] Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> I think we should have in JIRA at least the following components:
>>
>> Website (with or without space)
>> Infrastructure
>> Contributions
>> ServiceUI
>> JTSK
>
> In Sun's existing issue DB, we use Java package names as the
> component granularity for code, and I think it has worked well.
I know Bob and I don't find it very intuitive. I always used 'any' to
browse or search with a proper keyword. For example sometimes I was
curious to see what kind of issues where against the specs, sometimes I
was just interested in implementation details. Going through that pull
down menu to select all the relevant packages was one bridge too far.
Can you also explain the advantage of such a granular level.
For some parts I don't see harm in it (when we consider each net.jini
package a separate spec), but if somebody (also the uninformed user) has
a problem against Outrigger, he or she would like to assign to
Outrigger, the notion of a package name is not very helpful for such a
person.
BTW I expect JTSK to get split in multiple components, but I think it is
nice if we have at least a component for now so we can start. Gregg's
issue is already lingering in the 'unknown'.
--
Mark
Re: [PROPOSAL] Components for JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I think we should have in JIRA at least the following components:
>
> Website (with or without space)
> Infrastructure
> Contributions
> ServiceUI
> JTSK
In Sun's existing issue DB, we use Java package names as the
component granularity for code, and I think it has worked well.
- Bob
[PROPOSAL] Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
I think we should have in JIRA at least the following components:
Website (with or without space)
Infrastructure
Contributions
ServiceUI
JTSK
If the above is not proper we can move afterwards without a fuzz, that
is better than having nothing at the moment.
--
Mark
Re: Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Mark Brouwer wrote:
> Mark Brouwer wrote:
>> Craig L Russell wrote:
>>> Hi marbro,
>>>
>>> What happens when you go to the River JIRA page and click on Create
>>> New Issue?
>>
>> It was not there when I looked for it, the purple must have blinded me
>> to see the cause. I had to create an account today for I only had an
>> account on ASF Bugzilla. After creating the account I was convinced I
>> was logged in, but apparently not. Logging in solved my problem.
>>
>>> River has been set up correctly as far as I can tell. It has standard
>>> permissions that allows any jira user to enter a new issue.
>>
>> You are right, I was blind.
>
> I notice that everytime I go to JIRA I have to log in even while I
> selected "Remember my login on this computer". On my own JIRA
> installation (3.6.3) this seems to work, is this policy or something else?
I think I found the cause for this. When you go to JIRA by the link on
the River project site you go the HTTP version and for that one you have
to login, clinking Login redirects you to the HTTPS version and you have
to provide your user ID and password there.
If you go straight to the HTTPS version then it has remembered your
login, going through the HTTP version first screws everything. I have
bookmarked the HTTPS version now and it works as expected. Maybe we
should change the link on the project site to point to HTTPS directly ...
--
Mark
Re: Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Mark Brouwer wrote:
> Craig L Russell wrote:
>> Hi marbro,
>>
>> What happens when you go to the River JIRA page and click on Create
>> New Issue?
>
> It was not there when I looked for it, the purple must have blinded me
> to see the cause. I had to create an account today for I only had an
> account on ASF Bugzilla. After creating the account I was convinced I
> was logged in, but apparently not. Logging in solved my problem.
>
>> River has been set up correctly as far as I can tell. It has standard
>> permissions that allows any jira user to enter a new issue.
>
> You are right, I was blind.
I notice that everytime I go to JIRA I have to log in even while I
selected "Remember my login on this computer". On my own JIRA
installation (3.6.3) this seems to work, is this policy or something else?
--
Mark
Re: Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Craig L Russell wrote:
> Hi marbro,
>
> What happens when you go to the River JIRA page and click on Create New
> Issue?
It was not there when I looked for it, the purple must have blinded me
to see the cause. I had to create an account today for I only had an
account on ASF Bugzilla. After creating the account I was convinced I
was logged in, but apparently not. Logging in solved my problem.
> River has been set up correctly as far as I can tell. It has standard
> permissions that allows any jira user to enter a new issue.
You are right, I was blind.
--
Mark
Re: Components for JIRA
Posted by Craig L Russell <Cr...@Sun.COM>.
Hi marbro,
What happens when you go to the River JIRA page and click on Create
New Issue?
River has been set up correctly as far as I can tell. It has standard
permissions that allows any jira user to enter a new issue.
Craig
On Jan 4, 2007, at 6:57 AM, Mark Brouwer wrote:
> Gregg Wonderly wrote:
>> Mark Brouwer wrote:
>>> I think it is worth to have a component named 'Website' at this
>>> point in JIRA. I'm not sure whether a separate component
>>> 'Governance' is worth it, or that we can keep track of these
>>> things under Website.
>> There were several posts and discussions on the serviceui lists
>> that I'd like to move over to JIRA issues.
>
> I think it would be great if these are moved over here. I thought
> everybody that created an account at the JIRA instance at the ASF
> could
> enter issues for a project, but it turns out I can't even enter an
> issue, so maybe Geir can shed some light about this.
>
> In time we have to come up with proper JIRA components for everything,
> but for now I think we can enter them for "Unknown" and move them over
> to the proper component. Or maybe Bill has some good ideas about the
> components for ServiceUI.
> --
> Mark
Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!
Re: Components for JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> I think it is worth to have a component named 'Website' at this point
>> in JIRA. I'm not sure whether a separate component 'Governance' is
>> worth it, or that we can keep track of these things under Website.
>
> There were several posts and discussions on the serviceui lists that I'd
> like to move over to JIRA issues.
I think it would be great if these are moved over here. I thought
everybody that created an account at the JIRA instance at the ASF could
enter issues for a project, but it turns out I can't even enter an
issue, so maybe Geir can shed some light about this.
In time we have to come up with proper JIRA components for everything,
but for now I think we can enter them for "Unknown" and move them over
to the proper component. Or maybe Bill has some good ideas about the
components for ServiceUI.
--
Mark
Re: Components for JIRA
Posted by Gregg Wonderly <ge...@cox.net>.
Mark Brouwer wrote:
> I think it is worth to have a component named 'Website' at this point in
> JIRA. I'm not sure whether a separate component 'Governance' is worth
> it, or that we can keep track of these things under Website.
There were several posts and discussions on the serviceui lists that I'd like to
move over to JIRA issues.
Gregg Wonderly