Use JIRA's "Fix Version/s" in the future?

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Use JIRA's "Fix Version/s" in the future?

marcelstoer
This has been bugging me for a while but I never had the nerve to ask here.
It would make the life of many Jenkins users so much easier if commiters
used JIRA's "Fix Version/s" field. Right now you'd have to parse
changelogs for possibly lots of releases to really find out in which
version a particular issue was fixed.

Is there a particular reason for not using it?

Cheers,

Context:
KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
fixed in 1.397. I wanted to see if this information was consistent with
the value in the "Fix Version/s" field and saw that it was empty. I
first thought it was a simple glitch and tried to update it myself. Then
I noticed that there are no versions configured in JIRA at all.

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Ulli Hafner
On 02/07/2011 10:08 PM, Marcel Stör wrote:

> This has been bugging me for a while but I never had the nerve to ask
> here.
> It would make the life of many Jenkins users so much easier if
> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
> parse changelogs for possibly lots of releases to really find out in
> which version a particular issue was fixed.
>
> Is there a particular reason for not using it?
>
> Cheers,
>
> Context:
> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
> fixed in 1.397. I wanted to see if this information was consistent
> with the value in the "Fix Version/s" field and saw that it was empty.
> I first thought it was a simple glitch and tried to update it myself.
> Then I noticed that there are no versions configured in JIRA at all.
>

I think we already talked about that quite a time ago when we discussed
the splitting of Jira into Core and Plugins... However, we did not find
a  solution yet ;-)

See:
http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html

Ulli
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

marcelstoer
On 07.02.11 23:14, Ulli Hafner wrote:

> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>> This has been bugging me for a while but I never had the nerve to ask
>> here.
>> It would make the life of many Jenkins users so much easier if
>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>> parse changelogs for possibly lots of releases to really find out in
>> which version a particular issue was fixed.
>>
>> Is there a particular reason for not using it?
>>
>> Cheers,
>>
>> Context:
>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>> fixed in 1.397. I wanted to see if this information was consistent
>> with the value in the "Fix Version/s" field and saw that it was empty.
>> I first thought it was a simple glitch and tried to update it myself.
>> Then I noticed that there are no versions configured in JIRA at all.
>>
>
> I think we already talked about that quite a time ago when we discussed
> the splitting of Jira into Core and Plugins... However, we did not find
> a solution yet ;-)
>
> See:
> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html

Thanks for digging this up.

Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
(splitting into three projects) never even saw daylight?!
If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I
see no Jenkins Plugins project and not Jenkins Infrastructure project
:-( To me the issue list still looks like what Andrew described as "such
a mess".
He also said "stop letting the perfect be the enemy of the good and get
things cleaned up". From reading that old thread I conclude that this
was exactly what eventually happened?

Cheers,

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Erik Ramfelt
Isnt one of the problems with fix versions are that they are project
based? So if we are going to have one plugin project (or as today one
project for everything), then those have to share release versions.
This may confuse users when reporting new issues for plugins as there
will be tons of different version number (some may even be future
versions). I guess one way would be to have one project per plugin but
that might be a big administrative task to fix.

Regards
//Erik
Ps. Im no JIRA expert so i may be wrong here


On Tue, Feb 8, 2011 at 20:46, Marcel Stör <[hidden email]> wrote:

> On 07.02.11 23:14, Ulli Hafner wrote:
>>
>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>
>>> This has been bugging me for a while but I never had the nerve to ask
>>> here.
>>> It would make the life of many Jenkins users so much easier if
>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>> parse changelogs for possibly lots of releases to really find out in
>>> which version a particular issue was fixed.
>>>
>>> Is there a particular reason for not using it?
>>>
>>> Cheers,
>>>
>>> Context:
>>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>>> fixed in 1.397. I wanted to see if this information was consistent
>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>> I first thought it was a simple glitch and tried to update it myself.
>>> Then I noticed that there are no versions configured in JIRA at all.
>>>
>>
>> I think we already talked about that quite a time ago when we discussed
>> the splitting of Jira into Core and Plugins... However, we did not find
>> a solution yet ;-)
>>
>> See:
>>
>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
>
> Thanks for digging this up.
>
> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
> (splitting into three projects) never even saw daylight?!
> If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
> the issue list still looks like what Andrew described as "such a mess".
> He also said "stop letting the perfect be the enemy of the good and get
> things cleaned up". From reading that old thread I conclude that this was
> exactly what eventually happened?
>
> Cheers,
>
> --
> Marcel Stör, http://www.frightanic.com
> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Arnaud Héritier-2
no it's right
As Jira cannot handle a version per component if we use versions in
only one jira project we'll have to define versions for all components
core-1.2.3
plugin-xxx-2.4.3
....
Which is almost useless
The only solution to cleanup that is the split in various projects.
For that we need to define a permissions scheme and who will have
necessary rights to administer projects and manage versions and
components in them.
I think that for now it is restricted to a very little number of
people (and automated by the kk's bot on IRC)
Thus the question is, do we need to update the bot to allow it to
manage multi-projects and then split the big project if we want to
cleanup without adding to much administrative tasks.



On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt <[hidden email]> wrote:

> Isnt one of the problems with fix versions are that they are project
> based? So if we are going to have one plugin project (or as today one
> project for everything), then those have to share release versions.
> This may confuse users when reporting new issues for plugins as there
> will be tons of different version number (some may even be future
> versions). I guess one way would be to have one project per plugin but
> that might be a big administrative task to fix.
>
> Regards
> //Erik
> Ps. Im no JIRA expert so i may be wrong here
>
>
> On Tue, Feb 8, 2011 at 20:46, Marcel Stör <[hidden email]> wrote:
>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>
>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>
>>>> This has been bugging me for a while but I never had the nerve to ask
>>>> here.
>>>> It would make the life of many Jenkins users so much easier if
>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>> parse changelogs for possibly lots of releases to really find out in
>>>> which version a particular issue was fixed.
>>>>
>>>> Is there a particular reason for not using it?
>>>>
>>>> Cheers,
>>>>
>>>> Context:
>>>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>> I first thought it was a simple glitch and tried to update it myself.
>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>
>>>
>>> I think we already talked about that quite a time ago when we discussed
>>> the splitting of Jira into Core and Plugins... However, we did not find
>>> a solution yet ;-)
>>>
>>> See:
>>>
>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
>>
>> Thanks for digging this up.
>>
>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>> (splitting into three projects) never even saw daylight?!
>> If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
>> the issue list still looks like what Andrew described as "such a mess".
>> He also said "stop letting the perfect be the enemy of the good and get
>> things cleaned up". From reading that old thread I conclude that this was
>> exactly what eventually happened?
>>
>> Cheers,
>>
>> --
>> Marcel Stör, http://www.frightanic.com
>> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
>> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

