Hi, On Sun, Dec 9, 2012 at 8:40 AM, Eric Charles <[email protected]> wrote: > On 08/12/2012 17:48, Ioan Eugen Stan wrote: >> >> Hello devs, >> >> I've done some work on mailets, and more is coming under MAILET-41 [1] >> but there are some things I would like to discuss. >> >> 1. I've noticed that the packages are named org.apache.james.mailet >> and I propose to change from "mailets" back to "mailet" in the >> artifact names. >> > > good.
Done, committed. > >> 2. Jenkins is down, Eric could you please grant me right to fix the >> mailets builds on Jenkins -- you're the one in charge according to [2] >> ? >> > > Permissions granted. Thanks, Updated the jobs. We now have just https://builds.apache.org/view/G-L/view/James/job/james-mailet/ and it builds fine. > > Thre are a few mailet projects that you can delete in jenkings, keeping only > one now (check that the remaining is not deactivated). > > Gump has built fine. Let's see if this holds. I'll try to update if I get new emails. > > On my laptop, I have > [ERROR] Failed to execute goal on project apache-mailets-standard: Could not > resolve dependencies for project > org.apache.james:apache-mailets-standard:bundle:1.2.0-SNAPSHOT: Could not > find artifact org.apache.james:apache-mailets-base:jar:tests:1.2.0-SNAPSHOT > in apache.snapshots (http://repository.apache.org/snapshots) -> [Help 1] > Fixed and committed. Now builds fine on Jenkins https://builds.apache.org/view/G-L/view/James/job/james-mailet/1888/ We could make an optional profile to speed things up as I think it's only needed less often. > > >> 3. I would like to aggregate all mailet JIRA projects under MAILET >> project (see issue MAILET-44 [3]). Any thoughts on how to do this? I >> would go with moving the issues and deleting the projects or making >> them read-only. >> >> What are your thought on this? >> > > If we move and delete, we move the previous reference (in th svn commits, in > the mailing list threads...) > > If we make them read-only, we are no more able to comment and close the > JIRA. > > I think both none of those options are acceptable. > > Why not letting them open and trying to resolve all or a max of JIRA. Once > this is done, we can make the projects READONLY and copy the few remaning > ones to the new project. > > If someone creates a JIRA in an old project, we simply have to close it > asking to create it on the new one. Not perfect, but the new JIRA traffic is > not so high... I've analyzed the situation a bit. Here's a summary. Total number of issues per project - total issues (including open) / open issues. James Basic Mailet Toolkit - MAILETBASE 7 Issues / 0 open James Crytography Mailets - MAILETCRYPTO 9 Issues / 0 open James Mailet - MAILET 46 Issues -- not applicable James Mailets Standard - MAILETSTANDARD 13 Issues / 5 open James MailetDocs Maven Plugin - MAILETDOCS 7 Issues / 3 open James Ai Mailets - JAMESMAILAI 2 issues / 1 open We have a total of 9 open issues. spread over the 5 projects we wish to close. We would make history confusing for 38-9= 29 issues if we move + delete jira projects. I personally think it's reasonable for people to do a bit of extra work if they wish to find out more about the issues related to each commit. Another argument is that those issues are not that important so people will probably never search/get to them. Considering this, my recommendation is to Move+Archive ('Hiding'). I believe keeping all those projects will be more confusing than useful on the long turn. I tried to make Basic Mailets Read-only following [2] but I don't have enough rights to change the Permissions. Eric do you have permissions to make the project Read-Only/ Archive them? I think simple is better. What do you think? [1] https://confluence.atlassian.com/display/JIRA/Moving+an+Issue [2] https://confluence.atlassian.com/display/JIRA/Archiving+a+Project#ArchivingaProject-'Hiding'aproject > Thx, Eric > > >> [1] https://issues.apache.org/jira/browse/MAILET-41 >> [2] http://wiki.apache.org/general/Jenkins >> [3] https://issues.apache.org/jira/browse/MAILET-44 >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > -- Ioan Eugen Stan / CTO / http://axemblr.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
