For this new year, we decided to change how we organise the CubicWeb project at Logilab. We clarified how to define priorities and how to contribute.
Rotating the coordinator of the month
First of all, we pinpointed the need to have a coordinator to organise meetings, issues and dispatch work between contributors. It was an evidence to define this role as a rotating responsability. Each month a coordinator is picked from the volontary participants. The previous coordinator and the new one have to write this monthly review together to communicate on what happened for the CubicWeb project during the month and to officially change the coordinator.
New kanban boards
To separate the on-going issues and the planned issues for the next versions, we divided the existing kanban in two.
The first one defines the ongoing work and the states of each issue. The column "IMPORTANT" is used to track the important bug which need to be fixed in the version in development.
The R&D board tracks the ideas and the future versions. This board contains an "IDEA" column, which is used as a backlog. Then we can move the "IDEA" issues into the dedicated column to plan the issue for a specific future version. The "Exploration" label is set on issues that are not asking to implement a feature, but to explore the problem and find a good implementation plan. Ideally these issues will lead to classic issues to be implemented.
The CubicWeb Forge is dead, Heptapod is our new friend
Heptapod is a friendly fork of GitLab that supports Mercurial repositories, allowing to use all the features of GitLab and all the features of Mercurial (draft changesets, automatic evolution, etc).
All cubes were migrated to the new forge. CubicWeb Forge is still available, but will be made read-only and will be shutdown in the future.
Every tuesday afternoon (UTC+1), there is a weekly meeting. We discuss the issues in the kanban boards to track progress and plan the work. Feel free to join us in the CubicWeb matrix room.
To work on specific issues we have decided to organize regular sprints. The first one occured on January 26th and 27th 2021 with ten participants. It was a success as good work was done.
Separate Back and Front
The main subject which was studied during this sprint was the front/back separation, which is an "Exploration" issue planned for the CubicWeb v3.30.
The next steps will be to test this API into a project and study how to handle authentication.
Another subject is how to generate frontend forms from the YAMS schema, such as the current CubicWeb.web implementation but all with the React framework. The result is implemented into the CWElements project: - handle relations - allow update queries.
The ongoing issues for CWElements is to test this form into a project and define how to establish a graphical identity by specifying CSS files and/or CSS framework (such as Bootstrap, Material-UI and so on)
Cleaning up the CubicWeb code repository
We corrected some bugs listed below, but more importantly we transformed all the branches from the old forge into merge requests in the new forge. Each merge request will thus be properly tracked and reviewed.
If you have a patch for CubicWeb, now is a good time to send a merge request. The merge requests will benefit from the automatimated tests. Also, all the discussion will be properly stored.
Important issues closed and merged
- [v3.30] [docker] allow to read REQUIRED variables from environments #85
- [v3.30] remove statsd integration? #39
- [v3.30] remove web.cors in favor of wsgicors with pyramid #192
- [v3.30] RQL TODAY in sqlite is not equivalent to RQL TODAY in postgresql #109
- [v3.30] Include pyramid as direct deps in cubicweb by default #191
- [v3.26] Box view of a CWEtype is broken #74
- [v3.26 & v3.30] No translation in pviews #87
Since we started working on Cubicweb 3.29, we have been reworking the documentation step-by-step.
A new landing page was created.
A new tutorial is being written.
It focus on:
- Data import
- React to display a custom page (with RQL information)
- content-negociation to retrieve information in RDF format
The fictionnal usecase is a website publishing a list of museum (imported from an existing source). The final result is compiled in the tuto cube.
If you have any comment on the documentation, create an issue or come in the matrix room.