Re: [RESULT][VOTE] [APACHE FINERACT] 1.1.0 Release

2018-03-23 Thread Phil Steitz


> On Mar 23, 2018, at 5:39 AM, Avik Ganguly  wrote:
> 
> Hello all,
> 
> Voting for Apache Fineract 1.1.0 is now closed. The release has
> passed this step of process.
> 
> The vote breakdown is as follows:
> 
> +1 Avik Ganguly
> +1 Sendoro Juma
> +1 Santosh Math
> +1 Mexina Daniel
> +1 Nayan Ambali
> +1 Steve Conrad
> +1 Ed Cable
> +1 Zayyad Said
> +1 Awasum Yannick
> +1 Nikhil Pawar
> +1 Isaac Kamga
> +1 Ippez Robert
> 
> *Total: +12*
> 
> Now we are going ahead for vote on the gene...@apache.org list.

There is no need for any other vote.   All you need is at least 3 +1 votes from 
fineract PMC members and more positive than negative votes (among PMC members). 
 Are all of the people above on the PMC?  It’s a good practice to mark the PMC 
members with a * in the vote tally or write (binding) next to their names.  
This is because only votes from PMC members count in determining the decision 
to release.  All interested parties are encouraged to test the release and 
vote, but it’s the PMC member votes that determine the outcome.

Phil



> Thank you all for your inputs and votes.
> 
> Thanks,
> Avik.


Re: Fineract - Export Authorization

2018-03-22 Thread Phil Steitz
On 3/21/18 6:59 PM, Victor Manuel Romero Rodriguez wrote:
> Hi Myrle,
>
> Thank you for your response. I'm looking for information too, and
> I would like to contribute in this point, right now customers in
> Mexico, which are now looking at the OSS projects like Fineract
> have this questions and if we can help, would be great.
>
> I will come back with our 2 bucks.

Thanks, Victor!

Good places to start looking are [1] and  the page you posted below [2].

IANAL, but I think the key thing to determine first is does Fineract
include any crypto code of its own or bundle any third party
libraries including crypto?  If so, we need to follow the process
described in [1].

Does anyone know if fineract sources include crypto code or if there
is any bundled dependency that includes this?

If you have questions about what counts as crypto, etc, you can
subscribe and post questions to [3]

Phil
[1] http://www.apache.org/dev/crypto.html
[2] http://www.apache.org/licenses/exports/
[3] http://www.apache.org/foundation/mailinglists.html#foundation-legal


>
> Victor
>
>
> El 21/03/18 a las 01:31, Myrle Krantz escribió:
>> Hi Victor,
>>
>> To my knowledge, no committer or contributor has tried to figure
>> out what
>> we need to do here. If you want to step in here, your
>> contributions are
>> welcome!
>>
>> I’m not sure how to find out the next steps, but I’d start by
>> searching
>> through the mailing lists of projects that are in the incubator
>> and on the
>> list you sent us.
>>
>> Best Regards,
>> Myrle
>>
>> On Tue 20. Mar 2018 at 20:36 Victor Manuel Romero Rodriguez <
>> victor.rom...@fintecheando.mx> wrote:
>>
>>> Hello Fineract Team,
>>>
>>> Recently in Mexico as part of the FinTECH regulations our
>>> customers ask
>>> us about the licenses I have the link of ASF about export
>>> licenses, but
>>> I am unable to locate Fineract
>>>
>>> http://www.apache.org/licenses/exports/
>>>
>>> Is there any link/information related to the Export Authorization
>>> License/compliance of Apache Fineract ?
>>>
>>> Regards
>>>
>>> Victor
>>>
>
>



Re: Fwd: Releasing Apache Fineract 1.1 WAS [Fwd: Intergration test]

2018-03-19 Thread Phil Steitz
On 3/19/18 3:22 PM, Avik Ganguly wrote:
> Hi  Phil / Nazeer,
>
> Thanks for sharing all the details. It was really helpful.
>
> One small question regarding the published keys file to which I
> appended my key through the following command :-
>
> (gpg --list-sigs  && gpg --armor --export ) >> KEYS
>
> It added only 1 key to the file whereas the previous version of
> the file had 3 keys from Nazeer. Where did he / you obtain 3 keys
> from?
Your key got added.  I don't know where they came from, but the
others in there are:

gpg: key 8CB2BDA8B983100D: public key "Adi Raju (CODE SIGNING KEY
FOR APACHE FINERACT) <raj...@apache.org>"
gpg: key DAB52C0F0CB6C40C: public key "Shaik Nazeer Hussain (CODE
SIGNING KEY) <nazeer.sh...@confluxtechnologies.com>"
gpg: key 80C4D8890BB29444: public key "Shaik Nazeer Hussain (CODE
SIGNING KEY) <nazeer1100...@apache.org>"

I can check the sigs once you commit signed RC artifacts.  Don't
hesitate to ask if you have more questions.

Phil

