[GSoC] The coding begins

Tue May 24 08:40:22 UTC 2016

On Mon, 23 May 2016 16:51:03 +0200
Armin Krezović <krezovic.armin at gmail.com> wrote:

> On 23.05.2016 15:56, Pekka Paalanen wrote:
> > Hi Armin,
> >   
> 
> Hello.
> 
> > the community bonding period is over, and today is the first day of the
> > official coding period. How is it going? :-)
> >   
> 
> I was busy this past week, but now the things started to calm down.

Hi Armin,

glad to hear.

> > We had a chat in IRC a while back, and I asked for some things:
> > 
> > - a place where you will report your weekly progress (a website), which
> >   accumulates into something of a log of the whole GSoC project
> >   
> 
> Yes, we agreed on a blog-like site. I just finished setting up a personal
> blog @ blogspot where I'll report my progress (weekly), as noted in
> "The First Post".
> 
> https://armin-gsoc.blogspot.com

Nice, I'll keep an eye on that.

> > - some project plans, a hierarchical list of tasks and sub-tasks, which
> >   you would update as you find new tasks and close old ones (you can
> >   use fd.o Phabricator for this if you want!)
> > 
> > In fact, I would recommend taking a look at Phabricator and use as much
> > of it as you can. It would be possible to create a personal project for
> > you (I use that at Collabora to track all my jobs) where you can put
> > all your Tasks. We could also do patch review there later, perhaps.
> > There is also a wiki, but I believe you weren't so thrilled about that
> > idea. ;-)
> >   
> 
> I haven't used Phabricator, and I don't think I'll need to. I can keep
> track of things I have to do by myself. You can always ask for progress
> though, and I'll report on the blog.

I would really like to see a live project plan being updated somewhere.
It would be complementary to the blog.

It does not have to be Phab, Phab could be heavy for the smallest
items. Just do not dismiss Phab on the first hand, check what it has
and whether it could be useful for you. We have a long term plan to
migrate everything to Phab once it's up for it: bugs, tasks, patch
reviews, CI and testing...

There are also hierarchical TODO list trackers in the web, though I
haven't personally used any yet.

> As for the tasks, I'll once again recap on how I planned to get this done:
> 
> - Setup a testing framework, where I can emulate a no-output environment
> and hotplug automatically. The plan was to use the weston test suite. I'll
> manually test no-output at startup scenario using x11 backend's
> --output-count=0 parameter.
> 
> - Get weston to start without any outputs present (again, x11 backend and
> --output-count=0 come in handy here).
> 
> - Once that's finished, make weston (and at least apps from the weston tree)
> survive when all outputs have been removed. I will be really happy if this
> gets solved while solving the task above, but I still have to account for it
> (this is where the test suite will come in handy).

Cool, these would be the top-level tasks in your project plan. Then you
start thinking what you need to actually do to achieve each, which
should result in sub-tasks, or maybe you do the sub-tasks already while
at it, so you only need to write down what you did.

Often when working on one thing, you get an idea of what you need to do
for another thing, and I've noticed it really helps to write the ideas
down. Well, I could also be just a scatterbrain since it helps me to
focus. ;-)

Just write down everything that comes to mind, so you don't later
forget. It will then help us to discuss your tasks and keep your
project scope under control.

Don't forget the paper work that GSoC requires, those should be in your
project plan too. I've understood that there may be quite some
reporting to do.

> Once the following tasks have been finished, I'll submit a first part of
> my GSOC project for review to the wayland mailing list.

Don't wait that long. If you write patches that make sense on their
own, like clean-ups, adding comments, refactoring, fixes, etc. send
them out ASAP. Gathering a long list of commits can become a burden to
rebase, and is also less attractive for reviewers.

It is good to build up a routine of casually sending small patches
upstream. It helps to keep your backlog smaller and spreads out the
review effort over a long time.

OTOH, patches that work towards a new feature or design step by step,
which are not quite clear on "why" on their own, often require the
complete series finishing the feature before they can be meaningfully
reviewed. An example of a such big question is "is this architecture
good?".

I would recommend to err on sending too early, as it also nicely
shows your progress. You can also send "RFC" when you would like to
have some comments, but the patches are not finished.

> While going through the review process, we can start discussing ideas on
> how to implement the second part of my proposed changes - the extended
> outputs. At the moment, I'm not really familiar with the topic, but I'll
> get to it as soon as possible.
> 
> Now, while I do plan to do all of the tasks above right before midterms,
> it's possible that it may slip a bit further and take, lets say, until
> end of June. That still gives me plenty of time to work on the second
> part of my proposal.

Ok, but remember that we need some material to be able to write the
mid-term evaluations of your work. Actively sending patches whenever
you have something will help with that.

> > Could you also reiterate your schedules, how long and much studies will
> > be taking time from GSoC?
> >   
> 
> Sure.
> 
> I still have classes to attend to, but only for this and next week. After
> that, the end terms period starts, which will be happening in the same
> period the GSoC midterms are happening.
> 
> After June 22nd, all my end terms are over, and I can work full time until
> end of GSoC (unless something else comes out, in which case I'll notify
> you of the changes).
> 
> While I'm still attending classes, I won't be available at all (or will
> be, but for a really short amount of time) on Monday through Wednesday.
> 
> I'll be mostly (but still not fully available on Thursday and Friday).
> 
> And of course, I'll be always available during weekend.
> 
> When the classes end (in two weeks from today), I'll be mostly available
> on any working day and fully available during weekend.
> 
> I might not be available just the day before a really important exam,
> but I think that won't be a problem, as it will be 3 days at most in
> the 3 weeks period.

Ok, very good.

Kat reminded me, that you should be in contact with us on a daily
basis about your progress. Any sign of life would be good: a line in
irc, an email on the list, a commit in your repo, a post in your
blog... This is so that we see you haven't been hit by a truck. :-)
After all, this is supposed to be your day job for the summer.

Even just noting you didn't have time to do anything is worthwhile.
I'll try to keep in mind the Mon-Wed absence, etc.

> > There is no need to accumulate a whole summer's worth of development in
> > GitHub. I recommend sending patches towards upstream as soon as you
> > think they are applicable. Ideally everything you do lands upstream,
> > but it's not mandatory, of course. Weston is a moving goal, especially
> > libweston going on, so unmerged patches will need rebasing from time to
> > time.
> >   
> 
> I set up a weston repository at github. You can access it at:
> 
> https://github.com/krezovic/weston
> 
> I need to commit my work somewhere, as I'm often clumsy and end up
> deleting my home dir or stuff like that.

Yikes! :-D

> I'll submit patches for review often, so they don't accumulate and
> so they will be easier to review, in case one feature needs to
> depend on another.

Ah yes, 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/20160524/e7272130/attachment.sig>