[Linux-cluster] Organizing Bug Squash Party for Cluster 3.x, GFS2 and more
Fabio M. Di Nitto
fdinitto at redhat.com
Tue Feb 2 10:10:43 UTC 2010
this is the first time that we are trying to organize this kind of event
and we would like to hear opinions and ideas from everybody.
Because this is a bit of uncharted territory for us (upstream), I don´t
want to set too high expectations from the very first round, but hey..
let´s try and see what happens.
The general idea is to have a 24 hours "work together with upstream" to
find bugs, test quick fixes and provide all sort of feedback (even "HEY
THIS SOFTWARE SUCKS" is good feedback if you can tell us why and where
we need to improve).
I don´t want to restrict this bug squash party to only Red Hat Cluster
and GFS2. If other upstreams (pacemaker, OCFS2, drbd, corosync, openais,
conga, you name it) wants to join, please do so. This is an open
invitation. Feel free to forward this idea around as long as I am at
least CC´ed to keep track of participants.
Assuming there is interest in the event, let´s take a look at some
simple practical details:
- When is this going to happen? I am targeting the 2nd of March as
candidate date. Starting at 00:00 UTC and finishing at 23:59 UTC. Some
areas will have more coverages, others a bit less. If there will be a
next time, we will move the window around to facilitate other time zones.
- What should be tested? Anything really.. do whatever you think your
cluster should be able to do.
- What kind of hardware should be used? Again.. anything you want to put
in the test cluster. Virtual machines? bare metal.. you decide.
- We will get any help to configure the cluster? It depends. This is not
a training session, but mostly a dedicate tour to fix bugs. We don´t
want to exclude anyone but it´s best if you have already some experience
- As team we don´t have a 24h coverage around the world yet. We are
working to plan shifts to have at least one maintainer for each
component/subsystem available at any time. We will post what´s the best
coverage later on.
- In order to coordinate the event, we will use #linux-cluster IRC
channel on freenode.
- All issues found or features reported should be filed in the
appropriate bug tracker. It´s important to have track in case a fix or a
change cannot be provided within the 24h time frame.
- Be ready to trash your test cluster.
- Be ready to test and report back with information. As much as possible
we will try to provide patches and packages (read below) that people can
quickly install and use for testing.
- Distribution of choice: as best as we can, we would like to help as
many distributions as possible, but there are some practical limits.
We can easily provide binary packages for Fedora 12 and Fedora rawhide.
I am in the process to setup Debian and Ubuntu build machines, but
whenever possible, it´s best if you can build your own binary packages
to offload the team from this task.
- We will assume that the base version to start testing is the latest
upstream release version at the time (excluding kernel). It might be too
time consuming to look into bugs that might have been already fixed.
- Kernel bits.. This is clearly more complex to test and build if you
are less familiar with kernel and distribution packaging. We will work
on the base of the latest kernel available for your specific
distribution. Please make sure to have a URL handy to the source code
for us to look at.
Please feel free to add anything I might have missed.
More information about the Linux-cluster