Hi,
Ok, I am done.
I have sorted all versions alphabetically. This should make it easier to
select the affected and fix version.
I also cleaned up the components:
API
Commons
Engine
Extensions
General
Installer
JCR
Launchpad
Maven Plugins
Samples
Scripting
Servlets
Documentation -- documentation issues
Site -- site issues
Testing -- testing related issues
Console -- legacy component for web console
(not used for new issues any more)
Regards
Felix
Felix Meschberger schrieb:
> Hi,
>
> Thanks for the feedback.
>
> I am going to do some housekeeping on our JIRA then as follows:
>
> * consolidate components to reflect our module collections
> (launchpad, api, jcr, commons, engine, scripting, servlets,
> extensions, general [for things like the site, the parent pom,
> etc.])
>
> * organize the version names for ease of selection. this means
> the names are ordered alphabetically instead of chronological.
>
> During this work, a lot of issues will be reassigned to different
> components. I will make JIRA to not send modification mails for these
> changes.
>
> Regards
> Felix
>
> Ian Boston schrieb:
>> I think the key thing is for those reporting bugs to know where to put
>> them, intuetively and for committers to have the ability to correctly
>> record the fix.
>>
>> IMHO, the Jira Components should be easily identifiable, to the wider
>> community so issues get categorised correctly, and the Affects Version
>> and Fix Version should enable those more embedded in Sling to correctly
>> record the fix so when the release is done everything makes sense.
>>
>> IMHO, Affects Version, Fix Version being bound to the maven pom version
>> are correct and working well, as is the version scheme.
>>
>> I think splitting into multiple projects will make it harder to submit
>> bugs correctly, and manage the issues from the multiple projects. IIRC
>> Jira doesnt do views of multiple projects all that well especially if
>> they have different workflow states.
>>
>> So reviewing the list of Components so they serve a clear purpose not
>> duplicated by Affects Version might make sense.
>>
>> just my 2p's worth.
>> Ian
>>
>>
>> On 3 Sep 2009, at 09:49, Vidar Ramdal wrote:
>>
>>> On Thu, Sep 3, 2009 at 9:11 AM, Felix Meschberger<[email protected]>
>>> wrote:
>>>> Jukka Zitting once brought up the idea to split the Sling JIRA project
>>>> up into multiple projects.
>>>> [...]
>>>> On the other hand I think bloating the Sling project with a component
>>>> for each maven module does
>>>> not make any sense either.
>>> Why not?
>>>
>>>> So I think we should probably split the Sling JIRA project into several
>>>> projects along the general SVN structure lines:
>>>>
>>>> * Sling Launchpad/SLINGLAUNCHPAD (all launchpad modules)
>>>> * Sling Core/SLINGCORE (api, engine, ...)
>>>> * Sling JCR/SLINGJCR (including jcr install)
>>>> * Sling Commons/SLINGCOMMONS
>>>> * Sling Scripting/SLINGSCRIPTING
>>>> * Sling Servlets/SLINGSERVLETS (might also be merged in Core)
>>>> * Sling Extensions/SLINGEXT
>>>>
>>>> all projects would be part of the Sling project category.
>>>>
>>>> WDYT ?
>>> My gut feeling tells me this looks impractical, and I'm not sure if it
>>> solves the problem
>>>> In some case this is kind of confusing; for example: which component is
>>>> taking care of the launchpad/base module ?
>>> Isn't this just moving the question to "which project is taking care
>>> of the launchpad/base module"? OK, when the projects are named in a
>>> sensible way, it's easy to see, but couldn't we just apply a good
>>> naming scheme to the JIRA components?
>>>
>>>> In the Sling project we have almost 99 maven projects. Some of which
>>>> have a corresponding component in the Sling JIRA project. Most don't.
>>> So why don't we create a JIRA component for each maven module?
>>>
>>>
>>> --
>>> Vidar S. Ramdal <[email protected]> - http://www.idium.no
>>> Sommerrogata 13-15, N-0255 Oslo, Norway
>>> + 47 22 00 84 00 / +47 21 531941, ext 2070
>>
>
