Thanks, Harsh, for this extensive input. Giving lots of details helps making many points visible, so I can take the opportunity to clear up lots of misconceptions. This will be a long email. It might be useful to others who have the same misunderstandings. For everyone else reading the thread, please always keep in mind that the problem is very open on the subject of choice of technologies and specific frameworks to be used. Any mention of something specific is based on Harsh's proposal and is not an actual project requirement. If you have any question, please ask. Now, let's clear a number of things up: The project is about *packages*. Each Linux distribution has a number of them -- Debian, for example, has more than 50.000 of them. To make it even more obvious, a few data lines about packages in CSV format might be: distro,name,version ubuntu,aufs-tools,1:4.9+20170918-1ubuntu1 debian,libgomp1,6.3.0-18+deb9u1 debian,libgraphite2-dev,1.3.10-1 ubuntu,mlocate,0.26-2ubuntu3.1 debian,gettext,0.19.8.1-2+deb9u1 For each one of these packages, obviously, there will be more data, like a pointer to the corresponding sources, or info like size and license. I have already given a reply on this subject in another email. This is the only data we will be concerned about. The project is a Web-based read-only interface to this data. As such, there will be no uploading info, no "descriptions", no "where/how to download", etc. Just a simple interface to look at the table and find what you are interested in. The results might be presented in a single table, or a list, or whatever you decide and propose. You will be collecting the data from the upstream distributions: all of them have ways of querying about the packages they provide. The web interface does not need to have any interaction with this. The project includes the design of the database, although this might be as simple as a single table with few columns. It also includes the way to query the database, either from the UI or an API. If there will be an HTTP API, I'd expect it to be REST. Of course the project will have to include documentation and testing of the code. The main goal of the project is to produce software, not a service. As such, you should be more concerned about "how can this be deployed by anyone" rather than "where to set it up". It also shifts the focus away from "CI/CD and DevOps" towards plain testing. Once again, I want to stress that we are looking for a simple solution to a simple problem -- any unwarranted introduction of complexity will be a disadvantage. I hope this helps clearing up things a little, On Thu, Mar 18, 2021, at 14:21, Harsh Bardhan wrote: > Hello Sir, > > Thanks for resolving all my queries and helping me out here! I totally > understand the point of being Open-Source here and I promise that all > our conversation would be happening through this public list. > > For my background work on Strategic Analysis and Information > Architecture, I would like to share the initial wireframes that have > been developed on the previous input. Apart from the same I have also > worked on the Technical System Design, that are as available: > 1. *Frontend Library: *ReactJS with the standard Create-React-App > configuration. ReactJS is popular and widely used and supported by the > Open-Source Community. I have ample experience with the library and > would like to use it further with the Project as well. > > 2. *UI Framework: *I will be moving ahead with React Bootstrap > <https://github.com/react-bootstrap/react-bootstrap>. It is > Open-Source, highly customizable and provides the aesthetics of a > modern Web Application. I have explored the possibilities of using > Material UI but ultimately landed on my choice with React Bootstrap, > for strong reasons why I would discuss my proposal. > > 3. *Server-Side Framework: *I will be using Flask-RESTful for this. It > is easy to set up and use and with my experience in Flask, I am pretty > confident in using it as my choice for backend development. However, I > will be following some modern practices like the Factory Pattern to > make the application manageable and not cluttered. > > 4. *Database: *As per your previous response, I found that MySQL was > not the only choice, With PostgreSQL on the shelve, I decided to bank > on it. While my experience in PostgreSQL is not extensive, like > React/Flask, I am ready to learn more about it and use it for my > project. > > 5. *CI/CD and DevOps: *I will be using Docker and Github Actions for > the same. Both are easy to set up and can be interfaced with other free > services like Heroku and Netlify/Vercel, depending on the platform we > choose for deployment. > Coming to the Wireframes part, I have learnt basic wireframing within a > few days, and came up with the following designs: > * *Index Page: > <https://www.fastmail.com/mail/Inbox/goog_1230055452?u=16014082>*https://drive.google.com/file/d/1LnLuKr2DsGjqFkXYFlE-UMRkwtckcyUG/view?usp=sharing > * *Search Page: > *https://drive.google.com/file/d/1ZsuIt4bHvZ3psA0F9dfUxK82nT5yHbbE/view?usp=sharing > > Right now, I am working on two more wireframes: *Package Page *and > *What's new *page. The *Package Page *would display all the information > about the Package including the supported platform, and the ways to > download the package. The *What's new *page would display the new > packages that have been added by fetching information of the latest > packages added to the database. > > I would like to get feedback on the wireframes and any > suggestions/optimizations that can be made to make it look and perform > better. Since we are in an ideation stage now, it would be great if we > can communicate more on the design aspects so that we have a clear idea > of things to do before the coding period. > > Apart from that, I have a few more questions which I hope the mentors > can oblige me with: > 1. How are we planning to input all the packages data? I understand > that we will have our database, but we won't be manually putting in all > the details there. Since scrapping isn't an option, what else shall we > explore to automate this process. An admin panel would have made it > easier for a team managing the app, to input the data, but I would > rather keep it for a stretch goal. > > 2. Apart from Wireframes and technology designs, do we need to plan > out the Database Schema and API endpoints as well? I understand that > this can be the goal in the second week of the coding period, but I > would just like to make sure that we are not missing out on any > details. > > 3. Lastly, do we have any scope of documentation and testing in this > project? Documentation is perhaps the utmost need for any modern > software development project and it is something I would like to follow > from the start along with unit and end-to-end testing. > I would love to gain a perspective and feedback on my understanding and > work respectively, so far and would like to know more about my > questions. I would be looking forward to a positive response from the > Mentors. > > *Yours Sincerely,* > Harsh > > On Sun, Mar 14, 2021 at 4:50 PM Alexios Zavras <zvr+eellak [ at ] zvr [ dot ] gr > <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr>> wrote: > > Hi Harsh, > > > > brief answers: > > > > - in the interest of fairness of all applicants, we can not have "private" > > exchanges with any of them; everything will be on this mailing list > > in the open for everyone to see and learn from. This is very much > > the spirit of Open Source. > > Feel free to share whatever designs and proposals you come up with > > and we can all comment on them and discuss them. > > > > 1. on the UI framework: as we have discussed, nothing has been decided > > and we will carefully review any proposal -- as long as it uses > > only Open Source components, obviously. Therefore, > > NextJS (or ReactJS) would definitely be a valid alternative. > > > > 2. CSS frameworks: once again, no strong preferences for anything. > > > > 3. users of the app will be... people who would like to get information > > on different packages. They will be, for the majority of cases, users > > of the specific Linux distributions who would like to gain some insight > > in the components. I have sent a previous reply to this list > > describing some of the information that might be presented. > > > > 4. an "admin panel" falls in the "nice-to-have, very low priority" category > > for this project. I cannot easily think of any functionality it will provide. > > > > 5. no, there will be no information scrapping from random repositories. > > This is about information on packages available in Linux distributions, > > so I expect the information will be coming from the distributions themselves. > > An extension would be to handle more package locations, > > but it is definitely low priority -- and I think it will be handled almost > > automatically, since all the package locations are structured the same. > > > > 6. this is a textbook example of well-structured information, > > readily convertible to relational tables. As such, SQL is the way to go > > and any other approach would be inferior. Please note that, once again, > > no specific database software has been prescribed and any SQL > > solution can be proposed and will be considered (e.g. SQLite, > > PostgreSQL, MariaDB, etc.). > > > > In general, always keep in mind that we are looking for a simple solution > > to a (well-defined) rather simple problem -- any unwarranted introduction > > of complexity is a disadvantage in a proposal. > > > > Thanks for your questions, > > > > On Sat, Mar 13, 2021, at 18:23, Harsh Bardhan wrote: > > > Hello Sir, > > > > > > Thanks for having me here! > > > > > > I am really obliged to have your reply and support from your side and I > > > hope to capitalize on this opportunity. I completely agree with your > > > point on being fair with all the participants, so I would be using this > > > thread for all communication and discussions. > > > > > > However, I would like to know if I can share *proprietary* and > > > *intellectual information *like *Rough Proposals, UI/UX Wireframes *and > > > *Architectural Diagrams *through Google Drive, with the access shared > > > only to you. The primary reason why I am requesting this, is because > > > some of these would form part of my *Strategic Analysis *and > > > *Information Architecture*, which should be as unique as possible. > > > Please let me know if this can be worked out this way, provided all our > > > discussions and brainstorming would be available in public. I would be > > > highly obliged if you can grant me this request. > > > > > > Coming to the proposal part, I have started working on the *Index Page > > > UI/UX Design *and the *Server-Side Architecture flow. *It is my first > > > time doing both, on a professional scale so I would appreciate any > > > feedback on both of them, once they are ready to share. Some of the > > > important inspirations were taken from popular package managers like > > > *PyPi, NPM *and *Crate.io*, and I am combining their design > > > philosophies to come up to a basic workflow. > > > > > > By the next week, I would be able to present you the *User Stories, > > > UI/UX Wireframes *and *Server Architecture *on my own bidding. All of > > > these would form a part of my Strategic Analysis and Information > > > Architecture work prior to my proposal. For this point, I have a few > > > questions, which I hope you can address that would make things easier > > > for me to understand: > > > > > > 1. Since we have decided to use ReactJS, will we be using the standard > > > *create-react-app *or using a proprietary React-based framework like > > > NextJS ? > > > > > > 2. Shall I study about the various CSS Frameworks that we can use with > > > the same? I have particular hands-on experience with Material UI and > > > React Bootstrap but would like to know if we have a strong preference > > > for something else. > > > > > > 3. Who are the users for this project? This question is the most > > > essential for my understanding because we cannot jump into the UI > > > without understanding what the users/clients need. I would be obliged > > > if we can define the user base of this project and how exactly would > > > someone be using it. > > > > > > 4. Do we need an Admin Panel for this Web Application? An Admin Panel > > > would be something that would allow us to manage our database > > > altogether and present the necessary information to the user. My > > > understanding requires that we need an admin panel to overall regulate > > > the platform, where everything on the user side is read-only. > > > > > > 5. Would we be scrapping packages from Github, Gitlab or similar Git > > > providers? I overall want to understand how we will collect the data > > > for all of these packages. It can be either done manually through the > > > admin panel or we can build an automation workflow that would update > > > the database as new packages are discovered. I would like to have more > > > clarity on this. > > > > > > 6. My last question: Are we flexible with our Database? I have a > > > personal preference for NoSQL Databases for our scalability needs so > > > can we use a NoSQL Database like MongoDB for our case. Or otherwise if > > > we are sticking to MySQL, can we use Amazon RDS for our deployment > > > needs. > > > > > > I would love to gain a perspective on my understanding so far and would > > > like to know more about my questions. I would be looking forward > > > towards a positive response from the Mentors. > > > > > > Yours Sincerely, > > > Harsh Bardhan Mishra > > > > > > On Fri, Mar 12, 2021 at 4:42 PM Alexios Zavras <zvr+eellak [ at ] zvr [ dot ] gr <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr> > > > <mailto:zvr%2Beellak [ at ] zvr [ dot ] gr <mailto:zvr%252Beellak [ at ] zvr [ dot ] gr>>> wrote: > > > > Hi Harsh -- thanks for your interest in the project. > > > > > > > > You've found the right place for reaching out and discussing; > > > > it is this list. Once we move to further steps of the GSoC program > > > > and concrete work is under way, there will be more focused > > > > ways of communicating for a single project. > > > > > > > > As the project description says, this is a new project > > > > so we are completely open to any framework for the front end, > > > > for example -- and your proposal of ReactJS is totally fine. > > > > > > > > You are correct that some of the work -- at least the thinking and designing part -- > > > > should be done before the start of the official coding period. > > > > It will also help you formulate a better proposal. > > > > > > > > I m here and I can try to answer any specific questions. > > > > In order to be fair to all applicants, any communication before the selection > > > > will be done in the open, on this list. > > > > > > > > Greta to have you on board! > > > > > > > > On Wed, Mar 10, 2021, at 10:00, Harsh Bardhan wrote: > > > > > Respected Mentors and Maintainers, > > > > > > > > > > With due respect, I'm Harsh Bardhan Mishra, a Junior Year Student at > > > > > Sathyabama Institute of Science and Technology, Chennai, India. I am > > > > > currently majoring in Computer Science and Engineering, and I would > > > > > like to reach out to you on the prospects of working on the > > > > > *PackageInfo WebApp* through the Google Summer of Code 2021. > > > > > > > > > > I came across the project through the Google Summer of Code '2021 Ideas > > > > > Page listed here > > > > > <https://ellak.gr/wiki/index.php?title=Google_Summer_of_Code_2021_proposed_ideas#Brief_Explanation>. I was surprised at the ingenuity of projects, which I can work on during my Summer and even beyond. With an avid interest in Full Stack Web Development and DevOps, I would like to work on PackageInfo Web App under the guidance of *Alexios Zavras. * > > > > > > > > > > Previously I have worked as a Software Engineer Intern at Qxf2 and an > > > > > Explorer Fellow at Major League Hacking. Given the Project Idea, I > > > > > would like to work on this Project and I have explored some of the > > > > > technology stacks that can be used for the same: > > > > > > > > > > * *Frontend Framework/Library: *ReactJS (Professional-Level > > > > > Experience) > > > > > * *Server-Side Framework: *Flask/FastAPI (Professional-Level > > > > > Experience) > > > > > * *Database: *MySQL (Intermediate-Level Experience) > > > > > * *DevOps: *Docker, Github Actions > > > > > As of now, I would like to break the whole ideation process into these > > > > > parts: > > > > > * *Strategic Analysis: *To brainstorm on the specifics that we are > > > > > looking for in the Web Components. > > > > > * *Information Architecture:* Planning on how accessible the > > > > > information should be to the Users > > > > > * *Wireframing:* Using a prototyping tool (Adobe XD/Figma) to come up > > > > > with simple wireframes and communicate the overall idea and aesthetics > > > > > of the UI > > > > > * *Technical System Design: *Decide the Tech Stack, workflow and > > > > > integration > > > > > While this ideation process can be done when the Coding Period would > > > > > officially start, I would like to complete as much as possible during > > > > > the proposal process, so that I can get cracking on the project really > > > > > fast. > > > > > > > > > > I would love to gain a perspective on my understanding so far and would > > > > > like to know what we can go ahead with next. I would be looking forward > > > > > towards a positive response from the Mentors. > > > > > > > > > > Yours Sincerely, > > > > > Harsh Bardhan Mishra > > > > > > > > > > ---- > > > > > Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και > > > > > συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του > > > > > Google Summer of Code - A discussion list for student developers and > > > > > mentors of Google Summer of Code projects., > > > > > https://lists.ellak.gr/gsoc-developers/listinfo.html > > > > > Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. > > > > > ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr> <mailto:gsoc-developers%2Bunsubscribe [ at ] ellak [ dot ] gr <mailto:gsoc-developers%252Bunsubscribe [ at ] ellak [ dot ] gr>>>. > > > > > > > > > > > > > -- > > > > -- zvr - > > > > -- > > -- zvr - -- -- zvr -
---- Λαμβάνετε αυτό το μήνυμα απο την λίστα: Λίστα αλληλογραφίας και συζητήσεων που απευθύνεται σε φοιτητές developers \& mentors έργων του Google Summer of Code - A discussion list for student developers and mentors of Google Summer of Code projects., https://lists.ellak.gr/gsoc-developers/listinfo.html Μπορείτε να απεγγραφείτε από τη λίστα στέλνοντας κενό μήνυμα ηλ. ταχυδρομείου στη διεύθυνση <gsoc-developers+unsubscribe [ at ] ellak [ dot ] gr>.