GSOC

[Rainer Müller]

Hello Abhishek,

On 2018-03-25 16:43, Abhishek Kashyap wrote:
> I have drafted my proposals through GSOC portal.Please review it,give
> feedback and suggest changes.As time is very less (only 2 days left) So
> i hope you plase take steps soon as possible.

Your proposal is well-structured and follows our template. However, you
should be more careful with the English language and especially punctuation.

Let me go through the proposal and leave comments:

Project Idea & Abstract

The project idea section does not actually explain the project idea.

You cannot say that you want "To make MacPorts efficient ,useful and
popular". This would imply it is none of this at the moment. Also, how
does your project help to reach that?

In the abstract, the output of 'port selfupdate' is not relevant to your
proposal. Why are you not even showing the message for unread items that
would appear there? Why are you not demonstrating how 'port news' will work?

The goal needs to be made clear here. It is definitely not "to inform
user about exact configuration changes that has been made after updating
the port tree". Your goal is a mechanism to deliver announcements to
users of MacPorts. These announcements are distributed along with the
ports tree and can be read by users with a 'port news' command.

Methodology

Lots of details are left out or implied. The proposal should be written
such that it does not require prior knowledge on the topic. Imagine the
reader has never heard of what you are proposing, but has knowledge on
MacPorts itself.

One of the first things I noticed is that you must have blindly copied a
lot of stuff from Gentoo, without applying the necessary changes to
adapt this to MacPorts. The reference to Gentoo was meant as an
inspiration. We have not asked to copy and paste the functionality into
MacPorts.

a) News Manager

Why are you choosing a directory for the unread items? Where is this
directory? Are you planning to copy the news items them there? How does
it work with multiple ports trees? No details are given on this and I
honestly do not understand it.

Talk more about the mechanisms and what you want to achieve. Tell me
less what it will look like in the code. Before you tell me how you will
implement something, tell me about the design first. Afterwards you can
explain how this can be achieved with code, but first there has to be
plan what you even want to do.

I would have used the SQLite registry we already have to store the
unread state of each news entry.

You need a clear description here in which states a news item can be.
And then, which action will change the state of a news item? How will
these states be reflected in the database or in the filesystem. What do
you have to manipulate to apply a state change.

portdb, portdbapi, vardb, vardbapi, language_id, ...:
Lots of variables (?) or terms that do not exists in MacPorts.
Therefore most of the API description makes no sense. I assume you
blindly copied this from Gentoo, without applying the necessary changes
to adapt this to MacPorts.

unread_filename, skip_filename? What is this skip about? "skip" is not
mentioned before and never after. What should I make of such unconnected
pieces of information?

"updateItems: It will figure out which news items from NEWS_PATH are
both unread"
How exactly will it do that? This must probably be one of the most
important parts of the News Manager and you just left it out.

"getUnreadItems:It will determine if there are unread relevant items in
news.repoid.unread."
Aren't all items in news.repoid.unread relevant to the user? I thought
you filtered them before even adding them to the unread database?

b) News Items

Looks like a class description, but that is an implementation detail
that does not matter at this stage.

How would news items be stored in the ports tree?
What information do they need to contain?
What is an example of the file format?

c) Display

Are the restrictions full-blown Tcl expressions are just static
declarations?

"DisplayProfileRestriction": no such thing exists in MacPorts. Once
again, you blindly copied from Gentoo.

"count_unread_news": Why is this not the responsibility of the News Manager?

d) Adding command

So, a 'port news'. You tell me nothing more. How will it behave? Will it
have subcommands? What can the user do with it? When will an item be
marked as read? How will this interact with the News Manager?

All the implementation details here seem wrong. No, this will not be in
action_selfupdate, as it will be its own port action. You might want to
name it action_news. It will especially not be in
macports1.0/selfupdate.tcl, as this is solely a part of the port client.

News items added to web

How will the HTML pages be generated? Will it use templates? When will
the pages be updated? What tools will be required for this?

Is your plan to integrate it with our existing announcements or replace
them?

Here you did the exact opposite of the rest of your proposal. You
described a design, but left out the implementation.

Project Timeline

Hard to follow. For example, the first five weeks are just labeled "News
Manager". There are no milestones or details for each week.

Are the "#1,#2,#3" meant to refer to the API description given before?
This is really hard to follow. So, after four weeks you want to have
finished the init function and two one-liner functions for News Manger.
This cannot be realistic.

You need to come up with a better way to measure your progress. Set
yourself milestones which parts are supposed to work at which time. This
can be weekly or maybe monthly if you are not yet able to determine the
exact time you will need to specific tasks.

You could also give examples what you would do when you are unexpectedly
ahead of your schedule or behind. Are there things that could
additionally be implemented, but there was no time for it anymore? Are
there things that are not relevant to the core mechanisms and could be
left out due to time constraints?

You want to implement the 'port news' command very late in a single
week. How are you going to test the functionality in the weeks before
that if this command does not yet exist?

Also, writing tests at the end does not make sense to me either. You
should write tests while you are implementing the functionality, not
some time later.

The web part is missing completely from the timeline. Are you going to
implement that or not?

What I am still missing in the timeline is time for documentation.
For example, writing a new port action also means writing a new man page
for it. And it would also be helpful to users to have information on
this in the guide.

Overall

You still need to improve your proposal. Outline the goals clearly.
Review the parts you took from Gentoo again and make them fit into the
world of MacPorts. Give a proper design description before you explain
the implementation.

In general on your communication style: Please do not start new mail
threads all the time. Instead, reply to previous mails. There are also
other things being discussed at the same time over this list and your
GSoC topic across multiple threads is very hard to follow.

Oh, and by the way, I spent around two hours with reading, thinking and
writing this email. Please be more patient when you expect answers. We
are not at our computers all the time and even if we are, we cannot not
always reply immediately.

I hope these comments help you to improve your proposal. Let me know if
you need clarification on specific points.

Rainer