On 11/21/06, Henrique de Moraes Holschuh <hmh@xxxxxxxxxx> wrote: > Well, I have spent some time getting to know git, stgit and cogito. > Unfortunately it does take some time to really get all the quirks, and > those three *are* quirky like all heck. You may want to report your experience on the git@vger list, there is some talk now of fixing stuff and quality input from new users can be very useful. > Shem, it includes the T43 ec-bug-fix you don't like, as it worked better > here with userspace than the more correct fix. Err, which one and why didn't I like it? So many patches... > 3. Add rate control to procfs and any sysfs APIs, to avoid local > DoS. Read fan speed once every 5s, read temperatures once every 2s. I don't think this is right to have driver-specific code for this. It's an issue shared by many drivers, so ad-hoc solutions are the wrong way to go about it; see the recent threads about battery and hdaps monitoring. For now, just trust the user; there are so many other ways to DoS a Linux system isn't not even funny. (My latest example: turns out that an accidental fork loop with oprofile running means painful threashing death. And it effectively halted the rest of userspace, tp-fancontrol included, causing the fan to spin furiously in disengaged mode for half an hour before I pulled the plug.) > The TODO feature lists is: > 2. Add kernel-space fan control override What do you mean? > I am still looking at what I should be doing for the devel branches. I can > use stgit, but that requires some git usage that is annoying on remote repos > (you will need to use Pull: +<git uri> to disable fast-forward-merge > checking). I am studying git-rerere and git-rebase now and I will see what > I can do. > > stgit devel branches, if any are made public, will be named stgit/*. Of > course, all of them might be rewond, so you need to know what you are doing > to pull or clone them. I don't know how well stgit branches play with > remote repos, as it has extra metadata. I don't think the StGIT metadata will survive a push or fetch (but please do ask Catalin on git@vger). I think your options are: 1. Just push --force the tip of your StGIT stack, and tell people to use +ref. 2. Push the tip of your StGIT stack, using a new branch every time.This is essentially what's done with the -mm tree. 3. Linearly append patches, instead of fixing earlier ones. 4. Apply git on top of a quilt tree. Again, this is worth bringing up in git@vger. Shem ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ ibm-acpi-devel mailing list ibm-acpi-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/ibm-acpi-devel