>
> Regards,
> Avik.
>
> On Fri, Mar 16, 2018 at 9:27 PM, Ed Cable <edca...@mifos.org
> <mailto:edca...@mifos.org>> wrote:
>
> Phil,
>
> Thanks for taking all the time to put forth the detailed
> reply. The help is greatly appreciated as we've been aiming to
> get this release out for a while now and ran into these
> hurdles when our normal release manager wasn't available.
>
> Avik - do you have the required information you need to proceed?
>
> Thanks,
>
> Ed
>
> On Thu, Mar 15, 2018 at 1:05 PM, Phil Steitz
> <phil.ste...@gmail.com <mailto:phil.ste...@gmail.com>> wrote:
>
> On 3/14/18 5:34 AM, Myrle Krantz wrote:
> > Can someone who's done this before help Avik please?
> >
> > (cc'ing the mentor and the two PMC members who are most
> likely to be
> > able to provide concrete help.)
>
> Sorry, my response yesterday was probably not helpful.  It
> looks
> like you are on the PMC roster, Avik, so you should have
> the svn
> karma to access both
>
> /dist/dev/fineract/ (for RCs) and /dist/release/fineract/
> (for the actual release).
>
> Here is one way to do this, assuming that you want to
> stage the RC artifacts in /dist/dev, then vote, and then
> move them to /dist/release
>
> 1.  Create local directories called, say "fineract_rc" and
> "fineract_release"
> 2.  svn checkout
> https://dist.apache.org/repos/dist/dev/fineract/
> <https://dist.apache.org/repos/dist/dev/fineract/> into
> fineract_rc
> That will pull down all of the previous RC artifacts.  I
> was going to recommend that you clean out the old
> artifacts in this directory, but I can only find some of
> them in http://archive.apache.org/dist/fineract/
> <http://archive.apache.org/dist/fineract/>, so we should
> make sure that the others were never released before
> deleting them (which we should eventually do - its best to
> keep /dev just as staging for the latest RC)
> 3.  svn add the new artifacts to this checkout.
> 4.  svn commit -m "Publishing fineract 1.1 RC1"
> 5.  Send out a link to the subdirectory with the RC
> artifacts in the VOTE.  Also include a reference to the
> svn revision number of the /dev repo and the tag that the
> artifacts were built from (since the rc number is not in
> the name).  Here is an example (ignore all of the maven
> repo stuff):  https://s.apache.org/CCOX
>
> Repeat 3-5 until VOTE passes, incrementing RC number in
> announcement (but not in artifact names)
>
> 6.  svn checkout
> https://dist.apache.org/repos/dist/release/fineract/
> <https://dist.apache.org/repos/dist/release/fineract/>
> into fineract_release
> 7.  svn move the artifacts that passed the vote from
> fineract_rc to fineract_release
> 8.  verify that everything is in the right place in
> fineract_release
> 9.  svn commit -m "Publishing 1.1 release." from
> fineract_release
> 10. Update references on the web page, wait 12+ hours for
> mirrors to pick up the files, test download links, then
> send release announcement
>
> Example scripts that automate these steps with a slightly
> different layout are here:  https://s.apache.org/Ep4u
> (look at the -RC.sh and -rel

Re: Fwd: Releasing Apache Fineract 1.1 WAS [Fwd: Intergration test]

2018-03-15 Thread Phil Steitz
On 3/14/18 5:34 AM, Myrle Krantz wrote:
> Can someone who's done this before help Avik please?
>
> (cc'ing the mentor and the two PMC members who are most likely to be
> able to provide concrete help.)

Sorry, my response yesterday was probably not helpful.  It looks
like you are on the PMC roster, Avik, so you should have the svn
karma to access both

/dist/dev/fineract/ (for RCs) and /dist/release/fineract/ (for the actual 
release).

Here is one way to do this, assuming that you want to stage the RC artifacts in 
/dist/dev, then vote, and then move them to /dist/release

1.  Create local directories called, say "fineract_rc" and "fineract_release"
2.  svn checkout https://dist.apache.org/repos/dist/dev/fineract/ into 
fineract_rc
That will pull down all of the previous RC artifacts.  I was going to recommend 
that you clean out the old artifacts in this directory, but I can only find 
some of them in http://archive.apache.org/dist/fineract/, so we should make 
sure that the others were never released before deleting them (which we should 
eventually do - its best to keep /dev just as staging for the latest RC)
3.  svn add the new artifacts to this checkout.
4.  svn commit -m "Publishing fineract 1.1 RC1" 
5.  Send out a link to the subdirectory with the RC artifacts in the VOTE.  
Also include a reference to the svn revision number of the /dev repo and the 
tag that the artifacts were built from (since the rc number is not in the 
name).  Here is an example (ignore all of the maven repo stuff):  
https://s.apache.org/CCOX

Repeat 3-5 until VOTE passes, incrementing RC number in announcement (but not 
in artifact names)

6.  svn checkout https://dist.apache.org/repos/dist/release/fineract/ into 
fineract_release
7.  svn move the artifacts that passed the vote from fineract_rc to 
fineract_release
8.  verify that everything is in the right place in fineract_release
9.  svn commit -m "Publishing 1.1 release." from fineract_release
10. Update references on the web page, wait 12+ hours for mirrors to pick up 
the files, test download links, then send release announcement

Example scripts that automate these steps with a slightly different layout are 
here:  https://s.apache.org/Ep4u (look at the -RC.sh and -release.sh files)

hth,

Phil

 
>
> Thanks,
> Myrle
>
>
> -- Forwarded message --
> From: Avik Ganguly 
> Date: Wed, Mar 14, 2018 at 1:12 PM
> Subject: Re: Releasing Apache Fineract 1.1 WAS [Fwd: Intergration test]
> To: Ed Cable 
> Cc: Dev , Nikhil Pawar ,
> Kumaranath Fernando , Vishwas Babu A J
> , Nazeer Hussain Shaik
> , Santosh Math
> 
>
>
> Hey,
>
> Bump. Looking for someone who did this step before regarding uploading the
> binary and src artifacts to  https://dist.apache.org/
> repos/dist/dev/fineract/.
>
> This is a blocker for release.
>
> Regards,
> Avik.
>
> On Sat, Mar 10, 2018 at 2:12 AM, Avik Ganguly 
> wrote:
>
>> Hi guys,
>>
>> As per release sign documentation, a directory needs to be created at
>> https://dist.apache.org/repos/dist/dev/incubator/fineract which I am
>> unable to access (even https://dist.apache.org/repos/dist/dev/fineract/).
>>
>> @Nazeer / Ed,
>>
>> I have uploaded the release files to this link
>> 
>> instead as I can't find documentation to upload release to above links.
>>
>> I have not included the MD5 files as per the new policy change.
>>
>>
>> Regards,
>> Avik.
>>
>> On Fri, Mar 2, 2018 at 10:26 PM, Ed Cable  wrote:
>>
>>> Avik,
>>>
>>> I checked the JIRA native link itself and those seem to be up to date
>>> with all the recent issues that have been fixed. I don't think there was
>>> any JIRA ticket related to the notifications issue that Steve fixed but it
>>> was all part of the work that was in
>>>
>>>- [FINERACT-585 ]
>>>- Allow predefined SMS messages and Emails to be sent via existing
>>>SMS/Email implementations
>>>
>>>
>>> which is reflected in the release notes.
>>>
>>> Are you able to do the needful to move forward with this release?
>>>
>>> Thanks,
>>>
>>> Ed
>>>
>>> On Tue, Feb 27, 2018 at 1:36 PM, Avik Ganguly 
>>> wrote:
>>>
 Hi guys,

 Is Steve's changes getting reflected in the release notes
 
 ?

 If the release notes is up to date, I can give the release this Thursday
 after merging one pending item from my side.

 Regards,
 Avik.

 On Sun, Feb 25, 2018 at 9:13 PM, Ed Cable  wrote:

> Fineract committers,
>
> Now that the PRs have been 

Re: Releasing Apache Fineract 1.1 WAS [Fwd: Intergration test]

2018-03-14 Thread Phil Steitz


> On Mar 14, 2018, at 7:34 AM, Myrle Krantz  wrote:
> 
> Can someone who's done this before help Avik please?
> 
> (cc'ing the mentor and the two PMC members who are most likely to be
> able to provide concrete help.)


Have a look at the “normal publication” section here:
http://www.apache.org/dev/release-publishing.html

Someone with svn karma to the fineract dist directory in the svn repo 
referenced there needs to commit the artifacts.

Phil
> 
> Thanks,
> Myrle
> 
> 
> -- Forwarded message --
> From: Avik Ganguly 
> Date: Wed, Mar 14, 2018 at 1:12 PM
> Subject: Re: Releasing Apache Fineract 1.1 WAS [Fwd: Intergration test]
> To: Ed Cable 
> Cc: Dev , Nikhil Pawar ,
> Kumaranath Fernando , Vishwas Babu A J
> , Nazeer Hussain Shaik
> , Santosh Math
> 
> 
> 
> Hey,
> 
> Bump. Looking for someone who did this step before regarding uploading the
> binary and src artifacts to  https://dist.apache.org/
> repos/dist/dev/fineract/.
> 
> This is a blocker for release.
> 
> Regards,
> Avik.
> 
> On Sat, Mar 10, 2018 at 2:12 AM, Avik Ganguly 
> wrote:
> 
>> Hi guys,
>> 
>> As per release sign documentation, a directory needs to be created at
>> https://dist.apache.org/repos/dist/dev/incubator/fineract which I am
>> unable to access (even https://dist.apache.org/repos/dist/dev/fineract/).
>> 
>> @Nazeer / Ed,
>> 
>> I have uploaded the release files to this link
>> 
>> instead as I can't find documentation to upload release to above links.
>> 
>> I have not included the MD5 files as per the new policy change.
>> 
>> 
>> Regards,
>> Avik.
>> 
>>> On Fri, Mar 2, 2018 at 10:26 PM, Ed Cable  wrote:
>>> 
>>> Avik,
>>> 
>>> I checked the JIRA native link itself and those seem to be up to date
>>> with all the recent issues that have been fixed. I don't think there was
>>> any JIRA ticket related to the notifications issue that Steve fixed but it
>>> was all part of the work that was in
>>> 
>>>   - [FINERACT-585 ]
>>>   - Allow predefined SMS messages and Emails to be sent via existing
>>>   SMS/Email implementations
>>> 
>>> 
>>> which is reflected in the release notes.
>>> 
>>> Are you able to do the needful to move forward with this release?
>>> 
>>> Thanks,
>>> 
>>> Ed
>>> 
>>> On Tue, Feb 27, 2018 at 1:36 PM, Avik Ganguly 
>>> wrote:
>>> 
 Hi guys,
 
 Is Steve's changes getting reflected in the release notes
 
 ?
 
 If the release notes is up to date, I can give the release this Thursday
 after merging one pending item from my side.
 
 Regards,
 Avik.
 
> On Sun, Feb 25, 2018 at 9:13 PM, Ed Cable  wrote:
> 
> Fineract committers,
> 
> Now that the PRs have been submitted for all the outstanding critical
> bug fixes and integration test failures, can we please review, merge, and
> get the release prepped and call for the vote!
> 
> As you know the community has waiting on this for quite some time now
> and I"d like to get this shipped and shift focuses to Fineract 1.2
> 
> Thanks!
> 
> Ed
> -- Forwarded message --
> From: Ed Cable 
> Date: Sun, Feb 18, 2018 at 4:49 AM
> Subject: Re: Intergration test
> To: Dev 
> Cc: Vishwas Babu A J , Nazeer Hussain
> Shaik , Kumaranath Fernando <
> kumaranathferna...@gmail.com>, Avik Ganguly ,
> Nikhil Pawar , Santosh Math <
> sant...@confluxtechnologies.com>
> 
> 
> Great!
> 
> Committers, can you please review?
> 
> Nazeer, with this fix and Steve's for the notification, I think we're
> ready to move forward. Can you initiate the next steps in the release
> process?
> 
> Thanks,
> 
> Ed
> 
> On Sat, Feb 17, 2018 at 11:20 AM, Kumaranath Fernando <
> kumaranathferna...@gmail.com> wrote:
> 
>> Hi Ed!
>> 
>> I've just sent a PR 
>> correcting the integration test failures.
>> 
>> Regards,
>> Kumaranath Fernando
>> 
>>> On Fri, Feb 16, 2018 at 6:14 PM, Ed Cable  wrote:
>>> 
>>> Thanks for the feedback Vishwas. Kumaranath, hopefully you have
>>> enough to go by now and can make those changes. I believe Steve fixed 
>>> our
>>> other outstanding 

Re: Getting started on Fineract CN

2018-03-01 Thread Phil Steitz
On 3/1/18 10:34 AM, Myrle Krantz wrote:
> Hey Isaac,
>
> At a first glance, it looks good.  May I ask though why you removed
> the license parameter strictCheck?
>
> Regards,
> Myrle

The copyright statement should be removed entirely from the source
header files and placed instead in NOTICE.txt.

See http://www.apache.org/legal/src-headers.html

Phil
>
> On Thu, Mar 1, 2018 at 5:27 PM, Isaac Kamga  wrote:
>> Hi Myrle,
>>
>> I've just updated copyright information in fineract-cn-lang and created a
>> new pull request .
>>
>> I patiently await your review and possible merger.
>>
>> At Your Service,
>> Isaac Kamga.
>>
>> On Thu, Mar 1, 2018 at 5:05 PM, Isaac Kamga  wrote:
>>
>>> Hi Myrle,
>>>
>>> Thanks a million for your advice and guidance on this.
>>>
>>> I've closed the Pull Request, will do appropriate changes and send in
>>> another for review.
>>>
>>> At Your Service,
>>> Isaac Kamga.
>>>
>>> On Thu, Mar 1, 2018 at 4:56 PM, Myrle Krantz  wrote:
>>>
 Hey Isaac,

 Replies inline:

 On Thu, Mar 1, 2018 at 1:20 PM, Isaac Kamga 
 wrote:
> I have just updated the copyright information and package name on the
> fineract-cn-lang repository and sent in another pull request
>  for review.
 Please make a pull request with *just* the copyright information
 adjusted.  Changing package names is a backwards incompatible change.
 By changing them, you break everything that depends on lang.  And all
 of the other fineract cn repositories depend on lang.  Package names
 will have to be changed in all the repositories at once.

 We will have to continue to be careful about backwards compatible
 changes until we have three things:
 * signature checking
 * our artifacts in an artifactory
 * an established process of incrementing versions.

 Because changing package names is a global change and changing
 copyright information can be done locally, one repository at a time, I
 believe we should adjust the copyright information first.

> On a related note, I'd like to ask experienced developers on Fineract
 CN if
> it would be necessary to change the project's name ( from *lang* to
> *fineract-cn-lang* ) in the settings.gradle
> 
> file.
 I don't see any reason to change those names.  the project's name is
 appended to the artifact id.  If we did this, the artifact id in this
 case would be org.apache.fineract.cn.fineract-cn-lang.  It would
 contain duplicated information.  Of course we could adjust the build
 elsewhere to change the artifact id back to lang.  But i don't see a
 benefit in changing the project name.

 But perhaps I'm missing something here?

> Also, in the bintray.pkg section of the build.gradle file
> ,
> should the `repo` , `userOrg` and `vcsUrl` variables be changed too ?
 These
> will help with subsequent updates to fineract-cn-api,
> fineract-cn-cassandra, etc.
 Oops!  Good catch.  We can delete the bintray section in that
 build.gradlel file until we're ready to introduce the use of the
 apache artifactory.  I don't think you'll find a section like that in
 any other fineract cn project.  I was experimenting there.

 Thank you for taking this on Isaac,
 Myrle

>>>



Fwd: Re: Getting started on Fineract CN

2018-02-26 Thread Phil Steitz

Forgot to copy the list...

 Forwarded Message 
Subject:Re: Getting started on Fineract CN
Date:   Mon, 26 Feb 2018 16:38:56 -0700
From:   Phil Steitz <phil.ste...@gmail.com>
To: Myrle Krantz <my...@apache.org>



On 2/26/18 2:01 PM, Myrle Krantz wrote:
> Hey Phil,
>
> On Mon, Feb 26, 2018 at 8:13 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
>> We should replace the source headers with standard headers.  The SGA
>> entitles us to do that.  We *can* include copyright notices citing
>> the original authors in NOTICE.txt, but should only do so if that
>> has been requested by the grantors.
> Thank you for the information.  I'll do a simple replace, like you suggest.
>
>> I just did that.  To make this easier, I created a list of repos
>> based on the github query you posted.  I use bash one-liners to do
>> the clones, pulls and (attempted) builds.  For example, the build
>> locally one does this:
>>
>> cat $1 | while read in; do cd "$in"; echo "updating and publishing
>> $in"; git pull; chmod +x gradlew; ./gradlew PublishToMavenRepo; cd
>> ..; done
>>
>> where the command line arg is the file with just the repo names in
>> it.  The problem I am now having is that the order of the repos in
>> the file is just random and there appears to be a required build
>> order.  I am pretty new to gradle, but in maven the reactor would
>> take care of figuring that out.  I will try to figure it out and fix
>> the order of the file, clean up the scripts and post them
>> somewhere.  Or someone who actually knows gradle can create
>> something like a fineract-cn-parent thingy whose build does all of
>> this.  Or I learn that this is all easily done using some gradle
>> commands that I don't know :)
> We have a script like this in the demo-server project.  You can find
> it under fineract-cn-demo-server/scripts

Doh!  I should have seen that.  Does pretty much exactly what I was
fumbling with.

>   To be honest I don't use it;
> I work from my own knowledge of the dependencies, but I know it's
> ridiculous to ask that of anyone else.  We definitely need to improve
> this area.
>
> Other people have complained that there things missing or that it
> doesn't work under certain OSes, or that it doesn't work consistently.

The key is to get people directed to whatever we have in place and
improve it over time.  Once I have fully succeeded, I will submit a
doco patch that points people in the right direction to get started.
>
> I personally would prefer a gradle parent project like the one you
> describe.  But ultimately I'd like for everything to be in an
> artifactory so that in most cases, you only have to build the projects
> you are making changes to.  We have a bit of work to do before we get
> there though.

I don't know gradle well enough to know how much work that would be,
but no time like the present to learn something new :)
>
> In the meantime, I think several people would very much appreciate any
> improvements you might offer for the scripts.
>
> Once I've gotten the headers updated, and the packages straightened
> out, I'd like to start putting things in an artifactory.  I haven't
> gone exploring to figure out how other Apache projects work with
> unreleased build-snapshots though, which we'll need for this.  Do you
> know of any other projects at Apache which upload build-snapshots of
> unreleased code to an artifactory?
Yes, lots of projects use
https://repository.apache.org/snapshots/

There is an argument though that if it can be easily greased, the
pull-and-publish locally model may be just as good.  Once we have
releases, we can move to depending on released artifacts.  I guess
it depends on how much breakage happens / how current you need your
snaps to be.

Phil
>
> Best Regards,
> Myrle
>



Re: Getting started on Fineract CN

2018-02-26 Thread Phil Steitz
On 2/26/18 10:48 AM, Myrle Krantz wrote:
> Hey Phil,
>
> Thanks for the feedback.  I've just updated the artifact ids to apache
> fineract.  It's not the only place we need to replace Mifos with
> Apache Fineract though.
>
> Other places are:
> * the package names
> * a couple of variables in build scripts
> * the copyright notice headers in the source files.
>
> On that last point I have a question which you are probably a good
> person to ask: Can I just replace Mifos and Kuelap with Apache?  Or we
> need to do something more complicated there.

We should replace the source headers with standard headers.  The SGA
entitles us to do that.  We *can* include copyright notices citing
the original authors in NOTICE.txt, but should only do so if that
has been requested by the grantors.
>
> In the mean time, and with apologies, I strongly suggest you repull
> all the fineract repositories so that you are working with up-to-date
> artifact ids.

I just did that.  To make this easier, I created a list of repos
based on the github query you posted.  I use bash one-liners to do
the clones, pulls and (attempted) builds.  For example, the build
locally one does this:

cat $1 | while read in; do cd "$in"; echo "updating and publishing
$in"; git pull; chmod +x gradlew; ./gradlew PublishToMavenRepo; cd
..; done

where the command line arg is the file with just the repo names in
it.  The problem I am now having is that the order of the repos in
the file is just random and there appears to be a required build
order.  I am pretty new to gradle, but in maven the reactor would
take care of figuring that out.  I will try to figure it out and fix
the order of the file, clean up the scripts and post them
somewhere.  Or someone who actually knows gradle can create
something like a fineract-cn-parent thingy whose build does all of
this.  Or I learn that this is all easily done using some gradle
commands that I don't know :)

Phil
>
> Best Regards,
> Myrle
>
>
>
> On Mon, Feb 26, 2018 at 6:25 PM, Phil Steitz <phil.ste...@gmail.com> wrote:
>> On 2/26/18 12:52 AM, Markus Geiss wrote:
>>> Hey Phil,
>>>
>>> given all repos got pushed as is, I guess one of the first tasks is to
>>> rename
>>> all packages and projects to fit into the Apache layout.
>>>
>>> If you just want to get started now, you need to call
>>>
>>>   ./gradelw publishToMavenLocal (assuming a *nix OS)
>>>
>>> for every project. You should be able to adjust and run the
>>> initial setup script found at the demo-server.
>> Thanks, Markus.  I have started just doing the installs using the
>> mifos packaging.  Once I get that working, I will start working on a
>> repackaging PR.
>>
>> Phil
>>> Cheers
>>>
>>> Markus
>>>
>>> .::Yagni likes a DRY KISS::.
>>>
>>> On Sun, Feb 25, 2018 at 10:18 PM Phil Steitz <phil.ste...@gmail.com> wrote:
>>>
>>>> I would like to start contributing to CN.  I have cloned all of the
>>>> repos and thought it would be a good first step to build the
>>>> demo-server.  The readme for that component says that as a
>>>> precondition, "All Mifos I/O projects must be published to your
>>>> local Maven repository."  I assume that now means some subset of all
>>>> of the fineract-cn components.   But in build.gradle, I see
>>>> references to mifos components.  Do I maybe need to just replace
>>>> these with the fineract-cn versions and install these locally using
>>>> "gradle publisToMavenLocal" from each of these repos?
>>>>
>>>> I am happy to provide doco and config patches as I get this working
>>>> if I can get pointed in the right direction.   Thanks in advance!
>>>>
>>>> Phil
>>>>
>>>>



Re: Getting started on Fineract CN

2018-02-26 Thread Phil Steitz
On 2/26/18 12:52 AM, Markus Geiss wrote:
> Hey Phil,
>
> given all repos got pushed as is, I guess one of the first tasks is to
> rename
> all packages and projects to fit into the Apache layout.
>
> If you just want to get started now, you need to call
>
>   ./gradelw publishToMavenLocal (assuming a *nix OS)
>
> for every project. You should be able to adjust and run the
> initial setup script found at the demo-server.

Thanks, Markus.  I have started just doing the installs using the
mifos packaging.  Once I get that working, I will start working on a
repackaging PR.

Phil
>
> Cheers
>
> Markus
>
> .::Yagni likes a DRY KISS::.
>
> On Sun, Feb 25, 2018 at 10:18 PM Phil Steitz <phil.ste...@gmail.com> wrote:
>
>> I would like to start contributing to CN.  I have cloned all of the
>> repos and thought it would be a good first step to build the
>> demo-server.  The readme for that component says that as a
>> precondition, "All Mifos I/O projects must be published to your
>> local Maven repository."  I assume that now means some subset of all
>> of the fineract-cn components.   But in build.gradle, I see
>> references to mifos components.  Do I maybe need to just replace
>> these with the fineract-cn versions and install these locally using
>> "gradle publisToMavenLocal" from each of these repos?
>>
>> I am happy to provide doco and config patches as I get this working
>> if I can get pointed in the right direction.   Thanks in advance!
>>
>> Phil
>>
>>



Getting started on Fineract CN

2018-02-25 Thread Phil Steitz
I would like to start contributing to CN.  I have cloned all of the
repos and thought it would be a good first step to build the
demo-server.  The readme for that component says that as a
precondition, "All Mifos I/O projects must be published to your
local Maven repository."  I assume that now means some subset of all
of the fineract-cn components.   But in build.gradle, I see
references to mifos components.  Do I maybe need to just replace
these with the fineract-cn versions and install these locally using
"gradle publisToMavenLocal" from each of these repos?

I am happy to provide doco and config patches as I get this working
if I can get pointed in the right direction.   Thanks in advance!

Phil



Re: Meeting to Discuss Release Management Process

2018-02-12 Thread Phil Steitz
On 2/12/18 9:32 AM, Ed Cable wrote:
> Here's the link to screencast from the discussion:
> https://youtu.be/xnTGf4R2s5k
>
> Ed
>
> On Mon, Feb 12, 2018 at 6:32 AM, Ed Cable  wrote:
>
>> Hi all,
>>
>> Thanks to Nazeer for leading this session and the sizeable group that
>> attended. Based on the process, we can clearly use the assistance of other
>> community members in the planning process and committers in the release
>> process so happy we had such good attendance.
>>
>> Based on the discussion, here's a proposal of how timing might look for
>> monthly release cycles with planning (a new phase) starting out six months
>> prior to the release date.
>>
>> Screencast of session will be posted soon.
>>
>> Please comment on the notes in the table and here's proposed timing for
>> the next 1.2 release:
>>
>> Plans for Release Apache Fineract 1.2
>>
>> Planning Release - Start with a Meeting on Feb 14

How about starting with a discussion on this list?  Relying on
synchronous meetings cuts out people who can't attend due to time
zones / other commitments.

Phil
>>
>> Announce Release - Feb 28
>>
>> QA - Feb 28 - March 14
>>
>> Publish Release Notes - March 14
>>
>> Vote on Release - March 21
>>
>> Target release date - March 28
>>
>> Stage
>>
>> Description
>>
>> Proposed Length
>>
>> How Far in Advance of Release (Proposed)
>>
>> How Far in Advance of Release (Currently)
>>
>> Planning of Next Release
>>
>> Discuss with community what would like to ship in next release and what
>> people could work on.
>>
>> Create fix version on JIRA to assign to.
>>
>> Action: modify existing email template to open up planning process,
>> schedule a meeting to discuss and set a tentative branching date (i.e. 2
>> weeks later, if release date is a month past that).
>>
>> .
>>
>> 1 week
>>
>> 6 weeks
>>
>> Doesn’t Exist
>>
>> Announcement of Release
>>
>> Announce what is going to come in the release (should be 80% done at
>> least).
>>
>> Cut a release branch and freeze release branch and then develop branch can
>> still have active work on it but only in rare cases might anything
>> additional from develop
>>
>> Email out sharing release branch details
>>
>> 4 weeks prior
>>
>> 1 - 2 months
>>
>> QA
>>
>> QA begins on the release branch - staging Server setup
>>
>> Might fix some regression issues
>>
>> 1 - 2 weeks
>>
>> 4 weeks prior
>>
>> JIRA Sanitization/Publish RElease Notes
>>
>> Sanitize release documentation
>>
>> Create release notes and email community release information with links.
>>
>>
>> 2 weeks prior
>>
>> Vote
>>
>> Create artifacts, sign release, etc. Open up votes
>>
>> 1 week prior
>>
>> Release
>>
>> Tally up votes, announce, update websites and infrastructure with new
>> release artifacts.
>>
>> Release date
>>
>>
>>
>>
>> On Sun, Feb 11, 2018 at 7:40 AM, Ed Cable  wrote:
>>
>>> Hi all,
>>>
>>> This meeting is happening now for anybody that wants to join.
>>>
>>> Ed
>>>
>>> On Sat, Feb 10, 2018 at 6:07 AM, Ed Cable  wrote:
>>>
 Hi all

 Woule 1530GMT work on Sunday? Nazeer had a conflict on Saturday. I'll
 update the GoToTraining session.

 Ed

 On Thu, Feb 8, 2018 at 9:19 AM, Sendoro Juma 
 wrote:

> Hello Ed,
>
> Just in case, same Saturday(s) but starting 15:30GMT!
>
> if it is fine with Nazeer, then we will very much appreciate...
>
> Sorry our request is based on the fact on belief/religious related!
>
> Cheers
> Sendoro
>
> - Original Message -
> From: "Ed Cable" 
> To: "dev" 
> Cc: "Nazeer Hussain Shaik" 
> Sent: Thursday, February 8, 2018 7:05:55 PM
> Subject: Re: Meeting to Discuss Release Management Process
>
> Hmm... We can reschedule to accommodate everyone. Weekdays might be
> difficult for Nazeer with his new schedule.
>
> Ed
>
> On Thu, Feb 8, 2018 at 7:42 AM, Sendoro Juma 
> wrote:
>
>> Hello Ed,
>>
>> Hope you will record,
>>
>> I see two members missing from our side because of that new timing.
>>
>> Cheers
>> Sendoro
>>
>> - Original Message -
>> From: "Ed Cable" 
>> To: "dev" 
>> Cc: "Nazeer Hussain Shaik" 
>> Sent: Thursday, February 8, 2018 5:05:35 PM
>> Subject: Re: Meeting to Discuss Release Management Process
>>
>> Hi all,
>>
>> Nazeer is not available till Saturday for this meeting so I am going
> to
>> adjust the timing to Saturday at 1400GMT and will update the
> GoToTraining
>> session accordingly.
>>
>> Ed
>>
>> On Thu, Feb 8, 2018 at 6:46 AM, Awasum Yannick <
>> awasum.yann...@skylabase.com
>>> wrote:
>>> I already registered for it.
>>>
>>> I 

Re: [DISCUSS] Begin the process for bringing in Mifos I/O as Apache Fineract CN

2017-10-16 Thread Phil Steitz
On 10/16/17 4:32 AM, Myrle Krantz wrote:
> Hey Fineracters,
>
> Before I bring Fineract CN to vote, I need to bring up one last topic
> which is painful for us all: hibernate-jpa
>
> I know: nobody wants to talk about that, but we don't really have a choice.
>
> Most of the Fineract CN services have a run-time-only dependency on
> hibernate-jpa.  Unlike the other hibernate libraries we use,
> hibernate-jpa is an LGPL library.  The Apache Software Foundation does
> not allow LGPL source dependencies because of the legal risks they
> pose to potential commercial users of our code.  LGPL is a category X
> license.  Hibernate-jpa implements a JSR specification which is
> available under the CDDL 1.1 and TCK.  CDDL 1.1 is a category B
> license (1); it won't block us releasing dependent code.  Because the
> JPA interface is licensed via a category B license, and because
> FineractCN does not use any "non-JPA" features of hibernate, the
> FineractCN service code has no compile-time dependencies to a category
> X license.  Component-test code is a different matter.  Our
> component-tests do depend on hibernate-jpa via
> spring-boot-starter-data-jpa.
>
> We might argue that if we only make a source release of the service
> and API code and not the component-test code, that we are within
> policy.  Binary releases of FineractCN would be ruled out, or someone
> would have to do the pre-release testing work with OpenJPA.  This
> approach is complicated by our multiple-repository approach.  We need
> to produce artifacts from "lower" projects before we can build
> "higher" projects.  And building would be so much easier if we could
> place those artifacts in an artifactory rather than making everyone
> build everything every time.  But even build-snapshot artifacts could
> be considered a source release.  Likewise, running integration tests
> would be easier if we could reference build artifacts in an
> artifactory rather than locally.
>
> It remains to be seen if the ASF would accept this argument and this
> approach.  If the ASF does not accept this approach, there are two
> potential paths forward:
>
> a.) We bring the source into the project, then resolve this issue
> before the first release.
> b.) We resolve this issue before we accept the source into the project.
>
> I personally would prefer a, so that we can get back into on-list
> development.  I don't know if the ASF would accept that approach
> though.
>
> Does anybody else have an opinion? Am I missing any important
> information?  Please share.

