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.eQG6BQqpu0mRcu7MFgxFQTV@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 <wrar@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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE/d0M/zhkJ3YwohhskWT6HRe9XTYFAmdBnysACgkQkWT6HRe9 XTYZvxAAoCSEzdLZszgGr1Uj5s3cap5amwqDpbbXeezAthkE