Wintercamp 2010

Wintercamp 2010 will be held in Dublin. Based on the poll1, the optimal date is the weekend of 19th of February 2011.


The weekend of 19th of February 2011.

Arrivals: Friday, 18th of February 2011


Dublin, Ireland.


In order to stay in one place, it's best to choose the Grand Canal Hotel2, which is very close to the Google office on Barrow Street.

Grand Canal Hotel
Dublin 4, Dublin

Make sure to mention you are booking for Google/OpenCSW and you get the room for 75€/night.

Phone: +353-1-6461000
Fax: +353-1-6461001


Thursday, 2011-02-17

18:00 - 20:00 Dinner
20:00 - Reboot Hacking session in the Landsdowne suite (Hotel room 531)

Friday, 2011-02-18

13:00 - 18:00 Hacking session in the Landsdowne suite (Hotel room 531)
18:30 - 20:00 Tech talk by Dagobert Michelsen
20:00 - Pub

Saturday, 2011-02-19

09:00 - 12:00 Meeting
12:00 - 13:00 Lunch
13:00 - 18:00 Meeting
19:00 - 21:00 Dinner
21:00 - 0xFFFF Pub!

Sunday, 2011-02-20

09:00 - 12:00 Meeting
12:00 - 13:00 Lunch
12:00 - 18:00 Hacking session in the office (optional)
19:00 - 21:00 Dinner (optional)
21:00 - 0xFFFF Pub! (optional)


  • Dagobert Michelsen (Thursday 17.2. 18:00 - Monday 21.2. 12:00)
  • Maciej Bliziński
  • William Bonnet (Thursday 17.2. 11:15 - Monday 21.2. 19:35)
  • Ben Walton (Thursday 17.2 - Wednesday 24.2)
  • Peter Bonivart (Thursday 17/2 18.25 - Sunday 20/2 18.45)
  • Sebastian Kayser (Thursday 17/2 - Sunday 20/2)
  • Ihsan Dogan (Thursday 22:05 - Monday 17:00) (Grand Canal is full, staying at the Schoolhouse hotel)


  • Named Releases
    • Naming after camp location ("Dublin", "Luxembourg", etc.)
    • Freeze of package relevant changes (package naming, file locations, etc.)
    • All packages for a release must either be updated or banned from the catalog
  • Automatic Build (Reenable Hudson)
  • QA (Modeled after Debian)
    • Tools
      • Upstream watch 2 presentation
      • Mockup of QA pages in the web site
    • What has to be done
      • look at dropping orphaned packages that don't function (open bugs, etc) if they're impeding a release and nobody cares about them enough to update them why drag them forward.
      • stable release process
        • preparatory work
          • identify a list of criteria which should be matched by package to get promotion to stable catalog
  • Cleanup the list of active maintainers and see where we are in terms of unmaintained and important packages
  • Migration from Mantis to JIRA
  • Hacking sessions
    • Upgrade Xfce to version 4.8
    • Web site : hacking qa pages
  • Clearly define the goals of the project which in turn will be used to set package policy
    • Write a full mission statement (e.g. To produce a software distribution on top of Oracle Solaris…)
    • Update the core principles page
  • GEM packaging strategy (naming, multiple Ruby versions, multiple GEM versions)
  • Making OpenCSW more visible (longer domain lease, make competition.html more prominent)
  • Adding easy package status to page of each package
    • green=maintained+no known bugs+build recipe in repository and linked from package page/yellow=unmaintained but working/red=critical bugs present
    • current: package version vs. upstream version
    • 64 bit: No/Automatic (isaexec)/Manual
    • Comes with SMF integration: Yes / No (Missing) / N/A (doesn't need one)
    • Compliant with NFS-shared /opt/csw: Yes/No (reason: <explanation>)
    • Compliant with current library naming standard (link: what is it? -> description of standard), only if package is a library
    • Compliant with <whatever> (as tested by checkpkg if of global interest)
    • Extra field OPENCSW_OBSOLETED_BY for intermediate packages, GAR support
  • Perl update strategy
    • Consistent and easy way to adjust package names to CSWpm-<cpan>-<module>-<name>
    • Automatic dependencies
    • Automatic manifest generation
    • 64 bit Perl
  • Add list (RSS Feed?) of most recent opened bugs
  • Short mgar demo (no rocket-science, super-easy). Discuss future changes to GAR WRT to mgar. Think about making mgar the default build utility?
  • Fix currently stuck package builds
    • memcached (memory corruption on binary protocol only on Sparc, interesting problem)
    • aria2 (ugly c++ compile issue)
  • GPG key management - sooner or later, we will have to change the gpg key, because either the board, or the release manager will change. Let's prepare for this by coming up with a plan to help our users manage OpenCSW gpg public keys.
  • Forum - Should we give a web forum a try? While mailing lists are great for maintainers, forums are generally better suited for users.
  • Communication issues and dissent on the mailing list
  • Can we get graphical statistics for the bug count (open, assigned, resolved) just like we have for the package numbers/additions?
    • Answer is yes, it can be the topic of an hacking session

Meeting minutes

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