Wintercamp 2009 minutes

OpenCSW Technical Winter Camp – Meeting Minutes

Project Details Responsible
Board vote Board vote roughly once a year (according to the bylaws).
Needs to be announced X weeks in advance (dictated by the Swiss laws, Ihsan needs to find out).
Voting mechnism unclear, should be secret. One possibility: email to board@
Current board members as well as applicants running for board should introduce themselves, their accomplishments and what they think they can bring to the board/project on our wiki page.
Ihsan, Board, Applicants
Automatic builds Had been blocked by cross-platform builds which were not possible with GAR, now they are
There had been objections WRT to performance impact on the buildfarm
Dago will implement user-based resource controls for the build system if it proves to have a noticable impact
Can be combined with upstream watch to automate minor version bump workflows (update Makefile, automatic build, forward package locations and build log to maintainer)
Needs some thought on re-structuring the GAR tree
o Buildbot can cope better with a "same depth" tree (currently some Makefiles live in pkg/ while others in pkg/category/)
o Buildbot is triggered by svn updates (polls the svn tree, parses diff file listing to decide which branch to rebuild)
o Tags could be used to trigger automatic builds, but could potentially "pollute" the build tree (lots of stuff to checkout)
Script/GAR target to bump version would be useful
WRT to the "same depth" tree idea from above
o Maciej would like to structure it like Gentoo or Ports have it: =gar/pkg/<category>/<pkg>/
o When doing this we should rename the CATEGORIES in the Makefiles to PROFILE / BUILD_DEFAULTS (?) to remove semantical overlap
o Mapping/search function within GAR to find a package in GAR (gmake search name=lsof, matches against catalog name) _
Dago, Maciej
GAR Default build documentation should refer to GAR (ref. a dissappointed Blastwave user here). Leave current website as is, focus on presenting it as THE default build system on the new web site.
When we implement the incompatible change from above, we should also rename
Introduce OpenSolaris?-like flag day messages to maintainers@ to make it easier to implement in-compatible changes to GAR
Package tags NEED to refer to the point-in-time revision of GAR during the time of the tag. In-compatible changes to GAR can then automatically adjust existing trunk/ Makefiles without taking care of / breaking tags.
Bug tracker Needs additional meta information to support release cycles
o We will automatically populate version field for all packages
o We could use tags to mark a bug as release-critical (suggested release-csw-YYYY-MM)
Make it easier for users to file bugs
o Reduce severity field to less values: tweak, minor, major, critical
o Drop priority field from form
Classutils The idea to move from /usr to /opt to be more sparse zone friendly from last camp hasn't been implemented
Reasoning for current status and known challenges are now documented at cswclassutils-package
Licensing No progress from last camp, topic up for grabs
If we would want to introduce a GAR recipe license for each recipe we would need to contact all people who comitted and get their agreement.

For further minutes, the options are:

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License