An initial proposal for review

Thu Mar 27 09:26:20 UTC 2008

Hi Joel,
           Thanks a lot in spending your time in going through my proposal
and giving suggestions.

> See separate post.

As per what you have said in the separate mail on OO, I have entirely
retained all the OO terminologies. I hope I am not wrong from what you have
said. Please comment on this.

+ "The second variant converts the POSIX standard timespec structure
> into a single field 64-bit unsigned integer making the math operations
> on the timestamps more fast and reliable." isn't technically the goal --
> it is close.  How about this wording:
>
> The second variant uses a 64-bit unsigned integer representing
> nanoseconds since the POSIX epoch.  This will make the timestamp math
> faster on many target architecture

First of all I have to apologize for now not having a detailed discussion on
this issue which forms the heart of the project. These are the errors that
happen when I do things without detailed discussions. I will take care that
such things wont happen in future.

I have changed it through out the proposal. Please tell me if I am right in
the revised proposal I am sending you.

Also this is something that I do not believe can be selected at application
> configuration time.  I think it is an RTEMS compile time option so
> you can save space by not mentioning confdefs.h at all.  You are using
> a "configure time option to direct conditional compilation"
>
> It is even possible that you might do something like have a score
> timestamp
> that includes cpuopts.h and then conditionally includes implementation A
> or
> implementation B.  Or the Makefile.am could pick which implementation to
> compile and appropriate headers to install.   Correcting and going light
> on
> this descrtption will help you technically and on character counts.

This is again a blunder I have done by taking things for granted. In the
revised proposal, not to make things too complex, I have changed it to
something like this "compile time option that can be selected while running
scripts during configuration". I will enhance this based on your suggestions
and will work on the details like including cpuopts.h or using
Makefile.amin my blog. Is it ok?? This is to keep a check on character
count.

Oh are they an English teacher? :-D

He He He. No they are my classmates.

But the friends are right in that it is bad form in technical
> proposals.  You can use
> phrases like "this project" to be neutral though.
>
> - This project consists of...
> - At the conclusion of this project, we ...
> - Phase 3 of the project concludes...
>
> Also saying things like "design phase", "implementation phase"...
> documentation phase
> and test phase can help avoid I.
>
> One trick is to use abbreviations.  I don't know how many times "Score
> Timestamp"
> is used but making it "ST" after the first reference will help.
>
> Also shorter simpler words sometimes helps.
>
> nanoseconds -> nsecs...
>
> But mostly you need to get away from lengthy prepositional phrases.  My
> dissertation was bad about saying XXX of the YYY where I could have
> said YYY XXX ... if that makes sense... of the.. is often a junk type
> phrase.
>
> Consider this sentence from the Project Details:
>
> "When nanosecond granularity was added to RTEMS timestamps in version
> 4.8.0 and above, an immediate option was to use POSIX specified struct
> timespec containing two fields of 32-bits data types as a data
> structure. But performing math operations on struct timespec has been
> proved to be very slow on many of the target platforms supported by
> RTEMS. So the idea of this project is to provide a 64-bits timestamp
> support conditionally."
>
> When nanosecond granularity was added to RTEMS timestamps in version
> 4.8.0 and above, an immediate option was to use POSIX specified struct
> timespec containing two fields of 32-bits data types as a data
> structure. But performing math operations on struct timespec has been
> proved to be very slow on many of the target platforms supported by
> RTEMS. So the idea of this project is to provide a 64-bits timestamp
> support conditionally.
>
> Rough cut at a shorter version since your audience knows some background:
>
> Nanosecond timestamps currently use POSIX struct timespec.
> Math operations on struct timespec is computationally expensive.
> This project will implement a 64-bit timestamp which is more
> efficient on many targets. Individual targets will be able to select the
> implementation that is more efficient for them.
>
> A bit shorter... another example:
>
> "Since ScoreTimestamp is an abstract class, the core part of this
> project comes into picture now as a second implementation of this class."
>
> ST is an abstract class with two target selectable implementations.
>
> Another wordy place is.. "I would again perform verification of all the
> test
> cases in the same manner considered earlier."
>
> How about: "Verification testing must be repeated."
>
> This same paragraph is long because it repeats the details of the
> phase.  Just say something like "upon completion of the implementation
> phase, "