marcelstoer
On 08.02.11 21:05, Arnaud Héritier wrote:
> no it's right
> As Jira cannot handle a version per component if we use versions in
> only one jira project we'll have to define versions for all components
> core-1.2.3
> plugin-xxx-2.4.3
> ....
> Which is almost useless

Again, it doesn't have to be perfect to be better than it is now.
Why no split as proposed by Andrew and use versions only for core at the
moment? That would IMO be a huge leap forward.

> The only solution to cleanup that is the split in various projects.
> For that we need to define a permissions scheme and who will have
> necessary rights to administer projects and manage versions and
> components in them.
> I think that for now it is restricted to a very little number of
> people (and automated by the kk's bot on IRC)
> Thus the question is, do we need to update the bot to allow it to
> manage multi-projects and then split the big project if we want to
> cleanup without adding to much administrative tasks.
>
>
>
> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
>> Isnt one of the problems with fix versions are that they are project
>> based? So if we are going to have one plugin project (or as today one
>> project for everything), then those have to share release versions.
>> This may confuse users when reporting new issues for plugins as there
>> will be tons of different version number (some may even be future
>> versions). I guess one way would be to have one project per plugin but
>> that might be a big administrative task to fix.
>>
>> Regards
>> //Erik
>> Ps. Im no JIRA expert so i may be wrong here
>>
>>
>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
>>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>>
>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>>
>>>>> This has been bugging me for a while but I never had the nerve to ask
>>>>> here.
>>>>> It would make the life of many Jenkins users so much easier if
>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>>> parse changelogs for possibly lots of releases to really find out in
>>>>> which version a particular issue was fixed.
>>>>>
>>>>> Is there a particular reason for not using it?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Context:
>>>>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>>> I first thought it was a simple glitch and tried to update it myself.
>>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>>
>>>>
>>>> I think we already talked about that quite a time ago when we discussed
>>>> the splitting of Jira into Core and Plugins... However, we did not find
>>>> a solution yet ;-)
>>>>
>>>> See:
>>>>
>>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
>>>
>>> Thanks for digging this up.
>>>
>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>>> (splitting into three projects) never even saw daylight?!
>>> If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
>>> the issue list still looks like what Andrew described as "such a mess".
>>> He also said "stop letting the perfect be the enemy of the good and get
>>> things cleaned up". From reading that old thread I conclude that this was
>>> exactly what eventually happened?
>>>
>>> Cheers,
>>>
>>> --
>>> Marcel Stör, http://www.frightanic.com
>>> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
>>> O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org
>>>
>>


--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Arnaud Héritier-2
Perhaps, because the team only uses the bot to administrate Jira ?

On Tue, Feb 8, 2011 at 9:16 PM, Marcel Stör <[hidden email]> wrote:

> On 08.02.11 21:05, Arnaud Héritier wrote:
>>
>> no it's right
>> As Jira cannot handle a version per component if we use versions in
>> only one jira project we'll have to define versions for all components
>> core-1.2.3
>> plugin-xxx-2.4.3
>> ....
>> Which is almost useless
>
> Again, it doesn't have to be perfect to be better than it is now.
> Why no split as proposed by Andrew and use versions only for core at the
> moment? That would IMO be a huge leap forward.
>
>> The only solution to cleanup that is the split in various projects.
>> For that we need to define a permissions scheme and who will have
>> necessary rights to administer projects and manage versions and
>> components in them.
>> I think that for now it is restricted to a very little number of
>> people (and automated by the kk's bot on IRC)
>> Thus the question is, do we need to update the bot to allow it to
>> manage multi-projects and then split the big project if we want to
>> cleanup without adding to much administrative tasks.
>>
>>
>>
>> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
>>>
>>> Isnt one of the problems with fix versions are that they are project
>>> based? So if we are going to have one plugin project (or as today one
>>> project for everything), then those have to share release versions.
>>> This may confuse users when reporting new issues for plugins as there
>>> will be tons of different version number (some may even be future
>>> versions). I guess one way would be to have one project per plugin but
>>> that might be a big administrative task to fix.
>>>
>>> Regards
>>> //Erik
>>> Ps. Im no JIRA expert so i may be wrong here
>>>
>>>
>>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
>>>>
>>>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>>>
>>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>>>
>>>>>> This has been bugging me for a while but I never had the nerve to ask
>>>>>> here.
>>>>>> It would make the life of many Jenkins users so much easier if
>>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>>>> parse changelogs for possibly lots of releases to really find out in
>>>>>> which version a particular issue was fixed.
>>>>>>
>>>>>> Is there a particular reason for not using it?
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Context:
>>>>>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>>>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>>>> I first thought it was a simple glitch and tried to update it myself.
>>>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>>>
>>>>>
>>>>> I think we already talked about that quite a time ago when we discussed
>>>>> the splitting of Jira into Core and Plugins... However, we did not find
>>>>> a solution yet ;-)
>>>>>
>>>>> See:
>>>>>
>>>>>
>>>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
>>>>
>>>> Thanks for digging this up.
>>>>
>>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>>>> (splitting into three projects) never even saw daylight?!
>>>> If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I
>>>> see
>>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To
>>>> me
>>>> the issue list still looks like what Andrew described as "such a mess".
>>>> He also said "stop letting the perfect be the enemy of the good and get
>>>> things cleaned up". From reading that old thread I conclude that this
>>>> was
>>>> exactly what eventually happened?
>>>>
>>>> Cheers,
>>>>
>>>> --
>>>> Marcel Stör, http://www.frightanic.com
>>>> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
>>>> O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org
>>>>
>>>
>
>
> --
> Marcel Stör, http://www.frightanic.com
> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
> O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
>
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

