You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@fineract.apache.org by Myrle Krantz <my...@apache.org> on 2017/12/12 08:01:44 UTC
[DISCUSS] Fineract CN issue tracking
Hey all, we need to decide how to do issue tracking for Fineract CN.
I see a couple of possibilities:
1.) We do it under Fineract and create new components for the Fineract
CN components.
2.) We request a new Jira project for Fineract CN.
3.) We request a new Jira project for each of our 33 Fineract CN repositories.
I recommend we go with option #2. Option #1 is likely to cause
confusion. Option #3 would force us to request a new jira project
each time we add a repo.
What do you all think?
Regards,
Myrle
Re: [DISCUSS] Fineract CN issue tracking
Posted by Myrle Krantz <my...@apache.org>.
On Thu, Dec 21, 2017 at 7:27 PM, Markus Geiss <ma...@apache.org> wrote:
> this opens a completely new topic (;
Yes and I don't actually want to go much deeper into it. Important to
me is only how it relates to the question of how we set up our
components and form our tickets. I do *not* want sub-tickets for
component-level work in the FINCN Jira project.
> will we do time tracking in an open source project ... ???
Short answer: yes. Probably not for time spent, but rather for time
remaining on tickets which are already started, and currently in
progress. I'd like to use this information as an aid in assembling
road maps in the future.
Best Regards,
Myrle
Re: [DISCUSS] Fineract CN issue tracking
Posted by Markus Geiss <ma...@apache.org>.
this opens a completely new topic (;
will we do time tracking in an open source project ... ???
Cheers
Markus
.::Yagni likes a DRY KISS::.
On Thu, Dec 21, 2017 at 6:05 PM Myrle Krantz <my...@apache.org> wrote:
> I've learned through painful experience that tracking time on
> sub-tasks is nearly impossible in Jira, so I'm a vehement no to using
> sub-tasks for this purpose.
>
> Best Regards,
> Myrle
>
> On Thu, Dec 21, 2017 at 1:52 PM, Markus Geiss <ma...@apache.org> wrote:
> > Yes, it is also a no.
> >
> > I do believe that we should use this from a user's point of view.
> > We can use other mechanisms, e.g. sub tasks, to define where changes
> need to
> > take place.
> >
> > Cheers
> >
> > Markus
> >
> > .::Yagni likes a DRY KISS::.
> >
> > On Thu, Dec 21, 2017 at 1:29 PM Myrle Krantz <my...@apache.org> wrote:
> >
> >> On Mon, Dec 18, 2017 at 12:08 PM, Markus Geiss <ma...@apache.org> wrote:
> >> > Hey all,
> >> >
> >> > I'd vote for user facing components.
> >> >
> >> > Cheers
> >> >
> >> > Markus
> >>
> >> That's yes from you for the user-facing components Markus, but is it
> >> also a no to the repos as components *in* *addition* to the
> >> user-facing components?
> >>
> >> Best Regards,
> >> Myrle
> >>
>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Myrle Krantz <my...@apache.org>.
I've learned through painful experience that tracking time on
sub-tasks is nearly impossible in Jira, so I'm a vehement no to using
sub-tasks for this purpose.
Best Regards,
Myrle
On Thu, Dec 21, 2017 at 1:52 PM, Markus Geiss <ma...@apache.org> wrote:
> Yes, it is also a no.
>
> I do believe that we should use this from a user's point of view.
> We can use other mechanisms, e.g. sub tasks, to define where changes need to
> take place.
>
> Cheers
>
> Markus
>
> .::Yagni likes a DRY KISS::.
>
> On Thu, Dec 21, 2017 at 1:29 PM Myrle Krantz <my...@apache.org> wrote:
>
>> On Mon, Dec 18, 2017 at 12:08 PM, Markus Geiss <ma...@apache.org> wrote:
>> > Hey all,
>> >
>> > I'd vote for user facing components.
>> >
>> > Cheers
>> >
>> > Markus
>>
>> That's yes from you for the user-facing components Markus, but is it
>> also a no to the repos as components *in* *addition* to the
>> user-facing components?
>>
>> Best Regards,
>> Myrle
>>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Markus Geiss <ma...@apache.org>.
Yes, it is also a no.
I do believe that we should use this from a user's point of view.
We can use other mechanisms, e.g. sub tasks, to define where changes need to
take place.
Cheers
Markus
.::Yagni likes a DRY KISS::.
On Thu, Dec 21, 2017 at 1:29 PM Myrle Krantz <my...@apache.org> wrote:
> On Mon, Dec 18, 2017 at 12:08 PM, Markus Geiss <ma...@apache.org> wrote:
> > Hey all,
> >
> > I'd vote for user facing components.
> >
> > Cheers
> >
> > Markus
>
> That's yes from you for the user-facing components Markus, but is it
> also a no to the repos as components *in* *addition* to the
> user-facing components?
>
> Best Regards,
> Myrle
>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Myrle Krantz <my...@apache.org>.
On Mon, Dec 18, 2017 at 12:08 PM, Markus Geiss <ma...@apache.org> wrote:
> Hey all,
>
> I'd vote for user facing components.
>
> Cheers
>
> Markus
That's yes from you for the user-facing components Markus, but is it
also a no to the repos as components *in* *addition* to the
user-facing components?
Best Regards,
Myrle
Re: [DISCUSS] Fineract CN issue tracking
Posted by Markus Geiss <ma...@apache.org>.
Hey all,
I'd vote for user facing components.
Cheers
Markus
.::Yagni likes a DRY KISS::.Cheers
On Mon, Dec 18, 2017 at 11:17 AM Myrle Krantz <my...@apache.org> wrote:
> Hey everyone,
>
> I've requested a Jira project for Fineract CN named FinCN:
>
> https://issues.apache.org/jira/projects/INFRA/issues/INFRA-15684
>
> Once we have this, we need to decide which way to classify the project
> into components. There are two common approaches:
> * by build artifact (ie repository), or
> * by user-visible domain.
>
> Classifying by build artifact has the advantage that a newby starting
> on a ticket will know which repository to make changes to.
> Classifying by user-visible domain would make it easier for
> non-programmers to create an initial classification with minimal
> knowledge of the workings of the project.
>
> Since more than one component can be set for a ticket, we can combine
> these approaches. We can create the following components
> corresponding to UI domains:
> 1.) offices
> 2.) permissions
> 3.) employees
> 4.) accounting
> 5.) member
> 6.) loan
> 7.) deposit
> 8.) teller
>
> AND the following components corresponding to repositories:
> 9.) repo-fims-e2e
> 10.) repo-fims-web-app
> 11.) repo-portfolio
> 12.) repo-deposit-account-management
> 13.) repo-accounting
> 14.) repo-customer
> 15.) repo-demo-server
> 16.) repo-teller
> 17.) repo-cheques
> 18.) repo-payroll
> 19.) repo-reporting
> 20.) repo-office
> 21.) repo-rhythm
> 22.) repo-provisioner
> 23.) repo-permitted-feign-client
> 24.) repo-mariadb
> 25.) repo-api
> 26.) repo-lang
> 27.) repo-identity
> 28.) repo-default-setup
> 29.) repo-integration-tests
> 30.) repo-anubis
> 31.) repo-template
> 32.) repo-test
> 33.) repo-cassandra
> 34.) repo-command
> 35.) repo-async
> 36.) repo-starter
> 37.) repo-crypto
> 38.) repo-group
> 39.) repo-data-jpa
>
> Does that work for everyone?
>
> Best Regards,
> Myrle
>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Myrle Krantz <my...@apache.org>.
Hey everyone,
I've requested a Jira project for Fineract CN named FinCN:
https://issues.apache.org/jira/projects/INFRA/issues/INFRA-15684
Once we have this, we need to decide which way to classify the project
into components. There are two common approaches:
* by build artifact (ie repository), or
* by user-visible domain.
Classifying by build artifact has the advantage that a newby starting
on a ticket will know which repository to make changes to.
Classifying by user-visible domain would make it easier for
non-programmers to create an initial classification with minimal
knowledge of the workings of the project.
Since more than one component can be set for a ticket, we can combine
these approaches. We can create the following components
corresponding to UI domains:
1.) offices
2.) permissions
3.) employees
4.) accounting
5.) member
6.) loan
7.) deposit
8.) teller
AND the following components corresponding to repositories:
9.) repo-fims-e2e
10.) repo-fims-web-app
11.) repo-portfolio
12.) repo-deposit-account-management
13.) repo-accounting
14.) repo-customer
15.) repo-demo-server
16.) repo-teller
17.) repo-cheques
18.) repo-payroll
19.) repo-reporting
20.) repo-office
21.) repo-rhythm
22.) repo-provisioner
23.) repo-permitted-feign-client
24.) repo-mariadb
25.) repo-api
26.) repo-lang
27.) repo-identity
28.) repo-default-setup
29.) repo-integration-tests
30.) repo-anubis
31.) repo-template
32.) repo-test
33.) repo-cassandra
34.) repo-command
35.) repo-async
36.) repo-starter
37.) repo-crypto
38.) repo-group
39.) repo-data-jpa
Does that work for everyone?
Best Regards,
Myrle
Re: [DISCUSS] Fineract CN issue tracking
Posted by Nazeer Shaik <na...@confluxtechnologies.com>.
Thank you Myrle for clarifying. With the constraints mentioned, I believe
it is good to go with option 2.
Regards,
Nazeer
On Tue, Dec 12, 2017 at 3:09 PM, Myrle Krantz <my...@apache.org> wrote:
> > With option 2) how are we going to prepare a release for 1 or 2 micro
> > services?
>
> Very good question Nazeer,
>
> These are my thoughts:
>
> We need to decide how to version our source release, our binary
> releases, and we need to decide how to enter that versioning into Jira
> for the "fixed version(s)".
>
> Our approach will have to work within the following constraints:
> * We still want to do heartbeat releases.
> * We're using semantic versioning (1) for our build artifacts. In
> order to get continuous integration to work, we'll need to place
> versioned build-snapshots in an artifactory such as maven.
> * We have multiple build artifacts, and their versioning will not be
> synchronized.
> * But we'd like to have one Jira project for all 33 build artifacts.
> In Jira, releases belong to a project and not to a component.
> * We also don't want to release each build artifact individually; we
> want to create a complete release so that our users don't have to
> figure out which versions work together.
> * Releases are source code, but a binary artifact release in maven
> would make it easiest to use our stuff. These would have to use the
> semantic versioning of our build artifacts.
> * Jira only has one workflow per ticket. Not one workflow per release
> per ticket. That is, if the status is "in review" for one of the
> releases, it's "In review" for all of them, even if the actual fix
> hasn't been checked in on another branch.
> * We may wish to create bugfix releases to an already created heartbeat
> release.
>
> I suggest the following approach:
> * Create Jira releases for the source code release simply by date:
> fineract.2018.02, fineract.2018.04, fineract.2018.06, etc.
> * Postfix the release if a bugfix release is necessary:
> fineract.2018.02.r2.
> * Create jira releases in Jira for each maven artifact as well:
> portfolio.1.0.0, portfolio.1.1.0, deposit.1.0.0, deposit 2.0.0, etc.
> * Add an upcoming fixed version to a ticket only after it's done-done
> for that version. That means developed, tested, and merged. Create a
> new Jira field "Targeted version" for the purpose of communication.
>
> Do you believe this is a workable approach? Did I miss anything?
>
> Best Regards,
> Myrle
>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Myrle Krantz <my...@apache.org>.
> With option 2) how are we going to prepare a release for 1 or 2 micro
> services?
Very good question Nazeer,
These are my thoughts:
We need to decide how to version our source release, our binary
releases, and we need to decide how to enter that versioning into Jira
for the "fixed version(s)".
Our approach will have to work within the following constraints:
* We still want to do heartbeat releases.
* We're using semantic versioning (1) for our build artifacts. In
order to get continuous integration to work, we'll need to place
versioned build-snapshots in an artifactory such as maven.
* We have multiple build artifacts, and their versioning will not be
synchronized.
* But we'd like to have one Jira project for all 33 build artifacts.
In Jira, releases belong to a project and not to a component.
* We also don't want to release each build artifact individually; we
want to create a complete release so that our users don't have to
figure out which versions work together.
* Releases are source code, but a binary artifact release in maven
would make it easiest to use our stuff. These would have to use the
semantic versioning of our build artifacts.
* Jira only has one workflow per ticket. Not one workflow per release
per ticket. That is, if the status is "in review" for one of the
releases, it's "In review" for all of them, even if the actual fix
hasn't been checked in on another branch.
* We may wish to create bugfix releases to an already created heartbeat release.
I suggest the following approach:
* Create Jira releases for the source code release simply by date:
fineract.2018.02, fineract.2018.04, fineract.2018.06, etc.
* Postfix the release if a bugfix release is necessary: fineract.2018.02.r2.
* Create jira releases in Jira for each maven artifact as well:
portfolio.1.0.0, portfolio.1.1.0, deposit.1.0.0, deposit 2.0.0, etc.
* Add an upcoming fixed version to a ticket only after it's done-done
for that version. That means developed, tested, and merged. Create a
new Jira field "Targeted version" for the purpose of communication.
Do you believe this is a workable approach? Did I miss anything?
Best Regards,
Myrle
Re: [DISCUSS] Fineract CN issue tracking
Posted by Nazeer Shaik <na...@confluxtechnologies.com>.
With option 2) how are we going to prepare a release for 1 or 2 micro
services?
Regards,
Nazeer
On Tue, Dec 12, 2017 at 2:30 PM, Ippez Robert <ip...@gmail.com> wrote:
> Option #2 can accommodate us.
>
> Regards
> Ippez Robert
>
> On Tue, Dec 12, 2017 at 11:05 AM, Sendoro Juma <se...@singo.africa>
> wrote:
>
> > Hello Myrle,
> >
> > #2 is for me moderate and preferably
> >
> > Both #1 and #3 will bring complexity which may end-up bring volume of
> > emails for just clarifications purpose only etc.
> >
> > Best Regards
> > Sendoro
> >
> > ----- Original Message -----
> > From: "Myrle Krantz" <my...@apache.org>
> > To: "dev" <de...@fineract.apache.org>
> > Sent: Tuesday, December 12, 2017 10:01:44 AM
> > Subject: [DISCUSS] Fineract CN issue tracking
> >
> > Hey all, we need to decide how to do issue tracking for Fineract CN.
> >
> > I see a couple of possibilities:
> > 1.) We do it under Fineract and create new components for the Fineract
> > CN components.
> > 2.) We request a new Jira project for Fineract CN.
> > 3.) We request a new Jira project for each of our 33 Fineract CN
> > repositories.
> >
> > I recommend we go with option #2. Option #1 is likely to cause
> > confusion. Option #3 would force us to request a new jira project
> > each time we add a repo.
> >
> > What do you all think?
> >
> > Regards,
> > Myrle
> >
>
>
>
> --
> Ippez Roberts
> Founder/C.E.O - Swift3 Technologies (U) Ltd
> "Redefining Next Generation I/O Systems"
> P.O.Box 155, Moyo
> UGANDA.
> Tel: +256788725408/770602630
> Skype ID: ippez.robert1
> Email: ippezrobert@gmail.com
>
Re: [DISCUSS] Fineract CN issue tracking
Posted by Ippez Robert <ip...@gmail.com>.
Option #2 can accommodate us.
Regards
Ippez Robert
On Tue, Dec 12, 2017 at 11:05 AM, Sendoro Juma <se...@singo.africa> wrote:
> Hello Myrle,
>
> #2 is for me moderate and preferably
>
> Both #1 and #3 will bring complexity which may end-up bring volume of
> emails for just clarifications purpose only etc.
>
> Best Regards
> Sendoro
>
> ----- Original Message -----
> From: "Myrle Krantz" <my...@apache.org>
> To: "dev" <de...@fineract.apache.org>
> Sent: Tuesday, December 12, 2017 10:01:44 AM
> Subject: [DISCUSS] Fineract CN issue tracking
>
> Hey all, we need to decide how to do issue tracking for Fineract CN.
>
> I see a couple of possibilities:
> 1.) We do it under Fineract and create new components for the Fineract
> CN components.
> 2.) We request a new Jira project for Fineract CN.
> 3.) We request a new Jira project for each of our 33 Fineract CN
> repositories.
>
> I recommend we go with option #2. Option #1 is likely to cause
> confusion. Option #3 would force us to request a new jira project
> each time we add a repo.
>
> What do you all think?
>
> Regards,
> Myrle
>
--
Ippez Roberts
Founder/C.E.O - Swift3 Technologies (U) Ltd
"Redefining Next Generation I/O Systems"
P.O.Box 155, Moyo
UGANDA.
Tel: +256788725408/770602630
Skype ID: ippez.robert1
Email: ippezrobert@gmail.com
Re: [DISCUSS] Fineract CN issue tracking
Posted by Sendoro Juma <se...@singo.africa>.
Hello Myrle,
#2 is for me moderate and preferably
Both #1 and #3 will bring complexity which may end-up bring volume of emails for just clarifications purpose only etc.
Best Regards
Sendoro
----- Original Message -----
From: "Myrle Krantz" <my...@apache.org>
To: "dev" <de...@fineract.apache.org>
Sent: Tuesday, December 12, 2017 10:01:44 AM
Subject: [DISCUSS] Fineract CN issue tracking
Hey all, we need to decide how to do issue tracking for Fineract CN.
I see a couple of possibilities:
1.) We do it under Fineract and create new components for the Fineract
CN components.
2.) We request a new Jira project for Fineract CN.
3.) We request a new Jira project for each of our 33 Fineract CN repositories.
I recommend we go with option #2. Option #1 is likely to cause
confusion. Option #3 would force us to request a new jira project
each time we add a repo.
What do you all think?
Regards,
Myrle