Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

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

  1. Clean Re-factor (Straightforward)

This is fairly small and doesn’t change the 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 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

 

 

  • No labels