John Borghi
In reply to this post by Arnaud Héritier-2
On 2/8/2011 12:05 PM, Arnaud Héritier wrote:
> no it's right
> As Jira cannot handle a version per component if we use versions in
> only one jira project we'll have to define versions for all components
> core-1.2.3
> plugin-xxx-2.4.3
> ....
> Which is almost useless

I use this approach internally, and it is pretty successful, though our group is not so large as Jenkins. We have only about 30-40 components.  We do need to follow strict naming conventions for the component versions, and it is somewhat a chore to edit/select them because they are all cobbled in a single flat list, but the resulting info associated with any bug is pretty clear, along with finding what was fixed in what version of a component.  Not perfect, but maybe better than no version info...?

> The only solution to cleanup that is the split in various projects.
> For that we need to define a permissions scheme and who will have
> necessary rights to administer projects and manage versions and
> components in them.
> I think that for now it is restricted to a very little number of
> people (and automated by the kk's bot on IRC)
> Thus the question is, do we need to update the bot to allow it to
> manage multi-projects and then split the big project if we want to
> cleanup without adding to much administrative tasks.
>
>
>
> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
>> Isnt one of the problems with fix versions are that they are project
>> based? So if we are going to have one plugin project (or as today one
>> project for everything), then those have to share release versions.
>> This may confuse users when reporting new issues for plugins as there
>> will be tons of different version number (some may even be future
>> versions). I guess one way would be to have one project per plugin but
>> that might be a big administrative task to fix.
>>
>> Regards
>> //Erik
>> Ps. Im no JIRA expert so i may be wrong here
>>
>>
>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
>>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>> This has been bugging me for a while but I never had the nerve to ask
>>>>> here.
>>>>> It would make the life of many Jenkins users so much easier if
>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>>> parse changelogs for possibly lots of releases to really find out in
>>>>> which version a particular issue was fixed.
>>>>>
>>>>> Is there a particular reason for not using it?
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Context:
>>>>> KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
>>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>>> I first thought it was a simple glitch and tried to update it myself.
>>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>>
>>>> I think we already talked about that quite a time ago when we discussed
>>>> the splitting of Jira into Core and Plugins... However, we did not find
>>>> a solution yet ;-)
>>>>
>>>> See:
>>>>
>>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
>>> Thanks for digging this up.
>>>
>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>>> (splitting into three projects) never even saw daylight?!
>>> If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
>>> the issue list still looks like what Andrew described as "such a mess".
>>> He also said "stop letting the perfect be the enemy of the good and get
>>> things cleaned up". From reading that old thread I conclude that this was
>>> exactly what eventually happened?
>>>
>>> Cheers,
>>>
>>> --
>>> Marcel Stör, http://www.frightanic.com
>>> Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
>>> O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org
>>>

Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Richard Bywater
Perhaps we could target the Fix for Versions to the Core as this presumably would have the biggest impact on users (i.e. plugins are easy to move in and out and you can easily find info about them on the Wiki pages -- hopefully :) -- whereas core tends to be a little harder to know whats in and out due to the sheer volume of changes)

Richard.

2011/2/9 John Borghi <[hidden email]>
On 2/8/2011 12:05 PM, Arnaud Héritier wrote:
no it's right
As Jira cannot handle a version per component if we use versions in
only one jira project we'll have to define versions for all components
core-1.2.3
plugin-xxx-2.4.3
....
Which is almost useless

I use this approach internally, and it is pretty successful, though our group is not so large as Jenkins. We have only about 30-40 components.  We do need to follow strict naming conventions for the component versions, and it is somewhat a chore to edit/select them because they are all cobbled in a single flat list, but the resulting info associated with any bug is pretty clear, along with finding what was fixed in what version of a component.  Not perfect, but maybe better than no version info...?


The only solution to cleanup that is the split in various projects.
For that we need to define a permissions scheme and who will have
necessary rights to administer projects and manage versions and
components in them.
I think that for now it is restricted to a very little number of
people (and automated by the kk's bot on IRC)
Thus the question is, do we need to update the bot to allow it to
manage multi-projects and then split the big project if we want to
cleanup without adding to much administrative tasks.



On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
Isnt one of the problems with fix versions are that they are project
based? So if we are going to have one plugin project (or as today one
project for everything), then those have to share release versions.
This may confuse users when reporting new issues for plugins as there
will be tons of different version number (some may even be future
versions). I guess one way would be to have one project per plugin but
that might be a big administrative task to fix.

Regards
//Erik
Ps. Im no JIRA expert so i may be wrong here


On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
On 07.02.11 23:14, Ulli Hafner wrote:
On 02/07/2011 10:08 PM, Marcel Stör wrote:
This has been bugging me for a while but I never had the nerve to ask
here.
It would make the life of many Jenkins users so much easier if
commiters used JIRA's "Fix Version/s" field. Right now you'd have to
parse changelogs for possibly lots of releases to really find out in
which version a particular issue was fixed.

Is there a particular reason for not using it?

Cheers,

Context:
KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
fixed in 1.397. I wanted to see if this information was consistent
with the value in the "Fix Version/s" field and saw that it was empty.
I first thought it was a simple glitch and tried to update it myself.
Then I noticed that there are no versions configured in JIRA at all.

I think we already talked about that quite a time ago when we discussed
the splitting of Jira into Core and Plugins... However, we did not find
a solution yet ;-)

See:

http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html
Thanks for digging this up.

Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
(splitting into three projects) never even saw daylight?!
If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
the issue list still looks like what Andrew described as "such a mess".
He also said "stop letting the perfect be the enemy of the good and get
things cleaned up". From reading that old thread I conclude that this was
exactly what eventually happened?

Cheers,

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org



Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Andrew Bayer
In reply to this post by marcelstoer
Honestly? The only reason is because it hasn't happened. There's no philosophical reason - it's just that no one has done it. No excuse but being busy and lazy. =)

A.

On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör <[hidden email]> wrote:
On 08.02.11 21:05, Arnaud Héritier wrote:
no it's right
As Jira cannot handle a version per component if we use versions in
only one jira project we'll have to define versions for all components
core-1.2.3
plugin-xxx-2.4.3
....
Which is almost useless

Again, it doesn't have to be perfect to be better than it is now.
Why no split as proposed by Andrew and use versions only for core at the moment? That would IMO be a huge leap forward.


