[GSoC Application Review] Application Review for Wayland Project

[Pekka Paalanen]

On Thu, 17 Mar 2016 16:37:25 +0100
Armin Krezović <armin.krezovic at fet.ba> wrote:

> On 17.03.2016 14:29, Pekka Paalanen wrote:
> > On Sun, 13 Mar 2016 18:22:18 +0100
> > Armin Krezović <armin.krezovic at fet.ba> wrote:
> >   
> >> Hello Pekka, Quentin and Kat (sorry, don't know the real name yet).
> >>
> >> Pekka and Quentin have volounteered to review my GSoC application
> >> draft for the Wayland project. Pekka also suggested to add Kat to
> >> the list of reviewers.
> >>
> >> As suggested, I've used Google Docs to create a document. You can
> >> access it at:
> >>
> >> https://docs.google.com/document/d/1bBgH8h9UiAPkipGjxHePnmcVU73Tef033-xojVWIhCU/
> >>
> >> Embedded below is the text from document, so you can comment on
> >> individual sentences/paragraphs/etc if needed.
> >>
> >> Thank you in advance and looking forward to your reply.  
> > 
> > Hi Armin,
> > 
> > nice to hear from you. Since we last talked, I have learned that it is
> > actually encouraged for students to make their proposal drafts
> > completely public. You said public commenting is fine, so here it is.
> >   
> >> --- BEGIN HERE ---
> >>
> >> Project Proposal: Weston output management enhancements
> >>
> >> Armin Krezović
> >>
> >> Introduction
> >>
> >> My name is Armin Krezović, an engineering student studying at
> >> Faculty of Electrical Engineering, University of Tuzla, Bosnia
> >> and Herzegovina.
> >>
> >> Project Scope
> >>
> >> I am interested in implementing output hotplug in Weston. That
> >> includes making Weston able to start without any outputs present
> >> and implementing logic that handles output plugging/unplugging
> >> at runtime. When that's done, Weston will be able to properly
> >> configure newly plugged outputs, deconfigure unplugged ones and
> >> handle a situation when all outputs have been disconnected.
> >> This also includes applying different options for hotplugged
> >> outputs when their configuration is specified in the
> >> configuration file. And finally, depending on how long it will
> >> take to implement all the tasks listed above, I will try to
> >> implement output layout configuration through the Weston
> >> configuration file.  
> > 
> > You might also want to consider if rewriting the output configuration
> > to match better the libweston architecture is in or out of scope for
> > your project. For reference, here are my thoughts on that:
> > https://lists.freedesktop.org/archives/wayland-devel/2016-February/027250.html
> > 
> > If anyone tackles that, you may need to interact with those changes.
> >   
> 
> OK. Thanks for the heads up.
> 
> > I think you could be more clear and concrete on what the minimal project
> > goals are. For example, specifying some use cases and how Weston should
> > work there, a bit like the project idea in the wiki is written.
> > Something that we can easily test (manually) and see if it is done or
> > not.
> > 
> > Minimal project goals are what make or break your project as a whole
> > when the GSoC is over, so you should be confident you can achieve them
> > in the available time.
> > 
> > Weston already handles, more or less, output hotplugging and
> > unplugging, and configuring from weston.ini. You just cannot unplug the
> > last output AFAIK, and there is no way to affect the layout yet.
> >   
> 
> I think I already mentioned that. My primary goal so to make weston able to
> start without any outputs connected and survive when all outputs are gone. But
> since you said that weston handles hotplugging more or less, I'll extend my
> minimal goal to handling zero outputs and simple layout setting (right of, left of
> etc). I can't promise any complex layouts handling, but I'll sure try to make
> that happen as well.
> 
> Does this sound better?

Hi Armin,

sure.

I suppose what I was looking for is a bulleted list of requirements or
goals, to make them stand out in the doc. Something you could almost
have a check box to tick on the side, since on this topic we can
actually have concrete goals. :-)

