FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Cluster Development

 
 
LinkBack Thread Tools
 
Old 02-02-2010, 09:10 AM
"Fabio M. Di Nitto"
 
Default Organizing Bug Squash Party for Cluster 3.x, GFS2 and more

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
 
Old 02-16-2010, 11:15 AM
"Fabio M. Di Nitto"
 
Default Organizing Bug Squash Party for Cluster 3.x, GFS2 and more

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

Thread Tools




All times are GMT. The time now is 02:07 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright Đ2007 - 2008, www.linux-archive.org