The only solution to cleanup that is the split in various projects.
For that we need to define a permissions scheme and who will have
necessary rights to administer projects and manage versions and
components in them.
I think that for now it is restricted to a very little number of
people (and automated by the kk's bot on IRC)
Thus the question is, do we need to update the bot to allow it to
manage multi-projects and then split the big project if we want to
cleanup without adding to much administrative tasks.



On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
Isnt one of the problems with fix versions are that they are project
based? So if we are going to have one plugin project (or as today one
project for everything), then those have to share release versions.
This may confuse users when reporting new issues for plugins as there
will be tons of different version number (some may even be future
versions). I guess one way would be to have one project per plugin but
that might be a big administrative task to fix.

Regards
//Erik
Ps. Im no JIRA expert so i may be wrong here


On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
On 07.02.11 23:14, Ulli Hafner wrote:

On 02/07/2011 10:08 PM, Marcel Stör wrote:

This has been bugging me for a while but I never had the nerve to ask
here.
It would make the life of many Jenkins users so much easier if
commiters used JIRA's "Fix Version/s" field. Right now you'd have to
parse changelogs for possibly lots of releases to really find out in
which version a particular issue was fixed.

Is there a particular reason for not using it?

Cheers,

Context:
KK commented http://issues.jenkins-ci.org/browse/JENKINS-7745 as being
fixed in 1.397. I wanted to see if this information was consistent
with the value in the "Fix Version/s" field and saw that it was empty.
I first thought it was a simple glitch and tried to update it myself.
Then I noticed that there are no versions configured in JIRA at all.


I think we already talked about that quite a time ago when we discussed
the splitting of Jira into Core and Plugins... However, we did not find
a solution yet ;-)

See:

http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Hudson-Hudson-Plugins-and-Hudson-Infrastructure-tp1592745p1592745.html

