On Sun, Sep 23, 2007 at 08:03:35AM +0200, Sam Ravnborg wrote:It is not about particular case, it is about whole environment. * interactive: shell (profile setup).--> source editing / patching `-> building parts / doing tests where profile is one particular source tree with particular config/development goals. On multiple terminals (sessions), one may just type in favorite shell `wana profile-xx` and environment is set up there. I.e. + where ever you are, it's easy to go to current obj or src tree, + quilt knows its setup + kbuild does also + tracking files, sent to editor (e.g. emacsclient / emacsserver) o easily composing file / change sets to be operated by quilt o kbuild knows exactly what to check and possibly to rebuild + all actions are written to history, that can be imported into any session o saving sessions o restore sessions: checking profile consistency / updating + less ugly (e.g. just stupid bash command line) user interface o even ordinary command line can be improved much-much more in terms of efficiency and comfort o more nice-looking information of what is happening and how is happening * automatic: running setup of selected profiles: o patch/update sources o configure and (cross) build multiple source trees with multiple output trees each. o run time testing: emulators, hardware. Many ideas, collected in kbuild-2.5-history.tar.bz2 back in 2000, are still interesting and useful. More i do development, more i realize, that i spend too much time to do trivial and repeating things. And this time will not go less, if something like that will be by hand. I'd really like to see a work flow of best development staff, because behind patches i can not see anything. And frankly, i doubt there's anything significant there. The only sharing of tools i can see is patch scripts (now quilt), diff-tools, linux/scripts. Still just tools. There's no environment, where people would know particular configs for editors, mailers, 2-3 steps easy to get right help messages, i.e *environment*. UI tricks, like common, most useful, sh aliases for using tools, different color schemas: for error/log output, editing C or asm (with linux specific annotations, rules), tools like checkpatch, but not checkpatch -- helper for developers to get changes checked and ready to create actual patch, etc. etc. etc.... For example, i'd really like to have, candy C + diff color fontlocking (emacs' brain damaged lexicon) for easy patch reviewing. I did some trivial enhancements more than 3 years ago, like highlighting of actions that change variable's value, thus, i don't do many stupid things in C any more. I'd like to have candy fontlocking for sed and shell and sed-in-shell syntax, etc. etc. And all this is needed just for stupid terminal emulator. So, what people are doing all this time? Noo, X? There's no X, period. ____ -
| Andrew Morton | -mm merge plans for 2.6.23 |
| Benjamin Herrenschmidt | Re: [PATCH] Remove process freezer from suspend to RAM pathway |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| Mel Gorman | [PATCH 6/8] x86_64 - Specify amount of kernel memory at boot time |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | Re: Soft-Lockup/Race in networking in 2.6.31-rc1+195 ( possibly?caused by netem) |