> >> Why am I the right person for this task?
> >>
> >> The main reason I want to work on this is to help the project
> >> grow, but also to learn new skills, both in programming and
> >> communication/collaboration/team work. I also want to learn
> >> and understand how display output work in Linux. I have
> >> contributed to Weston before. I wrote a couple of patches for
> >> the build system and have implemented configuration options
> >> for touchpad acceleration. All of those patches have landed
> >> in Weston. I have also implemented a feature suggested as a
> >> "small contribution" before applying for GSoC (Panel clock
> >> configuration), which has been reviewed and submitted to the
> >> Weston git repository.  
> > 
> > Do you have experience in other FOSS projects?
> > Hobby projects?
> >   
> 
> I used to work on Linux From Scratch for couple of year as
> main editor. While doing that, I learned a lot on how Linux
> system works, using VCS, building software, etc. Currently,
> I do not work on any project.
> 
> >> Dedication
> >>
> >> Since I'm still attending classes and need to study to pass them,
> >> I won't be able to dedicate a lot of time to the project during
> >> semester (which ends mid June). I expect to be able to dedicate
> >> at least 25 hours a week in that period, where most of that time
> >> will be on weekends. I'll still be available on work days to
> >> send patches, respond to feedback, communicate with people who
> >> are only available during their work hours, etc. After the
> >> classes and terms are done, I should be able to dedicate more
> >> time (up to 40 hours a week, more if needed), which should be
> >> enough to compensate for all the time I may lose during the
> >>  +semester and accomplish all the tasks listed above.  
> > 
> > This is important to reflect in your tentative work schedule/plan.
> > 
> > The mid-term evaluations will come in mid-June. You should have
> > verifiable goals for the mid-term, I think.
> >   
> 
> My goal is to figure out what would be the best way to make
> weston survive zero outputs and implement it before the midterms
> (doesn't have to land in that time).
> 
> The rest will come after midterms.
> 
> Does this sound okay?

Probably. There are interesting questions like should we report a fake
output to clients while there are no outputs, or should also the final
wl_output get removed. If it gets removed, how will the shell handle
maximized/fullscreened apps etc. You can propose a policy on what the
shell in Weston should do (if/when you do the work, not in the
proposal).

I'd expect fixing Weston core to be relative straightforward, but
making the shell(s) manage it requires inventing policies on what
should happen and how it will show towards the clients through e.g.
xdg-shell.

And don't forget that having automated tests would be extremely good to
have. I suspect this is a feature that will very easily break and go
unnoticed without tests. You might have e.g. the headless backend
simulate output hotplug.

Of course, drawing the line between in-scope and out-of-scope features
is up to you to propose. You probably don't have time to do everything.

> >> Communication
> >>
> >> I have worked on a project where developers were from different
> >> time zones and countries and had no difficulties with that.
> >> Although I speak Bosnian language, I am confident that my
> >> English is good enough that I can use it to communicate with
> >> people related to the project. I also have no problem in
> >> communicating via e-mail, IRC or any kind of reviewboard. I'm
> >> familiar enough with git, so I can easily set up a fork for the
> >> project where the progress can be tracked by mentor and other
> >> interested parties.
> >>
> >> --- END HERE ---
> >>  
> > 
> > I think it would be good to also draft a timeline. When you start, how
> > much time you have available weekly, and when will you do and how long
> > it might take to:
> > - do the mandatory reporting GSoC requires  
> 
> I usually reply to all the things related to me in less than a day. I can
> spare 1-2 hours on any day.
> 
> > - weekly public reports on your progress (blog?)  
> 
> I don't have any blog (I don't like any kind of social media either),
> but I can keep track somewhere if needed. Since it's weekly and I'll
> always have time on weekends, it can be handled.
> 
> > - getting to know the code base before you can make a dent  
> 
> I am already familiar with parts of the code base. I expect to be able to
> fully understand the part I'm going to work on in the time community
> bonding period is over. I intend to use that period to get to know
> how output related stuff works and draw some initial ideas.
> 
> > - each of the tasks you can came up with that will lead to your goals
> >   
> 
> This is hard to know right now, so I'll rather leave this one out. After
> all, I need to learn and analyze current code base and only then draw
> what needs to be done (and how).

Right, this is hard even for me, as I am dropping "oh btw this thing
here" in every message. But still, even on a coarse scale would be
better than nothing.

And this I think is where the community should help, but I understand
the proposal deadline is coming fast.

> > The schedule/plan will undoubtedly change during the project if you get
> > selected, but some sort of guess to begin with would be very good. You
> > need to know where you start and what you tackle next.
> > 
> >  
> 
> I'll include all of the mentioned things in the next draft (and some that
> sardemff77 suggested to). I just mailed them to make sure they'll be enough.
> 
> Please let me know if any additional clarification to the answers above is
> needed.
> 
> Thank you for taking your time to review this.

Cool. :-)


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160318/17943d9c/attachment-0001.sig>