Google Summer of Code Summary

[Pekka Paalanen]

On Sun, 21 Aug 2016 17:39:08 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:

> Hi everyone!
> 
> As you know, I worked on this project during the Google Summer of
> Code this year.
> 
> Now that GSoC is comming to an end, it's time to present what I've
> done so far.
> 
> I've written a blog post to summarize my work during this summer,
> you can find it at:
> 
> https://armin-gsoc.blogspot.com/2016/08/summary.html
> 
> Thanks to Wayland project for accepting me for GSoC!

Hi Armin,

that is an excellent write-up of your work!

Kat, Quentin, IMO this is a very satifactory explanation as the
"Work Product".


	Project comments

I agree the "let's refactor a huge bunch" came as a last minute
idea, but given the already done refactorings to let libweston
finally become a real thing, there really was no room to have more
complicated output layout algorithms inside libweston - adding it
would have just complicated the output config API of the time, just
to be ripped out eventually anyway. Therefore I preferred we
proceeded to the ripping out phase first. Someone was bound to do
that work, and I am glad I got you doing it. :-)

Adding the zero-output and output hotplug testing to the test suite
would have been a equally great task, so completing both was not
possible. I now understand, that we will probably need the headless
backend to expose Wayland test interfaces allowing direct control
of outputs (and input devices for input testing) before proper
tests for these things can be written.



	Future work

Btw. do think about the output layout API a bit before you go
rewriting the big refactoring series once again. Does offering an
output layout API cause big parts of the refactoring you already
have patches for to be rewritten, or is it just small bits of the
previous work that needs tuning? If most of the pending patch
series is still valid also after adding the output layout API, then
adding the output layout API can (and should) be done incrementally.

I have a feeling it might be better to make the output layout API
with incremental patches. The refactoring you did is about moving
the existing output configuration from libweston to the compositor.
Adding an output layout feature is a whole new feature. From
semantical point of view, they should already be separate patches
(patch series).

The only thing to be wary of is having one patch put some code in
place and then the very soon following next patch removing or
rewriting the just added code completely. Each patch should be a
step towards the foreseeable goal. Side-steps are sometimes
necessary and that's ok depending on the cost/benefit. Stepping
backward is not ok if you can predict it. But, a step forward can
be just an API, even if the implementation will need a rewrite
later. Setting up API is actually more important than the
implementation, since it sets up the agreement between the user and
the provider of the API.

Ok, that was hard to explain and it came out longer than I
intended. Just saying that needing small changes to the API you
drafted already does not necessarily mean you have to rewrite the
old patches if they haven't landed yet. If the old patches have
already taken serious review effort (and they have), it might be
better to push them through as is, and push the small changes to it
separately later.

"Perfect" is the worst enemy of "good enough", a truth that I, too,
tend to forget.


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/20160822/4defecbe/attachment-0001.sig>