Hey all,
Please find my reply in the form of inline comments.
Thank you.
On 04/04/2012 08:43 PM, brlcad wrote:
On Apr 03, 2012, at 02:30 PM, Suryajith Chillara
<[email protected]> wrote:
This is the my proposal for the "Benchmark Performance Database" (web
development) project idea for GSoC 2012 (
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/suryajith/8002
<http://www.google-melangecom/gsoc/proposal/review/google/gsoc2012/suryajith/8002>).
I would like to request you folks to go through the proposal and
comment where necessary.
Hello again, Suryajith, and thanks for sharing your proposal with
everyone. Just a quick review, but it looks like it has all of the
requisite pieces of information we like to see.
I found your frontend coupling to mediawiki to be interesting and
would like to see some rationale in the write-up as to why you'd like
to develop it there (as opposed to a drupal or django or custom or
whatever front-end). If the front-end is predominantly a read-only
view of the database, that seems like a peculiar choice, so it'd be
nice to see your reasoning.
My intention of trying to couple the frontend to mediawiki/drupal (Sorry
I did not mention that before) is to add it to the already existing web
framework of brlcad and thus minimizing the number of services(and thus
lesser sys-admin work related to that) that brlcad organization has to
run and thus maintain.
The wide range of already existing opensource extensions to
mediawiki(though none readily available for me to use) would help me not
to start from scratch. I would prefer mediawiki for various other
technical reasons.
Since the benchmark data is always written to a file on the disk and the
file provides all the necessary input the organization wants to collect,
the data collection through the front end is not really needed at the
moment for the proposed backend.
Your first June 4 deliverable date seems optimistically "ambitious" to
me. You describe sorting out the kinks for a complete database schema
along with the web API and *also* the log parsers within about three
weeks time. That may be how much technical time is involved, but I
don't believe that's sufficient time to include the extensive
discussions and documentation that should accompany the work
(particularly for the API). At a minimum, I'd like to at least see
some acknowledgement of time going towards API discussion and
documentation.
I have modified the roadmap in the proposal as per Sean's suggestions.
That last comment goes for everyone -- if you're proposing features
that are going to be exposed to users (whether they're developer users
working with API or non-developer users running tools), be sure to
allocate a little time in your proposal for discussions and basic
documentation. That's not something to be done after you're "done",
because you might not finish or you might fall behind schedule. It
should be accommodated throughout your schedule iteratively. If you
are proposing a new tool with 5 features, for example, you'd want to
include a documentation milestone for each feature (not just one
bigger tool documentation milestone at the end).
Cheers!
Sean
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
------------------------------------------------------------------------------
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