I have considered all your suggestions above. I have made all the changes as
you have mentioned above In addition to the above pieces, I have also
changed things through out the document based on the above suggestions.

This is last but not least... I think your benefits section is good.
> Try to make sure you don't repeat details from the description
> unnecessarily.

I have changed this a bit. Can you please tell if it still contains
repition.

>
>
> I don't think example code will be needed since it is used completely
> in RTEMS itself and you will do 100% testing of it both functional
> and performance using the RTEMS test suites.

Ok understood. I have taken out this part. I first thought that it will be
required for Application Programmer's Manual or for some one else who uses
this for the first time, i.e new contributors or users. Anyhow removed.

> Phases could all start with resume like phrases which start with a verb.
>
> "Work with.." "Analyze ..."
>
> That eliminates garbage phrases like "In this phase I will" which
> helps on the character count.

    Have taken care of this part through out the proposal

>
>
> I am not being too picky.. overall it is very good.. just needs
> tightening to loose 3500 characters. :-D
>
>    Thanks a lot for all the reviews. I have mailed you the 5th revision of
my proposal (2 revisions after my friends' reviews, 3rd based on Daron's
suggestions, 4th based on your suggestions, and the 5th revision was based
on self-review). I will also mail this to as many mentors as possible. Since
any number of reviews will not be sufficient to bring out the perfecr
proposal.

    I think the proposal has now come to a level. I donno whether Google has
imposed restriction of 7,500 characters including spaces or not. The
document now is 7,200 charachters not considering spaces and 9,100
charachters considering spaces. I have mailed you a manually wrapped text
version too, since google accepts only in the plain text format as one the
participants of GSoC 2007 told me. I will take out all those design symbols
in the final proposal. That was just to keep the text version neat and look
good. If possible please go through this version I have attached.

  Also I have made available the empirical test I was claiming to have done
through my blog and link to the same is given in the document. I have given
it below too[1 <http://madhusudancs.byethost13.com/rtems/empiricaltest>].
Please go through it and give your suggestions.

  Also I have made my proposal available through my blog to
everyone[2<http://madhusudancs.byethost13.com/rtems/proposalgsoc>].
Since this is the 5th revision and I have incorporated most of the things
you have suggested, I will be eagerly waiting for your suggestions for the
6th revision. With this revision I will also be expecting your "Go Ahead!"
signal to submit this proposal through Google Application Area. I feel I
should do it today since I had promised that I will be submitting the
proposal on Thursday, and further all of you mentors will have access to my
proposal through Google's infrastructure. So we can still discuss and edit
the proposal till April 1st 00:00 (UTC).What is your take on this?

[1] http://madhusudancs.byethost13.com/rtems/empiricaltest<http://madhusudancs.byethost13.com/rtems/empiricaltest>
[2] http://madhusudancs.byethost13.com/rtems/proposalgsoc<http://madhusudancs.byethost13.com/rtems/proposalgsoc>
-- 
Thanks and regards,
Madhusudan.C.S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080327/d5eb52b8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: madhusudancs-rtems-rev05.odt
Type: application/vnd.oasis.opendocument.text
Size: 29523 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20080327/d5eb52b8/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: madhusudancs-rtems-rev05.pdf
Type: application/pdf
Size: 14278 bytes
Desc: not available
URL: <http://lists.rtems.org/pipermail/users/attachments/20080327/d5eb52b8/attachment-0001.pdf>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: madhusudancs-rtems-rev05.txt
URL: <http://lists.rtems.org/pipermail/users/attachments/20080327/d5eb52b8/attachment-0001.txt>