[Linux-cluster] 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