[GSoC Application Review] Application Review for Wayland Project

[Armin Krezović]

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?

>> 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?

>> 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).

> 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.
 
> Thanks,
> pq
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160317/8383ff26/attachment.sig>