Gsoc 18 Project | Collect build statistics

Vishnu vishnum1998 at gmail.com
Mon Apr 23 22:45:37 UTC 2018


Hey,

So first thing.
(a.1) I am planning to install ubuntu on my pc in a day.
        I guess We can install Macports on that.
(a.2 , a.3) Once macports is installed i'll install mpstats ,buildbot too.

(b.1) I went and completed week 1.But i am unable to access week 3 , week
4.Because the course starts on April 30 i guess.
I went through the topics.
Week 3 : Subqueries and Join
Week 4 : Modifying and Analyzing Data with SQL

So now would learn more about these topics through youtube, many other
resources.

(b.2) Will look into them.
(b.3) Django hopefully wouldn't be a problem.

(c.0)  I would suggest that we create a new repository for your project
under
MacPorts, you fork it and use your own fork for endlessly playing with
it, testing etc
This sounds good.
I think i would be more comfortable with Github.

(c.2) Can be done.
(c.3) You are talking about Build History data ..right?
There is already a JSON API for it as you said..so cant we use it? (
*https://build.macports.org/json/help
<https://build.macports.org/json/help>* )

(d.1 , d.2) Yes will do the research .


(e.1) I think when i will be changing Buildbot to update the database after
every build ..Then i would need Tcl.
Will learn them as i get time.

Will see Project Description.

Also i have my Semester End exams from 27 April - 7 may.
So maybe i would not be able to reply on time.

Thanks
Vishnu







On 24 April 2018 at 03:37, Mojca Miklavec <mojca at macports.org> wrote:

> Dear Vishnu,
>
> I have a bunch of suggestions written below. Community bonding should
> usually be used to getting familiar with our codebase, our tools, our
> communication channels, getting to know people, ...
>
> Since you are creating a standalone product, this community bonding
> could be slightly different (not so much need to learn our base code
> by heart), but it should warm you up and get you up to full speed by
> the time the coding period starts.
>
> The most important parts are:
> - getting MacPorts installed somewhere where you have regular access
> - creating a repository and finish/improve the planning, I would like
> to see the database design finalized, finish the sample HTML document,
> ...
> - creating tickets with milestones
>
> I hope others will be able to comment on my suggestions (they are not
> universal truths :)
>
>
>
> INSTALLING MACPORTS, BUILDBOT
>
> (a.1) We explained that owning a Mac was not a requirement for working
> on this project, but it would be orders of magnitude easier to work on
> some tasks if you had a regular access to MacPorts. This could either
> be:
>   - SSH access to a remote Mac or VM
>   - A Linux machine (even if Raspberry PI) or a VM with Linux
>
> You should start working on this as soon as possible because it would
> be a pity to waste precious time during the coding period. MacPorts
> can theoretically be installed on a UNIX machine, but there might be
> problems of one kind or the other. We can help you circumvent the
> problems, but you need to star working on this ASAP.
>
> Please let us know what your plan is.
>
> (a.2) With MacPorts you should be able to install mpstats and use it
> to submit statistics (to either the official server or your new server
> once ready).
>
> (a.3) It would probably be quite helpful if you manage to install
> buildbot and replicate our setup (at least to some extent). But (a.1)
> is a strong requirement for that, else it makes no sense.
>
>
> SQL & OTHER TOOLS
>
> (b.1) This is an absolute must:
>     https://www.coursera.org/learn/sql-for-data-science#
> along with some further understanding of primary keys, indices,
> foreign keys, ...
>
> Let us know whether you managed to subscribe and how you are
> progressing, whether you have any further questions etc.
>
> (b.2) I found two (fully optional) courses on web design:
> - a very lightweight one with very clear explanations and adorable
> teacher, good for listening to while going for a walk :)
>   https://www.coursera.org/learn/responsivedesign/
> - a more comprehensive one about bootstrap 4:
>   https://www.coursera.org/learn/bootstrap-4/
> You might know these things already and even if not, you probably know
> enough to come up with some basic styles for what we need; we don't
> need perfect design anyway.
>
> (b.3) Django (which you should know from inside out :)
>
>
> PLANNING
>
> (c.0) Open for discussion/suggestions ...
> I would suggest that we create a new repository for your project under
> MacPorts, you fork it and use your own fork for endlessly playing with
> it, testing etc. (No need to fork though, you can just start
> somewhere.) Once you think that part of your code is ready for review,
> you submit a pull request, we review it and merge it. That way we
> would end up with clean code upstream, all of it being properly
> reviewed.
>
> Once the code ends up in the MacPorts repository, that code should
> basically be ready for deployment.
>
> We use Trac as our main issue tracker. It depends on what others
> think, but as a pilot project we could use GitHub issues & milestones
> in this case. What do others think?
>
> (c.1) I would suggest to turn your application (just plans, no
> personal info) and spreadsheet with database into some
> documentation/plan document in that repository. Then we can make
> further suggestions for how to improve the plan before the summer
> starts.
>
> (c.2) Let's use the bonding period to open a bunch of tickets and
> assign milestones to them, say:
>   - "install MacPorts on X; milestone: community bonding"
>   - "accept and store installation statistics; milestone: 1st midterm"
>   - "deploy basic page; milestone: 1st midterm"
>   - ...
>   - "implement OAuth; milestone: stretch goals"
> to match his timeline from the proposal. We might need to identify
> further requirements (that could be implemented by someone else) for
> the work to be complete (like: improve portindex2json, whatever needs
> to be changed on the buildbot side, ...).
>
> (c.3) Plan the API to get the data from the database in JSON format
> (so that someone else could write an independent app with the same
> display functionality).
> More in a separate email, I guess.
>
>
> MARKET RESEARCH
>
> (d.1) Figure out if the app could be deployed somewhere temporarily.
> (Heroku?)
>
> (d.2) Do some "market research" of different available graph drawing
> toolkits and try to report pros/cons for our application. (Personally
> I would like to find something that would allow zooming and sliding in
> time, but even if that requirement is not met, that's OK.)
>
>
> MACPORTS BASE
>
> (e.1) Usually we would have suggested the students to get really
> familiar with the Tcl and MacPorts base. I'm not sure how much Tcl is
> really needed in this case. You might want to be able to modify
> mpstats or portindex2json or something like that, so it helps to have
> a basic understanding of our code, but the tricky stuff can be done by
> someone else when needed.
>
> Here's a video about Tcl from Clemens:
> * https://youtu.be/46qshiDskrM
>
> That said, you should become familiar with various concepts of how
> MacPorts works from the user point of view, where all the resources
> are (build infrastructure etc.), ...
>
> PROJECT DESCRIPTION
>
> The official project description still has some typos and could be
> improved. It can still be modified until the coding starts. Low
> priority, but let's think of some improvements during those three
> weeks.
>
>
> Mojca
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20180424/73e21134/attachment-0001.html>


More information about the macports-dev mailing list