GSOC

[Abhishek Kashyap]

I have improved my proposals as suggested by you except timeline.Now you
can see is this is perfect.
Few hours are left so please reply soon as possible.Now i'm improving
project timeline.
Thank You

On 26 March 2018 at 12:53, Mojca Miklavec <mojca.miklavec.lists at gmail.com>
wrote:

> Dear Abhishek,
>
> On 26 March 2018 at 08:00, Abhishek Kashyap wrote:
> > Yes,I can totally ageee with you.But i focus more attention towards the
> goal
> > of the project almost from GSOC period.I am not doing for money instead i
> > want to be part of open source. This will be my achivements.So please
> view
> > my proposals and suggest changes.Even i not able to contact my mentor.So
> > that i can maximise the chance of accepting into GSOC.
> > Thank You
>
> I did send you some feedback for which you have deliberately chosen to
> argue against instead of doing it.
>
> And you did receive a very detailed reply from precisely one of two
> people listed as a potential mentor. Do you want to say you did not
> receive it?
>
> I have nothing to add to that, except that Ignoring the advice we gave
> you in numerous email (including the plea to not send emails to
> individual people, but keep discussion on the list, ignoring feedback
> you receive etc.) will do anything but increase your chances to get
> accepted.
>
> Mojca
>
> On 25 March 2018 at 23:38, Rainer Müller wrote:
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20180327/3f8060dd/attachment-0001.html>