You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Jim Hurley <Ji...@Sun.COM> on 2007/07/17 00:08:59 UTC
getting current buglist into JIRA
After two weeks of a frustrating and unsuccessful effort to
try to get bug information exported from Sun's bug tracking
system such that we could import into our Apache River (JIRA),
we're going to scrap it and look at a plan B.
MarkB suggested (<http://mail-archives.apache.org/mod_mbox/incubator-
river-dev/200706.mbox/%3c466D9507.9090901@cheiron.org%3e>)
that we ask each of the committers to add in issues. Although
not too exciting, I think it's a good way to start getting everyone
involved. Breaking things up, I'm guessing we could start with
10 issues each and get them all in within a week. If you don't
think you have an hour to spend on this sometime in the next
week - please send me a note.
I'll go through the bug list and divy them up and pass along
instructions on how to do this.
Before we get started, though, we're going to need to set
a few things up. One thing is to create JIRA Components
to break the bugs up into different categories.
We can change it later, but to make things simple to start,
I'd like to keep the (package) names we have in the Sun
bugs. I also thought about changing the component of
com_sun_jini to org_apache_{jini|river} but thought we
should keep it for now until we make the code changes
for the package names.
Therefore, I'd like to create the following (these match
existing outstanding bugs) Components in JIRA:
Components:
------------------
net_jini_core
net_jini_config
net_jini_discovery
net_jini_export
net_jini_event
net_jini_io
net_jini_jeri
net_jini_lease
net_jini_loader
net_jini_lookup
net_jini_security
net_jini_space
net_jini_url
other
build
doc
com_sun_jini_reggie
com_sun_jini_example
com_sun_jini_fiddler
com_sun_jini_logging
com_sun_jini_lookup
com_sun_jini_mahalo
com_sun_jini_mercury
com_sun_jini_norm
com_sun_jini_outrigger
com_sun_jini_phoenix
com_sun_jini_start
com_sun_jini_tool
com_sun_jini_action
com_sun_jini_discovery
com_sun_jini_start
com_sun_jini_thread
--------------------------------
I'm not sure what the proper procedure is here (so
please advise). If someone objects, please speak
up. Otherwise, I'm not sure if we need to call for a
vote, or just proceed if there's no objections?
thanks -Jim
Re: getting current buglist into JIRA
Posted by Phil Steitz <ph...@gmail.com>.
On 7/17/07, Mark Brouwer <ma...@cheiron.org> wrote:
> Phil Steitz wrote:
>
> > No need for a vote on this. Lazy consensus is fine. No objections from
> > me. +1 on Mark's suggestion to add tracking. I am also willing to help.
>
> Just to be sure, do you favor an additional field or just the link
> reference Phil?
I would be fine either way, but the field would probably be a little
more flexible and just as easy to populate, so I would say go for
that.
Phil
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Phil Steitz wrote:
> No need for a vote on this. Lazy consensus is fine. No objections from
> me. +1 on Mark's suggestion to add tracking. I am also willing to help.
Just to be sure, do you favor an additional field or just the link
reference Phil?
--
Mark
Re: getting current buglist into JIRA
Posted by Phil Steitz <ph...@gmail.com>.
On 7/16/07, Jim Hurley <Ji...@sun.com> wrote:
> After two weeks of a frustrating and unsuccessful effort to
> try to get bug information exported from Sun's bug tracking
> system such that we could import into our Apache River (JIRA),
> we're going to scrap it and look at a plan B.
>
> MarkB suggested (<http://mail-archives.apache.org/mod_mbox/incubator-
> river-dev/200706.mbox/%3c466D9507.9090901@cheiron.org%3e>)
> that we ask each of the committers to add in issues. Although
> not too exciting, I think it's a good way to start getting everyone
> involved. Breaking things up, I'm guessing we could start with
> 10 issues each and get them all in within a week. If you don't
> think you have an hour to spend on this sometime in the next
> week - please send me a note.
>
> I'll go through the bug list and divy them up and pass along
> instructions on how to do this.
>
> Before we get started, though, we're going to need to set
> a few things up. One thing is to create JIRA Components
> to break the bugs up into different categories.
>
> We can change it later, but to make things simple to start,
> I'd like to keep the (package) names we have in the Sun
> bugs. I also thought about changing the component of
> com_sun_jini to org_apache_{jini|river} but thought we
> should keep it for now until we make the code changes
> for the package names.
>
> Therefore, I'd like to create the following (these match
> existing outstanding bugs) Components in JIRA:
>
> Components:
> ------------------
> net_jini_core
> net_jini_config
> net_jini_discovery
> net_jini_export
> net_jini_event
> net_jini_io
> net_jini_jeri
> net_jini_lease
> net_jini_loader
> net_jini_lookup
> net_jini_security
> net_jini_space
> net_jini_url
> other
> build
> doc
> com_sun_jini_reggie
> com_sun_jini_example
> com_sun_jini_fiddler
> com_sun_jini_logging
> com_sun_jini_lookup
> com_sun_jini_mahalo
> com_sun_jini_mercury
> com_sun_jini_norm
> com_sun_jini_outrigger
> com_sun_jini_phoenix
> com_sun_jini_start
> com_sun_jini_tool
> com_sun_jini_action
> com_sun_jini_discovery
> com_sun_jini_start
> com_sun_jini_thread
> --------------------------------
>
> I'm not sure what the proper procedure is here (so
> please advise). If someone objects, please speak
> up. Otherwise, I'm not sure if we need to call for a
> vote, or just proceed if there's no objections?
>
No need for a vote on this. Lazy consensus is fine. No objections from me.
+1 on Mark's suggestion to add tracking. I am also willing to help.
Phil
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> fyi -- I've added all of these Components to our River
> project JIRA.
>
> We have 26 issues filed with "No Component"... if it makes
> sense - it would be great for the Reporter or Assignee to move
> them into the proper Component.
I'll do that as soon as the versions are added to JIRA, otherwise I'll
have to go over them again.
--
Mark
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
fyi -- I've added all of these Components to our River
project JIRA.
We have 26 issues filed with "No Component"... if it makes
sense - it would be great for the Reporter or Assignee to move
them into the proper Component.
thanks -Jim
On Jul 16, 2007, at 6:08 PM, Jim Hurley wrote:
:
> Therefore, I'd like to create the following (these match
> existing outstanding bugs) Components in JIRA:
>
> Components:
> ------------------
> net_jini_core
> net_jini_config
> net_jini_discovery
> net_jini_export
> net_jini_event
> net_jini_io
> net_jini_jeri
> net_jini_lease
> net_jini_loader
> net_jini_lookup
> net_jini_security
> net_jini_space
> net_jini_url
> other
> build
> doc
> com_sun_jini_reggie
> com_sun_jini_example
> com_sun_jini_fiddler
> com_sun_jini_logging
> com_sun_jini_lookup
> com_sun_jini_mahalo
> com_sun_jini_mercury
> com_sun_jini_norm
> com_sun_jini_outrigger
> com_sun_jini_phoenix
> com_sun_jini_start
> com_sun_jini_tool
> com_sun_jini_action
> com_sun_jini_discovery
> com_sun_jini_thread
> --------------------------------
Re: getting current buglist into JIRA
Posted by Thomas Vinod Johnson <Th...@Sun.COM>.
>>
>>
>> Still this doesn't solve the problem I face with building on top of Jini
>> where I need something to say as Seven/Service/Product is compliant with
>> Jini version x.y
>>
Long discussion I suppose :)
>
> Any other opinions from committers and folks on the list?
>
I'm for the start simple and evolve as we go along approach.
- For River's temporary version number AR1 seems fine.
- We may decide at some point that there is a need for multiple projects
- then so be it (from briefly looking at Avalon, it seems that they
split up into sub-projects later on in life - people with a grasp of
Apache project history please correct me). I'm expecting that the
development process at Apache can accommodate such a change.
- For bugtraq id's I prefer a custom field.
- I don't really have a strong preference for having a JTSK prefix in
the version numbers or not. If asked to choose, I would go with no
prefix - as Mark suggested there is some value in being able to just
refer to the old version numbers and dealing with river as a progression
from the JTSK. As for potential confusion for newbies, that could be
fixed with a brief history of river (the bugtraq id field will also be a
hint that this came from the JTSK).
> thanks -Jim
>
>
Re: getting current buglist into JIRA
Posted by "John McClain - Sun Microsystems, Inc." <Jo...@Sun.COM>.
Jim Hurley wrote:
> Any other opinions from committers and folks on the list?
I think it is simplest to start with a single deliverable mind set and
get additional projects if we need them latter.
Version number wise I like the idea of river starting where the Sun
Starter Kit version number left off.
Having, said that, the first version number still won't be obvious at
this point (2.1_1?, 2.1.1?, 2.1? ...), so I would start with something
like "AR1" and change its name latter once we know what we think it is.
Given the notion starting the River version numbers where the Sun
numbers left off, I am fine with bring over bugs with there existing
version numbers intact, though a prefix may make things a bit clearer.
--
John McClain john.mcclain@sun.com
Sun Microsystems, Inc.
Burlington, MA
And it is that way today. We are tricked by hope into starting
companies, beginning books, immigrating to this country and investing
in telecom networks. The challenges turn out to be tougher than we
imagined. Our excessive optimism is exposed. New skills are demanded.
But nothing important was ever begun in a prudential frame of mind.
- David Brooks
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 18, 2007, at 10:50 AM, Mark Brouwer wrote:
> Jim Hurley wrote:
>> On Jul 18, 2007, at 10:24 AM, Mark Brouwer wrote:
>>> Jim Hurley wrote:
>>> :
>>>> To segment these into more historical versions (versus
>>>> what we're going to create in the River project), I thought
>>>> it might be better to preface these with "JTSK_" (for example,
>>>> JTSK_1.0, JTSK_1.1). Let me know if someone has a better
>>>> idea.
>>>
>>> The problem is indeed that *if* we are going to create multiple
>>> deliverables for River we are a bit stuck with the fact we have one
>>> project in JIRA and JIRA has no notion of subprojects. As version
>>> numbers are tied to a project we have a problem, solving this with
>>> prefixing is kind of ugly as are components, etc. and in that case I
>>> would favor to ask for multiple projects we can group, such as
>>> Avalon,
>>> Geronimo, etc. see
>>> https://issues.apache.org/jira/secure/BrowseProjects.jspa .
I'm not proposing multiple deliverables at this time.
>>> Nevertheless I'm not that much in favor of prefixing the version
>>> number
>>> at this point with JTSK_ as we have no clear picture about what the
>>> deliverables will be. And as version numbers can be renamed like
>>> everything else in JIRA with great ease I think it is just fine
>>> to stick
>>> with what is in Bugtraq and change when we have that picture and it
>>> turns out to be a problem.
>> I understand your point -- but these aren't version numbers for
>> *this* project, they are historical version numbers for another
>> release. If we just put them in as "1.0, etc", I think it will be
>> hard
>
> But they are for exactly the same codebase, same beast. A codebase
> that
> is referred to in a lot of worldwide documentation based on the JTSK
> version numbering.
I, personally, don't understand why there would be contention here.
Irrespective of the fact that the initial River codebase is
predominantly
comprised of the Starter Kit codebase -- we're talking about how we
can identify the issues that were filed against the old starter kit
releases
(versus future releases produced by the River project). It seems logical
to me that you'd want to make it clear that these are pre-existing
bugs/rfes
that were originally filed against the starter kit releases (that
we're importing
into the project).
> I could argue that it would have been better in the
> past if there was a clearer separation between the version
> numbering for
> the specs versus the JTSK implementation but I'll refrain from that.
I'm not looking to go there right now.
>> for people to understand what the version numbers that this project
>> has delivered (versus, version numbers present just so that we
>> can track when a bug/rfe had been submitted against years ago).
>> That's the only reason I wanted to preface the historical starter kit
>> version numbers.
>> This also tangentially raises the question on what we want our
>> first version number (that River will deliver) to be, so that we can
>> assign bugs to be fixed in that version. I know this also won't be
>> warmly received, but for now, I'll throw out "AR1" (Apache River 1).
>
> The way I look to it is that River is the continuation of the JTSK
> as developed by Sun and therefore I would expect a logical increase of
> version number just because of the fact that to many the specs are
> referred to as Jini 2 and went hand in hand with the
> implementation. If
> it turns out that from the JTSK new beasts roll into the world I think
> we can start with some fresh version numbering, but that is not the
> case
> yet.
>
> As a party that builds upon the Jini Platform/core/... I want to keep
> something that I can refer to for compatibility and seems a logical
> evolution. Of course if some spec/platform was separated from the
> final
> deliverable the problem would be much less. But I don't believe we
> should start with a version 1. I would say that if the first
> release is
> an almost literal copy of JTSK 2.1 I would still go for 2.2 and
> when the
> real work starts we head for 3.
I guess I was looking to temporarily call it (in JIRA) "AR1" to not have
to dive into the "what are we really going to call the release
(starter kit,
something else?) and what version number is it going to have (0.1, 1.0,
2.2, etc?)". We'll have time to address that - but I'd rather make some
progress now. You've said that Release names in JIRA can be easily
changed - so I'd like to just call it *something* generic and move on.
>
> Otherwise I would suggest to go for 2007.1 (2007.2, 2008.1, 2009.1) (I
> know John McClain will love me for that :-), also a nice indication
> they
> can expect a release this year.
>
> Still this doesn't solve the problem I face with building on top of
> Jini
> where I need something to say as Seven/Service/Product is compliant
> with
> Jini version x.y
> --
> Mark
Any other opinions from committers and folks on the list?
thanks -Jim
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> On Jul 18, 2007, at 10:24 AM, Mark Brouwer wrote:
>> Jim Hurley wrote:
>> :
>>> To segment these into more historical versions (versus
>>> what we're going to create in the River project), I thought
>>> it might be better to preface these with "JTSK_" (for example,
>>> JTSK_1.0, JTSK_1.1). Let me know if someone has a better
>>> idea.
>>
>> The problem is indeed that *if* we are going to create multiple
>> deliverables for River we are a bit stuck with the fact we have one
>> project in JIRA and JIRA has no notion of subprojects. As version
>> numbers are tied to a project we have a problem, solving this with
>> prefixing is kind of ugly as are components, etc. and in that case I
>> would favor to ask for multiple projects we can group, such as Avalon,
>> Geronimo, etc. see
>> https://issues.apache.org/jira/secure/BrowseProjects.jspa .
>>
>> Nevertheless I'm not that much in favor of prefixing the version number
>> at this point with JTSK_ as we have no clear picture about what the
>> deliverables will be. And as version numbers can be renamed like
>> everything else in JIRA with great ease I think it is just fine to stick
>> with what is in Bugtraq and change when we have that picture and it
>> turns out to be a problem.
>
> I understand your point -- but these aren't version numbers for
> *this* project, they are historical version numbers for another
> release. If we just put them in as "1.0, etc", I think it will be hard
But they are for exactly the same codebase, same beast. A codebase that
is referred to in a lot of worldwide documentation based on the JTSK
version numbering. I could argue that it would have been better in the
past if there was a clearer separation between the version numbering for
the specs versus the JTSK implementation but I'll refrain from that.
> for people to understand what the version numbers that this project
> has delivered (versus, version numbers present just so that we
> can track when a bug/rfe had been submitted against years ago).
> That's the only reason I wanted to preface the historical starter kit
> version numbers.
>
> This also tangentially raises the question on what we want our
> first version number (that River will deliver) to be, so that we can
> assign bugs to be fixed in that version. I know this also won't be
> warmly received, but for now, I'll throw out "AR1" (Apache River 1).
The way I look to it is that River is the continuation of the JTSK
as developed by Sun and therefore I would expect a logical increase of
version number just because of the fact that to many the specs are
referred to as Jini 2 and went hand in hand with the implementation. If
it turns out that from the JTSK new beasts roll into the world I think
we can start with some fresh version numbering, but that is not the case
yet.
As a party that builds upon the Jini Platform/core/... I want to keep
something that I can refer to for compatibility and seems a logical
evolution. Of course if some spec/platform was separated from the final
deliverable the problem would be much less. But I don't believe we
should start with a version 1. I would say that if the first release is
an almost literal copy of JTSK 2.1 I would still go for 2.2 and when the
real work starts we head for 3.
Otherwise I would suggest to go for 2007.1 (2007.2, 2008.1, 2009.1) (I
know John McClain will love me for that :-), also a nice indication they
can expect a release this year.
Still this doesn't solve the problem I face with building on top of Jini
where I need something to say as Seven/Service/Product is compliant with
Jini version x.y
--
Mark
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 18, 2007, at 10:24 AM, Mark Brouwer wrote:
> Jim Hurley wrote:
> :
>> To segment these into more historical versions (versus
>> what we're going to create in the River project), I thought
>> it might be better to preface these with "JTSK_" (for example,
>> JTSK_1.0, JTSK_1.1). Let me know if someone has a better
>> idea.
>
> The problem is indeed that *if* we are going to create multiple
> deliverables for River we are a bit stuck with the fact we have one
> project in JIRA and JIRA has no notion of subprojects. As version
> numbers are tied to a project we have a problem, solving this with
> prefixing is kind of ugly as are components, etc. and in that case I
> would favor to ask for multiple projects we can group, such as Avalon,
> Geronimo, etc. see
> https://issues.apache.org/jira/secure/BrowseProjects.jspa .
>
> Nevertheless I'm not that much in favor of prefixing the version
> number
> at this point with JTSK_ as we have no clear picture about what the
> deliverables will be. And as version numbers can be renamed like
> everything else in JIRA with great ease I think it is just fine to
> stick
> with what is in Bugtraq and change when we have that picture and it
> turns out to be a problem.
I understand your point -- but these aren't version numbers for
*this* project, they are historical version numbers for another
release. If we just put them in as "1.0, etc", I think it will be hard
for people to understand what the version numbers that this project
has delivered (versus, version numbers present just so that we
can track when a bug/rfe had been submitted against years ago).
That's the only reason I wanted to preface the historical starter kit
version numbers.
This also tangentially raises the question on what we want our
first version number (that River will deliver) to be, so that we can
assign bugs to be fixed in that version. I know this also won't be
warmly received, but for now, I'll throw out "AR1" (Apache River 1).
-Jim
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> I guess the thing to do is enter those in Jira as versions so
> as we enter the issues we can fill in the "Affects Version/s" field.
Yes
> To segment these into more historical versions (versus
> what we're going to create in the River project), I thought
> it might be better to preface these with "JTSK_" (for example,
> JTSK_1.0, JTSK_1.1). Let me know if someone has a better
> idea.
The problem is indeed that *if* we are going to create multiple
deliverables for River we are a bit stuck with the fact we have one
project in JIRA and JIRA has no notion of subprojects. As version
numbers are tied to a project we have a problem, solving this with
prefixing is kind of ugly as are components, etc. and in that case I
would favor to ask for multiple projects we can group, such as Avalon,
Geronimo, etc. see
https://issues.apache.org/jira/secure/BrowseProjects.jspa .
Nevertheless I'm not that much in favor of prefixing the version number
at this point with JTSK_ as we have no clear picture about what the
deliverables will be. And as version numbers can be renamed like
everything else in JIRA with great ease I think it is just fine to stick
with what is in Bugtraq and change when we have that picture and it
turns out to be a problem.
--
Mark
Re: getting current buglist into JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Jim Hurley wrote:
> To segment these into more historical versions (versus
> what we're going to create in the River project), I thought
> it might be better to preface these with "JTSK_" (for example,
> JTSK_1.0, JTSK_1.1).
Sounds reasonable to me.
- Bob
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 24, 2007, at 4:48 AM, Mark Brouwer wrote:
:
>
> Also I just updated all the issues that I assigned to myself or
> entered
> recently and all current issues have a component now, but some
> things I
> ran into:
>
> 1) all jtsk prefixed versions appeared in the unreleased part of the
> multiple select list (or whatever the name is for such a thing), which
> was confusing. The version should be set to released and if someone
> can
> dig up the official release dates we can enter that information too. I
> took the liberty to set the versions to 'released'. Jim are you
> willing
> to dig up and enter the release dates.
Will do that today.
-Jim
Re: getting current buglist into JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> I realize you ask all these question
> to show us how advanced Bugtraq is for the part that we publicly
> couldn't see ;-)
Just trying to understand how JIRA should be used. As for Bugster
(Bugtraq was the previous tool), I consider it adequate, not advanced.
- Bob
Wiki plans?
Posted by Iain Shigeoka <ia...@messaginglogic.com>.
Hi all,
Are there any concrete plans for the river wiki at apache?
(Specifically an import of other existing content?) I scanned through
the lists and don't see anything relevant. If there is no real plan,
I'm going to start editing ad hoc, and rely on normal wiki workflow
(e.g. chaos with hopefully emergent order) to develop content
organically. Thoughts/comments?
-iain
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 25, 2007, at 2:02 AM, Mark Brouwer wrote:
> :
> Another thing, I saw Jim entering RIVER-37 and it contains information
> not available in
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442766 which
> probably means that Bugtraq has private information. If so this has
> some
> consequences for the committers who have no access to Bugtraq directly
> in their ability to type over the issues, am I right?
There seems to be a field or two that are not available via the
bugs.sun.com
view. That's why I'm going through all the bugs by hand and ensuring
that
the bugs we give to non-Sun committers to enter don't have any
information
in those fields.
-Jim
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> OK, how do you represent something that's fixed but not yet integrated
>>> in a release?
>>
>> The way I worked when exposed to JIRA was to enter the main lines
>> (2.2dev) and milestones (2.2m1, 2.2m3) in JIRA as working versions and
>> at the end we merged them into the release version.
>
> OK, but assuming review-then-commit :), if you've fixed something in
> a branch but not yet committed it up to the trunk, you leave it
> In Progress in JIRA?
Yes, that is what I did with many of the issues in JIRA for Apache
River. It is possible and rather easy to introduce an additional
workflow action to accommodate that properly.
In the Cheiron project I have an action "Resolve Issue, submit(ted) to
JTSK" to indicate something is fixed in the Cheiron view on the JTSK
code while not yet integrated in the Sun/Apache River version.
If a super formal review-then-commit policy is going to be used by the
committers we can arrange for that. I realize you ask all these question
to show us how advanced Bugtraq is for the part that we publicly
couldn't see ;-)
Another thing, I saw Jim entering RIVER-37 and it contains information
not available in
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4442766 which
probably means that Bugtraq has private information. If so this has some
consequences for the committers who have no access to Bugtraq directly
in their ability to type over the issues, am I right?
--
Mark
Re: getting current buglist into JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
>> OK, how do you represent something that's fixed but not yet integrated
>> in a release?
>
> The way I worked when exposed to JIRA was to enter the main lines
> (2.2dev) and milestones (2.2m1, 2.2m3) in JIRA as working versions and
> at the end we merged them into the release version.
OK, but assuming review-then-commit :), if you've fixed something in
a branch but not yet committed it up to the trunk, you leave it
In Progress in JIRA? So you can't indicate fixed (in a branch), only
Resolved = integrated (into trunk)?
> > And represent something's that's fixed in one release
>> but still scheduled for fixing in another release?
> As this is not a change you want to do while you are on your way can you
> indicate how essential you think this is.
For River I would guess not essential at all.
- Bob
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>>> If you use it for scheduling, how do you make sure in the end that
>>> you know what was fixed in a given release?
>>
>> Through the resolution field.
>
> OK, how do you represent something that's fixed but not yet integrated
> in a release?
The way I worked when exposed to JIRA was to enter the main lines
(2.2dev) and milestones (2.2m1, 2.2m3) in JIRA as working versions and
at the end we merged them into the release version. So people could
report against non released versions and in the end we rolled it into
another version.
This can give you some problems though if you use JIRA for internal bug
reporting purposes against working versions, but there are ways to work
around it as in general you don't want to show your internal bugs in
ongoing work in release notes, etc.
> And represent something's that's fixed in one release
> but still scheduled for fixing in another release?
In this case you have a problem due to having no distinction between
planned and fix version/s. There are ways to work around this for which
we must add a field and customize the workflow, but I don't know how the
various JIRA reports will act after such a change.
As this is not a change you want to do while you are on your way can you
indicate how essential you think this is. There is a possibility to just
clone issues for which a link will be created to the original and that
you can utilize to plan/report against a backport e.g.
--
Mark
Re: getting current buglist into JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
>> If you use it for scheduling, how do you make sure in the end that
>> you know what was fixed in a given release?
>
> Through the resolution field.
OK, how do you represent something that's fixed but not yet integrated
in a release? And represent something's that's fixed in one release
but still scheduled for fixing in another release?
- Bob
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Bob Scheifler wrote:
> Mark Brouwer wrote:
>> 2) some people fill in the fix versions field just when they resolve the
>> issue, others use it for scheduling purposes as well so all planned
>> issues show up in the roadmap and release notes reports.
>
> Seems pretty poor that there aren't two distinct fields.
> (Could another field be easily added?)
>> I'm of the
>> latter category and would love to do this, but it requires issue
>> scheduling.
>
> If you use it for scheduling, how do you make sure in the end that
> you know what was fixed in a given release?
Through the resolution field. This represents that state the issue is
in. So an issue with a fixed version/s field set to one or more versions
with a non-final resolution represents a schedule. A final resolution
of fixed e.g. indicates the versions where the issue was fixed.
I hope this answers your first remark too (another field can be created
but I haven't seen that before, which of course doesn't say anything).
--
Mark
Re: getting current buglist into JIRA
Posted by Bob Scheifler <Bo...@Sun.COM>.
Mark Brouwer wrote:
> 2) some people fill in the fix versions field just when they resolve the
> issue, others use it for scheduling purposes as well so all planned
> issues show up in the roadmap and release notes reports.
Seems pretty poor that there aren't two distinct fields.
(Could another field be easily added?)
> I'm of the
> latter category and would love to do this, but it requires issue
> scheduling.
If you use it for scheduling, how do you make sure in the end that
you know what was fixed in a given release?
- Bob
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> Thanks Mark.
>
> So just to clarify -- we should just put in the ascii Bug ID number
> in this field (not a URL to the bug in the Sun Developer bug db)?
Indeed just the number (actually it is a text field), the field will
show a description though with a link that I directed to the Sun
Developer Bug Database and it opens with the Category set to Jini.
If you want also a link in the description that refers to the issue
directly we must enter:
Bugtraq ID [xxxxx|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=xxxxx]
I think it is a little effort and allows us to remove the custom field
one day while keeping a reference, but I consider it your call whether
we should do it.
Also I just updated all the issues that I assigned to myself or entered
recently and all current issues have a component now, but some things I
ran into:
1) all jtsk prefixed versions appeared in the unreleased part of the
multiple select list (or whatever the name is for such a thing), which
was confusing. The version should be set to released and if someone can
dig up the official release dates we can enter that information too. I
took the liberty to set the versions to 'released'. Jim are you willing
to dig up and enter the release dates. We can also archive some versions
for which we don't expect bugs to be reported after the initial upload
as that will reduce some clutter in the versions list (they won't appear
there anymore when entering issues).
2) some people fill in the fix versions field just when they resolve the
issue, others use it for scheduling purposes as well so all planned
issues show up in the roadmap and release notes reports. I'm of the
latter category and would love to do this, but it requires issue
scheduling. As we haven't done or discussed that yet I didn't fill in
the fix versions even while many of the issues are already fixed in my
workspace as I don't know in what release we are going to fix them.
Please opinions about the process we should use for 'fix version/s' field.
3) ServiceUI issues, Gregg and/or Bill ... ?
--
Mark
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
Thanks Mark.
So just to clarify -- we should just put in the ascii Bug ID number
in this field (not a URL to the bug in the Sun Developer bug db)?
On Jul 23, 2007, at 4:51 AM, Mark Brouwer wrote:
> Mark Brouwer wrote:
>
>> So I'll create the custom field, but we can still decide whether
>> we also
>> want to include the link to the public view on Bugtraq in the
>> description as I showed in my previous email. It ain't that much work
>> and when we disable the Bugtraq field we still have the link in the
>> description.
>
> A custom field called 'Bugtraq ID' has been created that can be
> searched
> and that is only active for the River project. It shows up under the
> custom fields when you select project River in the 'find' function.
> --
> Mark
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Mark Brouwer wrote:
> So I'll create the custom field, but we can still decide whether we also
> want to include the link to the public view on Bugtraq in the
> description as I showed in my previous email. It ain't that much work
> and when we disable the Bugtraq field we still have the link in the
> description.
A custom field called 'Bugtraq ID' has been created that can be searched
and that is only active for the River project. It shows up under the
custom fields when you select project River in the 'find' function.
--
Mark
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Fred Oliver wrote:
>
> The numbering scheme with the prefix sounds reasonable to me as well.
>
> I'm a bit more inclined to collapse all of the Sun versions into a
> single value for JIRA, such as "pre-apache". Since prior versions of
> Jini are no longer available for download for browsing or diffs, I see
> little value in being more explicit. (I discount 1.2.x as not
> particularly relevant.)
Indeed there is value in collapsing them especially if we no longer
support that version, but for me it is a bit too soon to merge them all
at this stage in the life of River. Maybe we also have to go through all
the issues and see what is still relevant in the context of River.
JIRA supports merging versions (collapsing) so we can do it at a later
date, we are getting good at making decisions at a later data ;-)
> Since bugtraq IDs should eventually join old Sun version numbers in
> obscurity, I would prefer not to create any long-lived field for them.
A very valid point. Still I think there is some value in having a custom
field. I agree that when the moment is there we should be able to get
rid of it and JIRA supports disabling a field so it no longer shows up
in the issue screens but still remains a field you can perform queries
over (don't know for sure though). Eventually we can also remove the
field but then data will be lost forever (this one I know for sure).
So I'll create the custom field, but we can still decide whether we also
want to include the link to the public view on Bugtraq in the
description as I showed in my previous email. It ain't that much work
and when we disable the Bugtraq field we still have the link in the
description.
> A placeholder token of "AR1" for the next release is also reasonable.
I'm fine with a placeholder of AR1 with a description to the version
number that it is a temporary version number to be changed for final
release (this description will show up at various places in JIRA such as
roadmap, release notes, etc.).
--
Mark
Re: getting current buglist into JIRA
Posted by Fred Oliver <Fr...@Sun.COM>.
The numbering scheme with the prefix sounds reasonable to me as well.
I'm a bit more inclined to collapse all of the Sun versions into a
single value for JIRA, such as "pre-apache". Since prior versions of
Jini are no longer available for download for browsing or diffs, I see
little value in being more explicit. (I discount 1.2.x as not
particularly relevant.)
Since bugtraq IDs should eventually join old Sun version numbers in
obscurity, I would prefer not to create any long-lived field for them.
A placeholder token of "AR1" for the next release is also reasonable.
Fred
Jim Hurley wrote:
> On Jul 17, 2007, at 7:59 AM, Jim Hurley wrote:
>> On Jul 17, 2007, at 4:25 AM, Mark Brouwer wrote:
>> :
>>> You will also need all or at least some
>>> historical versions in JIRA to assign the version the issue was reported
>>> against.
>>
>> Ah - good point. I'll put those in as well.
>
> Going through our open bug/rfe list, it looks like we
> have issues that were first reported against the
> starter kit, versions:
> 1.0
> 1.1
> 1.2
> 2.0
> 2.0_001
> 2.0_002
> 2.0.1
> 2.0.2
> 2.1
>
> I guess the thing to do is enter those in Jira as versions so
> as we enter the issues we can fill in the "Affects Version/s" field.
>
> To segment these into more historical versions (versus
> what we're going to create in the River project), I thought
> it might be better to preface these with "JTSK_" (for example,
> JTSK_1.0, JTSK_1.1). Let me know if someone has a better
> idea.
>
> thanks -Jim
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 17, 2007, at 7:59 AM, Jim Hurley wrote:
> On Jul 17, 2007, at 4:25 AM, Mark Brouwer wrote:
> :
>> You will also need all or at least some
>> historical versions in JIRA to assign the version the issue was
>> reported
>> against.
>
> Ah - good point. I'll put those in as well.
Going through our open bug/rfe list, it looks like we
have issues that were first reported against the
starter kit, versions:
1.0
1.1
1.2
2.0
2.0_001
2.0_002
2.0.1
2.0.2
2.1
I guess the thing to do is enter those in Jira as versions so
as we enter the issues we can fill in the "Affects Version/s" field.
To segment these into more historical versions (versus
what we're going to create in the River project), I thought
it might be better to preface these with "JTSK_" (for example,
JTSK_1.0, JTSK_1.1). Let me know if someone has a better
idea.
thanks -Jim
Re: getting current buglist into JIRA
Posted by Jim Hurley <Ji...@Sun.COM>.
On Jul 17, 2007, at 4:25 AM, Mark Brouwer wrote:
:
> You will also need all or at least some
> historical versions in JIRA to assign the version the issue was
> reported
> against.
Ah - good point. I'll put those in as well.
> When adding bugs I think there is value in having a reference to the
> Bugtraq ID. I can add a custom field just for the River project, or we
> can decide to add a link to each issue we enter as in time
> hopefully the
> Bugtraq id will loose its value.
>
> Bugtraq ID
> [xxxxx|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6430026]
>
> Which will create the text 'Bugtraq ID xxxxx' where xxxxx is a link to
> the Sun bug database.
I like the bugtraq id/link idea. Thanks.
-Jim
Re: getting current buglist into JIRA
Posted by Mark Brouwer <ma...@cheiron.org>.
Jim Hurley wrote:
> I'm not sure what the proper procedure is here (so
> please advise). If someone objects, please speak
> up. Otherwise, I'm not sure if we need to call for a
> vote, or just proceed if there's no objections?
I'm in favor of proceeding until someone objects. Based on a quick look
of the committer permissions for JIRA it seems you will be able to add
the components yourself. You will also need all or at least some
historical versions in JIRA to assign the version the issue was reported
against.
When adding bugs I think there is value in having a reference to the
Bugtraq ID. I can add a custom field just for the River project, or we
can decide to add a link to each issue we enter as in time hopefully the
Bugtraq id will loose its value.
Bugtraq ID
[xxxxx|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6430026]
Which will create the text 'Bugtraq ID xxxxx' where xxxxx is a link to
the Sun bug database.
--
Mark