What are Thematic months ?
Each month, a given subject is highlighted within the project. Animation is created around this issue, and it is proposed to members to focus a significative part of the effort on the topic.
Thematic months goals are to advance subject, technical or otherwise, such as :
- mass bug fixing actions
- package update campaigns
- documentation writing sessions
The themes will focus effort on large scale issues asking to coordinate the activities of members, and help to process quickly issues related to users need.
Participation in events is based upon voluntarism. Each member is invited to participate, but implication is left open to everyone (it is important to note that lack of participation will not be charged). Moreover the activities are by no means exclusives of other tasks a member would prefer to do.
The following paragraphs describe the advantages, the proposed process, and the list of topics identified so far.
Why Thematics month ?
The main goal of the thematics month is to provide a visibility on the roadmap of the project. The organization of this events will help to :
- Give users a better visibility on the project by telling them what will be the next major step, and give them the opportunity to give their feedback, and offer users the possibility to express more easily their needs.
- Coordinate members effort and large scale task (like updating large desktop system like gnome or kde, or mass moving existing packages to GAR build system)
- Provide all the documentation needed either by users, current members or new members
- Create and increase momentum in the project, and hopefully recruit new members
proposal : feedback is welcome
The organization of each theme is assigned to a member (or small group of members) based upon voluntarism. This member is in charge of the preliminary work, including :
- definition of the detailed scope of the topic
- organization and identification of tasks required to reach the goal,
- identification of the required documentation, and preliminary documentation work
The organization and scope of the topic can be discussed on the mailing list the weeks prior to the event. During the week before the beginning of the event, the member in charge of the event will sum up the discussion and announce the scope and goals on the maintainer (?) list. At this step, the task are not necessarily precisely defined. Then a is a call for volunteer is issued.
A typical schedule is the following :
- The first week of the event is focused on defining precise tasks, discussing technical point and finding solutions.
- In the next two or three weeks, the activities are mainly realization and technical discussions.
- The last week of the event is dedicated to tasks finalization and publish work results (documentation, packages release, etc.)
The detailed process, goal and schedule of the events will be described in specific wiki pages linked from this one.
It is important to note that this thematics events does not replace ongoing activities, nor it does not mean that work on a topic will stop after the end of the month.
List of themes for 2009
Please note that the following list gather the proposal received so far and must be considered as under construction. This also means it is still time to make some feedback and propose modification or new themes.
Communication : Detailed view
The goal of the first thematic months is to setup and improve OpenCSW project communication and its visibility from the outside.
This topic will cover a range of actions including :
- improve the web site (design and content),
- write articles and slides for the presentation of the project and tools,
- produce all the material we will need to make presentation (in meeting like FOSDEM),
- improve Google rank,
- establish a communication with Sun and maybe other corporates,
- establish links and relation with other open source projects etc.
March: Mass moving package to GAR build system
The goal of this topic is to add to GAR build system as much as possible of existing packages. The realisation of the require to setup :
- live training on how to use gar
- write and produce howto and tutorials for GAR (if needed because Dago already did a lot to create documentation)
- write and produce howto and tutorials for uwatch
- update some package when moving to GAR
- split some package, adding develpment, documentation and runtime packages (this will help to reduce dependencies)
April: Package update
The goal of this topic is move to up to date version of as much as possible of existing packages. At this step, most of the work should be done using the GAR. Packages which are not yet up to date will be listed and a priority list will be created (taking in account both priority from a user point of view, and constraint created by dependencies and prerequisite).
Then packages will be grouped in tiers according to their importance and updated from most to least important tier, and updates will be released to testing. Orphan packages (package without maintainer or with a retired maintainer) will be processed and reassigned at this step. Either a new maintainer will take over such package, or they will be assigned to a special internal team in charge of orphan packages. At the end of this step there should be no longer orphan packages.
May: Bug hunting
The goal of this topic is to fix and close as many as possible of bug entries in Mantis (the bug tracking tool). The current number of opened entries is high, and the status of the different packages have to be updated to give users an accurate view of the problem they may encounter with the different software. Before actually fixing the bugs all known issues like superfluous .la-files or missing 64 bit versions of libraries should be filed as bugs to nothing is forgotten
From this step, upstream watch system (uwatch) will work together with bug tracking. Issue will be automatically inserted when an update is detected.
In parallel of the bug fixing activities, two task forces will be setup to discuss about :
- the way we will handle security alert and patch release strategy
- the process needed to handle bug tracking and more generally Q&A activities
June: Continuous integration
The goal of this topic is to add to continuous integration process as much as possible of existing packages, and to process a system in with GAR and Hudson work together to produce packages for testing.
Note : The description of this step requires more details (Trygve ?)
July: Build world
The goal of this topic is to create a procedure that will be used to rebuild every packages from scratch in an blank environment.
During this stage, the following activities will occur :
- Analysis of dependencies between packages
- Split some packages, adding development, documentation and runtime packages (this will help to reduce dependencies)
- Add dependencies information to GAR Makefile and to a back end database
- Create the top level procedure that will be based on GAR (and maybe Hudson ?) to build and install packages in a black environment, following the order given by dependencies
August: Summer camp
Considering the summer holiday break there will be no specific topic this month, but the end of summer camp organization. Work on the summer will be started before august, nonetheless extra help will surely be needed in the last weeks.
The first OpenCSW technical summer camp will be help this year. Date and location will be chosen in the first month of the year. The summer camp will offer different sessions to attendee like :
- GAR hacking sessions
- Solaris porting sessions
- Move to GAR training sessions
- Package update sessions
- Visit the host city :)
September: Mass porting and package creation
The goal of this topic is to increase the number of available packages and the choice given to users. During this stage, the "package request list" will be processed. Based upon voluntarism, the package will be assigned to a maintainer, or to a team , what will created the package using the GAR build system.
In parallel of the technical activities, a workflow will be setup to process requests.
At the end of this step, the request list should be empty. Packages should be either processed (created and released to testing), in progress (assigned to a maintainer), or refused. In the last case, the requesting user will be notified of the reason why the package will not be added to our repository.
October: CPAN Coverage
The goal is to identify how many packages from CPAN are actually available from OpenCSW and eventually mass-import automatically missing modules.
November: To be defined
No topic defined yet. Feel free to submit your ideas
December: General meeting
No topic defined yet, but the organization of the general meeting. Feel free to submit your ideas