[yast-devel] Fwd: openSUSE - Google Summer of Code 2020
openSUSE is considering to apply for Google Summer of Code this year. We offered some projects in the past, some of them were indeed executed([1],[2]). [1] Alternatives YaST Module https://github.com/openSUSE/mentoring/issues/13 [2] Rewrite Keyboard Management - Done out of GSoC https://github.com/openSUSE/mentoring/issues/79 Others never made it to GSoC for several reasons, although some of them were finally implemented by the YaST Team itself ([3],[4],[5]) [3] REST API for testing based on libYUI https://github.com/openSUSE/mentoring/issues/87 [4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12 [5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11 Time to resurrect any of those projects or come with a new one? Anyone willing to mentor? I am, although I have not decided the project yet. Cheers. PS.- It doesn't have to be exactly about YaST, we have had projects in the past about Jangouts, One-click installer, the Travel Support Program application.... https://github.com/openSUSE/mentoring/issues/63 https://github.com/openSUSE/mentoring/issues/78 https://github.com/openSUSE/mentoring/issues/80 https://github.com/openSUSE/mentoring/issues/82 https://github.com/openSUSE/mentoring/issues/16 https://github.com/openSUSE/mentoring/issues/77 https://github.com/openSUSE/mentoring/issues/15 -------- Forwarded Message -------- Subject: [Research] openSUSE - Google Summer of Code 2020 Date: Mon, 27 Jan 2020 10:00:18 +0100 From: ddemaio To: ----- Hi All, Applications for the Google Summer of Code are open and openSUSE members are considering applying for this year's GSoC to be a mentor organization. You would need to be committed to providing a mentor and the mentors would need to write progress reports; I believe there are 2 reports the mentors must write (mid-term review and final review) in addition to the mentoring of the student. The application deadline is Feb. 5, so if you want to do this, please update the git repository (https://github.com/openSUSE/mentoring) for https://101.opensuse.org and I can submit the application. If you have a project that you would like to consider as a GSoC project, please let me know. v/r Doug -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 27.01.20 10:28, Ancor Gonzalez Sosa wrote:
[4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12
Heaven forbid, please no more YaST modules written by a newbie who will be gone after the initial version with nobody left to maintain it. I thought we had agreed that we have too many of those already.
[5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11
I am all for doing that, but it's a vital piece of infrastructure, so we (!) need to do this right. Outsourcing this to a GSoC student would be most counterproductive IMHO. Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH Geschäftsführer: Felix Imendörffer HRB 36809 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 27 Jan 2020 11:21:55 +0100 Stefan Hundhammer <shundhammer@suse.de> wrote:
On 27.01.20 10:28, Ancor Gonzalez Sosa wrote:
[4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12
Heaven forbid, please no more YaST modules written by a newbie who will be gone after the initial version with nobody left to maintain it. I thought we had agreed that we have too many of those already.
Well, idea was to replace useless and horrible yast-http-server with something that is wizard like. I also think that now with summer of code and more strict mentoring from us the latest modules was not bad ( e.g. yast2-journal or yast2-alternatives was not bad modules, especially compare to some of our own old modules we do not touch much ). So in short it was planned as replacement of old and bad our module with something new with different approach. So 1 by 1 replacement.
[5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11
I am all for doing that, but it's a vital piece of infrastructure, so we (!) need to do this right. Outsourcing this to a GSoC student would be most counterproductive IMHO.
Sadly, even if it is vital, we do not assign any resources to libyui in past. Now situation is better, still I am not sure if we can finish it in reasonable future. But I agree that this is a bit too much for GSoC and probably result will be only some prototype how it can work, which can be start of discussion and maybe even not used in final connection.
Kind regards
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 27.01.20 13:42, Josef Reidinger wrote:
[5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11 I am all for doing that, but it's a vital piece of infrastructure, so we (!) need to do this right. Outsourcing this to a GSoC student would be most counterproductive IMHO.
Sadly, even if it is vital, we do not assign any resources to libyui in past. Now situation is better, still I am not sure if we can finish it in reasonable future. But I agree that this is a bit too much for GSoC and probably result will be only some prototype how it can work, which can be start of discussion and maybe even not used in final connection.
When we do something that is really important for us, we should get into the habit of doing it the proper way, not doing something half-baked or, worse, letting some outsider do something half-baked. We need to make use of our expert knowledge in the area; otherwise somebody from the outside will repeat mistakes that we already made in the past. If we do it, we have better chances of keeping those past mistakes in the back of our head and avoiding them in a new implementation. This process starts with collecting requirements, thinking hard (which requires a free head, i.e. not being interrupted by countless meetings and unrelated things), coming up with a solid concept, maybe doing a feasibility prototype, evaluating it, starting a skeleton, fleshing it out. Yes, this can be done in an agile way (if that is what we want). Agile does not have to mean doing minimalistic stuff that falls apart when the first unexpected thing happens. ;-) Kind regards -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Software Solutions Germany GmbH Geschäftsführer: Felix Imendörffer HRB 36809 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 27 Jan 2020 15:26:23 +0100 Stefan Hundhammer <shundhammer@suse.de> wrote:
On 27.01.20 13:42, Josef Reidinger wrote:
[5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11 I am all for doing that, but it's a vital piece of infrastructure, so we (!) need to do this right. Outsourcing this to a GSoC student would be most counterproductive IMHO.
Sadly, even if it is vital, we do not assign any resources to libyui in past. Now situation is better, still I am not sure if we can finish it in reasonable future. But I agree that this is a bit too much for GSoC and probably result will be only some prototype how it can work, which can be start of discussion and maybe even not used in final connection.
When we do something that is really important for us, we should get into the habit of doing it the proper way, not doing something half-baked or, worse, letting some outsider do something half-baked. We need to make use of our expert knowledge in the area; otherwise somebody from the outside will repeat mistakes that we already made in the past. If we do it, we have better chances of keeping those past mistakes in the back of our head and avoiding them in a new implementation.
Well, goal of GSOC is to learn that things to our student. So ideally we should catch early enough that student doing something wrong what does not work in past and explain it to them. I think we do not necessary do coding, we just need to be sure that it does not repeat mistakes we do in past and drive that development.
This process starts with collecting requirements, thinking hard (which requires a free head, i.e. not being interrupted by countless meetings and unrelated things), coming up with a solid concept, maybe doing a feasibility prototype, evaluating it, starting a skeleton, fleshing it out.
I am not seeing anything that cannot be done together with student. Last time we have daily meeting where we discuss stuff with students, we write ideas down ( which we often do not do ourself ), it is not one man show. So ideally in GSOC we should just do first part ( requirements needs to be known in advance, so it can be evaluated ) and probably we wont reach much more then that skeleton depending on available time and student.
Yes, this can be done in an agile way (if that is what we want).
Agile is useful with student as it is regularly evaluated if it goes properly and in right direction. So student do not waste month on something that won't work. BTW I think we do agile ourself for same reason, as often right way is not clear.
Agile does not have to mean doing minimalistic stuff that falls apart when the first unexpected thing happens. ;-)
It is goal of mentor to ensure that this stuff should not happen. In general GSOC should be both side win situation. Student learn something new from us, get paid and learn how open source works ( last few years google promote also social part of contributing ). We on other hand see newcomers issues, discuss yast with someone with fresh mind, having new contribution and potentially also new contributor.
Kind regards
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Hi, Dne 27. 01. 20 v 15:26 Stefan Hundhammer napsal(a):
When we do something that is really important for us, we should get into the habit of doing it the proper way, not doing something half-baked or, worse, letting some outsider do something half-baked. We need to make use of our expert knowledge in the area; otherwise somebody from the outside will repeat mistakes that we already made in the past. If we do it, we have better chances of keeping those past mistakes in the back of our head and avoiding them in a new implementation.
I agree with that, mentoring this project will be really challenging as you need to carefully watch the progress and communicate a lot with the student to avoid driving into a wrong direction. And the more eyes the better, this should be ideally mentored by more people so we collect more different ideas and remember all that issues from the past... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, 27 Jan 2020 10:28:48 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
openSUSE is considering to apply for Google Summer of Code this year.
We offered some projects in the past, some of them were indeed executed([1],[2]).
[1] Alternatives YaST Module https://github.com/openSUSE/mentoring/issues/13 [2] Rewrite Keyboard Management - Done out of GSoC https://github.com/openSUSE/mentoring/issues/79
Others never made it to GSoC for several reasons, although some of them were finally implemented by the YaST Team itself ([3],[4],[5])
[3] REST API for testing based on libYUI https://github.com/openSUSE/mentoring/issues/87 [4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12 [5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11
Time to resurrect any of those projects or come with a new one? Anyone willing to mentor? I am, although I have not decided the project yet.
Hi, I had in past idea that we can probably improve experience for opensuse installation for impaired users. As we have in PRG QA that can do testing and helping us with topic it can be good opportunity. Sadly I do not have much time this summer due to personal stuff. But I am willing to co-mentor with someone. Josef
Cheers.
PS.- It doesn't have to be exactly about YaST, we have had projects in the past about Jangouts, One-click installer, the Travel Support Program application....
https://github.com/openSUSE/mentoring/issues/63 https://github.com/openSUSE/mentoring/issues/78 https://github.com/openSUSE/mentoring/issues/80 https://github.com/openSUSE/mentoring/issues/82 https://github.com/openSUSE/mentoring/issues/16 https://github.com/openSUSE/mentoring/issues/77 https://github.com/openSUSE/mentoring/issues/15
-------- Forwarded Message -------- Subject: [Research] openSUSE - Google Summer of Code 2020 Date: Mon, 27 Jan 2020 10:00:18 +0100 From: ddemaio To: -----
Hi All, Applications for the Google Summer of Code are open and openSUSE members are considering applying for this year's GSoC to be a mentor organization.
You would need to be committed to providing a mentor and the mentors would need to write progress reports; I believe there are 2 reports the mentors must write (mid-term review and final review) in addition to the mentoring of the student.
The application deadline is Feb. 5, so if you want to do this, please update the git repository (https://github.com/openSUSE/mentoring) for https://101.opensuse.org and I can submit the application.
If you have a project that you would like to consider as a GSoC project, please let me know. v/r Doug
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
Dne 27. 01. 20 v 10:28 Ancor Gonzalez Sosa napsal(a): [...]
Others never made it to GSoC for several reasons, although some of them were finally implemented by the YaST Team itself ([3],[4],[5])
[3] REST API for testing based on libYUI https://github.com/openSUSE/mentoring/issues/87
I'd consider that as DONE. There are still some small areas to improve (https://github.com/libyui/libyui-rest-api/#todo) but it's rather about what openQA would like to use or which widget properties are not available via the REST API. Currently it's more like "maybe we could ..." than "this is missing/does not work/makes it unusable". So unless you know someone who would be really interested in the topic I'd skip it for GSoC... -- Ladislav Slezák YaST Developer SUSE LINUX, s.r.o. Corso IIa Křižíkova 148/34 18600 Praha 8 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2020-01-27 10:28, Ancor Gonzalez Sosa wrote:
openSUSE is considering to apply for Google Summer of Code this year.
We offered some projects in the past, some of them were indeed executed([1],[2]).
[1] Alternatives YaST Module https://github.com/openSUSE/mentoring/issues/13 [2] Rewrite Keyboard Management - Done out of GSoC https://github.com/openSUSE/mentoring/issues/79
Others never made it to GSoC for several reasons, although some of them were finally implemented by the YaST Team itself ([3],[4],[5])
[3] REST API for testing based on libYUI https://github.com/openSUSE/mentoring/issues/87 [4] Apache initial setup YaST Module https://github.com/openSUSE/mentoring/issues/12 [5] Native Ruby interface for libYUI https://github.com/openSUSE/mentoring/issues/11
Time to resurrect any of those projects or come with a new one? Anyone willing to mentor? I am, although I have not decided the project yet.
Some preliminary ideas (I could elaborate any of them, if needed), if someone wants to co-mentor: - New widgets for libYUI (like proper bargraphs or native list selection) - Support in gettext and weblate for Ruby-style placeholders (maybe not big enough?) - Proper NFS client support in the Partitioner (instead of embedding yast-nfs-client... which is heavily outdated) - Better libYUI support for 4k, 8k... ∞K - A new/alternative (really simpler) YaST Users - Modernize some of those old modules we cannot drop but that are really outdated (yast-dhcp-server or yast-dns-server, for example). I would co-mentor any of those (or any other idea you can come with). Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 1/29/20 10:59 AM, Ancor Gonzalez Sosa wrote:
[...]
I would co-mentor any of those (or any other idea you can come with).
So what? Anyone wanting to co-mentor any project (from my list or any other thing)? Any reader of this list willing to participate as student? Cheers -- Ancor González Sosa YaST Team at SUSE Software Solutions -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 4 Feb 2020 16:46:33 +0100 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 1/29/20 10:59 AM, Ancor Gonzalez Sosa wrote:
[...]
I would co-mentor any of those (or any other idea you can come with).
So what? Anyone wanting to co-mentor any project (from my list or any other thing)?
Any reader of this list willing to participate as student?
Cheers
Hi, I can help with co-mentoring, but as mentioned this summer I do not have time for full time mentoring. Regarding projects: - New widgets for libYUI (like proper bargraphs or native list selection) Sounds good to me. - Support in gettext and weblate for Ruby-style placeholders (maybe not big enough?) I am not sure if we are expert enough in weblate or gettext itself. - Proper NFS client support in the Partitioner (instead of embedding yast-nfs-client... which is heavily outdated) fine for me. - Better libYUI support for 4k, 8k... ∞K sounds good to me. - A new/alternative (really simpler) YaST Users If it is just trivial passwd and group module, it is fine for me. - Modernize some of those old modules we cannot drop but that are really outdated (yast-dhcp-server or yast-dns-server, for example). fine for me. Just do not forget in any alternative that ideally we need backward compatible autoyast support. From old projects I still think that new http-server as apache wizard quick setup module makes sense. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (4)
-
Ancor Gonzalez Sosa -
Josef Reidinger -
Ladislav Slezak -
Stefan Hundhammer