Developer notes

Impromptu notes and advice for developing Customizer. This page may be useful for the contributors to get started before looking into known issues.

How to handle issues

When someone has submitted an issue, it is advisable to check the following criteria:

1. The issue still affects latest commit or release of Customizer at that time

2. The environment and factors that causing the issue are well known

3. Based on criterion 2., at least two users are able to reproduce the issue

Any given issue must satisfy criterion 1., else should be ignored. Provided with sufficient information, the user who had submitted the issue and one or more users should confirm the issue.

If the issue satisfies all three criteria above, apply the "official" label.

How to detail issues

For any given issue, it may be numbered according to the standard format:

ISSUE-YYYY-NNN (OPTIONAL TITLE)

• YYYY is a four-digit year
• NNN is a three-digit issue number registered for that year, with leading zeros
• OPTIONAL TITLE is the short description for the issue, to be readable.

For example, there are six issues identified in 2011, so the known issue will be numbered as ISSUE-2011-001, ISSUE-2011-002... ISSUE-2011-006.

The details may be written according to format below:

• Issue name (follow format as explained above)
• Summary (short description of issue)
• Environment (operating system, applications affected)
• Description (long description of issue, including steps to reproduce the issue)
• Workaround (temporal cure or clever tricks with limitations, but doesn't solve the issue; effective only at a time because issue can reoccur)
• Solution (permanent cure that prevents or solves the issue)

These are originally part of standards used in the official user guide since 2012. While this section had been used for documentation purpose, this may also be applicable to issues on GitHub.

Some older issues on GitHub are following above standard, such as issue #55 which was filed as ISSUE-2011-005. This is because these issues had been moved from the official user guide "as it is" at that time.

Historical reviews

You should read this column to learn things done in the past and avoid errs in the future.

• Choosing Python over Gambas, with advantages have been explained.

• Installation via make for 4.1 releases from the master branch based on Python2, using "injection" method has been noted and noted again.

• Working directory pathname with non-ASCII causing ISO image cannot be extracted. Because Python2 defaults to ASCII encoding. Commit f3bdc01 has resolved this, but may not be all.