You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Ioan Eugen Stan <st...@gmail.com> on 2012/12/08 18:48:07 UTC
work on mailets
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.
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]
?
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?
[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
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Merge Mailet JIRA projects (was: Re: work on mailets)
Posted by Eric Charles <er...@apache.org>.
On 13/12/2012 10:56, Ioan Eugen Stan wrote:
> Hello,
>
> After the response on INFRA it looks like move + delete is an option.
> I am going move issues this week-end + ticket on infra to delete
> obsolete projects. Eric, is that ok with you?
>
Ok for me. Just ensure that all (closed/open/...) tickets are moved to
their new home.
Thx, Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Merge Mailet JIRA projects (was: Re: work on mailets)
Posted by Eric Charles <er...@apache.org>.
On 13/12/2012 10:56, Ioan Eugen Stan wrote:
> Hello,
>
> After the response on INFRA it looks like move + delete is an option.
> I am going move issues this week-end + ticket on infra to delete
> obsolete projects. Eric, is that ok with you?
>
OK for me. Just ensure that all tickets (close/open/...) are moved to
their new home.
Thx, Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello Eric,
On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
> Hi,
>
> I try to build trunk and get now Failed to execute goal
> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
I'm on it.
> I see also mailet packages changes. Are the other projects updated to
> take this into account? If the projects rely on a release, this has no
> impact for now, but do you plan to migrate them. If we don't do it now,
> there is a high risk to desynchronize code. The more we wait, the more
> difficult it will be.
>
> A good think would be to upgrade the other project to the current mailet
> snapshot and update them to reflect the repackaging.
>
> Thx, Eric
Thanks for letting me know of the issues. I'm on it, probably going to
fix it in week-end if not sooner. My tutorial for ApacheCon: Migrating
complex applications to OSGi - a case study: Apache James meets Karaf
got accepted and I wish to tidy up things and finish the integration
by February.
I will also need your help, especially when we will have to make
releases. I have my key signed during my last ApacheCon so I should be
able to sign releases. I hope I can count on your help too. Let's
release James 3 already :).
I'll go on my way and make changes, trying not to break stuff, but if
I do, please let me know. After all it's code and it should evolve.
Cheers,
> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>> Hi again,
>>
>> Did some work on a private branch [0] for [1]. I moved all site
>> related stuff under apache-mailet-aggregator which builds last so we
>> can aggregate javadocs and other stuff at the end.
>>
>> Please review [0].
>>
>> Right now I wish to stage the new mailet site and see how it performs.
>> I think there are a few bad links over there.
>> Please help with the staging.
>>
>> The main idea is to have all documentation in one place instead of
>> being spread across the project. This should make things easy to track
>> and consistent.
>>
>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>
>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
>>> INFRA moved and deleted the project.
>>>
>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>>
>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>> Hello,
>>>>>
>>>>> I just moved all of the issues to MAILET except for Mailet AI for which
>>>>> I
>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>
>>>>> Eric, could you move Mailet AI?
>>>>>
>>>>
>>>> Seems like Mailet AI is deleted.
>>>> I don't see it anymore as a user nor as an administrator.
>>>> Thx,
>>>> Eric
>>>>
>>>>> Thanks,
>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
>>>>> scris:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> After the response on INFRA it looks like move + delete is an option.
>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>
>>>>>> I personally enjoy a clean working place.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>>>>>> wrote:
>>>>>>> Hello Eric,
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I also
>>>>>> had
>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>> hands
>>>>>> of
>>>>>>>> apache infra and the goal is not to give delegation to the projects
>>>>>>>> on
>>>>>> that
>>>>>>>> level.
>>>>>>>>
>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>> responsibility I
>>>>>>>> think.
>>>>>>>>
>>>>>>>> But once again, I simply don't like the idea of losing any historical
>>>>>>>> information and I expect infra will ask you why you want to do this.
>>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>>
>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>>>>>> project
>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>
>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>
>>>>>>>> To make this information available, please simply announce it in a
>>>>>> separate
>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>> everyone is
>>>>>>>> well informed on what's going on.
>>>>>>>>
>>>>>>>> Thx, Eric
>>>>>>>>
>>>>>>>
>>>>>>> I'll ask on infra about the best course of action. I'll CC you in the
>>>>>> mail.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>>
>>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hi,
On Sun, Dec 23, 2012 at 2:44 PM, Eric Charles <er...@apache.org> wrote:
>
>
> On 23/12/2012 13:20, Ioan Eugen Stan wrote:
>>
>> Hello,
>>
>>
>> On Sun, Dec 23, 2012 at 12:50 PM, Eric Charles <er...@apache.org> wrote:
>>>
>>> Hi Ioan,
>>>
>>>
>>> On 22/12/2012 15:49, Ioan Eugen Stan wrote:
>>>>
>>>>
>>>> Hello,
>>>>
>>>> On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>> I try to build trunk and get now Failed to execute goal
>>>>> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
>>>>> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
>>>>
>>>>
>>>>
>>>> Eric, please try and build the project again and see what it's causing
>>>> RAT plugin to fail. I have a hunch that there are some files generated
>>>> by your IDE that cause it to fail. Look at target/rat.txt for the
>>>> cause.
>>>>
>>>
>>> I build with CLI (not IDE).
>>> Rat is not happy with the .settings folder in apache-mailet-ai.
>>>
>>> I tried to configure the exclusions in the parent, also tried to define
>>> the
>>> rat plugin on the apache-mailet-ai itself, without success...
>>>
>>> I think it's a matter of folder depth (apache-mailet-ai is one more depth
>>> than the others).
>>>
>>
>> You cna configure RAT in the parent with Ant style wildcards. For
>> example, to ignore all iml files at any depth use:
>> <exclude>**/*.iml</exclude> . I hope you won't need to
>> escape the dot in the case of '.settings'. Rat needs to be improved so
>> it will ignore some common IDE files.
>>
>
> I tried to tune them without success...
>
> I triggered a manual build on jenkins and it does not give the exception.
> https://builds.apache.org/view/G-L/view/James/job/james-mailet/1908/
>
> Do you see it on your PC?
> I had RAT no issue before the changes and changed nothing in my env.
>
I have no issues with RAT. I think you're missing something small or
there is a bug somewhere. Try deleting the offending files.
>>>>> I see also mailet packages changes. Are the other projects updated to
>>>>> take this into account? If the projects rely on a release, this has no
>>>>> impact for now, but do you plan to migrate them. If we don't do it now,
>>>>> there is a high risk to desynchronize code. The more we wait, the more
>>>>> difficult it will be.
>>>>
>>>>
>>>>
>>>> I've looked at james-server and it depends on release versions, except
>>>> for mailet-base which is SNAPSHOT.
>>>
>>>
>>>
>>> Let's keep in mind we need to impact james-server before or after the
>>> mailet
>>> release
>>
>>
>> Yes, it is a good point. I wish to cut a release soon. It's long over
>> due and now we have good OSGi headers and more consistent packages.
>>
>>>
>>>> I'm looking into starting the release process. It will take some time
>>>> as we need release them individually because of the dependencies.
>>>>
>>>
>>> Why don't we release all mailet at the same time and align all the
>>> version
>>> to the same number? It will be easier for the release and also to impact
>>> james-server.
>>
>>
>> I thought about that, it's good that you brought it up. I like the
>> idea, but wouldn't that be a problem when we need to provide patch
>> releases: release all mailets under the new version even though we
>> changed only Crypto mailet for example? If we do this we would send
>> the message that people should upgrade even though nothing changed.
>> And this is wrong. Did I answer your question correctly?
>>
>
> Yes, this is the well-known never-ending debate...
> I can agree with you, but I find we are a too little team to seek
> perfection. Also, when I see e.g. Apache Camel with has a single release
> scheme all its various components, I think we can also do it...
Agree. I was just looking at jclouds and they have a similar policy
for all their artifacts. I think we can use a consistent version for
all our libraries. I'll raise an issue for this and fix it, then go on
with the release. The new version should be 2.5.0 for all artifacts.
>
>> With regard to james-server, we can upgrade it to the new versions
>> after the release. Ideally we should have some tests that ensure
>> things will work the same but I hope we can skip that now and make it
>> better in the future.
>>
>> With regard to the release process, do you have some time to talk me
>> through it?
>>
>
> All is documented on
> http://www.apache.org/dev/publishing-maven-artifacts.html. If it doesn't
> work fine, just ping back.
Thanks,
> Thx, Eric
>
>
>
>> Cheers,
>>
>>>
>>>> Cheers,
>>>>
>>>>> A good think would be to upgrade the other project to the current
>>>>> mailet
>>>>> snapshot and update them to reflect the repackaging.
>>>>>
>>>>> Thx, Eric
>>>>>
>>>>> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>>>>>>
>>>>>>
>>>>>> Hi again,
>>>>>>
>>>>>> Did some work on a private branch [0] for [1]. I moved all site
>>>>>> related stuff under apache-mailet-aggregator which builds last so we
>>>>>> can aggregate javadocs and other stuff at the end.
>>>>>>
>>>>>> Please review [0].
>>>>>>
>>>>>> Right now I wish to stage the new mailet site and see how it performs.
>>>>>> I think there are a few bad links over there.
>>>>>> Please help with the staging.
>>>>>>
>>>>>> The main idea is to have all documentation in one place instead of
>>>>>> being spread across the project. This should make things easy to track
>>>>>> and consistent.
>>>>>>
>>>>>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>>>>>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>>>>>
>>>>>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan
>>>>>> <st...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>> INFRA moved and deleted the project.
>>>>>>>
>>>>>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a
>>>>>>> scris:
>>>>>>>
>>>>>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I just moved all of the issues to MAILET except for Mailet AI for
>>>>>>>>> which
>>>>>>>>> I
>>>>>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>>>>>
>>>>>>>>> Eric, could you move Mailet AI?
>>>>>>>>>
>>>>>>>>
>>>>>>>> Seems like Mailet AI is deleted.
>>>>>>>> I don't see it anymore as a user nor as an administrator.
>>>>>>>> Thx,
>>>>>>>> Eric
>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan"
>>>>>>>>> <st...@gmail.com> a
>>>>>>>>> scris:
>>>>>>>>>
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> After the response on INFRA it looks like move + delete is an
>>>>>>>>>> option.
>>>>>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>>>>>
>>>>>>>>>> I personally enjoy a clean working place.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>>
>>>>>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan
>>>>>>>>>> <st...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello Eric,
>>>>>>>>>>>
>>>>>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I
>>>>>>>>>>>> also
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> had
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>>>>>> hands
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> of
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> apache infra and the goal is not to give delegation to the
>>>>>>>>>>>> projects
>>>>>>>>>>>> on
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> that
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> level.
>>>>>>>>>>>>
>>>>>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> responsibility I
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> think.
>>>>>>>>>>>>
>>>>>>>>>>>> But once again, I simply don't like the idea of losing any
>>>>>>>>>>>> historical
>>>>>>>>>>>> information and I expect infra will ask you why you want to do
>>>>>>>>>>>> this.
>>>>>>>>>>>> Even retired projects (in the attic) are still accessible on
>>>>>>>>>>>> JIRA.
>>>>>>>>>>>>
>>>>>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new
>>>>>>>>>>>> JIRA
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> project
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>>>>>
>>>>>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>>>>>
>>>>>>>>>>>> To make this information available, please simply announce it in
>>>>>>>>>>>> a
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> separate
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> everyone is
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> well informed on what's going on.
>>>>>>>>>>>>
>>>>>>>>>>>> Thx, Eric
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I'll ask on infra about the best course of action. I'll CC you in
>>>>>>>>>>> the
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> mail.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> 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:
>>>>>>>>>>>>>> server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> server-dev-help@james.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
On 23/12/2012 13:20, Ioan Eugen Stan wrote:
> Hello,
>
>
> On Sun, Dec 23, 2012 at 12:50 PM, Eric Charles <er...@apache.org> wrote:
>> Hi Ioan,
>>
>>
>> On 22/12/2012 15:49, Ioan Eugen Stan wrote:
>>>
>>> Hello,
>>>
>>> On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I try to build trunk and get now Failed to execute goal
>>>> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
>>>> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
>>>
>>>
>>> Eric, please try and build the project again and see what it's causing
>>> RAT plugin to fail. I have a hunch that there are some files generated
>>> by your IDE that cause it to fail. Look at target/rat.txt for the
>>> cause.
>>>
>>
>> I build with CLI (not IDE).
>> Rat is not happy with the .settings folder in apache-mailet-ai.
>>
>> I tried to configure the exclusions in the parent, also tried to define the
>> rat plugin on the apache-mailet-ai itself, without success...
>>
>> I think it's a matter of folder depth (apache-mailet-ai is one more depth
>> than the others).
>>
>
> You cna configure RAT in the parent with Ant style wildcards. For
> example, to ignore all iml files at any depth use:
> <exclude>**/*.iml</exclude> . I hope you won't need to
> escape the dot in the case of '.settings'. Rat needs to be improved so
> it will ignore some common IDE files.
>
I tried to tune them without success...
I triggered a manual build on jenkins and it does not give the
exception.
https://builds.apache.org/view/G-L/view/James/job/james-mailet/1908/
Do you see it on your PC?
I had RAT no issue before the changes and changed nothing in my env.
>>>> I see also mailet packages changes. Are the other projects updated to
>>>> take this into account? If the projects rely on a release, this has no
>>>> impact for now, but do you plan to migrate them. If we don't do it now,
>>>> there is a high risk to desynchronize code. The more we wait, the more
>>>> difficult it will be.
>>>
>>>
>>> I've looked at james-server and it depends on release versions, except
>>> for mailet-base which is SNAPSHOT.
>>
>>
>> Let's keep in mind we need to impact james-server before or after the mailet
>> release
>
> Yes, it is a good point. I wish to cut a release soon. It's long over
> due and now we have good OSGi headers and more consistent packages.
>
>>
>>> I'm looking into starting the release process. It will take some time
>>> as we need release them individually because of the dependencies.
>>>
>>
>> Why don't we release all mailet at the same time and align all the version
>> to the same number? It will be easier for the release and also to impact
>> james-server.
>
> I thought about that, it's good that you brought it up. I like the
> idea, but wouldn't that be a problem when we need to provide patch
> releases: release all mailets under the new version even though we
> changed only Crypto mailet for example? If we do this we would send
> the message that people should upgrade even though nothing changed.
> And this is wrong. Did I answer your question correctly?
>
Yes, this is the well-known never-ending debate...
I can agree with you, but I find we are a too little team to seek
perfection. Also, when I see e.g. Apache Camel with has a single release
scheme all its various components, I think we can also do it...
> With regard to james-server, we can upgrade it to the new versions
> after the release. Ideally we should have some tests that ensure
> things will work the same but I hope we can skip that now and make it
> better in the future.
>
> With regard to the release process, do you have some time to talk me
> through it?
>
All is documented on
http://www.apache.org/dev/publishing-maven-artifacts.html. If it doesn't
work fine, just ping back.
Thx, Eric
> Cheers,
>
>>
>>> Cheers,
>>>
>>>> A good think would be to upgrade the other project to the current mailet
>>>> snapshot and update them to reflect the repackaging.
>>>>
>>>> Thx, Eric
>>>>
>>>> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>>>>>
>>>>> Hi again,
>>>>>
>>>>> Did some work on a private branch [0] for [1]. I moved all site
>>>>> related stuff under apache-mailet-aggregator which builds last so we
>>>>> can aggregate javadocs and other stuff at the end.
>>>>>
>>>>> Please review [0].
>>>>>
>>>>> Right now I wish to stage the new mailet site and see how it performs.
>>>>> I think there are a few bad links over there.
>>>>> Please help with the staging.
>>>>>
>>>>> The main idea is to have all documentation in one place instead of
>>>>> being spread across the project. This should make things easy to track
>>>>> and consistent.
>>>>>
>>>>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>>>>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>>>>
>>>>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> INFRA moved and deleted the project.
>>>>>>
>>>>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>>>>>
>>>>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I just moved all of the issues to MAILET except for Mailet AI for
>>>>>>>> which
>>>>>>>> I
>>>>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>>>>
>>>>>>>> Eric, could you move Mailet AI?
>>>>>>>>
>>>>>>>
>>>>>>> Seems like Mailet AI is deleted.
>>>>>>> I don't see it anymore as a user nor as an administrator.
>>>>>>> Thx,
>>>>>>> Eric
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan"
>>>>>>>> <st...@gmail.com> a
>>>>>>>> scris:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> After the response on INFRA it looks like move + delete is an
>>>>>>>>> option.
>>>>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>>>>
>>>>>>>>> I personally enjoy a clean working place.
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>>
>>>>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan
>>>>>>>>> <st...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hello Eric,
>>>>>>>>>>
>>>>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I
>>>>>>>>>>> also
>>>>>>>>>
>>>>>>>>> had
>>>>>>>>>>>
>>>>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>>>>> hands
>>>>>>>>>
>>>>>>>>> of
>>>>>>>>>>>
>>>>>>>>>>> apache infra and the goal is not to give delegation to the
>>>>>>>>>>> projects
>>>>>>>>>>> on
>>>>>>>>>
>>>>>>>>> that
>>>>>>>>>>>
>>>>>>>>>>> level.
>>>>>>>>>>>
>>>>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>>>>>
>>>>>>>>> responsibility I
>>>>>>>>>>>
>>>>>>>>>>> think.
>>>>>>>>>>>
>>>>>>>>>>> But once again, I simply don't like the idea of losing any
>>>>>>>>>>> historical
>>>>>>>>>>> information and I expect infra will ask you why you want to do
>>>>>>>>>>> this.
>>>>>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>>>>>
>>>>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new
>>>>>>>>>>> JIRA
>>>>>>>>>
>>>>>>>>> project
>>>>>>>>>>>
>>>>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>>>>
>>>>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>>>>
>>>>>>>>>>> To make this information available, please simply announce it in a
>>>>>>>>>
>>>>>>>>> separate
>>>>>>>>>>>
>>>>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>>>>>
>>>>>>>>> everyone is
>>>>>>>>>>>
>>>>>>>>>>> well informed on what's going on.
>>>>>>>>>>>
>>>>>>>>>>> Thx, Eric
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'll ask on infra about the best course of action. I'll CC you in
>>>>>>>>>> the
>>>>>>>>>
>>>>>>>>> mail.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>> server-dev-help@james.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello,
On Sun, Dec 23, 2012 at 12:50 PM, Eric Charles <er...@apache.org> wrote:
> Hi Ioan,
>
>
> On 22/12/2012 15:49, Ioan Eugen Stan wrote:
>>
>> Hello,
>>
>> On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
>>>
>>> Hi,
>>>
>>> I try to build trunk and get now Failed to execute goal
>>> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
>>> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
>>
>>
>> Eric, please try and build the project again and see what it's causing
>> RAT plugin to fail. I have a hunch that there are some files generated
>> by your IDE that cause it to fail. Look at target/rat.txt for the
>> cause.
>>
>
> I build with CLI (not IDE).
> Rat is not happy with the .settings folder in apache-mailet-ai.
>
> I tried to configure the exclusions in the parent, also tried to define the
> rat plugin on the apache-mailet-ai itself, without success...
>
> I think it's a matter of folder depth (apache-mailet-ai is one more depth
> than the others).
>
You cna configure RAT in the parent with Ant style wildcards. For
example, to ignore all iml files at any depth use:
<exclude>**/*.iml</exclude> . I hope you won't need to
escape the dot in the case of '.settings'. Rat needs to be improved so
it will ignore some common IDE files.
>>> I see also mailet packages changes. Are the other projects updated to
>>> take this into account? If the projects rely on a release, this has no
>>> impact for now, but do you plan to migrate them. If we don't do it now,
>>> there is a high risk to desynchronize code. The more we wait, the more
>>> difficult it will be.
>>
>>
>> I've looked at james-server and it depends on release versions, except
>> for mailet-base which is SNAPSHOT.
>
>
> Let's keep in mind we need to impact james-server before or after the mailet
> release
Yes, it is a good point. I wish to cut a release soon. It's long over
due and now we have good OSGi headers and more consistent packages.
>
>> I'm looking into starting the release process. It will take some time
>> as we need release them individually because of the dependencies.
>>
>
> Why don't we release all mailet at the same time and align all the version
> to the same number? It will be easier for the release and also to impact
> james-server.
I thought about that, it's good that you brought it up. I like the
idea, but wouldn't that be a problem when we need to provide patch
releases: release all mailets under the new version even though we
changed only Crypto mailet for example? If we do this we would send
the message that people should upgrade even though nothing changed.
And this is wrong. Did I answer your question correctly?
With regard to james-server, we can upgrade it to the new versions
after the release. Ideally we should have some tests that ensure
things will work the same but I hope we can skip that now and make it
better in the future.
With regard to the release process, do you have some time to talk me
through it?
Cheers,
>
>> Cheers,
>>
>>> A good think would be to upgrade the other project to the current mailet
>>> snapshot and update them to reflect the repackaging.
>>>
>>> Thx, Eric
>>>
>>> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>>>>
>>>> Hi again,
>>>>
>>>> Did some work on a private branch [0] for [1]. I moved all site
>>>> related stuff under apache-mailet-aggregator which builds last so we
>>>> can aggregate javadocs and other stuff at the end.
>>>>
>>>> Please review [0].
>>>>
>>>> Right now I wish to stage the new mailet site and see how it performs.
>>>> I think there are a few bad links over there.
>>>> Please help with the staging.
>>>>
>>>> The main idea is to have all documentation in one place instead of
>>>> being spread across the project. This should make things easy to track
>>>> and consistent.
>>>>
>>>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>>>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>>>
>>>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com>
>>>> wrote:
>>>>>
>>>>> INFRA moved and deleted the project.
>>>>>
>>>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>>>>
>>>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I just moved all of the issues to MAILET except for Mailet AI for
>>>>>>> which
>>>>>>> I
>>>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>>>
>>>>>>> Eric, could you move Mailet AI?
>>>>>>>
>>>>>>
>>>>>> Seems like Mailet AI is deleted.
>>>>>> I don't see it anymore as a user nor as an administrator.
>>>>>> Thx,
>>>>>> Eric
>>>>>>
>>>>>>> Thanks,
>>>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan"
>>>>>>> <st...@gmail.com> a
>>>>>>> scris:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> After the response on INFRA it looks like move + delete is an
>>>>>>>> option.
>>>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>>>
>>>>>>>> I personally enjoy a clean working place.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan
>>>>>>>> <st...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hello Eric,
>>>>>>>>>
>>>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I
>>>>>>>>>> also
>>>>>>>>
>>>>>>>> had
>>>>>>>>>>
>>>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>>>> hands
>>>>>>>>
>>>>>>>> of
>>>>>>>>>>
>>>>>>>>>> apache infra and the goal is not to give delegation to the
>>>>>>>>>> projects
>>>>>>>>>> on
>>>>>>>>
>>>>>>>> that
>>>>>>>>>>
>>>>>>>>>> level.
>>>>>>>>>>
>>>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>>>>
>>>>>>>> responsibility I
>>>>>>>>>>
>>>>>>>>>> think.
>>>>>>>>>>
>>>>>>>>>> But once again, I simply don't like the idea of losing any
>>>>>>>>>> historical
>>>>>>>>>> information and I expect infra will ask you why you want to do
>>>>>>>>>> this.
>>>>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>>>>
>>>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new
>>>>>>>>>> JIRA
>>>>>>>>
>>>>>>>> project
>>>>>>>>>>
>>>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>>>
>>>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>>>
>>>>>>>>>> To make this information available, please simply announce it in a
>>>>>>>>
>>>>>>>> separate
>>>>>>>>>>
>>>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>>>>
>>>>>>>> everyone is
>>>>>>>>>>
>>>>>>>>>> well informed on what's going on.
>>>>>>>>>>
>>>>>>>>>> Thx, Eric
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I'll ask on infra about the best course of action. I'll CC you in
>>>>>>>>> the
>>>>>>>>
>>>>>>>> mail.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>> server-dev-help@james.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
Hi Ioan,
On 22/12/2012 15:49, Ioan Eugen Stan wrote:
> Hello,
>
> On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
>> Hi,
>>
>> I try to build trunk and get now Failed to execute goal
>> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
>> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
>
> Eric, please try and build the project again and see what it's causing
> RAT plugin to fail. I have a hunch that there are some files generated
> by your IDE that cause it to fail. Look at target/rat.txt for the
> cause.
>
I build with CLI (not IDE).
Rat is not happy with the .settings folder in apache-mailet-ai.
I tried to configure the exclusions in the parent, also tried to define
the rat plugin on the apache-mailet-ai itself, without success...
I think it's a matter of folder depth (apache-mailet-ai is one more
depth than the others).
>> I see also mailet packages changes. Are the other projects updated to
>> take this into account? If the projects rely on a release, this has no
>> impact for now, but do you plan to migrate them. If we don't do it now,
>> there is a high risk to desynchronize code. The more we wait, the more
>> difficult it will be.
>
> I've looked at james-server and it depends on release versions, except
> for mailet-base which is SNAPSHOT.
Let's keep in mind we need to impact james-server before or after the
mailet release
> I'm looking into starting the release process. It will take some time
> as we need release them individually because of the dependencies.
>
Why don't we release all mailet at the same time and align all the
version to the same number? It will be easier for the release and also
to impact james-server.
> Cheers,
>
>> A good think would be to upgrade the other project to the current mailet
>> snapshot and update them to reflect the repackaging.
>>
>> Thx, Eric
>>
>> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>>> Hi again,
>>>
>>> Did some work on a private branch [0] for [1]. I moved all site
>>> related stuff under apache-mailet-aggregator which builds last so we
>>> can aggregate javadocs and other stuff at the end.
>>>
>>> Please review [0].
>>>
>>> Right now I wish to stage the new mailet site and see how it performs.
>>> I think there are a few bad links over there.
>>> Please help with the staging.
>>>
>>> The main idea is to have all documentation in one place instead of
>>> being spread across the project. This should make things easy to track
>>> and consistent.
>>>
>>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>>
>>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
>>>> INFRA moved and deleted the project.
>>>>
>>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>>>
>>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I just moved all of the issues to MAILET except for Mailet AI for which
>>>>>> I
>>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>>
>>>>>> Eric, could you move Mailet AI?
>>>>>>
>>>>>
>>>>> Seems like Mailet AI is deleted.
>>>>> I don't see it anymore as a user nor as an administrator.
>>>>> Thx,
>>>>> Eric
>>>>>
>>>>>> Thanks,
>>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
>>>>>> scris:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> After the response on INFRA it looks like move + delete is an option.
>>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>>
>>>>>>> I personally enjoy a clean working place.
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Hello Eric,
>>>>>>>>
>>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>>>>>>>>
>>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I also
>>>>>>> had
>>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>>> hands
>>>>>>> of
>>>>>>>>> apache infra and the goal is not to give delegation to the projects
>>>>>>>>> on
>>>>>>> that
>>>>>>>>> level.
>>>>>>>>>
>>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>>> responsibility I
>>>>>>>>> think.
>>>>>>>>>
>>>>>>>>> But once again, I simply don't like the idea of losing any historical
>>>>>>>>> information and I expect infra will ask you why you want to do this.
>>>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>>>
>>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>>>>>>> project
>>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>>
>>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>>
>>>>>>>>> To make this information available, please simply announce it in a
>>>>>>> separate
>>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>>> everyone is
>>>>>>>>> well informed on what's going on.
>>>>>>>>>
>>>>>>>>> Thx, Eric
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'll ask on infra about the best course of action. I'll CC you in the
>>>>>>> mail.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello,
On Wed, Dec 19, 2012 at 9:39 AM, Eric Charles <er...@apache.org> wrote:
> Hi,
>
> I try to build trunk and get now Failed to execute goal
> org.apache.rat:apache-rat-plugin:0.8:check (default) on project
> apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
Eric, please try and build the project again and see what it's causing
RAT plugin to fail. I have a hunch that there are some files generated
by your IDE that cause it to fail. Look at target/rat.txt for the
cause.
> I see also mailet packages changes. Are the other projects updated to
> take this into account? If the projects rely on a release, this has no
> impact for now, but do you plan to migrate them. If we don't do it now,
> there is a high risk to desynchronize code. The more we wait, the more
> difficult it will be.
I've looked at james-server and it depends on release versions, except
for mailet-base which is SNAPSHOT.
I'm looking into starting the release process. It will take some time
as we need release them individually because of the dependencies.
Cheers,
> A good think would be to upgrade the other project to the current mailet
> snapshot and update them to reflect the repackaging.
>
> Thx, Eric
>
> On 16/12/2012 00:37, Ioan Eugen Stan wrote:
>> Hi again,
>>
>> Did some work on a private branch [0] for [1]. I moved all site
>> related stuff under apache-mailet-aggregator which builds last so we
>> can aggregate javadocs and other stuff at the end.
>>
>> Please review [0].
>>
>> Right now I wish to stage the new mailet site and see how it performs.
>> I think there are a few bad links over there.
>> Please help with the staging.
>>
>> The main idea is to have all documentation in one place instead of
>> being spread across the project. This should make things easy to track
>> and consistent.
>>
>> [0] https://github.com/ieugen/james-mailet/tree/single-site
>> [1] https://issues.apache.org/jira/browse/MAILET-43
>>
>> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
>>> INFRA moved and deleted the project.
>>>
>>> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>>
>>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>>> Hello,
>>>>>
>>>>> I just moved all of the issues to MAILET except for Mailet AI for which
>>>>> I
>>>>> don't have kharma. I also raised INFRA-5660.
>>>>>
>>>>> Eric, could you move Mailet AI?
>>>>>
>>>>
>>>> Seems like Mailet AI is deleted.
>>>> I don't see it anymore as a user nor as an administrator.
>>>> Thx,
>>>> Eric
>>>>
>>>>> Thanks,
>>>>> În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
>>>>> scris:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> After the response on INFRA it looks like move + delete is an option.
>>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>>> obsolete projects. Eric, is that ok with you?
>>>>>>
>>>>>> I personally enjoy a clean working place.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>>>>>> wrote:
>>>>>>> Hello Eric,
>>>>>>>
>>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>>>>>>>
>>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I also
>>>>>> had
>>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>>> hands
>>>>>> of
>>>>>>>> apache infra and the goal is not to give delegation to the projects
>>>>>>>> on
>>>>>> that
>>>>>>>> level.
>>>>>>>>
>>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>>> responsibility I
>>>>>>>> think.
>>>>>>>>
>>>>>>>> But once again, I simply don't like the idea of losing any historical
>>>>>>>> information and I expect infra will ask you why you want to do this.
>>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>>
>>>>>>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>>>>>> project
>>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>>
>>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>>
>>>>>>>> To make this information available, please simply announce it in a
>>>>>> separate
>>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>>> everyone is
>>>>>>>> well informed on what's going on.
>>>>>>>>
>>>>>>>> Thx, Eric
>>>>>>>>
>>>>>>>
>>>>>>> I'll ask on infra about the best course of action. I'll CC you in the
>>>>>> mail.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>>>
>>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
Hi,
I try to build trunk and get now Failed to execute goal
org.apache.rat:apache-rat-plugin:0.8:check (default) on project
apache-mailet-ai: Too many unapproved licenses: 4 -> [Help 1]
I see also mailet packages changes. Are the other projects updated to
take this into account? If the projects rely on a release, this has no
impact for now, but do you plan to migrate them. If we don't do it now,
there is a high risk to desynchronize code. The more we wait, the more
difficult it will be.
A good think would be to upgrade the other project to the current mailet
snapshot and update them to reflect the repackaging.
Thx, Eric
On 16/12/2012 00:37, Ioan Eugen Stan wrote:
> Hi again,
>
> Did some work on a private branch [0] for [1]. I moved all site
> related stuff under apache-mailet-aggregator which builds last so we
> can aggregate javadocs and other stuff at the end.
>
> Please review [0].
>
> Right now I wish to stage the new mailet site and see how it performs.
> I think there are a few bad links over there.
> Please help with the staging.
>
> The main idea is to have all documentation in one place instead of
> being spread across the project. This should make things easy to track
> and consistent.
>
> [0] https://github.com/ieugen/james-mailet/tree/single-site
> [1] https://issues.apache.org/jira/browse/MAILET-43
>
> On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
>> INFRA moved and deleted the project.
>>
>> �n data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>>
>>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>>>> Hello,
>>>>
>>>> I just moved all of the issues to MAILET except for Mailet AI for which
>>>> I
>>>> don't have kharma. I also raised INFRA-5660.
>>>>
>>>> Eric, could you move Mailet AI?
>>>>
>>>
>>> Seems like Mailet AI is deleted.
>>> I don't see it anymore as a user nor as an administrator.
>>> Thx,
>>> Eric
>>>
>>>> Thanks,
>>>> �n data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
>>>> scris:
>>>>
>>>>> Hello,
>>>>>
>>>>> After the response on INFRA it looks like move + delete is an option.
>>>>> I am going move issues this week-end + ticket on infra to delete
>>>>> obsolete projects. Eric, is that ok with you?
>>>>>
>>>>> I personally enjoy a clean working place.
>>>>>
>>>>> Regards,
>>>>>
>>>>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>>>>> wrote:
>>>>>> Hello Eric,
>>>>>>
>>>>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>>>>>>
>>>>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> 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 also read this morning [2] (which is not an apache page) but I also
>>>>> had
>>>>>>> not the rights to do anything. I think those settings are in the
>>>>>>> hands
>>>>> of
>>>>>>> apache infra and the goal is not to give delegation to the projects
>>>>>>> on
>>>>> that
>>>>>>> level.
>>>>>>>
>>>>>>> Closing a jira project is just like opening one: it's infra
>>>>> responsibility I
>>>>>>> think.
>>>>>>>
>>>>>>> But once again, I simply don't like the idea of losing any historical
>>>>>>> information and I expect infra will ask you why you want to do this.
>>>>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>>>>
>>>>>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>>>>> project
>>>>>>> (with a comment on the old ones to redirect to the new ones).
>>>>>>>
>>>>>>> But unless someone pops-up here, it's all in your hand.
>>>>>>>
>>>>>>> To make this information available, please simply announce it in a
>>>>> separate
>>>>>>> mail on the james dev + mailet lists with a notice of 3 days so
>>>>> everyone is
>>>>>>> well informed on what's going on.
>>>>>>>
>>>>>>> Thx, Eric
>>>>>>>
>>>>>>
>>>>>> I'll ask on infra about the best course of action. I'll CC you in the
>>>>> mail.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>>
>>>>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hi again,
Did some work on a private branch [0] for [1]. I moved all site
related stuff under apache-mailet-aggregator which builds last so we
can aggregate javadocs and other stuff at the end.
Please review [0].
Right now I wish to stage the new mailet site and see how it performs.
I think there are a few bad links over there.
Please help with the staging.
The main idea is to have all documentation in one place instead of
being spread across the project. This should make things easy to track
and consistent.
[0] https://github.com/ieugen/james-mailet/tree/single-site
[1] https://issues.apache.org/jira/browse/MAILET-43
On Sat, Dec 15, 2012 at 2:41 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
> INFRA moved and deleted the project.
>
> În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
>
>> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
>> > Hello,
>> >
>> > I just moved all of the issues to MAILET except for Mailet AI for which
>> > I
>> > don't have kharma. I also raised INFRA-5660.
>> >
>> > Eric, could you move Mailet AI?
>> >
>>
>> Seems like Mailet AI is deleted.
>> I don't see it anymore as a user nor as an administrator.
>> Thx,
>> Eric
>>
>> > Thanks,
>> > În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
>> > scris:
>> >
>> >> Hello,
>> >>
>> >> After the response on INFRA it looks like move + delete is an option.
>> >> I am going move issues this week-end + ticket on infra to delete
>> >> obsolete projects. Eric, is that ok with you?
>> >>
>> >> I personally enjoy a clean working place.
>> >>
>> >> Regards,
>> >>
>> >> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>> >> wrote:
>> >>> Hello Eric,
>> >>>
>> >>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>> >>>>
>> >>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>> >>>>>
>> >>>>>
>> >>>>> 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 also read this morning [2] (which is not an apache page) but I also
>> >> had
>> >>>> not the rights to do anything. I think those settings are in the
>> >>>> hands
>> >> of
>> >>>> apache infra and the goal is not to give delegation to the projects
>> >>>> on
>> >> that
>> >>>> level.
>> >>>>
>> >>>> Closing a jira project is just like opening one: it's infra
>> >> responsibility I
>> >>>> think.
>> >>>>
>> >>>> But once again, I simply don't like the idea of losing any historical
>> >>>> information and I expect infra will ask you why you want to do this.
>> >>>> Even retired projects (in the attic) are still accessible on JIRA.
>> >>>>
>> >>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>> >> project
>> >>>> (with a comment on the old ones to redirect to the new ones).
>> >>>>
>> >>>> But unless someone pops-up here, it's all in your hand.
>> >>>>
>> >>>> To make this information available, please simply announce it in a
>> >> separate
>> >>>> mail on the james dev + mailet lists with a notice of 3 days so
>> >> everyone is
>> >>>> well informed on what's going on.
>> >>>>
>> >>>> Thx, Eric
>> >>>>
>> >>>
>> >>> I'll ask on infra about the best course of action. I'll CC you in the
>> >> mail.
>> >>>
>> >>> Thanks,
>> >>>
>> >>>>
>> >>>>> 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: server-dev-unsubscribe@james.apache.org
>> >>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> >>>> For additional commands, e-mail: server-dev-help@james.apache.org
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Ioan Eugen Stan / CTO / http://axemblr.com
>> >>
>> >>
>> >>
>> >> --
>> >> Ioan Eugen Stan / CTO / http://axemblr.com
>> >>
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
INFRA moved and deleted the project.
În data de 15.12.2012 14:25, "Eric Charles" <er...@apache.org> a scris:
> On 15/12/2012 11:38, Ioan Eugen Stan wrote:
> > Hello,
> >
> > I just moved all of the issues to MAILET except for Mailet AI for which I
> > don't have kharma. I also raised INFRA-5660.
> >
> > Eric, could you move Mailet AI?
> >
>
> Seems like Mailet AI is deleted.
> I don't see it anymore as a user nor as an administrator.
> Thx,
> Eric
>
> > Thanks,
> > În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
> > scris:
> >
> >> Hello,
> >>
> >> After the response on INFRA it looks like move + delete is an option.
> >> I am going move issues this week-end + ticket on infra to delete
> >> obsolete projects. Eric, is that ok with you?
> >>
> >> I personally enjoy a clean working place.
> >>
> >> Regards,
> >>
> >> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
> >> wrote:
> >>> Hello Eric,
> >>>
> >>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
> >>>>
> >>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
> >>>>>
> >>>>>
> >>>>> 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 also read this morning [2] (which is not an apache page) but I also
> >> had
> >>>> not the rights to do anything. I think those settings are in the hands
> >> of
> >>>> apache infra and the goal is not to give delegation to the projects on
> >> that
> >>>> level.
> >>>>
> >>>> Closing a jira project is just like opening one: it's infra
> >> responsibility I
> >>>> think.
> >>>>
> >>>> But once again, I simply don't like the idea of losing any historical
> >>>> information and I expect infra will ask you why you want to do this.
> >>>> Even retired projects (in the attic) are still accessible on JIRA.
> >>>>
> >>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
> >> project
> >>>> (with a comment on the old ones to redirect to the new ones).
> >>>>
> >>>> But unless someone pops-up here, it's all in your hand.
> >>>>
> >>>> To make this information available, please simply announce it in a
> >> separate
> >>>> mail on the james dev + mailet lists with a notice of 3 days so
> >> everyone is
> >>>> well informed on what's going on.
> >>>>
> >>>> Thx, Eric
> >>>>
> >>>
> >>> I'll ask on infra about the best course of action. I'll CC you in the
> >> mail.
> >>>
> >>> Thanks,
> >>>
> >>>>
> >>>>> 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: server-dev-unsubscribe@james.apache.org
> >>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >>>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Ioan Eugen Stan / CTO / http://axemblr.com
> >>
> >>
> >>
> >> --
> >> Ioan Eugen Stan / CTO / http://axemblr.com
> >>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
On 15/12/2012 11:38, Ioan Eugen Stan wrote:
> Hello,
>
> I just moved all of the issues to MAILET except for Mailet AI for which I
> don't have kharma. I also raised INFRA-5660.
>
> Eric, could you move Mailet AI?
>
Seems like Mailet AI is deleted.
I don't see it anymore as a user nor as an administrator.
Thx,
Eric
> Thanks,
> �n data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
> scris:
>
>> Hello,
>>
>> After the response on INFRA it looks like move + delete is an option.
>> I am going move issues this week-end + ticket on infra to delete
>> obsolete projects. Eric, is that ok with you?
>>
>> I personally enjoy a clean working place.
>>
>> Regards,
>>
>> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
>> wrote:
>>> Hello Eric,
>>>
>>> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>>>
>>>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>>>
>>>>>
>>>>> 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 also read this morning [2] (which is not an apache page) but I also
>> had
>>>> not the rights to do anything. I think those settings are in the hands
>> of
>>>> apache infra and the goal is not to give delegation to the projects on
>> that
>>>> level.
>>>>
>>>> Closing a jira project is just like opening one: it's infra
>> responsibility I
>>>> think.
>>>>
>>>> But once again, I simply don't like the idea of losing any historical
>>>> information and I expect infra will ask you why you want to do this.
>>>> Even retired projects (in the attic) are still accessible on JIRA.
>>>>
>>>> I favor the readonly mode, recreating the 9 open one in the new JIRA
>> project
>>>> (with a comment on the old ones to redirect to the new ones).
>>>>
>>>> But unless someone pops-up here, it's all in your hand.
>>>>
>>>> To make this information available, please simply announce it in a
>> separate
>>>> mail on the james dev + mailet lists with a notice of 3 days so
>> everyone is
>>>> well informed on what's going on.
>>>>
>>>> Thx, Eric
>>>>
>>>
>>> I'll ask on infra about the best course of action. I'll CC you in the
>> mail.
>>>
>>> Thanks,
>>>
>>>>
>>>>> 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: server-dev-unsubscribe@james.apache.org
>>>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>>
>>> --
>>> Ioan Eugen Stan / CTO / http://axemblr.com
>>
>>
>>
>> --
>> Ioan Eugen Stan / CTO / http://axemblr.com
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello,
I just moved all of the issues to MAILET except for Mailet AI for which I
don't have kharma. I also raised INFRA-5660.
Eric, could you move Mailet AI?
Thanks,
În data de 13.12.2012 12:56, "Ioan Eugen Stan" <st...@gmail.com> a
scris:
> Hello,
>
> After the response on INFRA it looks like move + delete is an option.
> I am going move issues this week-end + ticket on infra to delete
> obsolete projects. Eric, is that ok with you?
>
> I personally enjoy a clean working place.
>
> Regards,
>
> On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com>
> wrote:
> > Hello Eric,
> >
> > On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
> >>
> >> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
> >>>
> >>>
> >>> 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 also read this morning [2] (which is not an apache page) but I also
> had
> >> not the rights to do anything. I think those settings are in the hands
> of
> >> apache infra and the goal is not to give delegation to the projects on
> that
> >> level.
> >>
> >> Closing a jira project is just like opening one: it's infra
> responsibility I
> >> think.
> >>
> >> But once again, I simply don't like the idea of losing any historical
> >> information and I expect infra will ask you why you want to do this.
> >> Even retired projects (in the attic) are still accessible on JIRA.
> >>
> >> I favor the readonly mode, recreating the 9 open one in the new JIRA
> project
> >> (with a comment on the old ones to redirect to the new ones).
> >>
> >> But unless someone pops-up here, it's all in your hand.
> >>
> >> To make this information available, please simply announce it in a
> separate
> >> mail on the james dev + mailet lists with a notice of 3 days so
> everyone is
> >> well informed on what's going on.
> >>
> >> Thx, Eric
> >>
> >
> > I'll ask on infra about the best course of action. I'll CC you in the
> mail.
> >
> > Thanks,
> >
> >>
> >>> 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: server-dev-unsubscribe@james.apache.org
> >>>> For additional commands, e-mail: server-dev-help@james.apache.org
> >>>>
> >>>
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> >> For additional commands, e-mail: server-dev-help@james.apache.org
> >>
> >
> >
> >
> > --
> > Ioan Eugen Stan / CTO / http://axemblr.com
>
>
>
> --
> Ioan Eugen Stan / CTO / http://axemblr.com
>
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello,
After the response on INFRA it looks like move + delete is an option.
I am going move issues this week-end + ticket on infra to delete
obsolete projects. Eric, is that ok with you?
I personally enjoy a clean working place.
Regards,
On Sun, Dec 9, 2012 at 6:02 PM, Ioan Eugen Stan <st...@gmail.com> wrote:
> Hello Eric,
>
> On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>>
>> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>>
>>>
>>> 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 also read this morning [2] (which is not an apache page) but I also had
>> not the rights to do anything. I think those settings are in the hands of
>> apache infra and the goal is not to give delegation to the projects on that
>> level.
>>
>> Closing a jira project is just like opening one: it's infra responsibility I
>> think.
>>
>> But once again, I simply don't like the idea of losing any historical
>> information and I expect infra will ask you why you want to do this.
>> Even retired projects (in the attic) are still accessible on JIRA.
>>
>> I favor the readonly mode, recreating the 9 open one in the new JIRA project
>> (with a comment on the old ones to redirect to the new ones).
>>
>> But unless someone pops-up here, it's all in your hand.
>>
>> To make this information available, please simply announce it in a separate
>> mail on the james dev + mailet lists with a notice of 3 days so everyone is
>> well informed on what's going on.
>>
>> Thx, Eric
>>
>
> I'll ask on infra about the best course of action. I'll CC you in the mail.
>
> Thanks,
>
>>
>>> 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: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
>
> --
> Ioan Eugen Stan / CTO / http://axemblr.com
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hello Eric,
On Sun, Dec 9, 2012 at 5:33 PM, Eric Charles <er...@apache.org> wrote:
>
> On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>>
>>
>> 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 also read this morning [2] (which is not an apache page) but I also had
> not the rights to do anything. I think those settings are in the hands of
> apache infra and the goal is not to give delegation to the projects on that
> level.
>
> Closing a jira project is just like opening one: it's infra responsibility I
> think.
>
> But once again, I simply don't like the idea of losing any historical
> information and I expect infra will ask you why you want to do this.
> Even retired projects (in the attic) are still accessible on JIRA.
>
> I favor the readonly mode, recreating the 9 open one in the new JIRA project
> (with a comment on the old ones to redirect to the new ones).
>
> But unless someone pops-up here, it's all in your hand.
>
> To make this information available, please simply announce it in a separate
> mail on the james dev + mailet lists with a notice of 3 days so everyone is
> well informed on what's going on.
>
> Thx, Eric
>
I'll ask on infra about the best course of action. I'll CC you in the mail.
Thanks,
>
>> 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: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
On 09/12/2012 14:30, Ioan Eugen Stan wrote:
>
> 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 also read this morning [2] (which is not an apache page) but I also
had not the rights to do anything. I think those settings are in the
hands of apache infra and the goal is not to give delegation to the
projects on that level.
Closing a jira project is just like opening one: it's infra
responsibility I think.
But once again, I simply don't like the idea of losing any historical
information and I expect infra will ask you why you want to do this.
Even retired projects (in the attic) are still accessible on JIRA.
I favor the readonly mode, recreating the 9 open one in the new JIRA
project (with a comment on the old ones to redirect to the new ones).
But unless someone pops-up here, it's all in your hand.
To make this information available, please simply announce it in a
separate mail on the james dev + mailet lists with a notice of 3 days so
everyone is well informed on what's going on.
Thx, Eric
> 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: server-dev-unsubscribe@james.apache.org
>> For additional commands, e-mail: server-dev-help@james.apache.org
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Ioan Eugen Stan <st...@gmail.com>.
Hi,
On Sun, Dec 9, 2012 at 8:40 AM, Eric Charles <er...@apache.org> 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: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
--
Ioan Eugen Stan / CTO / http://axemblr.com
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: work on mailets
Posted by Eric Charles <er...@apache.org>.
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.
> 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.
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.
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]
> 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...
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org