Thanks for digging this up.

Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
(splitting into three projects) never even saw daylight?!
If I check http://issues.jenkins-ci.org/secure/BrowseProjects.jspa#all I see
no Jenkins Plugins project and not Jenkins Infrastructure project :-( To me
the issue list still looks like what Andrew described as "such a mess".
He also said "stop letting the perfect be the enemy of the good and get
things cleaned up". From reading that old thread I conclude that this was
exactly what eventually happened?

Cheers,

--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O<  ascii ribbon campaign - stop html mail - www.asciiribbon.org




--
Marcel Stör, http://www.frightanic.com
Couchsurfing: http://www.couchsurfing.com/people/marcelstoer
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

mlb5000-2
Having administered our Jira instance for going on almost 2 years,
it's very clear that Jira is project-centric, not component-centric.
Projects can have components but (as stated above) projects are
versioned, not components.  When you release a version all the
components go with it (from Jira's standpoint).  I personally like the
way Atlassian has their stuff set up for plugin developers here:
https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
plugin has its own project in that Jira instance so users can report
issues with that plugin directly to the developer.  Conceivably
Jenkins proper (i.e. core) would have a project of its own, along with
each of the plugins.  I think overall this would make things much
easier to manage, especially if you have named owners/maintainers of
specific plugins.  Issues could actually be slated for a particular
release, and plugin developers would be able to keep track of their
own release plans and keep their users informed.  There would be a
clear place for everything to go and you can still move issues back
and forth between projects if need be (like components change today).

I'd be happy to help with this if anyone is interested.  I'm sure the
improved organization will save me a ton of time while weeding out the
bug backlog.  However, this is NOT something I can do currently
because I don't have admin privileges...

On Feb 8, 3:52 pm, Andrew Bayer <[hidden email]> wrote:

> Honestly? The only reason is because it hasn't happened. There's no
> philosophical reason - it's just that no one has done it. No excuse but
> being busy and lazy. =)
>
> A.
>
>
>
>
>
>
>
> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör <[hidden email]> wrote:
> > On 08.02.11 21:05, Arnaud Héritier wrote:
>
> >> no it's right
> >> As Jira cannot handle a version per component if we use versions in
> >> only one jira project we'll have to define versions for all components
> >> core-1.2.3
> >> plugin-xxx-2.4.3
> >> ....
> >> Which is almost useless
>
> > Again, it doesn't have to be perfect to be better than it is now.
> > Why no split as proposed by Andrew and use versions only for core at the
> > moment? That would IMO be a huge leap forward.
>
> >  The only solution to cleanup that is the split in various projects.
> >> For that we need to define a permissions scheme and who will have
> >> necessary rights to administer projects and manage versions and
> >> components in them.
> >> I think that for now it is restricted to a very little number of
> >> people (and automated by the kk's bot on IRC)
> >> Thus the question is, do we need to update the bot to allow it to
> >> manage multi-projects and then split the big project if we want to
> >> cleanup without adding to much administrative tasks.
>
> >> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>  wrote:
>
> >>> Isnt one of the problems with fix versions are that they are project
> >>> based? So if we are going to have one plugin project (or as today one
> >>> project for everything), then those have to share release versions.
> >>> This may confuse users when reporting new issues for plugins as there
> >>> will be tons of different version number (some may even be future
> >>> versions). I guess one way would be to have one project per plugin but
> >>> that might be a big administrative task to fix.
>
> >>> Regards
> >>> //Erik
> >>> Ps. Im no JIRA expert so i may be wrong here
>
> >>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>  wrote:
>
> >>>> On 07.02.11 23:14, Ulli Hafner wrote:
>
> >>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>
> >>>>>> This has been bugging me for a while but I never had the nerve to ask
> >>>>>> here.
> >>>>>> It would make the life of many Jenkins users so much easier if
> >>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
> >>>>>> parse changelogs for possibly lots of releases to really find out in
> >>>>>> which version a particular issue was fixed.
>
> >>>>>> Is there a particular reason for not using it?
>
> >>>>>> Cheers,
>
> >>>>>> Context:
> >>>>>> KK commentedhttp://issues.jenkins-ci.org/browse/JENKINS-7745as
> >>>>>> being
> >>>>>> fixed in 1.397. I wanted to see if this information was consistent
> >>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
> >>>>>> I first thought it was a simple glitch and tried to update it myself.
> >>>>>> Then I noticed that there are no versions configured in JIRA at all.
>
> >>>>> I think we already talked about that quite a time ago when we discussed
> >>>>> the splitting of Jira into Core and Plugins... However, we did not find
> >>>>> a solution yet ;-)
>
> >>>>> See:
>
> >>>>>http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Huds...
>
> >>>> Thanks for digging this up.
>
> >>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
> >>>> (splitting into three projects) never even saw daylight?!
> >>>> If I checkhttp://issues.jenkins-ci.org/secure/BrowseProjects.jspa#allIsee
> >>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To
> >>>> me
> >>>> the issue list still looks like what Andrew described as "such a mess".
> >>>> He also said "stop letting the perfect be the enemy of the good and get
> >>>> things cleaned up". From reading that old thread I conclude that this
> >>>> was
> >>>> exactly what eventually happened?
>
> >>>> Cheers,
>
> >>>> --
> >>>> Marcel Stör,http://www.frightanic.com
> >>>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
> >>>> O<  ascii ribbon campaign - stop html mail -www.asciiribbon.org
>
> > --
> > Marcel Stör,http://www.frightanic.com
> > Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
> > O< ascii ribbon campaign - stop html mail -www.asciiribbon.org
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

J. David Beutel-2
I agree that our JIRA would be better with a project per plugin.  The
Grails JIRA uses components for its plugins, and its version list has
become so long that it's very difficult to find the right
component-version combination on that list when submitting an issue on a
Grails plugin.


On 2011-02-08 18:22 , mlb5000 wrote:

> Having administered our Jira instance for going on almost 2 years,
> it's very clear that Jira is project-centric, not component-centric.
> Projects can have components but (as stated above) projects are
> versioned, not components.  When you release a version all the
> components go with it (from Jira's standpoint).  I personally like the
> way Atlassian has their stuff set up for plugin developers here:
> https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
> plugin has its own project in that Jira instance so users can report
> issues with that plugin directly to the developer.  Conceivably
> Jenkins proper (i.e. core) would have a project of its own, along with
> each of the plugins.  I think overall this would make things much
> easier to manage, especially if you have named owners/maintainers of
> specific plugins.  Issues could actually be slated for a particular
> release, and plugin developers would be able to keep track of their
> own release plans and keep their users informed.  There would be a
> clear place for everything to go and you can still move issues back
> and forth between projects if need be (like components change today).
>
> I'd be happy to help with this if anyone is interested.  I'm sure the
> improved organization will save me a ton of time while weeding out the
> bug backlog.  However, this is NOT something I can do currently
> because I don't have admin privileges...
>
> On Feb 8, 3:52 pm, Andrew Bayer<[hidden email]>  wrote:
>> Honestly? The only reason is because it hasn't happened. There's no
>> philosophical reason - it's just that no one has done it. No excuse but
>> being busy and lazy. =)
>>
>> A.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör<[hidden email]>  wrote:
>>> On 08.02.11 21:05, Arnaud Héritier wrote:
>>>> no it's right
>>>> As Jira cannot handle a version per component if we use versions in
>>>> only one jira project we'll have to define versions for all components
>>>> core-1.2.3
>>>> plugin-xxx-2.4.3
>>>> ....
>>>> Which is almost useless
>>> Again, it doesn't have to be perfect to be better than it is now.
>>> Why no split as proposed by Andrew and use versions only for core at the
>>> moment? That would IMO be a huge leap forward.
>>>   The only solution to cleanup that is the split in various projects.
>>>> For that we need to define a permissions scheme and who will have
>>>> necessary rights to administer projects and manage versions and
>>>> components in them.
>>>> I think that for now it is restricted to a very little number of
>>>> people (and automated by the kk's bot on IRC)
>>>> Thus the question is, do we need to update the bot to allow it to
>>>> manage multi-projects and then split the big project if we want to
>>>> cleanup without adding to much administrative tasks.
>>>> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>    wrote:
>>>>> Isnt one of the problems with fix versions are that they are project
>>>>> based? So if we are going to have one plugin project (or as today one
>>>>> project for everything), then those have to share release versions.
>>>>> This may confuse users when reporting new issues for plugins as there
>>>>> will be tons of different version number (some may even be future
>>>>> versions). I guess one way would be to have one project per plugin but
>>>>> that might be a big administrative task to fix.
>>>>> Regards
>>>>> //Erik
>>>>> Ps. Im no JIRA expert so i may be wrong here
>>>>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>    wrote:
>>>>>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>>>>> This has been bugging me for a while but I never had the nerve to ask
>>>>>>>> here.
>>>>>>>> It would make the life of many Jenkins users so much easier if
>>>>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>>>>>> parse changelogs for possibly lots of releases to really find out in
>>>>>>>> which version a particular issue was fixed.
>>>>>>>> Is there a particular reason for not using it?
>>>>>>>> Cheers,
>>>>>>>> Context:
>>>>>>>> KK commentedhttp://issues.jenkins-ci.org/browse/JENKINS-7745as
>>>>>>>> being
>>>>>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>>>>>> I first thought it was a simple glitch and tried to update it myself.
>>>>>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>>>> I think we already talked about that quite a time ago when we discussed
>>>>>>> the splitting of Jira into Core and Plugins... However, we did not find
>>>>>>> a solution yet ;-)
>>>>>>> See:
>>>>>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Huds...
>>>>>> Thanks for digging this up.
>>>>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>>>>>> (splitting into three projects) never even saw daylight?!
>>>>>> If I checkhttp://issues.jenkins-ci.org/secure/BrowseProjects.jspa#allIsee
>>>>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To
>>>>>> me
>>>>>> the issue list still looks like what Andrew described as "such a mess".
>>>>>> He also said "stop letting the perfect be the enemy of the good and get
>>>>>> things cleaned up". From reading that old thread I conclude that this
>>>>>> was
>>>>>> exactly what eventually happened?
>>>>>> Cheers,
>>>>>> --
>>>>>> Marcel Stör,http://www.frightanic.com
>>>>>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
>>>>>> O<    ascii ribbon campaign - stop html mail -www.asciiribbon.org
>>> --
>>> Marcel Stör,http://www.frightanic.com
>>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
>>> O<  ascii ribbon campaign - stop html mail -www.asciiribbon.org

Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Richard Bywater
+1 - plus if there's someone willing to lend a hand to set it up, all
the better to my mind :)

Richard.

On Wednesday, February 9, 2011, J. David Beutel <[hidden email]> wrote:

