Hi,
you all are probably aware now that flashrom 1.0 is pending release and the philosophy for further development (total rewrite vs. incremental changes) is heavily disagreed upon. Completely forking the codebase into separate projects is something I'd like to avoid because we already have too few development resources.
Suggestion: After 1.0, we create - a development branch where people can go wild with rewriting stuff - a stable branch with incremental changes where breakage is not allowed.
Each branch would have its own maintainer, possibly with final authority over what goes in. I suggest Peter as maintainer for the radical development branch because he has expressed the need for a flashrom rewrite in the past. I personally believe more in the incremental approach with minimal changes.
Regards, Carl-Daniel
On Sun, Jul 20, 2008 at 01:49:04PM +0200, Carl-Daniel Hailfinger wrote:
Completely forking the codebase into separate projects is something I'd like to avoid because we already have too few development resources.
Full ack.
Suggestion: After 1.0, we create
- a development branch where people can go wild with rewriting stuff
- a stable branch with incremental changes where breakage is not allowed.
Nah, overkill and not really useful IMO.
I personally believe more in the incremental approach with minimal changes.
Ack. No patch should ever break the build or runtime-behaviour of flashrom. That doesn't mean we can't do radical changes, such changes just have to be done in a manner which doesn't break flashrom, either in small incremental steps or in bigger patch-series which do all changes at once. But we don't need (or want, IMO) branches for either...
Uwe.
On 21.07.2008 16:25, Uwe Hermann wrote:
On Sun, Jul 20, 2008 at 01:49:04PM +0200, Carl-Daniel Hailfinger wrote:
Completely forking the codebase into separate projects is something I'd like to avoid because we already have too few development resources.
Full ack.
Suggestion: After 1.0, we create
- a development branch where people can go wild with rewriting stuff
- a stable branch with incremental changes where breakage is not allowed.
Nah, overkill and not really useful IMO.
Hm. There have been quite a few disagreements over design and code questions in the recent past. Branching would allow people who share a common vision to showcase what they intend to do without being limited to single patches.
I personally believe more in the incremental approach with minimal changes.
Ack. No patch should ever break the build or runtime-behaviour of flashrom. That doesn't mean we can't do radical changes, such changes just have to be done in a manner which doesn't break flashrom, either in small incremental steps or in bigger patch-series which do all changes at once. But we don't need (or want, IMO) branches for either...
There are philosophical differences as well. Peter and Stefan want to remove #defines and use magic values directly. I heavily disagree with that and believe the code is more readable if the meaning of a constant is visible in the code without having to consult data sheets. I hope that branching is a way to avoid revert wars or NACKs for design reasons.
Regards, Carl-Daniel
On Mon, Jul 21, 2008 at 7:36 AM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
There are philosophical differences as well. Peter and Stefan want to remove #defines and use magic values directly. I heavily disagree with that and believe the code is more readable if the meaning of a constant is visible in the code without having to consult data sheets. I hope that branching is a way to avoid revert wars or NACKs for design reasons.
one of the bad states an open source project can get into is what we might call "gilding the lily". In this case it is not "dining philosophers", it is "coding philosophers". The project is fine, but there is this persistent urge to tweak here and there and make it perfect. But, of course, nobody can ever agree on what constitutes perfection. I am tending, nowadays, to like Plan 9 coding styles, which are at variance with the coding styles of Linux and, hence, coreboot. I'm not about to try and change that area, however :-)
There are all sorts of these types of design points that smart people can disagree on. In many cases, both sides can be right, and have good reasons. I think we want to be very careful not to take the disagreements too far. We could end up damaging the project.
Constants visible in the code: if a constant is only ever used once, it is hard to see the harm. If a constant is used more than once, there is the possibility of a typo and confusion. We should keep those factors in mind.
Just my $.02, which is now about .01 euro.
ron
On 20/07/08 13:49 +0200, Carl-Daniel Hailfinger wrote:
Hi,
you all are probably aware now that flashrom 1.0 is pending release and the philosophy for further development (total rewrite vs. incremental changes) is heavily disagreed upon. Completely forking the codebase into separate projects is something I'd like to avoid because we already have too few development resources.
Suggestion: After 1.0, we create
- a development branch where people can go wild with rewriting stuff
- a stable branch with incremental changes where breakage is not allowed.
Each branch would have its own maintainer, possibly with final authority over what goes in. I suggest Peter as maintainer for the radical development branch because he has expressed the need for a flashrom rewrite in the past. I personally believe more in the incremental approach with minimal changes.
The way you have presented it, I get a vision of two competing trees, each one bickering with the other, and competing for new ports. One tree has the advantage of being somewhat stable, while the other one could be better, but lacks the resources to make itself better. Sound familiar?
I like the idea of a stable tree, but a stable tree needs to be just that, stable. No incremental features, no massive changes - just bug fixes. Anything else is just a fork in sheeps clothing.
I believe in solid competition. I think that Peter should openly fork flashrom, call it something new and develop what he thinks is best. When ready, he can bring it to the community, and we can compare. The community will gravitate toward the best solution. Peter can attract those who agree with them, and work on a solution. I volunteer to join him.
Jordan
On Mon, Jul 21, 2008 at 8:16 AM, Jordan Crouse jordan.crouse@amd.com wrote:
I believe in solid competition. I think that Peter should openly fork flashrom, call it something new and develop what he thinks is best. When ready, he can bring it to the community, and we can compare. The community will gravitate toward the best solution. Peter can attract those who agree with them, and work on a solution. I volunteer to join him.
makes sense to me. I think a new name is a good idea.
ron
Carl-Daniel Hailfinger wrote:
Nah, overkill and not really useful IMO.
Hm. There have been quite a few disagreements over design and code questions in the recent past. Branching would allow people who share a common vision to showcase what they intend to do without being limited to single patches.
This is an Open Source project. You are allowed to keep your private branch without decision from everyone, if you can't convince the community that your stuff should go in right away.
There are philosophical differences as well. Peter and Stefan want to remove #defines and use magic values directly. I heavily disagree with that and believe the code is more readable if the meaning of a constant is visible in the code without having to consult data sheets. I hope that branching is a way to avoid revert wars or NACKs for design reasons.
Go ahead and create your own branch if you feel this is necessary. If it is deemed successful, chances are good that it will be merged at some point.
-
Carl-Daniel Hailfinger -
Jordan Crouse -
ron minnich -
Stefan Reinauer -
Uwe Hermann