On 30.10.2009 08:47, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
If one action breaks the tree unintentionally, I doubt more of the same will be a good idea.
Are you saying that software development in general is a bad idea? ;-)
No. If I had not mentioned the tree breakage, nobody would have noticed it until it was too late. Now we know the multi-move _as proposed_ is a bad idea. Software development usually tries to improve the codebase (if we ignore developmestruction environments). This move is guaranteed to make the codebase worse, and even after fixups the end result will still be worse than what we had before.
On 29.10.2009 13:38, Stefan Reinauer wrote:
Carl-Daniel Hailfinger wrote:
- Does it fix a bug?
Yes.
- Does it add a new feature?
No. It's an infrastructure bug fix.
Sorry, if you call this a "bug fix", then renaming util/ would be the next obvious bug fix because lots of stuff in util/ is not a utility. And src/mainboard/ and targets/ would have to be merged as well (they are both mainboard stuff).
- Does it make the lives of developers easier?
Yes. Because
- people will ask why v4 is called v2 and we will waste time to answer.
We need at most one minute to answer such a question. This move will cost every developer more than five minutes (if warned, and everything goes well) and perhaps an hour (if unwarned) per tree. Assuming two trees per developer and an average of twenty minutes per tree, multiplied by the number of committers in the v2 tree for this year (eighteen), this move has a total cost of roughly 18*2*20=720 minutes for the core committers. At least a dozen other people don't have commit privileges and still contribute patches. We shouldn't ignore them either.
If you expect core developers to answer the question "why is the tree called v2" more than 720 times, the move is a net benefit. If you expect to answer less often, the move is a net loss. If any non-committer developers (or even users) answer the questions, the move is even worse.
This suspiciously sounds like Gentoo. "I can save 2 seconds of startup if I recompile the whole system for days." (No offense intended, some people use Gentoo and avoid such claims.)
- if we go down path 2, we will finally have all utilities together
again. (Something I want to see anyways), so branching and merging will become substantially easier.
With that move (which is a revert), we admit that the original move was a bad idea. What are we going to say about the current move proposal a year from now? "Bad idea, let's revert the revert?" And it will increase checkout size by ~20%.
I don't buy the branching/merging argument. So far I've seen exactly zero branches for anything in v2/util or util/.
I'm intrigued, though. How exactly should things move around even more? Please enlighten me.
tags/ tags/coreboot-some-importand-snapshot branches/ branches/coreboot-v1 branches/coreboot-v1/src branches/... trunk/ trunk/Makefile trunk/Kconfig trunk/src trunk/... trunk/util
Same like flashrom, basically. Same as most other projects, really.
Totally different from flashrom. flashrom doesn't carry around flash-and-burn, nor does it carry around any of the mtd tools. AFAIK v1 is a totally different codebase, so branches/ is the wrong place. And I've not seen anybody suggest to merge v3 into the v2 repo under branches/.
plus, it would elegantly solve us the trouble of whether the other utilities should "go back into the v2 tree or not"
Please see above.
Regards, Carl-Daniel