[sup] 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

Post by 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
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 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/
--
You received this message because you are subscribed to the Google Groups "The Sup email client" group.
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]

Post by Gaute Hope
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.

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]

Post by Martin Bähr

Post by Gaute Hope
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]

Post by Gaute Hope

Post by Martin Bähr
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.

Post by Gaute Hope
E.g. #358 is difficult to write a test case for, but you
- 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!

Post by Gaute Hope
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.

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]

Post by Martin Bähr

Post by Gaute Hope

Post by Martin Bähr
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.

Post by Gaute Hope
E.g. #358 is difficult to write a test case for, but you
- 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!

Post by Gaute Hope
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