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
>
>