> I agree that our JIRA would be better with a project per plugin.  The Grails JIRA uses components for its plugins, and its version list has become so long that it's very difficult to find the right component-version combination on that list when submitting an issue on a Grails plugin.
>
>
> On 2011-02-08 18:22 , mlb5000 wrote:
>
> Having administered our Jira instance for going on almost 2 years,
> it's very clear that Jira is project-centric, not component-centric.
> Projects can have components but (as stated above) projects are
> versioned, not components.  When you release a version all the
> components go with it (from Jira's standpoint).  I personally like the
> way Atlassian has their stuff set up for plugin developers here:
> https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
> plugin has its own project in that Jira instance so users can report
> issues with that plugin directly to the developer.  Conceivably
> Jenkins proper (i.e. core) would have a project of its own, along with
> each of the plugins.  I think overall this would make things much
> easier to manage, especially if you have named owners/maintainers of
> specific plugins.  Issues could actually be slated for a particular
> release, and plugin developers would be able to keep track of their
> own release plans and keep their users informed.  There would be a
> clear place for everything to go and you can still move issues back
> and forth between projects if need be (like components change today).
>
> I'd be happy to help with this if anyone is interested.  I'm sure the
> improved organization will save me a ton of time while weeding out the
> bug backlog.  However, this is NOT something I can do currently
> because I don't have admin privileges...
>
> On Feb 8, 3:52 pm, Andrew Bayer<[hidden email]>  wrote:
>
> Honestly? The only reason is because it hasn't happened. There's no
> philosophical reason - it's just that no one has done it. No excuse but
> being busy and lazy. =)
>
> A.
>
>
>
>
>
>
>
> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör<[hidden email]>  wrote:
>
> On 08.02.11 21:05, Arnaud Héritier wrote:
>
> no it's right
> As Jira cannot handle a version per component if we use versions in
> only one jira project we'll have to define versions for all components
> core-1.2.3
> plugin-xxx-2.4.3
> ....
> Which is almost useless
>
> Again, it doesn't have to be perfect to be better than it is now.
> Why no split as proposed by Andrew and use versions only for core at the
> moment? That would IMO be a huge leap forward.
>   The only solution to cleanup that is the split in various projects.
>
> For that we need to define a permissions scheme and who will have
> necessary rights to administer projects and manage versions and
> components in them.
> I think that for now it is restricted to a very little number of
> people (and automated by the kk's bot on IRC)
> Thus the question is, do we need to update the bot to allow it to
> manage multi-projects and then split the big project if we want to
> cleanup without adding to much administrative tasks.
> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>    wrote:
>
> Isnt one of the problems with fix versions are that they are project
> based? So if we are going to have one plugin project (or as today one
> project for everything), then those have to share release versions.
> This may confuse users when reporting new issues for plugins as there
> will be tons of different version number (some may even be future
> versions). I guess one way would be to have one project per plugin but
> that might be a big administrative task to fix.
> Regards
> //Erik
> Ps. Im no JIRA expert so i may be wrong here
> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>    wrote:
>
> On 07.02.11 23:14, Ulli Hafner wrote:
>
> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>
> This has been bugging me for a while but I never had the nerve to ask
> here.
> It would make the life of many Jenkins users so much easier if
> commiters used JIRA's "Fix Version/s" field. Right now you
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Ulli Hafner
In reply to this post by mlb5000-2
+1 (A requirement would be that the plug-in developers will get the
project administrator role...)

I also would be happy to help with the setup and with the issue moving
(from the single Jenkins project to the individual plug-in projects).

Ulli

On 02/09/2011 05:22 AM, mlb5000 wrote:

> Having administered our Jira instance for going on almost 2 years,
> it's very clear that Jira is project-centric, not component-centric.
> Projects can have components but (as stated above) projects are
> versioned, not components.  When you release a version all the
> components go with it (from Jira's standpoint).  I personally like the
> way Atlassian has their stuff set up for plugin developers here:
> https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
> plugin has its own project in that Jira instance so users can report
> issues with that plugin directly to the developer.  Conceivably
> Jenkins proper (i.e. core) would have a project of its own, along with
> each of the plugins.  I think overall this would make things much
> easier to manage, especially if you have named owners/maintainers of
> specific plugins.  Issues could actually be slated for a particular
> release, and plugin developers would be able to keep track of their
> own release plans and keep their users informed.  There would be a
> clear place for everything to go and you can still move issues back
> and forth between projects if need be (like components change today).
>
> I'd be happy to help with this if anyone is interested.  I'm sure the
> improved organization will save me a ton of time while weeding out the
> bug backlog.  However, this is NOT something I can do currently
> because I don't have admin privileges...
>
> On Feb 8, 3:52 pm, Andrew Bayer<[hidden email]>  wrote:
>> Honestly? The only reason is because it hasn't happened. There's no
>> philosophical reason - it's just that no one has done it. No excuse but
>> being busy and lazy. =)
>>
>> A.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör<[hidden email]>  wrote:
>>> On 08.02.11 21:05, Arnaud Héritier wrote:
>>>> no it's right
>>>> As Jira cannot handle a version per component if we use versions in
>>>> only one jira project we'll have to define versions for all components
>>>> core-1.2.3
>>>> plugin-xxx-2.4.3
>>>> ....
>>>> Which is almost useless
>>> Again, it doesn't have to be perfect to be better than it is now.
>>> Why no split as proposed by Andrew and use versions only for core at the
>>> moment? That would IMO be a huge leap forward.
>>>   The only solution to cleanup that is the split in various projects.
>>>> For that we need to define a permissions scheme and who will have
>>>> necessary rights to administer projects and manage versions and
>>>> components in them.
>>>> I think that for now it is restricted to a very little number of
>>>> people (and automated by the kk's bot on IRC)
>>>> Thus the question is, do we need to update the bot to allow it to
>>>> manage multi-projects and then split the big project if we want to
>>>> cleanup without adding to much administrative tasks.
>>>> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>    wrote:
>>>>> Isnt one of the problems with fix versions are that they are project
>>>>> based? So if we are going to have one plugin project (or as today one
>>>>> project for everything), then those have to share release versions.
>>>>> This may confuse users when reporting new issues for plugins as there
>>>>> will be tons of different version number (some may even be future
>>>>> versions). I guess one way would be to have one project per plugin but
>>>>> that might be a big administrative task to fix.
>>>>> Regards
>>>>> //Erik
>>>>> Ps. Im no JIRA expert so i may be wrong here
>>>>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>    wrote:
>>>>>> On 07.02.11 23:14, Ulli Hafner wrote:
>>>>>>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>>>>>>> This has been bugging me for a while but I never had the nerve to ask
>>>>>>>> here.
>>>>>>>> It would make the life of many Jenkins users so much easier if
>>>>>>>> commiters used JIRA's "Fix Version/s" field. Right now you'd have to
>>>>>>>> parse changelogs for possibly lots of releases to really find out in
>>>>>>>> which version a particular issue was fixed.
>>>>>>>> Is there a particular reason for not using it?
>>>>>>>> Cheers,
>>>>>>>> Context:
>>>>>>>> KK commentedhttp://issues.jenkins-ci.org/browse/JENKINS-7745as
>>>>>>>> being
>>>>>>>> fixed in 1.397. I wanted to see if this information was consistent
>>>>>>>> with the value in the "Fix Version/s" field and saw that it was empty.
>>>>>>>> I first thought it was a simple glitch and tried to update it myself.
>>>>>>>> Then I noticed that there are no versions configured in JIRA at all.
>>>>>>> I think we already talked about that quite a time ago when we discussed
>>>>>>> the splitting of Jira into Core and Plugins... However, we did not find
>>>>>>> a solution yet ;-)
>>>>>>> See:
>>>>>>> http://jenkins.361315.n4.nabble.com/PROPOSAL-Splitting-JIRA-into-Huds...
>>>>>> Thanks for digging this up.
>>>>>> Uhhm, if I'm not mistaken it's even worse...Andrew's "minimal" proposal
>>>>>> (splitting into three projects) never even saw daylight?!
>>>>>> If I checkhttp://issues.jenkins-ci.org/secure/BrowseProjects.jspa#allIsee
>>>>>> no Jenkins Plugins project and not Jenkins Infrastructure project :-( To
>>>>>> me
>>>>>> the issue list still looks like what Andrew described as "such a mess".
>>>>>> He also said "stop letting the perfect be the enemy of the good and get
>>>>>> things cleaned up". From reading that old thread I conclude that this
>>>>>> was
>>>>>> exactly what eventually happened?
>>>>>> Cheers,
>>>>>> --
>>>>>> Marcel Stör,http://www.frightanic.com
>>>>>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
>>>>>> O<    ascii ribbon campaign - stop html mail -www.asciiribbon.org
>>> --
>>> Marcel Stör,http://www.frightanic.com
>>> Couchsurfing:http://www.couchsurfing.com/people/marcelstoer
>>> O<  ascii ribbon campaign - stop html mail -www.asciiribbon.org

Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Erik Ramfelt
In reply to this post by Richard Bywater
Im willing to help migrate plugin issues to their respective project
(and create the projects), as long as we know how to set up the
projects properly with all schemas and such.

regards
//Erik

On Wed, Feb 9, 2011 at 07:19, Richard Bywater <[hidden email]> wrote:

> +1 - plus if there's someone willing to lend a hand to set it up, all
> the better to my mind :)
>
> Richard.
>
> On Wednesday, February 9, 2011, J. David Beutel <[hidden email]> wrote:
>> I agree that our JIRA would be better with a project per plugin.  The Grails JIRA uses components for its plugins, and its version list has become so long that it's very difficult to find the right component-version combination on that list when submitting an issue on a Grails plugin.
>>
>>
>> On 2011-02-08 18:22 , mlb5000 wrote:
>>
>> Having administered our Jira instance for going on almost 2 years,
>> it's very clear that Jira is project-centric, not component-centric.
>> Projects can have components but (as stated above) projects are
>> versioned, not components.  When you release a version all the
>> components go with it (from Jira's standpoint).  I personally like the
>> way Atlassian has their stuff set up for plugin developers here:
>> https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
>> plugin has its own project in that Jira instance so users can report
>> issues with that plugin directly to the developer.  Conceivably
>> Jenkins proper (i.e. core) would have a project of its own, along with
>> each of the plugins.  I think overall this would make things much
>> easier to manage, especially if you have named owners/maintainers of
>> specific plugins.  Issues could actually be slated for a particular
>> release, and plugin developers would be able to keep track of their
>> own release plans and keep their users informed.  There would be a
>> clear place for everything to go and you can still move issues back
>> and forth between projects if need be (like components change today).
>>
>> I'd be happy to help with this if anyone is interested.  I'm sure the
>> improved organization will save me a ton of time while weeding out the
>> bug backlog.  However, this is NOT something I can do currently
>> because I don't have admin privileges...
>>
>> On Feb 8, 3:52 pm, Andrew Bayer<[hidden email]>  wrote:
>>
>> Honestly? The only reason is because it hasn't happened. There's no
>> philosophical reason - it's just that no one has done it. No excuse but
>> being busy and lazy. =)
>>
>> A.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör<[hidden email]>  wrote:
>>
>> On 08.02.11 21:05, Arnaud Héritier wrote:
>>
>> no it's right
>> As Jira cannot handle a version per component if we use versions in
>> only one jira project we'll have to define versions for all components
>> core-1.2.3
>> plugin-xxx-2.4.3
>> ....
>> Which is almost useless
>>
>> Again, it doesn't have to be perfect to be better than it is now.
>> Why no split as proposed by Andrew and use versions only for core at the
>> moment? That would IMO be a huge leap forward.
>>   The only solution to cleanup that is the split in various projects.
>>
>> For that we need to define a permissions scheme and who will have
>> necessary rights to administer projects and manage versions and
>> components in them.
>> I think that for now it is restricted to a very little number of
>> people (and automated by the kk's bot on IRC)
>> Thus the question is, do we need to update the bot to allow it to
>> manage multi-projects and then split the big project if we want to
>> cleanup without adding to much administrative tasks.
>> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>    wrote:
>>
>> Isnt one of the problems with fix versions are that they are project
>> based? So if we are going to have one plugin project (or as today one
>> project for everything), then those have to share release versions.
>> This may confuse users when reporting new issues for plugins as there
>> will be tons of different version number (some may even be future
>> versions). I guess one way would be to have one project per plugin but
>> that might be a big administrative task to fix.
>> Regards
>> //Erik
>> Ps. Im no JIRA expert so i may be wrong here
>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>    wrote:
>>
>> On 07.02.11 23:14, Ulli Hafner wrote:
>>
>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>
>> This has been bugging me for a while but I never had the nerve to ask
>> here.
>> It would make the life of many Jenkins users so much easier if
>> commiters used JIRA's "Fix Version/s" field. Right now you
>
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Andrew Bayer
We'll be talking about this in the governance meeting (which, hey, is in half an hour - whoops!) today. =)

A.

On Wed, Feb 9, 2011 at 7:41 AM, Erik Ramfelt <[hidden email]> wrote:
Im willing to help migrate plugin issues to their respective project
(and create the projects), as long as we know how to set up the
projects properly with all schemas and such.

regards
//Erik

On Wed, Feb 9, 2011 at 07:19, Richard Bywater <[hidden email]> wrote:
> +1 - plus if there's someone willing to lend a hand to set it up, all
> the better to my mind :)
>
> Richard.
>
> On Wednesday, February 9, 2011, J. David Beutel <[hidden email]> wrote:
>> I agree that our JIRA would be better with a project per plugin.  The Grails JIRA uses components for its plugins, and its version list has become so long that it's very difficult to find the right component-version combination on that list when submitting an issue on a Grails plugin.
>>
>>
>> On 2011-02-08 18:22 , mlb5000 wrote:
>>
>> Having administered our Jira instance for going on almost 2 years,
>> it's very clear that Jira is project-centric, not component-centric.
>> Projects can have components but (as stated above) projects are
>> versioned, not components.  When you release a version all the
>> components go with it (from Jira's standpoint).  I personally like the
>> way Atlassian has their stuff set up for plugin developers here:
>> https://studio.plugins.atlassian.com/secure/Dashboard.jspa.  Each
>> plugin has its own project in that Jira instance so users can report
>> issues with that plugin directly to the developer.  Conceivably
>> Jenkins proper (i.e. core) would have a project of its own, along with
>> each of the plugins.  I think overall this would make things much
>> easier to manage, especially if you have named owners/maintainers of
>> specific plugins.  Issues could actually be slated for a particular
>> release, and plugin developers would be able to keep track of their
>> own release plans and keep their users informed.  There would be a
>> clear place for everything to go and you can still move issues back
>> and forth between projects if need be (like components change today).
>>
>> I'd be happy to help with this if anyone is interested.  I'm sure the
>> improved organization will save me a ton of time while weeding out the
>> bug backlog.  However, this is NOT something I can do currently
>> because I don't have admin privileges...
>>
>> On Feb 8, 3:52 pm, Andrew Bayer<[hidden email]>  wrote:
>>
>> Honestly? The only reason is because it hasn't happened. There's no
>> philosophical reason - it's just that no one has done it. No excuse but
>> being busy and lazy. =)
>>
>> A.
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Feb 8, 2011 at 12:16 PM, Marcel Stör<[hidden email]>  wrote:
>>
>> On 08.02.11 21:05, Arnaud Héritier wrote:
>>
>> no it's right
>> As Jira cannot handle a version per component if we use versions in
>> only one jira project we'll have to define versions for all components
>> core-1.2.3
>> plugin-xxx-2.4.3
>> ....
>> Which is almost useless
>>
>> Again, it doesn't have to be perfect to be better than it is now.
>> Why no split as proposed by Andrew and use versions only for core at the
>> moment? That would IMO be a huge leap forward.
>>   The only solution to cleanup that is the split in various projects.
>>
>> For that we need to define a permissions scheme and who will have
>> necessary rights to administer projects and manage versions and
>> components in them.
>> I think that for now it is restricted to a very little number of
>> people (and automated by the kk's bot on IRC)
>> Thus the question is, do we need to update the bot to allow it to
>> manage multi-projects and then split the big project if we want to
>> cleanup without adding to much administrative tasks.
>> On Tue, Feb 8, 2011 at 8:57 PM, Erik Ramfelt<[hidden email]>    wrote:
>>
>> Isnt one of the problems with fix versions are that they are project
>> based? So if we are going to have one plugin project (or as today one
>> project for everything), then those have to share release versions.
>> This may confuse users when reporting new issues for plugins as there
>> will be tons of different version number (some may even be future
>> versions). I guess one way would be to have one project per plugin but
>> that might be a big administrative task to fix.
>> Regards
>> //Erik
>> Ps. Im no JIRA expert so i may be wrong here
>> On Tue, Feb 8, 2011 at 20:46, Marcel Stör<[hidden email]>    wrote:
>>
>> On 07.02.11 23:14, Ulli Hafner wrote:
>>
>> On 02/07/2011 10:08 PM, Marcel Stör wrote:
>>
>> This has been bugging me for a while but I never had the nerve to ask
>> here.
>> It would make the life of many Jenkins users so much easier if
>> commiters used JIRA's "Fix Version/s" field. Right now you
>

Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

marcelstoer


On Feb 9, 7:32 pm, Andrew Bayer <[hidden email]> wrote:
> We'll be talking about this in the governance meeting (which, hey, is in
> half an hour - whoops!) today. =)

You guys seem to have agreed to split:
http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-09-19.04.log.html#l-43
Is there an ETA for this? Who's in charge of coordinating the
activities for the volunteers?

Cheers,
Marcel
Reply | Threaded
Open this post in threaded view
|

Re: Use JIRA's "Fix Version/s" in the future?

Arnaud Héritier-2
Hi,

  I began to push some TODO here : http://wiki.jenkins-ci.org/x/xwNDAw
  Feel free to comment and give ideas

Cheers

Arnaud


On Thu, Feb 17, 2011 at 10:01 PM, Marcel Stör <[hidden email]> wrote:

>
>
> On Feb 9, 7:32 pm, Andrew Bayer <[hidden email]> wrote:
>> We'll be talking about this in the governance meeting (which, hey, is in
>> half an hour - whoops!) today. =)
>
> You guys seem to have agreed to split:
> http://meetings.jenkins-ci.org/jenkins/2011/jenkins.2011-02-09-19.04.log.html#l-43
> Is there an ETA for this? Who's in charge of coordinating the
> activities for the volunteers?
>
> Cheers,
> Marcel