Hey,
> It's just that adding new feature mostly gives lesser exposure to code as
> compared to fixing an existing bug.
Well, that can be achieved by adding new features as well. Showing your
skills by fixing bugs will be good, given that the bug involves you to
look, understand and change code at every level of the stack, and not just
the frontend (html/css) part of it.
Things like adjusting the size of text-boxes as a bug fix is not our
priority for sure, but something more elaborate than that. By elaborate I
mean, a bug-fix or a feature that touches bits and portions of the whole
stack.
Surely we'll proceed with debugging last year's code, merging it to the
master branch and finally deploying it (in the first iteration), but that
must follow once we have decided to go forward with OGV as a GSoC project
and we have a student developer assigned to the project.
For now it is just a game of who can do what, i.e. a student displaying
his/her skills, relevant for the project, which should be portrayed by
handling the stack as a whole, either through debugging or by adding
something new. It is always upto the project owner, if he wants to
incorporate the new feature or not, but it surely puts the student's point
forward that he knows about the project he wishes to work for.
And since this is the part where students put forward their skills relevant
for the project, things like merging and debugging previous year's code
should ideally be proceeded with, once we begin with the official coding
period. We do not intend to use the proposal and patch submission period as
the actual development period, do we!?
The ability to read the existing code and understand it is very crucial
> for any open source project, specially for this term of OGV in GSoC
Yeah, but then, just that does not make OGV a GSoC worthy project. We would
finish the debugging and code cleaning in the first 2-3 weeks of the
program.
If you have looked at the GSOC2015-merged branch, a lot of tasks are either
already present, or need to be polished. There are 2-3 high priority
medium-hard problems (which have been taken note of), but even those are
not enough, to make it a "GSoC worthy project". This might be like a ~20
hours/week workload (on an average), instead of the standard ~40 hour/week.
Thanks
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785231&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
