On 3/8/10, Mark Pottorff <[email protected]> wrote:
> In reviewing the BOINC server code, one runs across a number of things that
> would be helpful to others later if they were documented differently, fixed,
> or otherwise changed. However, it isn't worth changing a program in a build
> just to do such a thing. Is there a place to keep a list of trivial items to
> be incorporated with other changes to the program in the future? I don't
> really feel they warrant creation of trac items.
>
> A few examples:
> The output template overflow condition I discussed last week. I've revised
> the wiki to try and help others avoid such a problem, but the code could be
> enhanced to prevent the buffer overflow that occurs (the code that appears
> to perform such a check is too late to detect it).
>
> The comments in backend_lib indicate the create_result routine is
> only called by the transitioner. This is incorrect. It is also called during
> assignment to specific hosts, users or teams for a project using the
> enable_assignment flag.
>
>
> There is a value in the lib/common_defs.h:#define ASSIGNED_WU_STR "asgn"
> which would imply that one could change this string to another value and
> recompile, however the db/boinc_db.cpp has "asgn" hardcoded. It would seem
> it should use the constant defined in the .h
>
> Clearly anyone that has been caught by these has already resolved the issue
> in some way (or perhaps stopped using BOINC). But they are traps laying in
> the path of future hikers. It would be good to create a place where such
> things could be checked in the next time other changes to the same program
> are performed. I'm hoping there is some simple and easy way to incorporate
> these learning experiences in to BOINC, without making server upgrade any
> more difficult then it has to be (i.e. only changing programs that require
> change).

Are you *seriously* suggesting and encouraging changing several
unrelated things in a single commit?

Look at these changes and you'll see the commit message is irrelevant
in every and each of them:

http://boinc.berkeley.edu/trac/log/trunk/boinc/doc/index.php

That certainly does not make things easier. If you think commits are
"expensive" and making a commit for a "minor" change is "not worth
it", maybe it's time to change version control system?

-- 
Nicolas
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.

Reply via email to