Hi Qianqian, thanks for reaching out and explaining the background of the assignement and also thanks for introducing your students to Open Source!
When mailing the students in the RFS bugs I've got one response from a student, as I've promissed in https://lists.debian.org/msgid-search/20241119083936.horde.eqg6bqqpu0mrcu7mfgxf...@sviech.de I'm trying to make some suggestions how this assignment could become more suitable for Debian. On Tue, Nov 19, 2024 at 06:43:28PM -0500, Qianqian Fang wrote: > hi everyone, > > I apologize for the trouble caused by this influx of review requests - I am > a professor at Northeastern University (Boston, MA US) and am teaching a > coding class for my Department, named "Essential computing skills for > bioengineers". This is the first time I offer this class, and I have about > 18 students this semester (mixture of undegrad, MS and PhD students). The > course covers software licenses, Linux, command line, regular expressions, > MATLAB/Python among other topics. I am not a DD, but packaged some of the > tools developed by my lab in the past. > > As a midterm project, I asked every student to identify an open-source > software (1. DFSG compatible license, 2. being actively maintained, 3. show > reasonable user adoption) that has not been carried by Debian and create an > initial package for Debian. I was hoping, at least with my initial intent, > that some of my students would like to continue polishing the package > after taking the class, although I share the same concern that many of them > will lose the drive after the assignment is over. > > I also have to admit that most students in my class - similarly in many > other universities, have extremely limited/low experience working with > Linux prior to taking my class - sadly, but this is the reality. This is > also a key reason I wanted to include lectures such as open-source licenses > and Linux in my class because I think there is an urgent need in higher > education to expose students to these topics. However, I did not have the > intent to add any unwanted burdens to the mentors if the submissions are of > low quality - I haven't started evaluating these submissions as the due > date was only two days ago. Thanks for understand this. It does not help Debian if there is a package introduced into the archive and the maintainer vanishes after that. Said that, I fear your assignement is additionally a very tough one, (IMHO too tough [1]) especially for students not having some previous experience how unix / distributions works. Creating a good package *requires* found knowledge of Debian, this is especially true if the package is to be done from scratch. Of course I do not know how you intended to measure/grade the assignement, and how much time the students should allocate to the task. [1] it is quite easy to cobble a packgage together for local use, but it is a very tough task to make it properly and suitable for inclusion to Debian. As a side, as Debian is a volunteer project, you should be aware that deadlines on such an assignment won't work, as there is absolutley no guarantee from Debian side that some will e.g review the submission *at all*. For example, when you look at the sponsorship-requests BTS page you can see that sometimes it can take many months until something is sponsored, especially if the package in question is some nieche software (for example, there are quite a few emacs packages in the RFS queue since months, but for example /me won't sponsor them because I don't speak emacs-packaging and therefore can't sensibly review them.) > I apologize for not giving a heads-up for this training exercise. I am > happy to reach out to my students, and get a list of packages that the > submitters are committed to finishing the work and potentially maintain > those in the future. For the rest, I agree that there is no need to spend > time reviewing if it obviously needs a lot of work. Frankly, I don't think this will work to ask students for a long-term committment. (Are they free to decide? Can they freely say "no" without facing the slightest fear of consequences?) We have Debian Constitution §2.1.1, and this is a very important aspect of Debian. > In the future repetition of this class (not decided yet), I will limit > students to using local resources only, and do some screening before > allowing them to post in debian mailing lists. I would also be happy to > invite any debian developers who are willing to teach university students > on Debian culture/development/packaging/maintenance and guest lectures > (remotely) - I will reach out in the future. I think this only flies if Debian also benefits from this. For example my "Debian time" is already limited and I won't spend time educating people how to package for Debian if I know already with almost certainly that this time will be wasted time. (note that this is my opinion, not necessarily other DD's) Said that, maybe the assignment can be modified/improved? The biggest issue is that it is very unlikely that your students will stick to Debian, so the tasks needs IMHO be some tasks were one-time contribution is totally OK. I think package new software is not suitable, (except if the student has already a history of Open Source contributions or in best case is already a Debian contributor.) But there are other ways to contribute to Debian, where one-time contribution is totally ok: - https://mentors.debian.net/intro-maintainers/ has some general information about what could be in scope for Debian. - Generally, https://www.debian.org/intro/help has many points that might be more suitable than new packages and if the assignment should be packaging releated, it might make more sense to do bug squashing / triaging - your students could triage open bugs filed against packages and report their findings back to the BTS, and if the bugs are still there trying to come up with a patch (e.g backported from upstram) and they can file this patch to the bug. Upload/Sponsoring is a possibity then, especially if the patch is for (RC) release criticial (or severity important) bugs [RC]. (If the package is orphaned, any bug can be fixed, but usually requires more work as a RFS for a orphaned pacakge should try get the package into its best shape, in contrast to RC/important where only the problem should be fixed in a Non Maintainer Upload (NMU) So I guess, when reaching out in future, probably you should take input from us how the assignment should look like. Some final words: Please ask your students to clean up after themselves, so closing the ITP and RFS packages and also deleting the salsa git repositories, especially if they are not committing to the maintaince of the package in question. Thanks! [RC] https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#manage-release-critical-bugs [NMU] https://www.debian.org/doc/manuals/developers-reference/pkgs.html#non-maintainer-uploads-nmus Cheer, -- tobi > Qianqian > > > On Mon, Nov 18, 2024 at 4:24 AM Andrey Rakhmatullin <w...@wrar.name> wrote: > > > Hello. > > It looks like the phenomenon of obvious students mass-submitting open > > source changes, because they were requested to, has come to Debian in the > > form of ITP+RFS. While those changes are, in my experience, almost never > > worth the time spent reviewing, they are sometimes good. But there can be > > no good *one-time* ITP+RFS, and I don't think the assignment requires the > > students to actually maintain the packages in Debian. So I suggest people > > doing reviews to not spent extra time explaining why specifically packages > > like https://mentors.debian.net/package/broot/ or > > https://mentors.debian.net/package/stc/ are bad (but it's up to you, just > > be aware). > > Thanks. > > > > -- > > WBR, wRAR > >
signature.asc
Description: PGP signature
