On Wed, Aug 26, 2020 at 12:20 AM Aleksandar Vidakovic < [email protected]> wrote:
> Hi Michael, > > ... I'm almost there... my release task generates also GPG signatures for > verification (tested them... all correct). > cool! > Only thing that is left is to include the generated API client JAR; at the > moment only the sources are created, but no JAR artifact is available. Any > idea how to proceed here (as this is a release I guess we shouldn't include > just the client sources)? > > All details here: https://issues.apache.org/jira/browse/FINERACT-1129 > (contains also link to sources) > I'll engage (and answer above re. client) on that JIRA. > Cheers > > On Tue, Aug 25, 2020 at 9:30 PM Aleksandar Vidakovic < > [email protected]> wrote: > >> Alright Michael... the first list it is (WAR, server and client JAR, and >> README). I'll create a PR for the Gradle task. >> >> One more question: I intend to git cherry pick features from develop that >> arrived after I created the release branch... is that OK or do you guys >> usually use different approaches (like rebase)? >> > Either is fine with me personally, but I think the real question here is more another one: Do you want to cherry-pick very selectively just a limited few particular last minute changes, or just rebase to catch up with everything on develop. The latter would in practice really mean that we just branched too soon? ;-) Personally I probably would therefore go for the former (and cherry-pick, only). There's always more coming in, and that's fine. Can't stop progress. You just draw a line in the sand somewhere. There will always be the next release after. Maybe we can have a 1.5.0 sooner after 1.4.0 than we had after 1.3.0? :) Otherwise we'll never release... ;-) A related interesting question is perhaps if YOU (as the RM) should be the one that raises PR for such cherry-picks. I would argue that you shouldn't have to... you "did your job" of the process. You've sent the heads up email, and nobody objected to the timeline you've proposed. Now I personally would probably just let any contributors who still absolutely WANT to get anything into 1.4.0 last minute raise PRs for the 1.4.0 branch themselves (and resolve conflicts, if any; and get them to build). https://github.com/apache/fineract/pull/1272 was a great working example of that; as a committer to the project, you can Rebase Merge those yourself in the future (if they are also on develop; I suggest that we do not put anything on 1.4.0 that isn't ALREADY in develop; and NOT the other way around, else it can quickly get very confusing IMHO) . BTW you could perhaps capture a summary of this discussion / conclusion on https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract, if you like. > On Tue, Aug 25, 2020 at 7:48 PM Michael Vorburger <[email protected]> >> wrote: >> >>> On Tue, 25 Aug 2020, 19:04 Ed Cable, <[email protected]> wrote: >>> >>>> Nazeer and Shruthi, are you able to provide some input on this thread >>>> based on your experiences leading the release process before. >>>> >>>> Thanks, >>>> >>>> Ed >>>> On Tue, Aug 25, 2020, 09:45 Aleksandar Vidakovic < >>>> [email protected]> wrote: >>>> >>>>> Hi Michael, >>>>> >>>>> ... I think I saw a release script mentioned somewhere, but don't see >>>>> it anywhere in the repo. >>>>> >>>>> I can put such a release task together for Gradle (aka >>>>> "distribution")... >>>>> >>>> >>> Yes, that would be really helpful, IMHO! I would be happy to try it out >>> and peer review a PR from you about this, if you would like. >>> >>> that's not too complicated. Just to list the artifacts again: >>>>> >>>>> - WAR >>>>> - server JAR >>>>> - client JAR >>>>> >>>>> SGMT, and let's throw in the /README.md, and whatever else the 1.3.0 >>> dist included? >>> >>> How about: >>>>> >>>>> - Kubernetes related YAML files >>>>> >>>>> I wouldn't, because technically that's not even "1.4.0" - it will pull >>> :latest from Docker Hub.. we should deal with that "separately & later" (if >>> ever), IMHO. >>> >>>> >>>>> - should we add maybe add the Docker Compose file so that people >>>>> can try out Fineract immediately (without installing a separate MySQL >>>>> instance) >>>>> >>>>> I also wouldn't, because that won't actually work, because it builds >>> from source, which won't be in *binary.tar.gz; sorting that out seems >>> like a separate future task (new JIRA?), to me. >>> >>> Cheers, >>>>> >>>>> Aleks >>>>> >>>>> On Tue, Aug 25, 2020 at 4:41 PM Michael Vorburger <[email protected]> >>>>> wrote: >>>>> >>>>>> Aleks, I was struggling to understand how you'll actually be building >>>>>> the apache-fineract-1.4.0-binary.tar.gz and >>>>>> apache-fineract-1.3.0-src.tar.gz archives for distribution on >>>>>> http://fineract.apache.org... I was assuming that we had a script or >>>>>> (much better) even directly a Gradle task for it in Fineract, but I >>>>>> couldn't actually find anything like it on git. >>>>>> >>>>>> >>>>>> https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract, >>>>>> surprisingly, doesn't actually speak to that - or am I just not seeing >>>>>> it? >>>>>> Hoping someone who was involved in past releases may be able to clarify >>>>>> here. >>>>>> >>>>>> If we never had that, and used to "manually cobble together" these >>>>>> distributions in the past (huh?), then I think it would be great to see a >>>>>> PR contributing this. It would be the first step towards more >>>>>> https://issues.apache.org/jira/browse/FINERACT-876 (later). >>>>>> >>>>>> I was looking for it to suggest that we include not only the *.war >>>>>> but now also the new server *.jar as well as the very recent client >>>>>> *.jar. >>>>>> >>>>>> On Tue, Aug 25, 2020 at 9:10 AM Aleksandar Vidakovic < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> @Ed Cable <[email protected]> >>>>>>> going through yesterday's emails from Michael et al. to see what >>>>>>> recent changes have to be included in the 1.4.0 ... had a couple of >>>>>>> power >>>>>>> outages here yesterday. Thanks for the pointers to work that has been >>>>>>> done >>>>>>> on the community app... good to have this on the radar. >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> On Mon, Aug 24, 2020 at 6:52 PM Ed Cable <[email protected]> wrote: >>>>>>> >>>>>>>> James, >>>>>>>> >>>>>>>> Thanks for bringing up the need for QA. The Mifos Community App UI >>>>>>>> should be relatively in sync with the Finerat 1.4 changes and I've put >>>>>>>> the >>>>>>>> call out for manual QA on Michael's fineract.dev server on the >>>>>>>> Mifos dev lists since a couple week back at >>>>>>>> >>>>>>>> Francis, Bharath, Sangamesh, Chirag, Alex from Habile, and some of >>>>>>>> our GSOC interns have been involved in the QA thus far at >>>>>>>> https://discourse.mifos.org/t/pull-request-review-and-qa-for-mifos-x-20-08-release/9671 >>>>>>>> >>>>>>>> The corresponding tickets at a UI level that complement the >>>>>>>> Fineract release are being tracked at: >>>>>>>> https://github.com/openMF/community-app/projects/6 or by following >>>>>>>> this milestone on Github: >>>>>>>> https://github.com/openMF/community-app/milestone/1 >>>>>>>> >>>>>>>> Francis nicely summarized the QA he's done to date in this Google >>>>>>>> Doc: >>>>>>>> >>>>>>>> >>>>>>>> https://docs.google.com/document/d/1_6kjJxUasLaaZakStDSMKUXw2oqfWt90hzPMuEOFxrE/edit?usp=sharing >>>>>>>> >>>>>>>> @Aleksandar Vidakovic <[email protected]> Thank you again >>>>>>>> for taking up the role of release manager. I do think that although it >>>>>>>> would push the release out a couple more days we should continue doing >>>>>>>> some >>>>>>>> remaining manual QA this week. There are also two important tickets >>>>>>>> that >>>>>>>> Avik from Fynarfin is aiming to have fixes for by Thursday to go into >>>>>>>> this >>>>>>>> release: https://issues.apache.org/jira/browse/FINERACT-629 and >>>>>>>> https://issues.apache.org/jira/browse/FINERACT-1120 >>>>>>>> >>>>>>>> With the release branch available, we're deploying it locally to >>>>>>>> some users as well who are testing it in their development >>>>>>>> environments. >>>>>>>> >>>>>>>> Ed >>>>>>>> >>>>>>>> On Sun, Aug 23, 2020 at 1:00 PM Aleksandar Vidakovic < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> I've added a note on >>>>>>>>> https://cwiki.apache.org/confluence/display/FINERACT/How+to+Release+Apache+Fineract >>>>>>>>> about the manual testing. FYI >>>>>>>>> >>>>>>>>> On Fri, Aug 21, 2020 at 7:52 PM Aleksandar Vidakovic < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> Hi James, >>>>>>>>>> >>>>>>>>>> ... alright... noted. A bit new to the release game here so the >>>>>>>>>> requirement to manually test slipped through the cracks. But maybe >>>>>>>>>> August >>>>>>>>>> might also not be the best of months for a release; responses to the >>>>>>>>>> various release announcements on the mailing list were a bit scarce. >>>>>>>>>> >>>>>>>>>> Having said that: someone wants to help out with QA as James >>>>>>>>>> mentioned? I'll give it a run on my machine, but would be great if >>>>>>>>>> we get a >>>>>>>>>> couple more people to verify. >>>>>>>>>> >>>>>>>>>> Speaking of manual testing - maybe we could do this a bit less >>>>>>>>>> manual... I wanted to propose this already for a while and didn't >>>>>>>>>> get to >>>>>>>>>> it: https://gatling.io/ >>>>>>>>>> >>>>>>>>>> So technically Gatling is a load testing tool, but it has a >>>>>>>>>> feature called Gatling Recorder ( >>>>>>>>>> https://gatling.io/docs/current/http/recorder/) that allows you >>>>>>>>>> to record all interaction between browser (read: community app) and >>>>>>>>>> Fineract. That way we could get those test scenarios once recorded >>>>>>>>>> and just >>>>>>>>>> include them in the build as some kind of integration test. The >>>>>>>>>> beauty of >>>>>>>>>> this is that maintenance doesn't require any coding, just run a >>>>>>>>>> specific >>>>>>>>>> scenario again in your browser; could even replace the current >>>>>>>>>> integration >>>>>>>>>> tests in Fineract that should - I guess - cover more or less UI >>>>>>>>>> scenarios, >>>>>>>>>> but are currently a bit neglected. >>>>>>>>>> >>>>>>>>>> Please ping here on the list if you want to help out. We can >>>>>>>>>> coordinate then for the final release date (I guess that won't be >>>>>>>>>> Monday). >>>>>>>>>> >>>>>>>>>> Thanks again for the help James. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Aleks >>>>>>>>>> >>>>>>>>>> On Fri, Aug 21, 2020 at 7:20 PM James Dailey < >>>>>>>>>> [email protected]> wrote: >>>>>>>>>> >>>>>>>>>>> Alex, >>>>>>>>>>> >>>>>>>>>>> I would like to see and understand the steps we need to take w >>>>>>>>>>> regard to quality assurance (QA). It is vital that we have enough >>>>>>>>>>> test >>>>>>>>>>> coverage. If we don't have that, then we may need to hold off on >>>>>>>>>>> the >>>>>>>>>>> release until we do. >>>>>>>>>>> >>>>>>>>>>> In previous releases we always relied heavily on users going >>>>>>>>>>> through each user interface screen to identify bugs. There were >>>>>>>>>>> even bug >>>>>>>>>>> finding rewards. This was true for the decade + that the code >>>>>>>>>>> lived as >>>>>>>>>>> Mifos. >>>>>>>>>>> >>>>>>>>>>> Since the Mifos front end UIs (multiple) are not yet at the same >>>>>>>>>>> development state, I believe we need to make sure that test >>>>>>>>>>> coverage is >>>>>>>>>>> adequate at the unit level and end to end level. >>>>>>>>>>> >>>>>>>>>>> Perhaps other devs could tell is what has been done to ensure >>>>>>>>>>> the QA is there. >>>>>>>>>>> >>>>>>>>>>> If there are additional testing needs, let's also make sure we >>>>>>>>>>> have jira tickets for those. >>>>>>>>>>> >>>>>>>>>>> If the Mifos UIs on the Mifos dev branches are tracking w this >>>>>>>>>>> 1.4 release exactly, then perhaps that can be used for the testing >>>>>>>>>>> here. >>>>>>>>>>> >>>>>>>>>>> QA should also include a look at any security issues that were >>>>>>>>>>> solved. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> >>>>>>>>>>> @jdailey >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 21, 2020, 5:42 AM Aleksandar Vidakovic < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi Everyone, >>>>>>>>>>>> >>>>>>>>>>>> As previously announced, I've just created the release branch >>>>>>>>>>>> for our upcoming 1.4.0 release. >>>>>>>>>>>> >>>>>>>>>>>> You can continue working and merging PRs to the develop branch >>>>>>>>>>>> for future releases, as always. >>>>>>>>>>>> >>>>>>>>>>>> The DRAFT release notes are on >>>>>>>>>>>> https://cwiki.apache.org/confluence/display/FINERACT/1.4.0+-+Apache+Fineract. >>>>>>>>>>>> Does anyone see anything missing? >>>>>>>>>>>> >>>>>>>>>>>> Does anyone have any last minute changes they would like to see >>>>>>>>>>>> cherry-picked to branch 1.4.0, or are we good to go and actually >>>>>>>>>>>> cut the >>>>>>>>>>>> release based on this branch as it is? >>>>>>>>>>>> >>>>>>>>>>>> I'll start the final stage of actually creating the release in >>>>>>>>>>>> 3 days (Monday, August 24) if nobody objects. >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Aleks >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Ed Cable* >>>>>>>> President/CEO, Mifos Initiative >>>>>>>> [email protected] | Skype: edcable | Mobile: +1.484.477.8649 >>>>>>>> >>>>>>>> *Collectively Creating a World of 3 Billion Maries | * >>>>>>>> http://mifos.org <http://facebook.com/mifos> >>>>>>>> <http://www.twitter.com/mifos> >>>>>>>> >>>>>>>
