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