Re: Now I'm curious...
Hello Steven, IIUC, 0.9.30 will come out of uClibc-NPTL branch? Can you post your ARM and SH4 patches (which are based on uClibc-NPTL branch) on this mailing list or put them in download area? Regards, Nitin Steven J. Hill wrote: On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
Hello Rob, I am curious now to find out if your curiosity got answered from this discussion? If yes, Could you please share your conclusions about uClibc future? Regards, Nitin Rob Landley wrote: On Wednesday 05 September 2007 5:18:32 am Denys Vlasenko wrote: Can you give me Peter's email address? It hasn't changed since he used to post here. Peter S. Mazinger [EMAIL PROTECTED] Rob ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Friday 07 September 2007 11:18:18 am Nitin Gupta wrote: Hello Rob, I am curious now to find out if your curiosity got answered from this discussion? My question was along the lines of What's up with this? so I'm not quite sure what form an answer would be expected to take... If yes, Could you please share your conclusions about uClibc future? Well, here's what I found out: 1) Steven Hill isn't doing any kind of merge of the various NPTL forks. Nobody seems to be doing so. The NPTL svn branch is not being actively developed at this time. 2) The last dozen patches applied to the main uClibc svn repository since its release were by the busybox maintainer. The most recent of those was over a month ago. There is nobody currently working on a 0.9.29.1. release, and the most likely candidate to _start_ doing so is me, except I don't mess with non-distributed source control systems anymore. The current maintainer of the project hasn't been spotted here in over a month. 3) The freenode #uclibc channel is essentially dead. The mailing list here isn't a major improvement. 4) I got a copy of Peter Mazinger's -hg tree a few days ago, and since then have watched him add more patches to it than -svn has seen since 0.9.29 was released. (Currently, 1242 changes since 0.9.29.) It doesn't currently work for me, but I continue to debug. Unfortunately, Peter A) doesn't seem to want to have anything to do with this list, B) doesn't want a larger userbase for his tree yet. From the #gentoo-embedded channel on freenode, earlier today: [20:27] landley Could I mirror your tree at http://landley.net/hg/plibc; with large warnings to the effect of This is a development tree that's in progress and not really expected to work. Don't bug Peter about it, he knows it's not finished and has a long todo list to work through. Bug me instead. For amusement purposes only. Not for internal use. Do not taunt happy fun library. etc? [20:30] psm landley: I dont think so, if you want to put it up, do it, but there won't be any updates to it later (I will disable the repository until I consider it usable), I do not intend to support it until I have ran basic tests, I do not have time for a larger userbase I'll let you know if/when he changes his mind on either point. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
RE: Now I'm curious...
Hi, What could be done to improve the issues you mentioned? I guess nothing about atomic operations, but what about TLS? What linuxthreads restrictions are you aware of wrt arm7 or uclinux? Thanks in advance for any help. Cheers, Matt -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Brook Sent: Wednesday, September 05, 2007 8:40 PM To: uclibc@uclibc.org Subject: Re: Now I'm curious... On Wednesday 05 September 2007, Daniel Jacobowitz wrote: On Wed, Sep 05, 2007 at 11:49:12AM -0400, Crane, Matthew wrote: What makes you say it would be useless? Or that the performance will suck? I'm curious too. I wouldn't expect it to work without a bit of hacking - I don't know if the futex and atomic bits in the kernel are right for no-mmu, and the last time I checked the arm no-mmu port, they weren't. But once that's solved, I would expect it to have the same advantages on uClinux that it has on Linux. Last time I checked (a coupe of months ago) the futex bits should work, TLS worked by trapping and emulating a hardware register (very slow) and atomic operations weren't supported. So with current kernels it's accurate to say that ARM uClinux NPTL won't work, and even the bits that do work will be slow. However I'm fairly sure that all these problems are fixable. We needed significant kernel ABI enhancements to make NPTL work on normal linux, so it's reasonable to expect the same changes will be required for uClinux. Saying use linuxthreads is ok, if you ignore the fact that noone is really maintaining the linuxthreads code, it has some fairly fundamental restrictions, doesn't scale particularly well, and probably doesn't work on ARM SMP hardware. Paul ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
Hi Rob, folks, On Wednesday 05 September 2007 00:38, Rob Landley wrote: Er, deciding to allow means nothing if nobody does the work. My objection is that people who were chased away from the current uClibc tree have since been doing more work than the people who did the chasing. That doesn't seem efficient, somehow. I don't care which tree is official. That means very little to me. I don't poke at svn much anymore now that I've moved on to distributed source control, and although it's _polite_ to post my fixes back here, if they don't get integrated oh well. My uClibc tree supports miniconfig. uClibc 0.9.29 does not. *shrug* I saw Linus' video. Distributed SCM is nice for development, but at the end of a day, people want to go to some official place and download a latest stable version. Yes. It's doesn't matter that developers use git or mercurial, the code has to eventually end up at http://www.uclibc.org/downloads/. Yes and no. When the maintainer of XFree86 threw out Keith Packard, he went off and started his own fork and the entire world followed. Glibc 2.0 and egcs were (more or less) such forks, prompted by stagnation. Back before Linus took up source control and was dropping the majority of patches on the floor (even the ones from maintainers), Alan Cox retired from Linux development for a year (went off and got an MBA) because people were starting to consider his tree the official one, and push him to become the new point man, and he didn't want the job. (More distros shipped stuff based on the -ac tree back in 2002 than on Linus's tree.) Yes Rob, basically you explain that when maintainership is bad, eventually someone else forks or takes over development. I am not arguing against it, I am merely saying that majority of end-users wants to download a release from website, not fetch svn head of git tree. It can be something else than http://www.uclibc.org/downloads/, but it has to be http://www.SOMETHING/downloads/. I'm not promoting any specific course of action, but a uClibc tree has come to my attention with about 30 times as many patches since 0.9.29 as mainline, and it's maintained by a guy who's answered over half the obscure technical questions I get stumped on about arm soft float and such (often answered by providing me patches). This developer will not return to this list, and has no interest in inheriting the existing tree (which is in an obsolete source control format anyway, and the new tree is mercurial which is my first choice these days anyway). ... I'm pointing out the nature of the problem. PSM is currently _doing_ the first, he's just not doing it publicly, nor in the context of this mailing list or the svn tree on uClibc.org. The second job doesn't have to be done by the same guy. Stable releases involve snapshotting the tree and applying bugfix patches only. There's less of a judgement call involved in that, especially if new stable releases come out often enough that the decision to leave a feature out until the next release isn't particularly painful. I could theoretically take the second job, but it's useless without the first. ... Between 0.9.28 and 0.9.28.1, uClibc went 16 months without a release. And when there _was_ a release, it was bugfixes for the previous version. The unstable branch had numerous new features that a decent chunk of its userbase couldn't live without, and they got used to using random svn snapshots in production. The maintainers actually recommended this. In fact, with the adjacent project buildroot, that was the _only_ option. I think this has greatly eroded the tendency to think of the uClibc.org release tarballs as the point of the wedge. So what does that leave, svn? So in current svn, which tree is taking point right now? Is it trunk/uClibc or is it branches/uClibc-nptl? Which one is slated to become 0.9.30? I honestly don't know. It's hard to have any kind of attachment to the existing tree under those sort of conditions. Let's all switch to mercurial/git doesn't solve it. Not by itself, no. It's just one factor I take into consideration when deciding which upstream to follow. I am a user of uClibc. I contribute the occasional patch and bug report, but I'm busy with my own projects, and mostly I'm looking for an upstream source to consume. What I'm doing here is examining my options. I'm not making any recommendations to anyone else, and certainly not trying to make trouble, but I am sharing my reasoning in the spirit of being open and fair to the other uClibc users. I don't currently know whether or not following PSM's tree is a better choice than following the one here, but I do know that it's an order of magnitude more active, and over the past year I've actually gotten slightly more of my technical questions answered offline by Peter than on
Re: Now I'm curious...
On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
Steven J. Hill wrote: On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. Or better, you can find SH4 port at STLinux ftp server at the following URL ftp://www.stlinux.com/pub/stlinux/2.3ear/SRPMS/stlinux23ear-target-uclibc-nptl-0.9.29-23.src.rpm This version contain some other changes/fixes with respect to the code Steve is having Steve, if you want, grab the latest code as well (Anyway no changes into the ld.so... is still working well) Regards, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
Hi Steven, I would be interested in the ARM NPTL patches for uClibc, Best regards, Steve On Wed, 2007-09-05 at 07:59 -0500, Steven J. Hill wrote: On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 latest SH4 uClibc public release in RPM source package: http://www.stlinux.com/pub/stlinux/2.3ear/SRPMS/stlinux23ear-target-uclibc-nptl-0.9.29-23.src.rpm There is also an SH4 uclibc toolchain and user-space applications (e.g. busybox). Binary versions of the RPMs are on same server. We'll hopefully release an entire uClibc-NPTL distribution for SH4 in the next few weeks. Carl Steven J. Hill wrote: On Wed, Sep 05, 2007 at 02:52:11PM +0200, Christian MICHON wrote: so, the NPTL stuff is ready... My branch contains a fully working NPTL for the MIPS architecture only. I have patches from CodeSourcery for ARM and ST Microelectronics for SuperH 4. Those are the only three architectures supported at this time. is it fully available somewhere now or it cannot be released ? The MIPS stuff is the 'uClibc-NPTL' branch. ARM and SH4 are in my mail folders somewhere if you are interested. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG3shQsOYe+9JwoiQRAkt0AJ9v1jX/PyhLQ/x7aLjCSOWYC3wTYwCfaH3i wAMiLmzehyxGzX8xqY0aRew= =Wqna -END PGP SIGNATURE- ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
Have you built nptl for arm7 no-mmu? I'm woried that I may be making the effort to integrate it into our build for a big let down and debugging effort in the end. It will not work. Using NPTL on a no-MMU system is going to be pretty worthless IMHO. You should stick with linuxthreads. Not only does it make doing TLS difficult, the performance is going to suck. Also, the stuff from CodeSourcery will not support no-MMU. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Mon, Sep 03, 2007 at 04:44:55PM -0500, Kevin Day wrote: Except for: 1) There is no stable uClibc, 0.9.28 is bugridden, 0.9.29 requires a number of patches only available in svn (let alone countless other bugs yet to be publicized) , and releases prior to 0.9.28 seem to have Yikes, is there a list of the known essential patches to 29? I'm using 0.9.28 and having problems with threads, so I'm attempting to upgrade to 29 as I see it includes a large libpthread update. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Monday 03 September 2007 4:08:06 am Christian MICHON wrote: On 9/2/07, Rob Landley [EMAIL PROTECTED] wrote: (...) I'm poking Peter to put out a release. I'll let you know if he does. (I'd happily send _him_ a cake, but he appears to be in Europe...) Hi Rob, and why not allowing us to peek at his 1194 commits instead ? Because he got roundly chewed out here and was essentially told to go away by at least two high-profile commiters, and Erik never stepped up to defend him, so he took his ball and went home? Now we're noticing that it was, in fact, a nice ball. does he have a public/private repository ? git ? mercurial ? svn ? He has a private repository of some kind. I spoke to him about it a year or so back but can't find it in my back email (might have been on irc). Recently he mentioned the number of commits in it, which is what brought it back to mind. Mostly what I see is when I bring up a question he sends me a patch fixing whatever it was from his repository... This would look less like a fork this way, no ? I think it's undeniably a fork, because he was checking everything in and was told to stop. He didn't create the fork, he was merging everything he did into mainline. That' show he got in trouble: Manuel and shjhill created the fork by telling him to stop merging last year. They thought he was merging too much. Of course, one could argue that a project on hiatus is about to fork anyway sooner or later... /me pleads the fifth: http://en.wikipedia.org/wiki/Tiny_C_Compiler My preference would be to see the people in charge back in the decision process. Maybe they're either too busy (understandable, they need to earn money also) or on holidays ? Patience then might be the key here... No flaming please :) I'm not flaming anybody, I'm just pointing out some interesting statistics. Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
- Original Message - From: Rob Landley [EMAIL PROTECTED] To: Christian MICHON [EMAIL PROTECTED] Cc: uclibc@uclibc.org Sent: Tuesday, September 04, 2007 12:45 AM Subject: Re: Now I'm curious... On Monday 03 September 2007 4:08:06 am Christian MICHON wrote: On 9/2/07, Rob Landley [EMAIL PROTECTED] wrote: (...) I'm poking Peter to put out a release. I'll let you know if he does. (I'd happily send _him_ a cake, but he appears to be in Europe...) Hi Rob, and why not allowing us to peek at his 1194 commits instead ? Because he got roundly chewed out here and was essentially told to go away by at least two high-profile commiters, and Erik never stepped up to defend him, so he took his ball and went home? Now we're noticing that it was, in fact, a nice ball. I agree that Peter was a valuable and aggressive contributor. It's sad that instead of communicating each other's concerns, high-profile committer(s) snatched psm's commit rights. IIRC, Peter got into trouble as his changes were huge, hard to review and some time broke the build and/or compatability. I am sure now PSM can very well contribute to uClibc and give it its glory back. I vote for offering him a maintainer position again. Regards, NK ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tue, Sep 04, 2007 at 01:08:53AM -0700, Nitin Gupta wrote: I agree that Peter was a valuable and aggressive contributor. It's sad that instead of communicating each other's concerns, high-profile committer(s) snatched psm's commit rights. Your facts are incorrect. Peter voluntarily removed himself and asked for his account to be deactivated. However, it is still active and he is welcome to check in changes. IIRC, Peter got into trouble as his changes were huge, hard to review and some time broke the build and/or compatability. This is correct. -Steve ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tuesday 04 September 2007 08:44, Rob Landley wrote: Er, deciding to allow means nothing if nobody does the work. My objection is that people who were chased away from the current uClibc tree have since been doing more work than the people who did the chasing. That doesn't seem efficient, somehow. I don't care which tree is official. That means very little to me. I don't poke at svn much anymore now that I've moved on to distributed source control, and although it's _polite_ to post my fixes back here, if they don't get integrated oh well. My uClibc tree supports miniconfig. uClibc 0.9.29 does not. *shrug* I saw Linus' video. Distributed SCM is nice for development, but at the end of a day, people want to go to some official place and download a latest stable version. It's doesn't matter that developers use git or mercurial, the code has to eventually end up at http://www.uclibc.org/downloads/. In the long run, successful long-term project must be usable by _users_, and users want to be able to figure out where latest code is, they don't want to search through forest of git/mercurial trees. Of course, if there is no agreement between maintainers and development slows down, sometimes it is naturally resolved by forking. It will be decided to do a release by whom? By whoever is doing most of maintainer's work. There are two editorial jobs involved in maintaining a project: 1) Deciding what to merge (and how), which often means saying no to the majority of submissions for the purposes of fighting off Sturgeon's Law. Book and magazine publishers do exactly the same thing with the slush pile, and movie producers do this with screenplays: this is nothing new. 2) Putting out stable releases. I've already mentioned I like time-based ones, and the video does a good job of explaining the benefits in detail. An interesting point is that the person putting out stable releases and the person controlling the development tree don't HAVE to be the same person. Especially once a stable release _has_ been issued, maintaining bugfix-only stable releases is often best done by somebody OTHER than the maintainer of the development branch. Do you propose someone to take these positions? If you use a modern distributed source control system, there's no concept of commit access. You can watch Linus Torvalds explain this on video, and hear him call CVS and SVN all sorts of nasty names. :) http://video.google.com/videoplay?docid=-2199332044603874737 http://kernel.org/ still exists, because people want to have official tree. Personally, I'm quite fond of Mercurial, as you can see at http://landley.net/hg;. Also, I just heard back from Peter whose tree is indeed in Mercurial. (Although not online at a permanent location, just when he leaves his machine on running hg serve, and the URL he emailed me last night is down at the moment. Possibly on a dynamic IP. I've asked him if I can mirror it on my website...) I have nothing against people using mercurial/git, it's just not very relevant to the question how to energize uclibc development? Let's all switch to mercurial/git doesn't solve it. -- vda ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
Re: Now I'm curious...
On Tuesday 04 September 2007 8:21:13 am Denys Vlasenko wrote: On Tuesday 04 September 2007 08:44, Rob Landley wrote: Er, deciding to allow means nothing if nobody does the work. My objection is that people who were chased away from the current uClibc tree have since been doing more work than the people who did the chasing. That doesn't seem efficient, somehow. I don't care which tree is official. That means very little to me. I don't poke at svn much anymore now that I've moved on to distributed source control, and although it's _polite_ to post my fixes back here, if they don't get integrated oh well. My uClibc tree supports miniconfig. uClibc 0.9.29 does not. *shrug* I saw Linus' video. Distributed SCM is nice for development, but at the end of a day, people want to go to some official place and download a latest stable version. Yes. It's doesn't matter that developers use git or mercurial, the code has to eventually end up at http://www.uclibc.org/downloads/. Yes and no. When the maintainer of XFree86 threw out Keith Packard, he went off and started his own fork and the entire world followed. Glibc 2.0 and egcs were (more or less) such forks, prompted by stagnation. Back before Linus took up source control and was dropping the majority of patches on the floor (even the ones from maintainers), Alan Cox retired from Linux development for a year (went off and got an MBA) because people were starting to consider his tree the official one, and push him to become the new point man, and he didn't want the job. (More distros shipped stuff based on the -ac tree back in 2002 than on Linus's tree.) In the long run, successful long-term project must be usable by _users_, and users want to be able to figure out where latest code is, they don't want to search through forest of git/mercurial trees. I think the ethereal userbase managed to find wireshark. http://www.linux.com/articles/54968 Of course, if there is no agreement between maintainers and development slows down, sometimes it is naturally resolved by forking. *shrug* I'm not promoting any specific course of action, but a uClibc tree has come to my attention with about 30 times as many patches since 0.9.29 as mainline, and it's maintained by a guy who's answered over half the obscure technical questions I get stumped on about arm soft float and such (often answered by providing me patches). This developer will not return to this list, and has no interest in inheriting the existing tree (which is in an obsolete source control format anyway, and the new tree is mercurial which is my first choice these days anyway). It will be decided to do a release by whom? By whoever is doing most of maintainer's work. Anyone can put out a release. I put out a release of my tcc fork: http://landley.net/code/tinycc/downloads/ And I plan another one soon. That is rampantly unofficial, I have no access to tinycc.org and wouldn't commit to a CVS tree unless well-paid to do so. But there are people using my fork. There are two editorial jobs involved in maintaining a project: 1) Deciding what to merge (and how), which often means saying no to the majority of submissions for the purposes of fighting off Sturgeon's Law. Book and magazine publishers do exactly the same thing with the slush pile, and movie producers do this with screenplays: this is nothing new. 2) Putting out stable releases. I've already mentioned I like time-based ones, and the video does a good job of explaining the benefits in detail. An interesting point is that the person putting out stable releases and the person controlling the development tree don't HAVE to be the same person. Especially once a stable release _has_ been issued, maintaining bugfix-only stable releases is often best done by somebody OTHER than the maintainer of the development branch. Do you propose someone to take these positions? I'm pointing out the nature of the problem. PSM is currently _doing_ the first, he's just not doing it publicly, nor in the context of this mailing list or the svn tree on uClibc.org. The second job doesn't have to be done by the same guy. Stable releases involve snapshotting the tree and applying bugfix patches only. There's less of a judgement call involved in that, especially if new stable releases come out often enough that the decision to leave a feature out until the next release isn't particularly painful. I could theoretically take the second job, but it's useless without the first. If you use a modern distributed source control system, there's no concept of commit access. You can watch Linus Torvalds explain this on video, and hear him call CVS and SVN all sorts of nasty names. :) http://video.google.com/videoplay?docid=-2199332044603874737 http://kernel.org/ still exists, because people want to have official tree. Sure. But if the official tree stops being the
Re: Now I'm curious...
On Tuesday 04 September 2007 3:08:53 am Nitin Gupta wrote: I vote for offering him a maintainer position again. Er, I don't think it works that way. (We vote?) And I don't think he wants the job. The great thing about open source is you can go off and do your own thing. He's done so. I'm interested in at least evaluating the thing he's done, possibly in using it in my projects. This might mean using his version instead of the version here, sending him patches for bugs I find instead of posting them here, etc. *shrug* If it works better for me... Dunno yet, just downloaded it last night, haven't had much of a chance to bang on it yet. (Still playing with linux-2.6.23-rc5. One new set of bugs at a time... :) Regards, NK Rob -- One of my most productive days was throwing away 1000 lines of code. - Ken Thompson. ___ uClibc mailing list uClibc@uclibc.org http://busybox.net/cgi-bin/mailman/listinfo/uclibc
