On Tue, Jul 7, 2009 at 8:32 AM, Subrata Modak<[email protected]> wrote: > On Mon, 2009-07-06 at 22:09 -0700, Garrett Cooper wrote: >> In order to put libcontrollers.a in an appropriate location, s.t. the >> cpuset, etc tests can properly find it, we need to adjust the Makefile >> to establish feature parity with the current backend supported in the >> cpuset Makefiles. >> >> This patch is needed to properly address the cross-compilation issues >> just posted on the list. >> >> This requires PATCH 2/4 and PATCH 3/4 in order to function. >> >> Signed-off-by: Garrett Cooper <[email protected]> > > Great. A Few comments from me: > > 1. I am little confused over which patches precedes whom. And i am > not seeing PATCH 2/4 and PATCH 3/4 in my mailbox,
Yeah... I went kind of crazy with the numbering schemes >.<. 1/3, 2/3 were the original numbers (I originally thought I was only going to add in 3 patches), but patches 2 and 3 can operate irrespective of one another, to a large degree, whereas patch 4 (and a few of the other patches) clearly depend on the work done with patches 2 and patches 3, and I wanted to make the patches more manageable for review because I want to make sure that the direction I'm moving in is clear and makes sense technically, so we don't end up with a system that people will either dislike or will scrap. > 2. Can you please send the other patches which has dependencies on > PATCH 2/4 and PATCH 3/4, only after the actual series from PATCH > 1 to PATCH 4 has been reviewed by Mike, others, and myself (or > Mike) has checked them in (1 -> 4) > > You are already doing a great work, still, i would just like to point > you the following. Give me some robust documentation (i know you have > already initiated that in your patch). I would love to see the > following: > > 1. A short description on why the present system is having > problems, > 2. How the present system (after your fixes are checked in) helps > solve them (cross-compilations, easy mainatinence, autoconf, > etc), > 3. Guide to users on how to use the present system, I started to do that with README.mk-[devel|user], but it can definitely be expanded and improved further. More comments w.r.t. what needs to be discussed would be really helpful. Let me know to which extent you would like the documentation to go to as well so that I hit as many key points as possible so more folks can join in the fun :). > Once that is done, i would encourage you to come up with some article, > or, whitepaper on a topic say: > > --- "Towards a better LTP Build System" --- > > I would help you to get it published in lwn.net(you yourself can even do > that if you have more clout with them). We can even send it to other > forums. This is very important from our projects perspective. If the > changes that we are about to make is really helpful to kernel > developers, the article should encourage them to use LTP. And hence we > will increase LTP contribution significantly in the long run. The > projectś visibility will improve drastically. Hope you understand my > point. Perfectly sir. Any form of positive PR for the project is a good thing, and I'll gladly do that. I'll have to brush up on formal documentation writing as it's been a while since I've done that, but that shouldn't be too hard to do. I'll have respins of the patches tonight (sometime before 1am PST) because I ran into the rt_sigaction* issue yesterday, but the work done resolves that issue, so I can continue my work tonight to validate the output from one tree (with my patches) vs the vanilla tree. I need to get back to Tcl and expect work for Cisco for the day because I have more stuff on my plate to complete :). I'll try to keep the clean patches coming though because there are ~2 other spots in the default tree were files aren't cleaned, because I want to reduce variation between my changes and the vanilla tree to simplify my life a bit, as this patchset will most likely take 1~2 weeks to take effect in HEAD (reviewers willing). Thanks for the feedback! -Garrett ------------------------------------------------------------------------------ Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/blackberry _______________________________________________ Ltp-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ltp-list
