Re: New contributor experience
Am 14. Juni 2025 16:18:40 MESZ schrieb Theodore Ts'o :
>
>I think the other reason why these discussions are a bit frustrating
>is that there seems to be an implicit assumptions that all
>contributions from newcomers *must* be good,
dunno.
I think the implicit assumption is that "new *contributors* are good" (which I
can relate to), not necessarily that their contributions are of outstanding
quality.
we all started out stupid and learned but doing...
> and MR's must be reviewed
>ASAP or it's an indication that the project or package is moribund.
>
>Sometimes code contributions are just bad quality. They might
>introduce bugs; or they might make the code unmaintable; or in the
>case of Debian packaging, the patch might be better sent upstream for
>evaluation.
fair enough.
however, submitting a "not acceptable" contribution need not necessarily be a
featuring experience - if we can communicate to the contributor why a
suggestion is rejected.
afaict, frustration arises if there's missing feedback where
- the contributor is lost in "how to contribute" ("what are my possibilities to
act?", aka: they don't know where to start)
- the contributor is lost after they contributed ("what are the effects of my
action?"; aka: they don't know what happened to their work)
so far the discussion was mostly about the first issue, you bring in the second
one.
in this (2nd) case I think it would be helpful for the contributor to receive a
*minimal* response telling them that their contribution was in vain die to the
complexity of the project.
in the end I'm pretty sure it is less effort to write a short (canned) response
("I'm afraid I cannot accept drive-by contributions for such a complex
project") than to be bothered with endless discussions on debian-devel :-)
mfh.her.fsr
IOhannes
RFH: manually rebuild pytorch-cuda on ppc64el and upload binaries
Hi folks, I expired my access to ppc64el since CUDA (>> 12.4) no longer supports ppc64el for the trixie+1 cycle. But the recent CUDA 12.2->12.4 transition requires me to rebuild pytorch-cuda, while I've already lost access. The help I need is pretty simple -- manuually rebuild pytorch-cuda and upload the resulting binaries. Note the building process involves two major non-free dependencies: (1) nvidia-cuda-toolkit: from non-free section (2) nvidia-cudnn: this is my installation script to download binary blobs during postinst. They are the direct reason why XS-Autobuild and porterbox do not work. Steps = 1. get the source of pytorch-cuda, make sure version is 2.6.0+dfsg-7 apt source pytorch-cuda 2. do the manual binNMU with sbuild sbuild --no-clean -c unstable-ppc64el-sbuild \ --build=ppc64el --arch=ppc64el \ --make-binNMU="Rebuild against CUDA 12.4." \ -m "your name " \ pytorch-cuda_2.6.0+dfsg-7.dsc -d sid 3. sign the built packages and upload debsign pytorch-cuda_2.6.0+dfsg-7+b1_ppc64el.changes dput ftp-master pytorch-cuda_2.6.0+dfsg-7+b1_ppc64el.changes Parallelism and RAM === On amd64/ppc64el building pytorch-cuda needs 4GB per job to avoid OOM during parallel link. On arm64 it requires 8GB per job. It is OK to allocate a large swap as it is largely used to counter the RAM spikes during parallel linker invokes. I have already done the amd64 rebuild: https://buildd.debian.org/status/package.php?p=pytorch%2dcuda My arm64 rebuild is on the way but it will take roughly one day with my raspberry pi 5. If you have a stronger arm64 device, feel free to help the rebuild and upload before I do. Note, arm64 needs roughly 8GB RAM/swap per job to avoid OOM.
Re: New contributor experience
sorry for all the typos, I'm on my mobile Am 14. Juni 2025 19:09:59 MESZ schrieb "IOhannes m zmölnig" : >Am 14. Juni 2025 16:18:40 MESZ schrieb Theodore Ts'o : >> >>I think the other reason why these discussions are a bit frustrating >>is that there seems to be an implicit assumptions that all >>contributions from newcomers *must* be good, > >dunno. >I think the implicit assumption is that "new *contributors* are good" (which I >can relate to), not necessarily that their contributions are of outstanding >quality. >we all started out stupid and learned but doing... > obviously "by doing" >however, submitting a "not acceptable" contribution need not necessarily be a >featuring rather, they need not be "a *frustrating* experience" I'm sure there are more autocorrection errors that I haven't spotted yet. mfh.her.fsr IOhannes
Bug#1107784: ITP: libreoffice-jdbc-bridge -- Make JDBC drivers available for libreoffice base
Package: wnpp Severity: wishlist Owner: Joachim Zobel X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libreoffice-jdbc-bridge Version : 1.5.0 Upstream Contact: prrv...@gmail.com * URL : https://prrvchr.github.io/jdbcDriverOOo/ * License : LGPL or MPPL, and MIT Programming Lang: Java, Python Description : Make JDBC drivers available for libreoffice base This libreoffice extension is the transcription in pure Java of the java.sql.* API to the com.sun.star.sdbc, com.sun.star.sdbcx and com.sun.star.sdb API of UNO. It allows you to use the JDBC driver of your choice directly in Base. Thanks to drivers providing an integrated database engine such as: HsqlDB, H2, SQLite, Derby or Jaybird, it is possible in Base to very easily create and manage databases, as easily as creating Writer documents. I will contact the libreoffice team to see if they consider this a team package.
Re: New contributor experience
On Wed, Jun 04, 2025 at 10:47:35AM -0700, Russ Allbery wrote: > > Sorry, yes, Debian discussions around workflow are often frustrating > because part of the discussion is usually at least a mild request > for existing maintainers to change their current workflows, and when > people feel overwhelmed, changing workflows often feels particularly > draining. Sometimes we manage to steer the discussion away from > existing maintainers changing how they currently do things towards > creating recommended best practices for *new* maintainers, and those > are often less fraught. I've been on vacation, so I only came across this thread now. I think the other reason why these discussions are a bit frustrating is that there seems to be an implicit assumptions that all contributions from newcomers *must* be good, and MR's must be reviewed ASAP or it's an indication that the project or package is moribund. Sometimes code contributions are just bad quality. They might introduce bugs; or they might make the code unmaintable; or in the case of Debian packaging, the patch might be better sent upstream for evaluation. And of course, there is always the case of the xz-utils backdoor, where the maintainer was bullied into letting a fresh-faced contributor "help", and that person ended ended up being a bad actor (perhaps from state-funded intelligence agency, such as the MSS, NSA or KGB). For critical code, if you don't have time, and the code quality is suspect, I don't think we should be shaming open source maintainers or package maintainers that they have some obligation to respond in some set time. Code quality is much more important than keeping newbies happy; at least, that's my set of priorities. - Ted
