That all sounds good to me, looking forwards to the improvements.
Ian
Sent from my iPhone
On 13 Sep 2009, at 22:56, Felix Meschberger <[email protected]> wrote:
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
