Re: Google Summer of Code proposal for Javascript Frontend
Dustin J. Mitchell <dustin <at> v.igoro.us>
2012-04-01 01:28:39 GMT
On Wed, Mar 28, 2012 at 1:01 PM, Naveen Kumar <naveen.iitm90 <at> gmail.com> wrote:
> This is first draft of my proposal. Please give your feedback
As I mentioned in IRC, this looks good.
> 1. Javasciprt frameworks:
> Possible options:
> 1. jQuery
> 2. Dojo
> 3. YUI
This is a good preliminary list. I suspect that part of the summer
will be building "test" implementations in a few frameworks so that
you can make a judgement based on experience.
> 2. User interface design:
> This is the best time to implement a better looking design. I am not
> very good with web design. I am going to need help with that part. My
> idea of implementation is, first implement a general template which
> will be used in all the pages then implement rest of the features on
> it.
As Tom said, I think that the UI design is a separate task from the
implementation of basic usability. We don't have anyone within the
project who has a great strength here, either, so this may be
something to leave unfinished, in the sense that the UI at the end of
the summer is perhaps a bit clunky, but all of the support is there
for someone else to improve it.
I suspect that building that support will be most of a summers' work,
in fact -- and for the project such work is actually *far* more
important than getting any particular pages implemented at all. If
you finished the summer with an aweomse buildbot.js library written
that integrates tightly with one or more external JS libraries like
jQuery and provides easy, reliable access to the Buildbot API -- but
only actually implemented the build page with it -- I would count that
a resounding success. On the other hand, if you produce working
JavaScript code for a half-dozen user-visible pages, but each is
implemented in an ad-hoc fashion and not particularly flexible or
maintainable, that would be somewhat disappointing.
> As I understand JsonStatusResource class serves the /json requests,
> and is used in WebStatus class in baseweb.py. Hence it is synchronous.
> Any python coding work will be mostly in status_json.py unless I have
> to interact with databases. I am not aware of code outside of this
> module.
And you could coordinate with other developers on the project to make
the needed changes.
As a note, depending on the timeline, I may have a significant chunk
of the *new* API finished, and it would be great to begin your
JavaScript work against that. In particular, it will include support
for dynamically updating pages as state changes.
> Schedule:
> Google Summer of Code program is spanned over 12 weeks(excluding
> community bonding period).
> 2 weeks: familizing with code, deciding upon things(javascript
> framework, features to implement).
> 5 -6 weeks: implement existing features i.e. builders, buildslaves,
> build details, waterfall. As directed in other thread of devel list
> tests also will be written along with the code.
> 2-3 weeks: Survey for extra features and implement them.
> 2 weeks: Wrap up. Merge missing code(if any).
One thing to keep in mind is that there is potentially a long time
between finishing some code and seeing it merged into the upstream
codebase. I'd like to see a bit more detail here about what can
happen in overlapping chunks: after you've submitted a patch for one
thing and are waiting for review, what will you work on? I also like
to see concrete artifacts described in a schedule: as of week three I
will produce ___. This gives the you and your mentor measurable goals
to aim for, and helps the rest of the development community know what
to expect over the course of the summer.
Perhaps more importantly, I think that your project will include a
good bit of experimentation. For example, an effective technique for
selecting the best JS library for the purpose might be to implement a
"fake" buildmaster in Django (since you're comfortable with it), and
then build a simple JS frontend on top of it using each of the
possible libraries. Then you, and the development community as a
whole, could get some real-world experience with the libraries and
make an informed decision. Even though most of that code would not
end up in Buildbot, this would be an excellent contribution to the
project.
Even once that is done, you may do several iterations of writing a
low-level library, then building a page on top of it, only to find
that the library could be better designed.
> I have fairly good experience in python. I know twisted basics. I
> mostly work on django for web development. I used javascipt/jQuery in
> web development projects. I have little experience with UI design.
> Though I follow some opensource projects never really contributed to
> any of them. This is the first time I am working for an open source
> project. We use git in our college for versioning. I am comfortable
> with it.
Welcome! I think that this is a strong application, and demonstrates
that you've done your homework. I look forward to seeing the final
proposal! (of course, another draft is welcome too)
Dustin
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Buildbot-devel mailing list
Buildbot-devel <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/buildbot-devel
RSS Feed