[Cluster-devel] Organizing Bug Squash Party for Cluster 3.x, GFS2 and more

[Cluster-devel] Organizing Bug Squash Party for Cluster 3.x, GFS2 and more

[Fabio M. Di Nitto]

Hi everybody,

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
with clustering.

- 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.

Cheers
Fabio

[Cluster-devel] Organizing Bug Squash Party for Cluster 3.x, GFS2 and more

[Fabio M. Di Nitto]

Given the close to 0 response to the initiative, I?d say we skip it.

thanks anyway for your time.

Fabio

On 2/2/2010 11:10 AM, Fabio M. Di Nitto wrote:
> Hi everybody,
> 
> 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
> with clustering.
> 
> - 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.
> 
> Cheers
> Fabio
> 
> --
> Linux-cluster mailing list
> Linux-cluster at redhat.com
> https://www.redhat.com/mailman/listinfo/linux-cluster