I have first posted [1] on Symantec Connect the idea of filling my cold winter evening with small projects that could help me and the community back in December 2009, naming the initiative with a funny reference to GSoC [2] - thus it became the Connect Winter of Code.
The initial goal right then was to write an IIS Log Analyzer (aila), which was completed over two Winters (2009 and 2010) and complemented last summer (2012) with a web-portal (aila-web).
This Winter I have published a couple of c# programs (much easier to rev up than the C code, but this is most likely because I had no learning curve to get over) that could be easily build and improved by junior or seasoned c# programmers.
So today I am crystallizing some of the not-so-formal design decision process, feature and bug handling as well as documentation, test and QA, as you can see below:
Table of content:
- Graphical overview
- Development processes
- Testing and Quality Assurance
- Releases
- Reporting bugs
- Requesting enhancements
- Contributing code
Graphical overview:
Development process:
The various project under the CWoC heading are available thru Google Code [3]. They vary in size and form, ranging from a few simple C utilities (clean_sim_xml, create_solnsam_mirror, dqnse), to a sizeable C program (aila), a web-portal (aila-web), shell projects (agent-workload-gen, agent-logs-automation) and some c# projects (patch-automation, zerodaypatch, agent-msd-asdk and mini-sdk).
The process always starts at the same point: provide some utilities that allow the user to extend and better use their Altiris environments or help troubleshooting the environment. The process itself is related to agile development, with the aim to code early, and improve or refine the tools with incremental changes.
This means the overall goal is clear but the fine details are worked on and code is the main documentation.
The code repository [3] is using Subversion, and contains the trunk (current code - not necessarily ready to use) and tags for major milestones in the various project (which is simpler than using a specific revision to refer to a build or released utility).
Testing and Quality Assurance:
Testing is part of the development process, and fully integrated, Features are written and unit-tested to ensure they react under expected input.
Quality Assurance takes the code further into tests that will bring some un-expected input or error conditions (database not available, table missing, invalid file name provided etc) to ensure the error conditions are handled and reported accordingly, and that the software operates in the desired manner at scale (when applicable).
For example, aila was written to handle IIS log files. It was tested with many small files to unit test variable log schema and content. It was QA'ed and scale tested with an aggregate IIS log file that contained many real life customer data that was ~15GiB in size and over 20 million lines.
Releases:
Releases are published on Symantec Connect when the utility is ready for public use but not feature complete. There are no formal beta or release candidate, given the size of the projects we can push code right out to the community and get some feedback quick.
Released files may be available on Symantec Connect, within Build directories or within the Download section of the Google code site.
Reporting bugs:
To report bugs you can reach me (and the community) via the Connect forum, Connect articles, blogs or downloads (related to the project - or to your bug report) or via Connect Direct Messages.
You can also use the Google repository to report defects.
Bug fixes are normally written fast to make sure the tools operate in the bast possible manner, within some boundaries. There are some bugs that we can accommodate first, and then fix whilst some are just not resolvable (I dropped the aila Windows builds after I encountered a number of issues with the memory allocation on Mingwin that just did not occur in Linux).
Requesting enhancements:
To request a tool change or new feature you can use the same mediums as for bug requests: you can reach me (and the community) via the Connect forum, Connect articles, blogs or downloads (related to the project - or to your enhancement request) or via Connect Direct Messages.
Contributing code:
Code contribution are more than welcome. At this point in time there is no need to provide SVN access to the Google Code project but this is something I would be more than happy to do.
Code reviews are also possible with the repository, so anyone wanting to review code can do so with a valid Google account after asking the permissions.
Finally, for submitting code changes we currently prefer unified diff patches, from a specified revision of the trunk or from a given tag.
[1] https://www-secure.symantec.com/connect/forums/interested-connect-winter-code-cwoc