Hi Merle,

I don't see any problem at all with a).  This happens frequently in
the Incubator, where initially granted code has dependencies on
libraries with unapproved licenses.  Step 0 is to get the code in so
getting it ready for release can be done by the community.  Getting
the code granted and formally incorporated into the project is
important.  Accepting the grant does not commit the project to
actually releasing it or anything based on it.  It just means that
it is part of the project and you can point people at the sources,
accept patches under the ASF CLA, etc.   Once the code is granted
and accepted into the project, you can decide how to solve the
dependency problems.  Unless the sources that you are bringing in
themselves include LGPL code, you are not violating any ASF policy
by incorporating them into your project.  You are correct, though,
that ASF policy [1] forbids release of code that has non-optional
LGPL dependencies and you will need to find a way to handle that
before first release.

Phil

[1] https://www.apache.org/legal/resolved.html#optional


>
> Greetings,
> Myrle
>
> 1.) https://www.apache.org/legal/resolved.html
>
> On Tue, Sep 19, 2017 at 10:18 AM, Myrle Krantz  wrote:
>> Hey all,
>>
>> I'd like to begin discussion to bring Mifos I/O in to the Fineract
>> project as Apache Fineract CN.  I propose the following process to get
>> us there.  Note that this is a discussion thread.  I will send a
>> voting thread once discussion has died down.
>>
>> A.) Discuss and vote to accept the code into the Fineract project and
>> begin the Apache processes. We should not proceed beyond this point
>> until at least 2/3 of the Committers have voted. My preference is that
>> we reach 100%.
>> B.) Go through the IP clearance process (1) for that code via the
>> Incubator. This will probably require at least:
>>a.) A software grant from the Mifos Initiative
>>b.) A CLA from Kuelap
>>c.) An iCLAs from Mark van Veen, Nina Delvos, and Riana Allen.
>>d.) A thorough check through of the code to make sure those of us
>> working on it haven't missed any licensing issues.
>> C.) Discuss the necessary infrastructure for the code, and place the
>> corresponding requests with the INFRA team. This will at least include
>> JIRA, and github.
>> D.) Move the code and rename the packages from Mifos to Fineract.
>> E.) After migrating the code resolve any release-blockers which