On Saturday 06 September 2008 23:39:16 KHMan wrote: > Of course I agree with all of your (Rob's) arguments, and I'm sure > most others as well. Don't need to keep repeating arguments I > already agree with. I just think this project should deal with > manpower first, and I'm RCS-neutral.
The thing is, I'm not. The repeated resurfacing of CVS has driven me away from this project several times now, for at least 3 months each time. Trying to deal with manpower before brain-damaged source control is focusing on effect and ignoring cause. > Okay then, you know, we're going around in circles. :-) This is > exactly like a past discussion that ended up with me setting up > the hg repository. Yeah, I remember that. I set one up, you set one up, neither were "official" and neither stopped people from checking more things into CVS and cutting releases from them. And hey, if that's how tcc development happens, I'm happy to get out of its way. > So I did try to get this tcc onto a modern > distributed RCS, and then managed to get Detlef to take over, but > no commits in the past 7 months or so. Anyone care to continue > that? So that's one data point. It says we need muscle. > > No muscle, no results. Need'um reliable muscle first, else > everything is stuck. Even the scenario where you (Rob) kindly send > patches over under LGPLv2 requires muscle plus a distributed RCS. Not really. I could post 'em to the list at patch files. What I can't do is read other people's patches that _weren't_ posted to the list, but instead went directly into CVS. It's not a question of setting up a new source control system. That's trivial. It's a question of KILLING OFF THE CVS ARCHIVE, which will never happen. > I was just trying (very carefully, knowing you are around, but > obviously not carefully enough) to point out to the list that > without reliable muscle, nothing is going to move. There's no muscle _on_this_list_, because there's no interest in checking crap into the old CVS except on Grischka's part. Back before I gave up on my fork (for the second time), I put enough "muscle" into it that wikipedia mentioned it, tinycc.org linked to it, there was even an Ubuntu launchpad entry about potentially switching to it: https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/201627 Heck, I hosted a compiler BOF at this year's OLS where I talked about it: http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg I didn't give up on it due to lack of "muscle", I gave up because no matter what I do, the old zombie CVS continues to lurch forward, and life's too short for me to to feel guilty about not fishing around in that toilet to see what patches I might be missing. Yes, my time is spread between a half-dozen projects, and I'd rather not be maintainer of a project I'm the only developer on. But what's sillier is racing to stay ahead of a _dead_project_. Most of what Grischka checks in to CVS is for the windows platform, about which I don't much care and can't easily test. (Yeah, I set up a wine based test environment six months ago. Now that I've upgraded to Kubuntu 8.04 I'd have to reinstall it, and I just haven't bothered.) Nobody but me seems to be working on an x86-64 target, or even an x86-64 _host_. You are aware that 32 bit x86 hardware is no longer being _manufactured_ outside of the embedded space? Everything that's shipped this year has been 64 bit. How long will Ubuntu continue to put out a 32 bit Linux distro, do you think? 3 years? 5? Since your project doesn't run on x86-64 you probably haven't noticed that if you use "-run" from a 64 bit version of tinycc it segfaults, because it jumps to a function pointer full of 32 bit code while in 64 bit mode. That requires changes to the build system so "-run" is only enabled for a fully native compiler, which is a trivial configuration test. Except I've completely rewritten my build system, it looks nothing like yours, so any work I do there brings the two projects further away. My build system lets you individually specify all six compiler paths; yours does not. Nobody but me seems to care about making the existing targets cross compile to each other. (Tried building running the x86 code generator on arm? Segfault, unaligned access...) And yet people keep asking _me_ about the 0.9.24 release, and why it has such and such bug they thought I'd fixed a year ago. > So to keep my message simple -- what we need is action, and I > think those who can take action gets to decide. I spent two years working on the codebase. I collected other people's code, I came up with my own changes, I debugged things, I added tests, I did actual work. Not useless talk like this email message, _work_. My work _before_ I changed the license got cherry-picked and flushed into the CVS, and wound up in the 0.9.24 release. And I'm happy that tcc got out a new release. But it does mean that my fork is dead, because to continue to work on it I'd have to go over cvs to see what changed, and that simply won't happen. Your version is still missing rather a lot of work I've done. But I can't change it, and nobody here wants to, so I'll stop bothering you now. > Forget I ever > mentioned CVS. We're beggars here, the thingy is mostly in deep > freeze, and in my very humble, personal opinion, I think I would > accept a bowl of plain rice instead of holding out and starve in > hope of a gourmet meal. I also think opinions like mine are very > cheap, thus I fervently hope for someone to step up to the plate. I don't want to fight what's left of the tcc community. Daniel's doing important work on arm that I can't do. Grischka knows more about the windows target than I'll ever care to. But my next major tinycc todo item was to busyboxify the thing so it works like "ld" when you call it as "ld". This involves merging my gcc command line parsing wrapper script logic so it's even more of a drop-in replacement for gcc, and can be used as the preprocessor part of "distcc" combined with gcc on the daemons to generate the .o files, and then tinycc to link them. That's a useful goal, easy to test, and it helps out my Firmware Linux project by making the parts that run inside the emulator work faster, and splitting out the bits that should work everywhere right now (no reason the preprocessor can't do a "tcc -E" on a mips or powerpc host) from the bits that need serious additional work (ala an x86-64 code generator). But for me to do that would be based on the work I've already done to break the options parsing logic out into a seperate file, and rename/move the i386 target into an i386 sudirectory and so on. My code is pretty far from tcc 0.9.24, and this would move it farther. Daniel's work isn't based on my fork. Nobody else's is. Instead, what work they do is based on the CVS version. And people continue to test the cvs version. When a bug report comes in (like https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/1898 or https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/71059) does it occur in my fork, or did I already fix it? When something like http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00009.html happens, what do I do? I don't use that feature and they don't use my version, I probably have that bug but is it worth fixing in a fork NOBODY ELSE WILL EVER USE? These days even stuff like http://lists.gnu.org/archive/html/tinycc-devel/2008-08/msg00007.html with a patch sitting there, all I do is mark it "todo". I did some fairly extensive renames ala http://landley.net/hg/tinycc/rev/574 and patches to the old code may or may not be easy to figure out where to apply to my fork. But the people checking stuff into the old CVS seem quite happy to continue to do so, and nothing _I_ do is going to discourage them. It seems quite the opposite: even after I changed the license to discourage the cvs, after I added "-v -v -v" verbose debugging info to my version, the cvs version got its own (somewhat incompatible) -v -v -v. I stopped working on my fork four months ago, and coincidentally the CVS has not seen a checkin for the past 4 months. But I guarantee you that if I start checking stuff into my tree again, "oh, look, more checkins to CVS". It's happened how many times now? Maybe I'm just imagining that there's a weird cycle going on where the CVS dying down encourages me to work on my version, and me working on my version encourages the CVS to start up again and make unpleasant forensic work for me to do if I don't want to feel like I'm doing a half-assed job of making the best tinycc version I know how to (thus totally discouraging me from working on my fork again until CVS goes silent for long enough that I'm sure it's dead _this_ time). But even if it's coincidence, I'm not working on tinycc at all anymore (my fork, somebody else's fork, whatever) while the darn CVS repository still exists. Even if I'm imagining it, it still bothers me, and it still makes unpleasant work for me to see what bug they think they're fixing and whether or not it applies to my version. That CVS repository hung over my head for two years, and that's long enough. It's no fun anymore. When I stopped regularly posting on this list, and changed the license of my project, that encouraged the existing developers here into enough of a spurt of activity to put out a 0.9.24 release. Maybe this will encourage another such spurt. This difference this time is, I don't really care. I don't believe development done in the CVS archive in savannah will never produce a compiler capable of building an x86-64 version of a current linux kernel. It will continue to lurch along until 32 bit hardware becomes obsolete (just like Windows XP), but so what? Maybe after that we'll all be using Apples (and the mach-o backend I've wanted to work on is even farther down the todo list of "things nobody else on this project cares about"). I cannot make CVS go away. I've spent two years trying to work around CVS. I've increasingly distanced myself from it, but it follows me. This is not a new issue, here it is cropping up a year ago: http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00107.html http://lists.gnu.org/archive/html/tinycc-devel/2007-05/msg00075.html Here it is cropping up February 2007: http://lists.gnu.org/archive/html/tinycc-devel/2007-02/msg00028.html Here I am back in October 2006 trying to shut down my mercurial tree, handing Fabrice a tarball of all the patches I'd collected: http://lists.gnu.org/archive/html/tinycc-devel/2006-10/msg00122.html Why? Because if he was going to check stuff into CVS, I wasn't going to track it. I can't track CVS, and never could. I was happy to step back and become just another user. (Still would be if the project actually did what I wanted, which it doesn't.) Before I ever _did_ a fork, we were arguing about source control: http://lists.gnu.org/archive/html/tinycc-devel/2006-09/msg00049.html And I described my initial efforts to create a mercurial mirror I could actual develop against as "fighting with CVS": http://lists.gnu.org/archive/html/tinycc-devel/2006-10/msg00042.html I spent two years trying to overcome the CVS repository, but the CVS repository is still there, and like a nuclear waste disposal site it's likely to continue to be there, festering, forever. Two years is about my limit for playing sisyphos. I can't do tcc development without having to deal with CVS, thus I can't do tcc development. Rob _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
