(Adding last year progress notes) |
m (internal link cleaning) |
||
(5 intermediate revisions by one other user not shown) | |||
Line 29: | Line 29: | ||
* I already requested the membership of the Infrastructure team. | * I already requested the membership of the Infrastructure team. | ||
* I'm very much interested in Kernel Development area of Linux Kernel and I'm quite in a confident state about the Linux driver development. I already developed few simple USB drivers and continuing to enhance them. I'm planning to contribute to the Kernel team in the near future. | * I'm very much interested in Kernel Development area of Linux Kernel and I'm quite in a confident state about the Linux driver development. I already developed few simple USB drivers and continuing to enhance them. I'm planning to contribute to the Kernel team in the near future. | ||
* I'm in a good standard on RPM packaging fist by reading the Fedora Packaging guidelines, packaging few simple test packages and then by adding some customized packages in to the [[ | * I'm in a good standard on RPM packaging fist by reading the Fedora Packaging guidelines, packaging few simple test packages and then by adding some customized packages in to the [[GSOC_2014/Student_Application_udinnet/FinIS#Past_involvement_with_Fedora_Project.2FFLOSS| Rajarata Linux]]. Furthermore I completed [http://www.redhat.com/training/courses/rh401 RH401] course on Red Hat Enterprise Deployment and Systems Management which has "building custom RPM packages for RHEL" in its syllabus. So I'm planning to submit few new packages for the review and contribute to the Packaging team. | ||
* Of course, I'll continue contributing this '''Fin IS GSoC''' project after this summer by improving its features, etc. | * Of course, I'll continue contributing this '''Fin IS GSoC''' project after this summer by improving its features, etc. | ||
===Why choose me?=== | ===Why choose me?=== | ||
For the project I chose to work in GSoC | For the project I chose to work in GSoC 2014 is basically related to the Ambassadors and FAmSCO within the fedora project. I already have a thorough idea and hands on experience with Fedora Financial activities. Also I'm in contract with most of the person who handles the comm-arch and finance in Fedora. Finally I'm a hard working person and I try my best to achieve the targets in a productive manner. So I believe that I already have clean set of resources to implement this project and complete it successfully. In addition to that, | ||
* I'm quite good in PHP development. I already developed various from scratch PHP apps and Joomla customized projects. | * I'm quite good in PHP development. I already developed various from scratch PHP apps and Joomla customized projects. | ||
Line 53: | Line 53: | ||
In the financial perspective, fedora project can be categorized in to “non-profit organizations”. Basically there will be three main categories of funding in Fedora Project. | In the financial perspective, fedora project can be categorized in to “non-profit organizations”. Basically there will be three main categories of funding in Fedora Project. | ||
* Premier Fedora Events - Premier Fedora Events are events organized by the Fedora community that are all about Fedora. [[FUDCons]] and [[FADs]] are the two most common types of Premier Fedora Events. | * Premier Fedora Events - Premier Fedora Events are events organized by the Fedora community that are all about Fedora. [[FUDCons]] and [[FADs]] are the two most common types of Premier Fedora Events. | ||
* Regional support - The small fedora related events like Release parties, Linux events which are happening under the control of [ | * Regional support - The small fedora related events like Release parties, Linux events which are happening under the control of [[Ambassadors#Where_are_we.3F|Regional Ambassadors teams]] will be covered under this category. | ||
* Discretionary funds - The funds which are allocated at the discretion of the OSAS team in conjunction with the FPL, which chooses to make that line item of its larger budget transparent because most discretionary spending ends up being on Fedora. | * Discretionary funds - The funds which are allocated at the discretion of the OSAS team in conjunction with the FPL, which chooses to make that line item of its larger budget transparent because most discretionary spending ends up being on Fedora. | ||
=====The Budgeting Process===== | =====The Budgeting Process===== | ||
For each [ | For each [[Ambassadors#Where_are_we.3F|region]], there will be an Ambassadors team consist of people from countries which are covered from that region. All the ambassadors regions are controlled by [[FAMSCO | Fedora Ambassadors Steering Committee (FAmSCo)]] and main budget planning process for the whole project happens there. For an upcoming fiscal year there will be a projected budget from every ambassadors regions. In other words, there will be planned spendings for each and every region distributed across four quarters in a year. After the regional budget is prepared by regional budget wrangler or treasure combining each country budget, it'll be submitted to FAmSCo and [[OSAS | OSAS]]. | ||
For example | For example | ||
Budget page for | Budget page for | ||
Line 141: | Line 141: | ||
====Top tire Architecture==== | ====Top tire Architecture==== | ||
* Below is the illustration of proposed top tire architecture. | * Below is the illustration of proposed top tire architecture. | ||
[[File:Ffs_top_tire_arch_legend.png]] | [[File:Ffs_top_tire_arch_legend.png|right|200px|alt=none.]] | ||
[[File:Ffs_top_tire_arch.png]] | [[File:Ffs_top_tire_arch.png]] | ||
Line 158: | Line 157: | ||
So what system does is, it check whether the FAS account is active and valid, then proceed to the next step which is mapping user in to the system db user details. If the user already (FAS name) in the table system go ahead and apply the role specific features. But if the user doesn't available in the system db, system will create a record automatically with the lowest privileged level. | So what system does is, it check whether the FAS account is active and valid, then proceed to the next step which is mapping user in to the system db user details. If the user already (FAS name) in the table system go ahead and apply the role specific features. But if the user doesn't available in the system db, system will create a record automatically with the lowest privileged level. | ||
{{Admon/note |This has been already completed in GSoC 2013, But in this time GSoC login mechanism will be improved by adding FedOAuth that supports OpenID to the authentication objects.}} | {{Admon/note |This has been already completed in GSoC 2013, But in this time GSoC login mechanism will be improved by adding FedOAuth that supports OpenID to the authentication objects.}} | ||
[[File:Login.png|thumb|200px|none|alt=The login for FFS with FAS login enabled.|Click to expand]] | |||
====The Ticket==== | ====The Ticket==== | ||
Line 185: | Line 183: | ||
{{Admon/note |Double entry mechanism has alredy been implemented with configuration features.}} | {{Admon/note |Double entry mechanism has alredy been implemented with configuration features.}} | ||
[[File:Ffs_accounting_rules.png|thumb|200px|none|alt=The login for FFS with FAS login enabled.|Click to expand]] | |||
====Currency Convention==== | ====Currency Convention==== | ||
Line 190: | Line 189: | ||
{{Admon/note |This implementation is pending.}} | {{Admon/note |This implementation is pending.}} | ||
===ACL Mechanism=== | |||
There should an advanced ACL mechanism due to the fact that we have several complex use cases. So I'm planning to implement an advanced ACL mechanism on top of the base system. | |||
====Reports==== | ====Reports==== | ||
Line 199: | Line 201: | ||
====Significant features==== | ====Significant features==== | ||
* '''State changes tacking of tickets through accounts.''' | * '''State changes tacking of tickets through accounts.''' | ||
:This feature is very useful when it gets to different states of tickets. As [[ | :This feature is very useful when it gets to different states of tickets. As [[GSOC_2014/Student_Application_udinnet/FinIS#The_Ticket | above]] illustration of ticket states and as mention in [[GSOC_2014/Student_Application_udinnet/FinIS#How_current_Fedora_finance_process_working | overview]] all the fund requests will be gone through a process. In the point of making the actual funding request(monetary) the requester will open the ticket. Then onwards the ticket state will be tracked papally from ticket's perspective and even from the accounting perspective. The advantage of the approach is that in the normal process, tickets will be there for a while (maybe one or two month(s)) and there should be a way to take a snapshot of current financial state of the organization even when some tickets are in a middle of a process. | ||
* '''Can be used by any FLOSS organization''' | * '''Can be used by any FLOSS organization''' | ||
:The development of this project is targeting not only Fedora Project but also any FLOSS organization that consist of a community. In a final phase of the implementation, the customization of the system in to the Fedora Project will be done in a top-level layer while not-touching the original code. | :The development of this project is targeting not only Fedora Project but also any FLOSS organization that consist of a community. In a final phase of the implementation, the customization of the system in to the Fedora Project will be done in a top-level layer while not-touching the original code. | ||
Line 230: | Line 232: | ||
:: Data storing in the database will be encrypted or hashed based on the importance of the data. | :: Data storing in the database will be encrypted or hashed based on the importance of the data. | ||
}} | }} | ||
[[File:Ffs_admin_panel.png|thumb|200px|none|alt=The login for FFS with FAS login enabled.|Click to expand]] | |||
====The Budgeting mechanism==== | ====The Budgeting mechanism==== | ||
Budgeting mechanism will be a branched one from the ticketing system. It'll help admins to forecast the budget for the next FY. The planned system budgeting process can be described as below, | Budgeting mechanism will be a branched one from the ticketing system. It'll help admins to forecast the budget for the next FY. The planned system budgeting process can be described as below, | ||
Line 280: | Line 284: | ||
====Details and Timespan of the iterations==== | ====Details and Timespan of the iterations==== | ||
=====Project Familiarizing Period===== | =====Project Familiarizing Period===== | ||
* | * Start packaging CakePHP | ||
=====Iteration #1 (June 16 - June 30)===== | =====Iteration #1 (June 16 - June 30)===== | ||
I'll start with the core components and develop the additional components around them. | I'll start with the core components and develop the additional components around them. | ||
* | * Transforming the integration of FAS JSON API to FedOAuth-OpenID | ||
* Finalizing the spec for CakePHP and submit for the reviewing. | |||
* | |||
=====Iteration #2 (July 1 - July 14)===== | =====Iteration #2 (July 1 - July 14)===== | ||
* | * Enhance the ticket interface | ||
* | * Starting the development of core ACL | ||
=====Iteration #3 (July 15 - July 29)===== | =====Iteration #3 (July 15 - July 29)===== | ||
* | * Development of core ACL | ||
* Transaction record system for the undo purposes | |||
* | |||
=====Iteration #4 (July 31 - August 20)===== | =====Iteration #4 (July 31 - August 20)===== | ||
* Defining Reporting filters and reporting output mechanisms. | * Defining Reporting filters and reporting output mechanisms. | ||
Line 308: | Line 305: | ||
=====Iteration #5 (August 21 - September 2)===== | =====Iteration #5 (August 21 - September 2)===== | ||
In this iteration I'll be bit busy with University project presentations and evaluations | In this iteration I'll be bit busy with my University research project presentations and evaluations. | ||
* | * Continuing development of ACL | ||
=====Iteration #6 (September 3 - September 16)===== | =====Iteration #6 (September 3 - September 16)===== |
Latest revision as of 14:25, 18 September 2016
Contact Information
- Name : Uditha Bandara Wijerathna
- Email Address: udithabnd@gmail.com
- Telephone: +94772315516
- Blog URL: http://blog.uditha.org
- Freenode IRC Nick: udinnet
Why Fedora Project?
I've been a FLOSS lover since I started to learn computing. I helped various FLOSS initiatives in Sri Lanka and helped lot of people who try to start their computing life with linux operating system. I'm already a fedora contributor for about 3 years now. Also I'm a Linux user since 2005. In my Linux journey, I used and experienced lot of types of distros. To me, Fedora Project is a wonderful place to learn, contribute and keep in contact with other cool project members. Also fedora project community seems the most successful Linux distro project which has nice and very solid community architecture.
Past involvement with Fedora Project/FLOSS
As I said. I'm a long term contributor of Fedora project. More details of my work in fedora project can be found in my fedora profile Uditha Bandara Wijerathna.
- I was a contributor of Joomla Project as a Developer for Joomla 1.7.
- Currently I'm holding the position, Manager (Initiatives) FOSSUser Project in Sri Lanka. I contributed to the FOSSUser Project as a speaker and technical writer. Furthermore I work closely with FLOSS fans in Sri Lanka to develop people's attention towards FLOSS, help them to raise up new initiatives and work in those.
- I'm one of the co-founders of LUG RUSL, The Linux User Group University of Rajarata. And I was able to release a fedora remix named Rajarata Linux using Fedora version 17. Rajarata Linux dirstro was built targeting mainly the CSE students who tends to develop applications in various types of programming languages and platforms.
- Currently I'm the webmaster and the maintainer of official Sri Lankan Fedora Community website.
- I have also given lot of tech talks in many conferences including, FUDCon KL 2012, FOSSASIA 2014 representing fedora.
Earlier participations of GSoC programmes
This is my second time participation in GSoC. My first time, I participated GSoC with Fedora Project.
Future contribution toward Fedora Project
As always, I was an active contributor and I'll. Currently I'm a member of Ambassadors, Fedora Bugs, Freemedia groups. My future contributions can be boiled down to below points.
- I already requested the membership of the Infrastructure team.
- I'm very much interested in Kernel Development area of Linux Kernel and I'm quite in a confident state about the Linux driver development. I already developed few simple USB drivers and continuing to enhance them. I'm planning to contribute to the Kernel team in the near future.
- I'm in a good standard on RPM packaging fist by reading the Fedora Packaging guidelines, packaging few simple test packages and then by adding some customized packages in to the Rajarata Linux. Furthermore I completed RH401 course on Red Hat Enterprise Deployment and Systems Management which has "building custom RPM packages for RHEL" in its syllabus. So I'm planning to submit few new packages for the review and contribute to the Packaging team.
- Of course, I'll continue contributing this Fin IS GSoC project after this summer by improving its features, etc.
Why choose me?
For the project I chose to work in GSoC 2014 is basically related to the Ambassadors and FAmSCO within the fedora project. I already have a thorough idea and hands on experience with Fedora Financial activities. Also I'm in contract with most of the person who handles the comm-arch and finance in Fedora. Finally I'm a hard working person and I try my best to achieve the targets in a productive manner. So I believe that I already have clean set of resources to implement this project and complete it successfully. In addition to that,
- I'm quite good in PHP development. I already developed various from scratch PHP apps and Joomla customized projects.
- I'm already using GIT for various projects and have a thorough idea about how GIT works.
- I'm quick learner.
The Project Proposal
Proposal overview
How current Fedora finance process working
Normally Fedora project community plans the budget for an upcoming fiscal year containing four quarters as below.
- March - May (Q1)
- June - August (Q2)
- September - November (Q3)
- December - February (Q4)
In the financial perspective, fedora project can be categorized in to “non-profit organizations”. Basically there will be three main categories of funding in Fedora Project.
- Premier Fedora Events - Premier Fedora Events are events organized by the Fedora community that are all about Fedora. FUDCons and FADs are the two most common types of Premier Fedora Events.
- Regional support - The small fedora related events like Release parties, Linux events which are happening under the control of Regional Ambassadors teams will be covered under this category.
- Discretionary funds - The funds which are allocated at the discretion of the OSAS team in conjunction with the FPL, which chooses to make that line item of its larger budget transparent because most discretionary spending ends up being on Fedora.
The Budgeting Process
For each region, there will be an Ambassadors team consist of people from countries which are covered from that region. All the ambassadors regions are controlled by Fedora Ambassadors Steering Committee (FAmSCo) and main budget planning process for the whole project happens there. For an upcoming fiscal year there will be a projected budget from every ambassadors regions. In other words, there will be planned spendings for each and every region distributed across four quarters in a year. After the regional budget is prepared by regional budget wrangler or treasure combining each country budget, it'll be submitted to FAmSCo and OSAS. For example Budget page for
After the budget planning is finished, Red Hat, the sponsor of the Fedora Project will allocate funding to the particular budget. Basically this will done by OSAS team and FPL. But there aren't any transaction recording and accounting systems at the moment within the fedora project.
Reimbursement of expenditure
A key point which must be considered in this project is the fund requesting and reimbursement process. Below are the different types of processes followed in different request types.
- For An regional event the process will be
- Creating a wiki page about the event. There should be event owner(s).
- Opening a ticket at particular regional trac
- Approve the ticket by attending the regional meeting.
- Upload receipts to the ticket and wait for reimbursement.
- For travel subsidies
- Opening a ticket at particular regional trac at least month before the travel date.
- Approve the ticket by attending the regional meeting.
- Upload receipts to the ticket and wait for reimbursement.
- For other funding requests (This type of funding requests making is only allowed to fedora project contributors)
- Opening a ticket at particular regional trac with the full detail of the fund request.
- Approve the ticket by attending the regional meeting.
- Upload receipts to the ticket and wait for reimbursement.
- In addition to these processes there will be funding processes for Premier Fedora Events according to the situation.
My Plan is to
It'll be good to have an internal finance system for Fedora Project to handle the budget and transactions in a detailed and very transparent way. So my plan is to develop a system that practices the well known double entry system and generate customized reports about the transaction details which are done within the project, customized to integrate with the fedora project's budget and funding routine.
As this is the continuation of the project which will first start with packaging CakePHP for fedora and then add some new features to current implementation.
The need it fulfils
- Users will have the facility to login to the system using FAS credentials. So there will be no need to create separate accounts for the system.
- As for the current process, the people who manage the budget within the project will only record their budget plan detailed expenses in the wiki. The funding, reimbursement process will done via the regional,famsco trac instances ,etc. There will be no transaction records within the project. But with this system, the details of a transaction (reimbursement, ticket purchase, etc) can be recorded in the db and the financial state of the organization will be automatically updated through the accounting process.
- A fully customizable accounting scheme which can be set up in the initiation of the project by whoever the person in-charge in accounting administration. From this, each an every account's behaviour can be pre planned.
- An authorized user or an authorized API call can generate report from the system about the current finance state of the Organization in any given time. So when it comes to public report preparation about the financial status of the Fedora project, it can be achieved through customized report generation API call.
- For the budgeting purpose for upcoming fiscal years, users will have the facility to create tickets(budget request tickets) for their country's upcoming events and other expenditure related fedora. Then from the reports admins will be able to project the upcoming budget by evaluating budget tickets on regional and country basis.
- Configurable currency convention options for individual tickets.
- Attractive UI
Relevant experience I have
I have relevant experience in the area which this project implements in.
- I have development experience with General PHP, Joomla, Moodle.
- I'm a B.Sc ICT (Special) Undergraduate of University of Rajarata Sri Lanka. (Curriculum includes Mutimedia & Web Design, Internet Programming, Web Services, Management, Principles and Practices of Accounting modules)
- Developer, PageShack.com
- A Joomla 1.5 project which is highly customized incorporating with K2
- component, newly designed login mechanism and user private front end
- control panel. The CMS is forced on user created blogs, supplying large
- amount of tool to handle their blogs.
- Developer, Flick&Post
- A photo sharing web app developed from scratch. It contain various
- advance features those a modern Photo sharing CMS has.
- Team Leader, Web Development Team, Rajarata University of Sri Lanka.
- Developed a PHP & MySQL based back-end to the current Faculty website.
- Currently developing the front-end of the Main university website and
- faculty website.
- I have experience in web-services including WSO2 web-services open-source products, Apache Axis :and Axis2. Also I've participated the WSO2 2011 and 2013 conferences with tutorial sessions, which are almost 100% about web-services.
Implementation of the proposal
Top tire Architecture
- Below is the illustration of proposed top tire architecture.
Most of in this project will be implemented within CakePHP, an opensource PHP MVC Developement Framework. The reasons are to select CakePHP
- Very mature project.
- Uses the MIT licence (Which is compatible with GPL)
- Good community support.
- Very organized documentation.
The Login mechanism
Login system will basically use the FAS JSON interface and there will be separate user role mapping within the system itself to handle the permission hierarchy. Because it is not possible to use the three roles that comes out of the box with FAS. The reason is the user need to be in a newly created group (something like fedora-financial) and bearing the role. But this will be big separate process including adding each and every contributor to a new group. Not only that, these roles are not intended to hold a responsibility which will be required by this financial system.
[role_type] => user,sponsor or admin
So what system does is, it check whether the FAS account is active and valid, then proceed to the next step which is mapping user in to the system db user details. If the user already (FAS name) in the table system go ahead and apply the role specific features. But if the user doesn't available in the system db, system will create a record automatically with the lowest privileged level.
The Ticket
System will use a basic element called a ticket as a commercial document (electronic) and the ticket will go through a process till it get funded. It has states through out the lifetime. Ticket body can be defined and customized as per the need. Fields on the ticket can be added and joined in to compatible data sets in accounting component.
- Ex: Organization's budget committee (For fedora project its FAmSCo) need to tack separate spendings for SWAGs, Media, Refreshments for event sponsorships.
- So the super user of the system can define,
- SWAG cost will go to ==> A account
- Media cost will got to ==> B account
- Refreshment cost will go to ==> C account
In addition to that, the tickets will be always populated from the initial configuration and tickets can have different templates. The body of those can be defined. It can be configures not only the status alone run a rule but another parameter too.
Accounting (Double entry) mechanism
The super user can design the accounting system in double entry aspect. That means when the system configuring initially, super user can create account posting pattern for each and every state change in the ticketing system. So when system is running it check the rule at each and every state change and execute the rule debiting or crediting amount to noted accounts. That allows the system to perform more than two amount updates.
- Ex: When a ticket is approved, a rule executes and update 4 accounts, Debit - Approved Not paid account / Credit - FY2014 Allocated budget account/ Debit - 2014 Event sponsorship account / Credit - 2014 Event sponsorship budget account
Currency Convention
Also users will be able to change the currency preference in the tickets , reports to their home currency and Google currency API will be used to convert the particular figures accurately.
ACL Mechanism
There should an advanced ACL mechanism due to the fact that we have several complex use cases. So I'm planning to implement an advanced ACL mechanism on top of the base system.
Reports
The reporting component of the system will deliver reports as requested. That mean the output of a report request can be customized through various filters. The reporting component will be accessed via a RESTful API and the system itself will utilize that inbuilt API for the report request from logged in users. The API will be implemented as authenticating required API. So that not everyone can view reports.
The Budgeting mechanism
Budgeting mechanism will be a branched one from the ticketing system. It'll help admins to forecast the budget for the next FY. The planned system budgeting process can be described as below,
- Individual users will submit their next FY expenditure with parameters like Country, Region through a budgeting ticket.
- Those tickets will be taken into account by Budget wranglers of the region and categorize according to parameters. Then process the total.
- After the budget allocation submitted by sponsor each regions budget will be automatically adjusted according to the parameters set by budget owner and divide across the regions.
- Then there will be initial amount submissions to the accounts for upcoming FY.
Final Deliverables
- Basically there will be few core components those need to be in the High Priority state
- Ticket creation for every users who has a FAS account.
- FAS login enable and disable feature in the configuration level.
- File uploading in to the tickets (Bill proofs)
- Stage change log of each and every ticket.
- Approval privilege can be applied in to Approval roles in the Regional basis and FAmSCo basis
- As the initial setup the admin will be able to setup set of main accounts with their type and credit/debit rules.
- On-site report generation and off-site report generation (API key auth) with customized queries.
- Mid priority
- Email notification system for the ticket creator, approval and admin(s).
- JQuery UI for the back-end and front-end.
- Low priority (If time permits)
- Integrate GAvatar in to user profiles.
- Formatted HTML output for API responses.
- Budget projecting mechanism
The Timeline
Development Methodology
I'll be using the iterative fashion development. It allows me to manage my development stages, revisit the coding I've done earlier and refine/patch them if needed. Also from this development methodology, it'll allow me to contact my mentors at least once a week in the worst case scenario.
Phases of the Development methodology
- Design and Implementation (~ 1 week)
- Prepare a check-list of TODOs
- Identify,design the classes.
- Define the reverent database fields
- Identify and write test cases for the current iteration.
- Communicate with the mentors and get the confirmation about the design.
- Blog about the design and prepare the initial documentation.
- Develop the Models, Controllers, and add Views.
- Refine the code where necessary.
- Testing and Documentation (~ 1 week)
- Discuss about the new codes and refinements with the mentor.
- If there are more refinements to do, finish them up.
- If test cases are available, do the tests and check whether they are passing.
- Enhance the documentation by adding content.
- Self evaluation about the iteration. Review the check-list. Prepare a list of components those can be improved in the next iteration.
- Blog about the achievements of the iteration.
Details and Timespan of the iterations
Project Familiarizing Period
- Start packaging CakePHP
Iteration #1 (June 16 - June 30)
I'll start with the core components and develop the additional components around them.
- Transforming the integration of FAS JSON API to FedOAuth-OpenID
- Finalizing the spec for CakePHP and submit for the reviewing.
Iteration #2 (July 1 - July 14)
- Enhance the ticket interface
- Starting the development of core ACL
Iteration #3 (July 15 - July 29)
- Development of core ACL
- Transaction record system for the undo purposes
Iteration #4 (July 31 - August 20)
- Defining Reporting filters and reporting output mechanisms.
- Develop simple RESTful API to access the reporting features.
- Extend the reporting API.
Iteration #5 (August 21 - September 2)
In this iteration I'll be bit busy with my University research project presentations and evaluations.
- Continuing development of ACL
Iteration #6 (September 3 - September 16)
Final iteration almost all have been done in this stage.
- Test the functionality in the system as a whole.
- Write the .spec to the system for packaging.
- Almost all dependencies for this project seems packaged already. So there will be no need of packaging the dependencies.
- Package the system.
- Test deployment of the packages.
- Finish up the coding and get ready for the final evaluation.
Potential Mentors
Buddhike Kurera and Charindu Thiwanka are my potential mentors.