papercuts and google code-in

[Martin Bähr]

hi,

while using sup i am taking notes whenever i notice some small issue or an idea
for an improvement.

some of these may be real bugs, some a matter of taste, and so i didn't take
the time to write them all up as issues.

i have put the list here http://pad.hackerspace.sg/p/sup-ideas
(but that server is down now, so i put a backup here:
https://factor.cc/pad/p/sup-ideas )

now, i am a mentor for FOSSASIA at google code-in, and i put up that list as a
source of tasks for students to work on.

(a sample task is here
https://www.google-melange.com/gci/task/view/google/gci2014/6127040658931712
i have since updated the text a little bit advising students for the need for
writing tests and testing against develop and use-mail branches)

essentially that means that sup is able to participate at google code-in.

so far only one student showed interest, but if well maintained he might become
a sup contributor.

if you are interested to take advantage of this you could help in the following ways:
if you have suggestions for tasks, add them right on that etherpad page. (add
your name and a description of the task)

you could also add your name behind existing tasks if you are interested to
help students with those.

i don't think you need to sign up with google code-in to help. it is probably
enough to communicate with the students through github issues and
pull-requests. and you can help by reviewing and closing pull-requests.

if a pull-request is closed i can immediately close the students task, though i
may close their task if i am satisfied with the work, regardless of the
pull-request status. (since the tasks are my wishlist, it doesn't necessarily
follow that all my wishes should be accepted into sup)

note that google code-in is a contest, and the number of tasks the students
close carries some weight in winning a prize. this causes some students to show
impatience with getting their tasks reviewed. i do hope that this impatience
does not spill over into github discussions, but if it happens, please just
ignore it (and let me know, so i can deal with it)

greetings, martin.

--
eKita - the online platform for your entire academic life
--
chief engineer eKita.co
pike programmer pike.lysator.liu.se caudium.net societyserver.org
BLUG secretary beijinglug.org
foresight developer foresightlinux.org realss.com
unix sysadmin
Martin Bähr working in china http://societyserver.org/mbaehr/

[Gaute Hope]

Hi,

I invited you to become a contributor to the sup organization on github
(embee right?). That way you can assign yourself to these issues and
handle them on the issue-tracker.

Thanks for doing this, I hope there is time to polish things up enough
to merge them.

regards, gaute

Excerpts from Martin Bähr's message of December 27, 2014 19:05:

> --
> You received this message because you are subscribed to the Google Groups "The Sup email client" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to supmua+un...@googlegroups.com.
> To post to this group, send email to sup...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/supmua/1419701714-sup-6215%40email.archlab.tuwien.ac.at.
> For more options, visit https://groups.google.com/d/optout.
>

[Martin Bähr]

Excerpts from Gaute Hope's message of 2014-12-28 15:14:01 +0100:

> I invited you to become a contributor to the sup organization on github
> (embee right?). That way you can assign yourself to these issues and
> handle them on the issue-tracker.
>
> Thanks for doing this, I hope there is time to polish things up enough
> to merge them.

i hope so too.
though i'd appreciate a little help in reviewing pull-requests, at least in
terms of deciding whether they are good enough for merging. in particular i am
inexperienced in dealing with test-cases, and it would be nice if you could
indicate if an issue should have a test case or not. or point out what to test for.

[Gaute Hope]

Excerpts from Martin Bähr's message of December 28, 2014 17:12:

> Excerpts from Gaute Hope's message of 2014-12-28 15:14:01 +0100:
>> I invited you to become a contributor to the sup organization on github
>> (embee right?). That way you can assign yourself to these issues and
>> handle them on the issue-tracker.
>>
>> Thanks for doing this, I hope there is time to polish things up enough
>> to merge them.
>
> i hope so too.
> though i'd appreciate a little help in reviewing pull-requests, at least in
> terms of deciding whether they are good enough for merging. in particular i am
> inexperienced in dealing with test-cases, and it would be nice if you could
> indicate if an issue should have a test case or not. or point out what to test for.

Yep, I can probably help a bit out there - though my time is limited.
Make sure that the code is tested by both the author and at least one
other (you?). E.g. #358 is difficult to write a test case for, but you
need to test how it works with:

- no .sup dir
- a previous config.yml but no sources.yml
- both existing, but perhaps sources empty.

indicate in the PR if you have tested it and what your recommendation is.

#357 does not need a test case, but I am not sure it is more accurate
now than before - please see my comment there.

cheers, gaute

[Martin Bähr]

Excerpts from Gaute Hope's message of 2014-12-28 18:06:10 +0100:

> > though i'd appreciate a little help in reviewing pull-requests, at least in
> > terms of deciding whether they are good enough for merging. in particular i am
> > inexperienced in dealing with test-cases, and it would be nice if you could
> > indicate if an issue should have a test case or not. or point out what to test for.
> Yep, I can probably help a bit out there - though my time is limited.
> Make sure that the code is tested by both the author and at least one
> other (you?).

yes, that's sensible.

> E.g. #358 is difficult to write a test case for, but you
> need to test how it works with:
>
> - no .sup dir
> - a previous config.yml but no sources.yml
> - both existing, but perhaps sources empty.

great, that sort of detail is very helpful. thanks!

> indicate in the PR if you have tested it and what your recommendation is.

> #357 does not need a test case, but I am not sure it is more accurate
> now than before - please see my comment there.

hehe, yeah, changing "found" to "loaded" was idea nr 44. adding a count is idea nr 45 :-)

the thing that irked me with "found" was that it suggested that there are no more threads.
"loaded" is just a statement of fact without that suggestion.

[Gaute Hope]

Excerpts from Martin Bähr's message of December 28, 2014 18:31:

> Excerpts from Gaute Hope's message of 2014-12-28 18:06:10 +0100:
>> > though i'd appreciate a little help in reviewing pull-requests, at least in
>> > terms of deciding whether they are good enough for merging. in particular i am
>> > inexperienced in dealing with test-cases, and it would be nice if you could
>> > indicate if an issue should have a test case or not. or point out what to test for.
>> Yep, I can probably help a bit out there - though my time is limited.
>> Make sure that the code is tested by both the author and at least one
>> other (you?).
>
> yes, that's sensible.
>
>> E.g. #358 is difficult to write a test case for, but you
>> need to test how it works with:
>>
>> - no .sup dir
>> - a previous config.yml but no sources.yml
>> - both existing, but perhaps sources empty.
>
> great, that sort of detail is very helpful. thanks!
>
>> indicate in the PR if you have tested it and what your recommendation is.
>
>> #357 does not need a test case, but I am not sure it is more accurate
>> now than before - please see my comment there.
>
> hehe, yeah, changing "found" to "loaded" was idea nr 44. adding a count is idea nr 45 :-)
>
> the thing that irked me with "found" was that it suggested that there are no more threads.
> "loaded" is just a statement of fact without that suggestion.

Ok, sounds good - I think with both 44 and 45 merged together it would
be good :)

- gaute