[cle-release-team] [sakai2-tcc] Sakai CLE 2.9.0 release status

Wed Mar 28 05:30:12 PDT 2012

The workflow is updated so please use it going forward.
https://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines

I am going to remove that stuff from the page to avoid confusion.
-AZ

On Tue, Mar 27, 2012 at 6:01 AM, Diego del Blanco Orobitg
<diego.delblanco at samoo.es> wrote:
> Hi:
>
>
>
> Meanwhile you decide the way to do things better (it’s important), we are
> going to write the issues we are testing  on
> https://confluence.sakaiproject.org/display/QA/2.9+Test+Fest page.
>
>
>
> So before take issue for testing, please check this page.
>
>
>
> Diego del Blanco
>
> Samoo.
>
>
>
>
>
> De: cle-release-team-bounces at collab.sakaiproject.org
> [mailto:cle-release-team-bounces at collab.sakaiproject.org] En nombre de
> Matthew Jones
> Enviado el: martes, 27 de marzo de 2012 2:15
> Para: Aaron Zeckoski
> CC: Rob.Egan at marist.edu; Miguel Carro Pellicer;
> cle-release-team at collab.sakaiproject.org
> Asunto: Re: [cle-release-team] [sakai2-tcc] Sakai CLE 2.9.0 release status
>
>
>
> Anthony, Seth, Megan and I talked about all of this 3 years ago in Boston. I
> think the reason we held off is because we weren't sure the value or even if
> there would ever be anyone able to test every specific issue. Developers and
> assigners don't write up test plans, and most descriptions are hard to
> follow. This makes testing most tickets is very difficult. Take any random
> ticket and see if it's testable. I could maybe do 1 or 2 without putting in
> a hour or so effort figuring it out first.
>
>
>
> And there wasn't anyone then changing Resolved->Closed either. There are
> currently 3812 tickets sitting in the Resolved state.
>
> In fact SAK-453 is Fixed and Resolved. :) . . . The oldest such ticket.
>
> https://jira.sakaiproject.org/browse/SAK-453
>
> So I wouldn't necessarily say this specific issue is new to 2.9. At best,
> smoke and regression testing was the only thing performed on the past
> releases, but that was done and active with someone assigned to QA
> (Megan/Pete/Alan).
>
>
>
> On Mon, Mar 26, 2012 at 7:47 PM, Matthew Jones <matthew at longsight.com>
> wrote:
>
> Yea, I was just saying that not being able to edit a closed issue is our
> decision rather than a limitation of the system. I set this on the Config
> Viewer custom Workflow too (not that anyone used that) because I wanted to
> be able to edit every issue.
>
>
>
> Anyway, I'm just afraid we'll have hundreds of issues sitting around jira
> with this new status that nobody ever looks at for 2 years, like the 1400+
> open feature requests. ;)
>
>
>
> -Matthew
>
>
>
> On Mon, Mar 26, 2012 at 7:39 PM, Aaron Zeckoski <azeckoski at unicon.net>
> wrote:
>
> I don't really want closed tickets to be editable for the same reasons
> as Steve mentioned.
> -AZ
>
>
>
> On Mon, Mar 26, 2012 at 7:38 PM, Matthew Jones <matthew at longsight.com>
> wrote:
>> Also, couldn't we just do
>>
>> Open->In Progress->Resolved (Ready to Test)->In Progress->Closed
>> (Verified)
>>
>> Or would having essentially two In Progress (In Progress - Development/In
>> Progress - Testing) be more used? Maybe this is what you're thinking.
>>
>> And as far as not being able to edit closed tickets, you can add a
>> property
>> jire.issue.editable to the "Closed" step to make it editable. I'm pretty
>> sure this works and we were using it on the UMich workflow if this is
>> desired globally.
>>
>> https://confluence.atlassian.com/pages/viewpage.action?pageId=193300072
>>
>> On Mon, Mar 26, 2012 at 7:21 PM, Sam Ottenhoff <ottenhoff at longsight.com>
>> wrote:
>>>
>>> My vote would be for not changing anything. This status seems the same
>>> as In Progress to me. I have never spent more than 30 mins testing a
>>> single jira issue. I don't see concurrent testing as a major issue
>>> right now.
>>>
>>> On 3/26/12, Steve Swinsburg <steve.swinsburg at gmail.com> wrote:
>>> > Oops, I forgot a status of ours. We have Testing in between Ready for
>>> > Test
>>> > and Closed.
>>> >
>>> > Anyway, I am -100 the idea of closing tickets as an indicator they are
>>> > tested. It was what we used to do in Jira 3 and worked ok, but in Jira
>>> > 4,
>>> > closing the tickets means they need to be reopened before you can edit
>>> > them,
>>> > ie to change the merge flag. This just disrupts everything and sends
>>> > out
>>> > new
>>> > notifications. Closing should mean its done, all work including QA is
>>> > done,
>>> > all merges are done, move on. I know you aren't suggesting this
>>> > Matthew,
>>> > just wanted to put it out there as an issue.
>>> >
>>> > I think a new field that indicates that an item is being tested is
>>> > fine.
>>> > But
>>> > you are also going to need one to indicate testing is complete.
>>> >
>>> > So the workflow could be:
>>> > Ticket created - Open/Unresolved
>>> > Developer works on ticket     - In progress (not always used, doesn't
>>> > matter too
>>> > much)
>>> > Developer resolves ticket - Resolved
>>> > QA person takes ticket - Testing
>>> > If issues in testing, reopen.
>>> > If no issues from testing, Verified/Testing complete
>>> > Merges are done and issue edited to set appropriate values on branch
>>> > merge
>>> > status fields
>>> > Issue closed.
>>> >
>>> > cheers,
>>> > S
>>> >
>>> > On 27/03/2012, at 10:06 AM, Matthew Jones wrote:
>>> >
>>> >> Well, as far as merging, the merging is indicated by the Merge status
>>> >> dropdown which mirrors the statuses of the the other fields including
>>> >> Merge, Resolved (Ready for Testing?), Closed (Tested).
>>> >>
>>> >> I believed that the ideal workflow involved closing the original
>>> >> ticket
>>> >> (which means it was verified) before the merge could happen. The
>>> >> branch
>>> >> manager would then set the merge drop down to Resolved. Then QA would
>>> >> test
>>> >> the branch, and set the Merge flag to Closed after they verified a
>>> >> branch.
>>> >> But we never had enough QA lately to test the initial issue, let alone
>>> >> whether or not the merge worked. And Sam is the only one really doing
>>> >> branch management.
>>> >>
>>> >> So we'd basically just merge as soon as that flag was set, if the
>>> >> issue
>>> >> was really a bug.
>>> >>
>>> >> I'm not against this new status, I just feel like it would be used as
>>> >> much
>>> >> as the "In Progress" status is. I can definitely see the value if
>>> >> there
>>> >> are multiple QA testers and they don't want other people duplicating
>>> >> effort. This rarely happens when fixing bugs though.
>>> >>
>>> >> -Matthew
>>> >>
>>> >> On Mon, Mar 26, 2012 at 6:27 PM, Aaron Zeckoski <azeckoski at unicon.net>
>>> >> wrote:
>>> >> We have an extra step of merging into branches at the moment which
>>> >> means we (Sakai) have something between Testing complete and Closed so
>>> >> that adds a bit more complexity and my preference is to take baby
>>> >> steps and not overcomplicate things.
>>> >>
>>> >> For now, I think we should just add an extra step in between the
>>> >> current "Resolved" and "Tested" statuses which indicates it is being
>>> >> tested. I don't think we should reassign it because that has some
>>> >> negative consequences in terns of reopening and it seems overly
>>> >> complex to create a subtask every time a ticket is being verified.
>>> >>
>>> >> If anyone is hugely against trying this for now then please let me
>>> >> know. Otherwise I will proceed with this first thing tomorrow.
>>> >>
>>> >> This stuff can all be changed later of course.
>>> >>
>>> >> -AZ
>>> >>
>>> >>
>>> >> On Mon, Mar 26, 2012 at 6:13 PM, Steve Swinsburg
>>> >> <steve.swinsburg at gmail.com> wrote:
>>> >> > At ANU we renamed some of the existing statuses and added a couple
>>> >> > more.
>>> >> >
>>> >> > So our workflow is:
>>> >> >
>>> >> > Open/Unresolved
>>> >> > In Progress
>>> >> > Resolved
>>> >> > Staged for Test (you could eliminate this one, it just signals that
>>> >> > an
>>> >> > issue
>>> >> > is on the testing server)
>>> >> > Ready for Test
>>> >> > Closed
>>> >> >
>>> >> > In regards to reassigning tickets when working on them, I think that
>>> >> > is
>>> >> > important so that people know what is happening. If more work needs
>>> >> > to
>>> >> > be
>>> >> > done, just reassign back to the original developer who worked on it.
>>> >> >
>>> >> > Alternatively we could start using the Project Roles more, and have
>>> >> > a
>>> >> > defined set of QA people, then adjust the notification scheme so
>>> >> > that
>>> >> > those
>>> >> > people get notified at the appropriate time.
>>> >> >
>>> >> > cheers,
>>> >> > Steve
>>> >> >
>>> >> > On 27/03/2012, at 4:51 AM, Matthew Jones wrote:
>>> >> >
>>> >> > Yea Jira never really had any good way of dealing with this
>>> >> > (identify
>>> >> > who is
>>> >> > testing it), and we've talked about it in the past. At Michigan we
>>> >> > ended
>>> >> > up
>>> >> > using a completely separate system (Pivotal Tracker) to manage the
>>> >> > QA
>>> >> > process because Jira alone just was not doing it. I believe that
>>> >> > solution
>>> >> > really ended up making things a lot more clearer than trying us use
>>> >> > wiki's,
>>> >> > jiras, text documents and emails.
>>> >> >
>>> >> > For multiple users on the same issue, the only really good idea they
>>> >> > have is
>>> >> > for subtasks (
>>> >> >
>>> >> >
>>> >> > https://confluence.atlassian.com/display/JIRA/How+do+I+assign+issues+to+multiple+users
>>> >> > )
>>> >> > and I'd even suggested in the past that we could use a plugin like
>>> >> > the
>>> >> > "Create subtask on transition"
>>> >> >
>>> >> >
>>> >> > (https://studio.plugins.atlassian.com/wiki/display/CSOT/Jira+Create+Subtask+for+transition
>>> >> > )
>>> >> > which would automatically create a subtask on each issue when it
>>> >> > hits
>>> >> > resolved that essentially was "Test SAK-XXXXX". When this was
>>> >> > resolved
>>> >> > then
>>> >> > both the parent and subtask were closed.
>>> >> >
>>> >> > However in the past this was basically dismissed because, well we've
>>> >> > got
>>> >> > hundreds of issues in the resolved state and nobody was reviewing
>>> >> > them
>>> >> > anyway (no QA) so what's the point? It just creates more useless
>>> >> > tickets
>>> >> > that won't be reviewed.
>>> >> >
>>> >> > I think the tester can watch it, the tester can comment "I'm testing
>>> >> > it",
>>> >> > but that should be about it. If we had people doing full time
>>> >> > testing
>>> >> > and
>>> >> > actually caught up (where all of these issues were closed) then
>>> >> > that's
>>> >> > fine.
>>> >> >
>>> >> > Is there a reason we can't just RENAME the current status from
>>> >> > saying
>>> >> > "Resolved" to "Resolved - Ready for Testing" and "Closed" to "Closed
>>> >> > -
>>> >> > Issue
>>> >> > Verified". What would another state get us?
>>> >> >
>>> >> > On Mon, Mar 26, 2012 at 1:35 PM, Noah Botimer <botimer at umich.edu>
>>> >> > wrote:
>>> >> >>
>>> >> >> I don't disagree. The emails are handy, and why I often Watch
>>> >> >> issues
>>> >> >> I've
>>> >> >> touched. Maybe that can be an automatic part of marking something
>>> >> >> Resolved
>>> >> >> (getting added as a watcher)?
>>> >> >>
>>> >> >> I was also reminded of something last week -- some people get tons
>>> >> >> of
>>> >> >> JIRA
>>> >> >> emails and they often go to a folder or just overlooked. In that
>>> >> >> mode,
>>> >> >> a
>>> >> >> direct contact is the only effective way forward, and it is
>>> >> >> probably
>>> >> >> a
>>> >> >> good
>>> >> >> practice anyway if there are questions.
>>> >> >>
>>> >> >> I think you're right about status + fix version, but I am
>>> >> >> interested
>>> >> >> in
>>> >> >> "who has the ball", which leaving the developer assigned doesn't
>>> >> >> seem
>>> >> >> to
>>> >> >> indicate.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> -Noah
>>> >> >>
>>> >> >> On Mar 26, 2012, at 1:21 PM, Bryan Holladay wrote:
>>> >> >>
>>> >> >> I'm not a big fan of re-assigning jira's for testing.  When you do
>>> >> >> that, the person who was originally assigned won't be notified of
>>> >> >> any
>>> >> >> comments/etc unless they physically clicked "watch" in the ticket.
>>> >> >> This is usually the person you want fixing any bugs found.
>>> >> >>
>>> >> >> how about:
>>> >> >>
>>> >> >> Resolved + Fix version means it's ready for testing
>>> >> >> Closed + fix version means it's tested and confirmed
>>> >> >>
>>> >> >> -Bryan
>>> >> >>
>>> >> >> On Mon, Mar 26, 2012 at 1:11 PM, Noah Botimer <botimer at umich.edu>
>>> >> >> wrote:
>>> >> >>
>>> >> >> Is this something we can handle with assignment of the issue? Any
>>> >> >> mechanism is going to require some diligence to be useful --
>>> >> >> they're
>>> >> >> all
>>> >> >> roughly equivalent there. But, I think the "who is the contact for
>>> >> >> this
>>> >> >> issue?" question is pretty important. If you are going to commit to
>>> >> >> testing
>>> >> >> it (claim it), assigning to yourself is a good way to do that.
>>> >> >>
>>> >> >>
>>> >> >> I am just a little hesitant to add more interim states -- our
>>> >> >> workflow
>>> >> >> and
>>> >> >> reports are complicated enough as it is. If it's a matter of
>>> >> >> access,
>>> >> >> our few
>>> >> >> known QA folks should definitely be able to assign/unassign issues
>>> >> >> across
>>> >> >> the board.
>>> >> >>
>>> >> >>
>>> >> >> This is just a thought -- I won't be hurt if we end up with another
>>> >> >> status. I just think Resolved + Unassigned is a good way to say
>>> >> >> "this
>>> >> >> needs
>>> >> >> testing" and Resolved + Assigned is a good way to say "this is
>>> >> >> being
>>> >> >> tested". It may alternatively make sense to set up a mail
>>> >> >> group/account
>>> >> >> like
>>> >> >> KERNEL TEAM for QA, and make it the default assignee for newly
>>> >> >> resolved
>>> >> >> issues (for an activity email push for those interested and easier
>>> >> >> reports
>>> >> >> of items needing to be tested).
>>> >> >>
>>> >> >>
>>> >> >> Thanks,
>>> >> >>
>>> >> >> -Noah
>>> >> >>
>>> >> >>
>>> >> >> On Mar 26, 2012, at 12:53 PM, Aaron Zeckoski wrote:
>>> >> >>
>>> >> >>
>>> >> >> It isn't too much trouble. I could probably get to that later
>>> >> >> today.
>>> >> >>
>>> >> >> -AZ
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Mar 26, 2012 at 12:48 PM, Diego del Blanco Orobitg
>>> >> >>
>>> >> >> <diego.delblanco at samoo.es> wrote:
>>> >> >>
>>> >> >> Ok, Simple way at this moment: add a comment with the "testing"
>>> >> >> message
>>> >> >> in
>>> >> >> the Jira.
>>> >> >>
>>> >> >> Anyway, maybe "testing" intermediate status between Resolved-fixed
>>> >> >> and
>>> >> >> Verified can be useful but as you say if doing it it's not too much
>>> >> >> trouble.
>>> >> >>
>>> >> >>
>>> >> >> Diego.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> -----Mensaje original-----
>>> >> >>
>>> >> >> De: azeckoski at gmail.com [mailto:azeckoski at gmail.com] En nombre de
>>> >> >> Aaron
>>> >> >> Zeckoski
>>> >> >>
>>> >> >> Enviado el: lunes, 26 de marzo de 2012 13:39
>>> >> >>
>>> >> >> Para: Diego del Blanco Orobitg
>>> >> >>
>>> >> >> CC: Miguel Carro Pellicer; Rob.Egan at marist.edu;
>>> >> >> cle-release-team at collab.sakaiproject.org
>>> >> >>
>>> >> >> Asunto: Re: [cle-release-team] [Building Sakai] [WG: Sakai QA]
>>> >> >> Sakai
>>> >> >> CLE
>>> >> >> 2.9.0 release status
>>> >> >>
>>> >> >>
>>> >> >> I would encourage you ro think of a process that uses jira itself
>>> >> >> as
>>> >> >> a
>>> >> >> way
>>> >> >> to know if an issue is being tested. This may be an adjustment in
>>> >> >> the
>>> >> >> JIRA
>>> >> >> workflow but I can make that without too much trouble. The problem
>>> >> >> with
>>> >> >> the
>>> >> >> google docs thing is that it doesn't scale up very well and it
>>> >> >> requires
>>> >> >> insider knowledge so it is a barrier to community participation.
>>> >> >>
>>> >> >>
>>> >> >> Also, in the current workflow, there is a "Verified" status which
>>> >> >> is
>>> >> >> what
>>> >> >> issues should be set to when testing is complete. So anything not
>>> >> >> verified
>>> >> >> yet will be marked as "resolved - fixed" and once testing is
>>> >> >> complete
>>> >> >> it is
>>> >> >> marked as "verified".
>>> >> >>
>>> >> >>
>>> >> >> -AZ
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Mon, Mar 26, 2012 at 6:58 AM, Diego del Blanco Orobitg
>>> >> >> <diego.delblanco at samoo.es> wrote:
>>> >> >>
>>> >> >> Dear Rob:
>>> >> >>
>>> >> >>
>>> >> >> We are going to begin to test the jira issues as Aaron said. To
>>> >> >> coordinate
>>> >> >> with you and don't duplicate work, we can create a shared document
>>> >> >> (in
>>> >> >> google docs or in a confluence page...), where each time one of us
>>> >> >> selects a
>>> >> >> jira to test, we need to add it to the document, so it's easy to
>>> >> >> check
>>> >> >> if an
>>> >> >> issue is "in use" at that moment. There is only need to search in
>>> >> >> the
>>> >> >> document. If it's not, then it's free.
>>> >> >>
>>> >> >>
>>> >> >> And in that way we have the full list of jiras tested by each one
>>> >> >> too.
>>> >> >>
>>> >> >>
>>> >> >> Aaron do you think this is good way or do you recommend other way
>>> >> >> as
>>> >> >> can
>>> >> >> be to put comments directly on Jira's indicating that we are
>>> >> >> working
>>> >> >> on
>>> >> >> this
>>> >> >> issue?
>>> >> >>
>>> >> >>
>>> >> >> I think in the shared document will be quicker to search "free
>>> >> >> issues"
>>> >> >> to
>>> >> >> work with.
>>> >> >>
>>> >> >>
>>> >> >> Other question... Once tested a Jira if everything is ok.. do we
>>> >> >> need
>>> >> >> to
>>> >> >> modify something in the Jira (add a comment or change state) or
>>> >> >> only
>>> >> >> communicate it to the team?
>>> >> >>
>>> >> >>
>>> >> >> Thanks
>>> >> >>
>>> >> >>
>>> >> >> Diego.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> -----Mensaje original-----
>>> >> >>
>>> >> >> De: azeckoski at gmail.com [mailto:azeckoski at gmail.com] En nombre de
>>> >> >>
>>> >> >> Aaron Zeckoski Enviado el: viernes, 23 de marzo de 2012 22:36
>>> >> >>
>>> >> >> Para: Miguel Carro Pellicer; Rob.Egan at marist.edu; Diego del Blanco
>>> >> >>
>>> >> >> Orobitg
>>> >> >>
>>> >> >> CC: Sam Ottenhoff; cle-release-team at collab.sakaiproject.org
>>> >> >>
>>> >> >> Asunto: Re: [Building Sakai] [WG: Sakai QA] Sakai CLE 2.9.0 release
>>> >> >>
>>> >> >> status
>>> >> >>
>>> >> >>
>>> >> >> Samoo guys,
>>> >> >>
>>> >> >> Here is the filter of items to QA in order for 2.9. There are quite
>>> >> >> a
>>> >> >> few
>>> >> >> (over 600) and there will be more coming in the following weeks.
>>> >> >>
>>> >> >> Just start cranking through them and you can give a status update
>>> >> >> at
>>> >> >> the
>>> >> >> meeting next week.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?mode=hide&req
>>> >> >>
>>> >> >> uestId=13243
>>> >> >>
>>> >> >>
>>> >> >> I am copying in Rob from Marist since he does some QA as well and
>>> >> >> you
>>> >> >> guys
>>> >> >> might want to coordinate some.
>>> >> >>
>>> >> >>
>>> >> >> -AZ
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> El 22/03/2012 14:07, Aaron Zeckoski escribió:
>>> >> >>
>>> >> >>
>>> >> >> Yes, they are always at 10am US NY time on thursdays.
>>> >> >>
>>> >> >> I will double check with the group and send you something later
>>> >> >> today
>>> >> >> (maybe a JIRA filter with a series of tickets in it).
>>> >> >>
>>> >> >> -AZ
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Mar 22, 2012 at 9:03 AM, Miguel Carro Pellicer
>>> >> >> <miguel.carro at samoo.es> wrote:
>>> >> >>
>>> >> >>
>>> >> >> Got it, i think we can help in those activities.
>>> >> >>
>>> >> >>
>>> >> >> Assign me some Jiras and we will verify/validate each ticket in the
>>> >> >> affected QA servers. Additionaly, we can propose a solution if the
>>> >> >> Jira
>>> >> >> requires a developer intervention.
>>> >> >>
>>> >> >>
>>> >> >> Usually the meetings are at the same hour? We're in GMT+1
>>> >> >>
>>> >> >>
>>> >> >> Regards, Miguel.
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> _______________________________________________
>>> >> >> cle-release-team mailing list
>>> >> >> cle-release-team at collab.sakaiproject.org
>>> >> >> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> >> >>
>>> >> >
>>> >> > _______________________________________________
>>> >> > cle-release-team mailing list
>>> >> > cle-release-team at collab.sakaiproject.org
>>> >> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > cle-release-team mailing list
>>> >> > cle-release-team at collab.sakaiproject.org
>>> >> > http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>>> >>
>>> >
>>> >
>>
>>
>>
>> _______________________________________________
>> cle-release-team mailing list
>> cle-release-team at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>>
>
>
>
> --
> Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile
>
>
>
>
>
> ________________________________
>
> No se encontraron virus en este mensaje.
> Comprobado por AVG - www.avg.com
> Versión: 2012.0.1913 / Base de datos de virus: 2114/4895 - Fecha de
> publicación: 03/26/12
>
> ________________________________
>
> No se encontraron virus en este mensaje.
>
>
> Comprobado por AVG - www.avg.com
> Versión: 2012.0.1913 / Base de datos de virus: 2114/4896 - Fecha de
> publicación: 03/26/12
>
>
> _______________________________________________
> cle-release-team mailing list
> cle-release-team at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/cle-release-team
>

-- 
Aaron Zeckoski - Software Architect - http://tinyurl.com/azprofile