I know some people will claim this hurts. But it will hurt the same way when the version number is up to 4, so we better do it now than later:
(This just renames coreboot-v2 to coreboot-devel in the tree) svn mv svn://coreboot.org/repos/trunk/coreboot-v2 \ svn://coreboot.org/repos/trunk/coreboot-devel
Alternatively:
(this moves all sudirectories of coreboot-v2 to trunk and wipes the coreboot-v2 directory as soon as it's empty. Then the directory hierarchy would be more similar to, e.g. flashrom)
svn mv svn://coreboot.org/repos/trunk/coreboot-v2/{COPYING,Makefile,NEWS,README,documentation,src,targets} \ svn://coreboot.org/repos/trunk/
svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{ADLO,abuild,analysis,cbfstool,compareboard,crossgcc,dump_mmcr} \ svn://coreboot.org/repos/trunk/util svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{kbuildall,kconfig,lbtdump,newconfig,nrv2b,optionlist,options,resetcf} \ svn://coreboot.org/repos/trunk/util svn mv svn://coreboot.org/repos/trunk/coreboot-v2/util/{romcc,sconfig,vgabios,x86emu,xcompile} \ svn://coreboot.org/repos/trunk/util
svn rm svn://coreboot.org/repos/trunk/coreboot-v2/
Signed-off-by: Stefan Reinauer stepan@coresystems.de
PS: If you Ack, please let me know which of the alternatives. :-)
All the best,
Stefan
On 29.10.2009 09:52, Stefan Reinauer wrote:
I know some people will claim this hurts. But it will hurt the same way when the version number is up to 4, so we better do it now than later:
Sorry, NACK. You're right that it hurts, but does it have any benefits except a cosmetic path name change? In that case we should finally kill the /repos/ component of the path and replace it with something meaningful like /coreboot-v42.1/ or something else which says we have coreboot v1/v2/v4 in there.
My personal criteria for any patch are: 1. Does it fix a bug? 2. Does it add a new feature? 3. Does it make the lives of developers easier?
If you really do the move, please pick the one-rename variant.
The multi-part move makes it extremely difficult to carry any local changes forward and it needlessly complicates any history investigation (e.g. "when was this change introduced"). Besides that, you can forget diffing between revisions
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Yes.
No. It's an infrastructure bug fix.
Yes. Because - people will ask why v4 is called v2 and we will waste time to answer. - 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.
Roughly your problem can be solved by:
svn diff > /tmp/my-patch.diff svn up patch < /tmp/my-patch.diff
This is a one time job, compared to the recurring pain with a scattered tree.
Stefan
There are two ways to look at this.
Either the change must come, in which case there will never be a good time to do it so better just get it over with.
Or, the change doesn't have to happen, and when code is no longer v2 everything is copied to a new (directory|repository).
Both hold some weight. In practise v2 is already no longer v2. Until there are resources to start work on a new branch, let's just be version free!
Stefan Reinauer wrote:
If moving then I prefer this. Do the job properly when the knife is out anyway. :)
I also agree with Carl-Daniel that it would be nice to change "repos". Maybe to coreboot.org/coreboot/trunk/ ?
What about stuff like cbfstool and kconfig which is required for a build? Oh, util is inside trunk.. Ok.
(Yes, I know we had this discussion already. :)
svn rm svn://coreboot.org/repos/trunk/coreboot-v2/
Signed-off-by: Stefan Reinauer stepan@coresystems.de
Go for it.
Acked-by: Peter Stuge peter@stuge.se
On 30.10.2009 01:54, Peter Stuge wrote:
NACK!!!
Are you two aware that every checkout of the new tree will look like this:
coreboot-v1/.cvsignore coreboot-v1/AUTHORS coreboot-v1/COPYING coreboot-v1/ChangeLog coreboot-v1/Documentation/ coreboot-v1/HOWTO/ coreboot-v1/NEWS coreboot-v1/README coreboot-v1/romimages/ coreboot-v1/src/ coreboot-v1/util/ COPYING Makefile NEWS README documentation/ src/ targets/ payloads/ util/ADLO util/abuild util/analysis util/cbfstool util/compareboard util/crossgcc util/dump_mmcr util/kbuildall util/kconfig util/lbtdump util/newconfig util/nrv2b util/optionlist util/options util/resetcf util/romcc util/sconfig util/vgabios util/x86emu util/xcompile util/ectool util/getpir util/inteltool util/k8resdump util/mkelfImage util/mptable util/msrtool util/nvramtool util/superiotool
Every coreboot checkout will contain a complete v1 tree, all utilities we ever had (including an alpha disassembler from v1, flash_and_burn from v1, AMD K7 MSR tools etc.), all payloads, and it will be dead slow to check it out.
You don't want that.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
..
Every coreboot checkout will contain a complete v1 tree, all utilities we ever had
Yeah. Things should move around even more then.
You don't want that.
That's not so nice wording. Maybe _you_ don't want that, but you can't really say what I want or not, not authoritatively like that.
//Peter
On 30.10.2009 03:49, Peter Stuge wrote:
If one action breaks the tree unintentionally, I doubt more of the same will be a good idea.
I'm intrigued, though. How exactly should things move around even more? Please enlighten me.
Sorry, this was an insider joke referring to a well-known person at SuSE Linux who has a sign "Das willst du nicht" which he uses from time to time. I assumed Stefan would know that sign and have a good laugh.
Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
Are you saying that software development in general is a bad idea? ;-)
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.
plus, it would elegantly solve us the trouble of whether the other utilities should "go back into the v2 tree or not"
Stefan
On 30.10.2009 08:47, Stefan Reinauer wrote:
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:
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).
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.)
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/.
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
Carl-Daniel Hailfinger wrote: ..
this move has a total cost of roughly 18*2*20=720 minutes for the core committers.
The cost when compared to this discussion and many others like it strikes me as negligible.
net benefit.
..
net loss.
I'm afraid you're ignoring the value of clear structure and good naming. This is important to ensure as low an entry level as possible. Which in turn is crucial in order to reach as many users, and developers, as possible.
This suspiciously sounds like Gentoo. "I can save 2 seconds of startup if I recompile the whole system for days."
It sounds like you (like so many others) have missed the point of Gentoo; it's not that users should compile for maximum binary performance, but that users should be able to make all choices that they want.
Many Linux users do not care squat about choice and are really happy with the latest cute bear distribution. Others enjoy the power of choice very much, probably not because it gives them 2 seconds faster execution, but perhaps because they feel more involved in how their system works.
The choices made by Gentoo users is irrelevant. The fact that they _can_ make those choices is what I think makes Gentoo unique.
//Peter
Carl-Daniel Hailfinger wrote:
Sorry, I completely don't understand your reasoning here.
I'll listen and smile, sorry, can't say more.
In fact, we won't be needing targets in a bit anymore, so it will be dropped soon.
You suspiciously sound like those microsoft consultants in the 90ies... "Windows may not be nice, but it's not bad enough that we would accept extra effort to improve and learn Linux".
I expect those 720 minutes to be well spent, and frankly, I spent more than 720 minutes extra due to the brokenness of the coreboot tree in the last 2 years.
Yes, that idea was really awful. But some of us did not know better, and others did not care enough to prevent it from happening.
Now we care. Now we know.
Ok, with that reasoning we should really just stop developing.
I don't buy the branching/merging argument. So far I've seen exactly zero branches for anything in v2/util or util/.
Well obviously not everything that happens happens under your supervision or on the mailing list.
Not at all. We just didn't do the same mistakes we did with coreboot in the beginning. It's only those mistakes that will be cleaned up by this move.
flashrom doesn't carry around flash-and-burn, nor does it carry around any of the mtd tools.
Yes, we did not import all of the history but that's barely a benefit.
AFAIK v1 is a totally different codebase,
We can easily move it to a separate repository if there is a good reason for it.
so branches/ is the wrong place. And I've not seen anybody suggest to merge v3 into the v2 repo under branches/.
Yes, I suggested that before. But v3 is dead, even more so than v1, so we shouldn't care. Plus v3 always was in a separate repository.
All the best,
Stefan
Carl-Daniel Hailfinger wrote:
...
Yes, the coreboot-v1 tree would of course go somewhere else, like branches.
Stefan
Peter Stuge wrote:
I think I agree.
That's simple and I would like to see this, too.
Ok, thank you.
As Carl-Daniel noted, we should be moving coreboot-v1 out of the way. would branches/coreboot-v1 be an acceptable place?
Stefan
As Carl-Daniel noted, we should be moving coreboot-v1 out of the way. would branches/coreboot-v1 be an acceptable place?
According to svn standards, yes previous software versions should be archived in branches.
On Fri, Oct 30, 2009 at 11:58:19AM +0100, Stefan Reinauer wrote:
Yes, I agree on version-free. svn revisions are our version and I do hope that we never will need or want a "rewrite from scratch" such as v3 was, but use gradual improvements instead. Even if we did a major rewrite that would likely be an extra repo again anyway.
I'm not so sure personally. Anyway, there are many issues to discuss before we start this massive amount of moving stuff, please leave time for at least 1-2 weeks discussion of whether it should be done, how it would be done best, and how users can recover their trees, what developers have to do to not lose work in their many trees etc. etc.
Yep, that's fine I guess.
As Carl-Daniel noted, we should be moving coreboot-v1 out of the way. would branches/coreboot-v1 be an acceptable place?
No, I don't think so. branches and tags should contain branches of the same codebase, but v1 is a totally different tree. If you want to get rid of it in this repo, the best way is probably to move it to its own v1 repo (while keeping history intact, of course).
Uwe.
Am Freitag, den 30.10.2009, 12:41 +0100 schrieb Uwe Hermann:
Discussed this with Stefan, how about this: We copy the repository from "repos" to "coreboot", mark "repos" (the current one) as read-only. The first steps in the new repository will be the various renames.
Migration is svn diff / new checkout / patch -p0.
That way, existing checkouts won't be harmed by svn up and developers can migrate their checkouts when they feel like it.
The only drawback is that they can't simply "svn up" to stay up to date. I consider this an incentive for devs to migrate relatively quickly.
I can do that, as I still have the scripts around that were used for flashrom.
Patrick
On Thu, Oct 29, 2009 at 09:52:52AM +0100, Stefan Reinauer wrote:
Iff we rename "coreboot-v2" I'd prefer "coreboot" instead of "coreboot-devel", the "devel" suggests that it's some kind of unstable dev branch, which it is not. It's the permanently stable one of course :)
I'd rather avoid this, it has too many issues, some of which Carl-Daniel mentioned. Personally I don't think any changes are really necessary. Renaming "coreboot-v2" to "coreboot" is the maximum of what I could live with if there is consensus that we want to rename it to something else. But I don't like the moving/removing of the directories as suggested here very much.
Uwe.
-
Carl-Daniel Hailfinger -
Joseph Smith -
Patrick Georgi -
Peter Stuge -
Stefan Reinauer -
Uwe Hermann