On Tuesday 01 February 2005 10:24, Jason Cooper wrote: > John Myers ([EMAIL PROTECTED]) scribbled: > > A clarification: > > I'm not talking about time estimation here. What I'm talking about is > > having each provider provide a minimum of two pieces of data: the > > number of subtasks it will run, and the number of subtasks which > > have been completed. > > So more like make saying "I have 33 files to compile, 13 are done"? Yeah, except a whole hierarchy of those.
> > On Tuesday 01 February 2005 02:47, Jason Cooper wrote: > > > > Also, progress information does not have to be limited to a percentage > > > > (though > > > > that is required). The information could contain many things, like > > > > compiler > > > > command lines, warnings, errors, einfos etc. > > > > > > This is the line item requirement I would drive a truck through, if I > > > were a customer/user. :) > > I think i did not properly articulate myself here either: What I meant was > > that > > in addition to the subtask count and subtask completion count, a client > > could > > send lots of other data, too. > > > > Or, again, perhaps you understand me, and I do not understand you. > > Sorry, I spend a lot of time focusing in on customer vagueness and nailing > it down. If you don't nail it down, you get 15 great 'ideas' that are > 'easy' to add two weeks before the delivery date, and contractually, you > would have to do it, if you didn't force them to restrict scope in the > beginning. > > In short, I understood what you were saying, I was just "highlighting an > area needing further clarification", albeit colorfully. :) > Ah, I get what you were saying with the truck thing. > > > Not > > > to rain on the idea. :) The problem is much more complicated than it > > > initially looks. For insight, take a look at the section in > > > linuxfromscratch regarding SBUs (static bash units). > > > > > > http://archive.linuxfromscratch.org/lfs-museum/4.0/LFS-BOOK-4.0-HTML/chapter02/aboutsbus.html > > I'm not looking to estimate the time left. I realize that that's impossible. > > Not impossible. Just that the potential gains are not worth the work > involved to implement. I agree. > With the adoption of the 2.6.x kernels, it's not as critical for most > users to know how long something will take. For me personally, I never > watch the 'emerge -uDav world' process. I start it on 4 machines, get a > cup of coffee, and proceed with normal computer use. It doesn't > interfere with user interaction at all, so I don't care if it takes 2 > hours or 2.5. Just let me know when it's finished. I usually do the same, but I would rather see a progress indication than compiler command lines. (though I would like them to be available for me to see, hence the extra data fields) > > > Personally, I would do less planning and more writing, some of the best > > > projects started off as a hack to scratch an itch. Keep it simple. A > > > lot of the most useful programs out there are very small. It can always > > > be rewritten later to include TCP/IP or threads. > > Yeah, I just wanted to make sure the idea wasn't stupid. > > Now that I understand you're not trying to predict compile times, it > seems much more feasible. However, I would most likely not use it > simply because it doesn't solve a problem I have. Others opinions are > certainly valid also. Is it worth pursuing? Well, if it solves a > problem _you_ have, go for it. That's all that really matters. Fine then, don't use it! =) > > If you find it useful, most likely others will too. I hope so! Thanks for the input! Since I have gotten several voices in favor of it, I will embark upon this great and noble expedition to improve my life (and work on building a reputation), and will report back here (maybe gentoo-dev first) when I have something to show -- t3h 3l3ctr0n3rd <[EMAIL PROTECTED]> Supermarket Deli Clerk and Student Programmer
pgpJmKfW2SBcp.pgp
Description: PGP signature
