As requested, I’ve organized my notes into a sort of after-report on the developer meeting that occurred on Dec 5-7 at the Roxen offices in Linköping. Please note that these notes are not complete; any additions or corrections are welcome.
The permanent URL for this document is: http://wiki.gotpike.org/PikeDevel/Conference+2014
Conference Topics
- Should we identify the criteria for what features get added to given branches (devel vs stable)? Who will declare a development branch stable? - What are the powers of the release manager? - Should we have procedures for adding new features to a stable branch. Note: do we need this if our stable releases happen at reasonable intervals? Note note: Aren't feature branches the tool to deal with long development cycles of complex features? - consistent type for sizes? (size_t, etc) - pointer aliasing in pike strings. There are several possibilities to fix this "for good". For instance by having a union of char[4], short[2] and int[1] arrays at the end. Alternatively, if string data was allocated seperately from the struct pike_string, a void pointer would could be correctly casted to all 3 string types without breaking aliasing rules. - arm32 machine code support (tobi/arne) - should we have a defined procedure for deprecating an API? (arne) A few other impromptu topics were discussed and didn't make it onto the "official" agenda.
Conference notes
These notes are probably incomplete, as discussion occasionally went in multiple directions simultaneously.
Database Support
Our database layer has not kept up to date with changes in database techniques:
- Precompiled queries for enhanced performance, even if this is “simulated”. - Oracle/ODBC are capable of returning binary data, which would allow us to receive native data such as integers. - We should probably not allow multiple queries to be included within one call to query(), as this (among other things) invites abuse. - The use of bindings should probably be documented in order to identify the recommended usage (and include examples).
Development Process
Some ground rules were agreed upon in order to have a framework for managing the development and release process of Pike. These are:
- Code that is not a bug fix should be committed to a development branch and be allowed to “mature” before committing to a stable branch. Seek feedback to determine when your code is “mature”. - Use of feature branches is recommended in order to allow a line of development to be more easily identified and reviewed. - When deprecating an API, that API must be marked as deprecated for at least 1 stable (X.Y) release before removal. Compatibility glue should be added wherever possible. - Your code should compile before being committed to the main branch. Try to keep in mind that pike gets built on non-*nix systems such as Windows, so your changes should take this fact into account. - When in doubt, advice should be solicited on the development list. We all have a role to play in keeping the stable tree in a reasonable state; additionally, the release manager is “deputized" to deal with unruly commits if the system doesn’t catch them.
Opera Critic is a code review system that might be worth considering for use with Pike development. We got a brief demo of it and it looks promising. Additionally, Opera’s auto build system has some nice features (binary exports, etc) that might be desirable in Pikefarm.
As is often mentioned, it would be good to do stable major releases more frequently. A suggestion was made that once every 2 years would be good. The point was made that development can occur in parallel to stabilization without affecting timing. The major reason stable releases don’t get made seems to be due to the dread of generating release notes, though waiting longer between releases makes this a greater real problem.
We’d like to rename the 8.1 branch to reflect it’s development status; this should various things easier (by avoiding having to explicitly change branches when a new stable branch is created).
ARM Machine Code
Arne and Tobi have been working on a machine code generator for 32 bit ARM machines. Currently, only a handful of opcodes have been implemented, but the generator generates working code. In addition to implementing more opcodes, a longer term goal includes support for ARM64. The code has been checked in to git in a feature branch (tobij/arm32)
Future roadmap
aka the wish list (incomplete, obviously, please send me additional items):
- Support for “implements” - Getting more up to date pikes into more distros - the ebuild is kept up to date by grubba - a working rpm spec file was submitted to the rpm forge project, however that project seems to be a zombie: the merge request has been lingering for over 6 months.