Ronald G Minnich rminnich@lanl.gov writes:
A short sketch.
What I want to do, but have not had time to do. For each mainboard, we designate an owner. The owner is responsible for letting us know that their mainboard works. Mainboards are in one of 3 states: (stable, unstable, unsupported)
Mainboards start out in the unstable or unsupported state.
We pick a date (1/1/03?) and say we want all owners of all mainboards to tell us that their mainboard is stable. We freeze the tree one month ahead of that time and the only changes that go in are for stabilization.
1 January 2003 is a bad date for me as I have plans to be far away from computers over christmas.
If nobody steps up for a board, it goes to unsupported state. Boards with owners start out in the unstable state.
The challenge is for a lot of boards we do not get active feedback after a port has been completed. So for any ongoing work we need to very very careful not to make changes to the core that break ports. I am probably the worst offender, except for the various bits of debug code that come and go but still.
Mainboards move to the stable state when the owner confirms stability. When patches are made for a problem, ALL stable mainboards revert to unstable. We iterate until we get it solid, then freeze it.
For the first round this looks o.k, it really depends on what kind of feedback we have.
This information is maintained by a file in each mainboard directory called STATUS, which consists of name/value paris.
One file in the root directory called STATUS should do it..
Will this work?
Sounds like a good rough draft. The very important thing about the stable series is that nothing happens to the core code that could possibly break a motherboard port. That way within a stable series we can get more but not fewer boards working.
Then whenever a new port gets working we can do another release. Of course if the come in fast enough we can delay...
thanks (I'm off email for a bit -- at a workshop)
Speaking of which we probably should put together some kind of conference/workshop for LinuxBIOS. So the developers can get together and talk face to face.
Eric
Missed the original message, but I do have a couple suggestions.
You only know if LinuxBIOS is "stable" on a particular motherboard when one or more people have gotten it to work on one or more revisions and instances of that motherboard. The more cumulative experience the greater your faith.
Perhaps the record you want is:
Reporter (email) LinuxBIOS version (tagged in CVS) Motherboard version Number of boards (especially in clusters) Status: working/no known problems, some problems, not working Description (optional, brief) of how used and any known problems.
To be able to *start* with a working version of LinuxBIOS (if one existed), and then move forward is a huge advantage.
-----Original Message----- From: Eric W. Biederman Sent: Sunday, October 13, 2002 10:38 PM
Ronald G Minnich rminnich@lanl.gov writes:
A short sketch.
What I want to do, but have not had time to do. For each mainboard, we designate an owner. The owner is responsible for letting us know that their mainboard works. Mainboards are in one of 3 states: (stable, unstable, unsupported)
Mainboards start out in the unstable or unsupported state.
We pick a date (1/1/03?) and say we want all owners of all mainboards to tell us that their mainboard is stable. We freeze the tree one month ahead of that time and the only changes that go in are for stabilization.
1 January 2003 is a bad date for me as I have plans to be far away from computers over christmas.
If nobody steps up for a board, it goes to unsupported state. Boards with owners start out in the unstable state.
The challenge is for a lot of boards we do not get active feedback after a port has been completed. So for any ongoing work we need to very very careful not to make changes to the core that break ports. I am probably the worst offender, except for the various bits of debug code that come and go but still.
Mainboards move to the stable state when the owner confirms stability. When patches are made for a problem, ALL stable mainboards revert to unstable. We iterate until we get it solid, then freeze it.
For the first round this looks o.k, it really depends on what kind of feedback we have.
This information is maintained by a file in each mainboard directory called STATUS, which consists of name/value paris.
One file in the root directory called STATUS should do it..
Will this work?
Sounds like a good rough draft. The very important thing about the stable series is that nothing happens to the core code that could possibly break a motherboard port. That way within a stable series we can get more but not fewer boards working.
Then whenever a new port gets working we can do another release. Of course if the come in fast enough we can delay...
thanks (I'm off email for a bit -- at a workshop)
Speaking of which we probably should put together some kind of conference/workshop for LinuxBIOS. So the developers can get together and talk face to face.
Hello from Gregg C Levine I confess I missed the original message as well. Drat! But I do agree with the sentiments expressed in the last part of the message. I'll post a copy of it here:
Speaking of which we probably should put together some kind of conference/workshop for LinuxBIOS. So the developers can get together and talk face to face.
That's what I agree with. Are any of you planning on attending the LWE conference & Expo in any form, next year? I'll be there, attending the exhibits. The idea is, that we should discuss more about what we are working on here. Sorry that didnt come out right. I was transcribing my thoughts, there, and sometimes they don't work out correctly. And the usual caveats about double posts apply. If any of you don't appreciate it, please complain directly. ------------------- Gregg C Levine hansolofalcon@worldnet.att.net ------------------------------------------------------------ "The Force will be with you...Always." Obi-Wan Kenobi "Use the Force, Luke." Obi-Wan Kenobi (This company dedicates this E-Mail to General Obi-Wan Kenobi ) (This company dedicates this E-Mail to Master Yoda )
-----Original Message----- From: linuxbios-admin@clustermatic.org [mailto:linuxbios- admin@clustermatic.org] On Behalf Of Preston L. Bannister Sent: Monday, October 14, 2002 2:10 PM To: Eric W. Biederman; Ronald G Minnich Cc: LinuxBIOS Subject: RE: the plan for stable
Missed the original message, but I do have a couple suggestions.
You only know if LinuxBIOS is "stable" on a particular motherboard
when one
or more people have gotten it to work on one or more revisions and
instances
of that motherboard. The more cumulative experience the greater your
faith.
Perhaps the record you want is:
Reporter (email) LinuxBIOS version (tagged in CVS) Motherboard version Number of boards (especially in clusters) Status: working/no known problems, some problems, not working Description (optional, brief) of how used and any known
problems.
To be able to *start* with a working version of LinuxBIOS (if one
existed),
and then move forward is a huge advantage.
-----Original Message----- From: Eric W. Biederman Sent: Sunday, October 13, 2002 10:38 PM
Ronald G Minnich rminnich@lanl.gov writes:
A short sketch.
What I want to do, but have not had time to do. For each mainboard,
we
designate an owner. The owner is responsible for letting us know
that
their mainboard works. Mainboards are in one of 3 states: (stable, unstable, unsupported)
Mainboards start out in the unstable or unsupported state.
We pick a date (1/1/03?) and say we want all owners of all
mainboards to
tell us that their mainboard is stable. We freeze the tree one month ahead of that time and the only changes that go in are for
stabilization.
1 January 2003 is a bad date for me as I have plans to be far away from computers over christmas.
If nobody steps up for a board, it goes to unsupported state. Boards
with
owners start out in the unstable state.
The challenge is for a lot of boards we do not get active feedback after a port has been completed. So for any ongoing work we need to very very careful not to make changes to the core that break ports. I am probably the worst offender, except for the various bits of debug code that come and go but still.
Mainboards move to the stable state when the owner confirms
stability.
When patches are made for a problem, ALL stable mainboards revert to unstable. We iterate until we get it solid, then freeze it.
For the first round this looks o.k, it really depends on what kind of feedback we have.
This information is maintained by a file in each mainboard directory called STATUS, which consists of name/value paris.
One file in the root directory called STATUS should do it..
Will this work?
Sounds like a good rough draft. The very important thing about the stable series is that nothing happens to the core code that could possibly break a motherboard port. That way within a stable series we can get more but not fewer boards working.
Then whenever a new port gets working we can do another release. Of course if the come in fast enough we can delay...
thanks (I'm off email for a bit -- at a workshop)
Speaking of which we probably should put together some kind of conference/workshop for LinuxBIOS. So the developers can get together and talk face to face.
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
-
ebiederman＠lnxi.com -
Gregg C Levine -
Preston L. Bannister