Meeting Minutes
Participants:
Taher Alkhateeb, Ron Wheeler, Gil Portenseigne, Nicolas Malin, Kulwant Singh, Deepak Dixit, Sharan Foga, Jacopo Cappellato, Jacques Le Roux
We started the call with basic introductions and then a discussion of the agenda.
Proposed Scope of Work
Taher began by talking about
previous project initiatives that haven't progressed because they were seen by the community as too hard to do
the fact that the community would also like to improve OFBiz and innovate, but before we can innovate, we need to tidy up and clean up the code
that a framework re-factor will hard but essential to the future of OFBiz
As a framework re-factor will be a lot of work
breaking the work up into bite-size chunks could be a good solution
by keeping it simple we could actively manage it and also attract people from the community to help because the workload may not seem so overwhelming
The general feedback to these points were that everyone agreed that the re-factoring would be a good thing and that it would bring benefits to the project.
Straightforward vs Complex Re-factoring
Taher mentioned that he saw two main types of re-factoring
- Clean Re-factor (Straightforward)
This is fairly small and doesn’t change the API signature. Examples include
tidying up code
cleaning or standardising variable names
formatting
cleaning up XML files
2. Design Re-Factor (Complex)
- This is a re-factor that impacts the design and incorporates changes to the current design.
- This also includes changes to the API signatures that might affect existing applications
- This could range from a small to a large re-factor of code.
A design re-factor is something significant so it would be good to share any proposal with the community for feedback and comments. Jira could be used and if there is a lot of concern regarding the change a branch could be created to verify the change before it is merged back
Re-factoring Impact on Applications
Ron raised the point that any re-factoring that impacts the applications could cause problems for current users. Although the re-factor would not change any of the existing functionality, it could potentially change the way applications interface to a class or interface.
There was a detailed discussion around how this could be handled. The re-factoring will at some point impact the applications. We will need to document the impact and publish information for people wanting to use the re-factored code. We also need to keep the rate of change under control so that we can address and fix any issues that come up.
Depending on the changes required and the impact this could be either straightforward or complex so would need to be assessed on a case by case basis.
Making Use of the Trunk
Jacques suggested that we do not have big commits so that we keep the changes small and traceable. He also recommended that we do not have commit bursts where lots of commits go in too quickly. Small steps with an agreed plan of work is more controllable.
Taher highlighted that the OFBiz project used the trunk in a different way to other open source projects. In other projects the trunk is normally the place where innovation happens and so this means that it is generally unstable. However in OFBiz the trunk has been kept stable which means that we are not actively using it to innovate or try out new functionality that could improve OFBiz. Instead branches have been used but they can quickly become dead branches that are too hard to merge back in.
Jacques suggested that re-factoring work be done using the trunk and back ported to an unreleased version (e.g 15.12). The project has always recommended the stable releases for production users.
After a lot of discussion the general feedback was that we begin using the trunk for the framework re-factor and communicate to the community that it may become unstable because of this.
The Way Forward
- Taher went through a list of possible areas to start re-factoring. After some discussion it was decided that we will put together an initial batch of work to do that is publicly available so that people can assign themselves to a task. We need to ensure that people are comfortable picking up a task and assigning it so a mix of straightforward, easier tasks as well as harder more complex would be included.
- We would look to implement the framework changes in the trunk and 15.12. The changes would not be back ported to any of the live release branches. This means that anyone using the current releases would not be affected by the framework changes. (Jacopo suggested that because of the framework changes it might be a bit harder to upgrade so we could possibly consider extending the life of the release branches to compensate.)
- Jacopo mentioned that changing the framework code that is not exposed to the applications is fairly easy so this would be a good place to start.
- Jacopo also suggested that during the re-factoring process if people have performed a change but see many places where a similar change is needed, then it would be good to publish the template showing how the problem was fixed. This would help other people to fix problems in other areas by using the template and adjusting it.
We briefly discussed the need for better test coverage and it was suggested that if people are not comfortable doing code changes then they can also help with improving the tests.
NOTE: Jacques wants to remind people about OFBIZ-4757 - Getting issue details... STATUS- Jacopo suggested we could "freeze" the framework part of the trunk and do the refactoring of the framework in a branch and merge it back to the trunk after a few weeks (no long waiting impractical branches). And in the process also upgrade the applications to it. This way it lets the people playing with framework refactoring to do the changes without the workload of upgrading the applications after every commit. And instead upgrade all the applications after a set of framework changes are done and "stable". In the process it's highly recommended to document the changes in the commit/s of course. But also in related JIRA issue/s and possibly in the Wiki for main/important changes.
Collaboration Tools
The Development mailing list, Jira and the Wiki were identified as the main tools to use for collaboration. The Skype group chat could also be used if required to help with clarifications
- The Wiki will be used to store the Framework Re-Factor backlog tasks available. People can then sign up to a task that they will work on
- Jira will be used to track the work. Once someone has signed up for a task a Jira will be created. We will try to create a working batch by limiting the number of Jira's open at a time (e.g a maximum of 10) and only move onto the next batch when the first batch is completed.
- We will make use of Jira sprints to help us control and understand what is in progress. It will also help identify any blockages.
Miscellaneous
Ron raised the topic of the running this as a separate project so that the framework could be marketed as a separate deliverable.
After some discussion it was decided that this was too big a change to try to implement at this stage and that we need to focus on clean up first.
Actions and Next Steps
Start the framework re-factor by identifying some fairly straightforward (easier) tasks and some harder tasks to focus on - Taher Alkhateeb
Setup a wiki page with the list of task details where people can assign themselves to a task - Sharan Foga
Setup a Sprint for the Framework Re-factor tasks (Default will be 2 weeks) - Sharan Foga
Write up meeting minutes and post details on the mailing list – Sharan Foga
Plan to setup an initial review / retrospective after the completion of the first sprint - Sharan Foga