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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cluster
