Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > To be honest, in terms of volunteered reviewing work, waiting > for several months is not something new. In academia, it may > take several months to years to get a journal paper response. Sure, but (1) that situation isn't popular in academia either, (2) at least you can put your work on arXiv or similar and have it be useful to people right away, and (3) a paper that's finally accepted (usually) doesn't ever have to be updated, and doesn't risk needing to go through the process again. And new papers don't require updates to old papers, usually. An analogy following from (3): how great fun it would be if a substantial paper correction would require no review from the publishing journal, but a title change would require a completely new peer review process! (Yes, the idea of a title change is far fetched, but still.) Seems a bit arbitrary to me. > I've ever tried to think of possible ways to improve the process, but > several observations eventually changed my mind, and I'm willing > to accept the status quo. > > * there is a trade-off between rigorousness and efficiency. > Any change in the process may induce disadvantages, where > the most difficult thing is to reach an agreement. > * we will add more work for ftp team if we get them involved in the > discussion of possible (but unsure) ways to improve NEW. > > My ultimate opinion on NEW processing is neutral, and my only > hope for ftp team is to increase the pace of hiring new members. > To be concrete, it is much harder to write a concrete proposal > to debian-vote@l.d.o than discussing possibilities. > > I understand we may have the enthusiasm to sprint on something. > However, in terms of the long-term endeavor on Debian development, > the negligible popcon number won't be less disappointing than > a long-term wait to clear the NEW queue. I don't think I'm worried about people being disappointed (by say an RC bug being filed due to a copyright issue – correctness is far more important than not being disappointed). I'm worried about the extremely long time horizons putting people off from contributing in the first place, because it requires focus and planning across a time gap that is so many orders of magnitude longer than the time spent doing the actual contributing work. In some sense, contributing to Debian becomes mostly about waiting. (Sure, there is something to be said about extremely short, fragmented attention spans being unhealthy – but some contributions are naturally short and easy, and we certainly don't want to drive those away.) > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? I hope we won't try to define what "necessary" means, or have it become a criterion for inclusion :-) > Must I do this to have fun? I don't think Debian contribution has ever been a necessary condition for fun. That's an incredibly high bar. If we were only to attract people whose only idea of fun was contributing to Debian, I think we'd become a very unhealthy project (and one severely lacking in contributors). > Strong motivations such as "I use this package, seriously" are not > likely to wear out very easily through time. Packages maintained > with a strong motivation are better cared among all packages in our > archive. I humbly disagree. Even from my own point of view, I may well be very motivated to package something I use seriously all the time, seriously. But then I see its dependency chain of 10 unpackaged items, start thinking about the probability that they'll *all* clear the NEW queue, and how long that would take, and I give up. And then there's the problem of attracting smaller contributions, as mentioned above: I really believe that people get put off from putting in 30 minutes of work for a nice MR on Salsa if they can't expect their work to hit the archives for months and months (suppose for example they contributed to a package whose SONAME is being bumped). > Why not calm down, and try to do something else as interesting > as Debian development when waiting for the NEW queue? Sure. That's what I do. My list of joyful and less joyful things to fill my days with is enormous. **BUT: I worry for the project if our solution to the problem at hand is "maybe just contribute less to Debian".** Is that really what we want? Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Paul Wise writes: > There are a lot of examples of busywork in Debian, such as documenting > licenses, packaging dependencies, removing non-free files that are only > in source packages, runtime selection of correct CPU instructions, > fixing build failures, porting reverse dependencies to newer versions > of APIs etc. All of these are things that contributors complain about > and get burned out by us requiring or even suggesting. All of them > however are necessary in some way. I think the requirements around > source and building are just another example of this. Indeed. But is it necessary that this busywork be checked in the way it's currently checked, as the package passes through NEW? Why does it only have to be checked this way when a package name changes or there's a new binary being built? The rest of the time we seem fine catching all of these kinds of things through bug reports. We trust each other not to violate Policy. If we do find violations, we file serious bugs, and expect those to be acted upon. But not if there's a new package name! Oh no, then we instead insist that related work stops, and have the developer wait for months for detailed manual review by overworked reviewers. Best, Gard signature.asc Description: PGP signature
Re: Current NEW review process saps developer motivation
Gard Spreemann writes: > Oh no, then we instead insist that related work stops Sorry, this was imprecise of me. We of course don't insist that related work stops. But I really fear that that is the consequence in a great many cases. -- Gard
Re: Porter roll call for Debian Bookworm
On 2021-10-02 11:57 +0200, Graham Inggs wrote: > Hi > > We are doing a roll call for porters of all prospective release > architectures. If you are an active porter behind one of these > architectures [1] and intend to continue for the development cycle of > Debian Bookworm (est. release mid-2023), please respond with a signed > email containing the following before Saturday, January 1, 2022: Oops, too slow! > * Which architectures are you committing to be an active porter for? arm64, amrhf, armel > * Please describe recent relevant porter contributions. Manage the arm buildds at ARM. Worked on packaging AI/ML stuff Worked with rust team on unbunging Help with give-backs Look at build issues brought to the attention of the debian-arm list > * Are you running/using Debian testing or sid on said port(s)? Largely only for building. I tend to run stable on boxes doing real work but switch to testing for half a release on development machines. I've never been a 'run sid on real machines' sort of person. > * Are you testing/patching d-i for the port(s)? Yes. I have a pretty good understanding of how it works, and sometimes test/fix things on new (to me) hardware, or when people ask about specific things. > I am an active porter for the following architectures and I intend to > continue for the development cycle of Debian Bookworm > (est. release mid-2023): > > For , I - test (most|all) packages on this architecture I have an arm64 desktop running stable and arm64/armhf/armel build machines I run an armhf home server (cubietruck) and an armel (Balloon) home controller I have various test hardware boards/machines > - run a Debian testing or unstable system on port that I use regularly - fix toolchain issues - triage arch-specific bugs (recent example is spurious neon instructions in init code: 982794, 998043, - fix arch-related bugs - test d-i sometimes - fix d-i bugs/issues - maintain buildds (@ARM Cambridge site - reboots, network moves, new hard-drives + fans, justifying functionality that we need to ARM corporate security who like to turn things off, assuring them that we have already (usually) dealt with this week's security scare) I plan to do an armhf-64-bit-timet rebuild soon, to provide info on breakage and help plan that transition I will probably be retiring from paid debian work at ARM within a year or so. Which probably means handing the buildd admin off to someone as it'll make access a lot easier. That won't change my debian-arm focus much, but it will probably change it a bit (away from AI, towards core arch activities and my personal packages). I'm not sure how much of my current test hardware I'll get to keep... I am a DD (since 2000) Wookey Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: > > contributing work. In some sense, contributing to Debian becomes > mostly > about waiting. (Sure, there is something to be said about extremely > short, fragmented attention spans being unhealthy – but some > contributions are naturally short and easy, and we certainly don't > want > to drive those away.) That's why I still hope ftp team to recruit more people. This is a very direct and constructive way to speed up everything. More volunteers = higher bandwidth. Recruiting more people doesn't seem to have a serious disadvantage. In my fuzzy memory, the last discussion on NEW queue improvement involves the disadvantages by allowing SOVERSION bump to directly pass the NEW queue. I'm not going to trace back, because I know this will not be implemented unless someone proposes a GR. > > If one's enthusiasm on working on some package is eventually > > worn out after a break, then try to think of the following > > question: > > > > Is it really necessary to introduce XXX to Debian? > > I hope we won't try to define what "necessary" means, or have it > become > a criterion for inclusion :-) > > > Must I do this to have fun? > > I don't think Debian contribution has ever been a necessary condition > for fun. That's an incredibly high bar. If we were only to attract > people whose only idea of fun was contributing to Debian, I think > we'd > become a very unhealthy project (and one severely lacking in > contributors). For newcomers, a long wait wears out their interest of course. I'm not sure what would be the reason for a potential newcomer to reach us if they do not find contributing this project "fun/interesting", or "worthwhile/useful". For people who chose to stay in this community, there must be a reason behind them. Because I believe no body can contribute to a volunteer project without payment / fame / enjoyment. Without such a high bar, the member list will be much more volatile. > > Strong motivations such as "I use this package, seriously" are not > > likely to wear out very easily through time. Packages maintained > > with a strong motivation are better cared among all packages in our > > archive. > > I humbly disagree. Even from my own point of view, I may well be very > motivated to package something I use seriously all the time, > seriously. But then I see its dependency chain of 10 unpackaged > items, > start thinking about the probability that they'll *all* clear the NEW > queue, and how long that would take, and I give up. And then there's > the > problem of attracting smaller contributions, as mentioned above: I > really believe that people get put off from putting in 30 minutes of > work for a nice MR on Salsa if they can't expect their work to hit > the > archives for months and months (suppose for example they contributed > to > a package whose SONAME is being bumped). I agree with your disagreement but I keep my opinion. My track record involves maintaining loads of reverse dependency libraries. I've already gone through all kinds of pains from the NEW queue and eventually learned to take a break immediately after uploading something to new. That said, if someone presents a GR proposal I'll join. In Debian, it is not that easy to push something forward unless it hurts everyone. Our NEW queue mechanism has been there for decades, and people are already accustomed to it (including me). From multiple times of discussion in the past, I don't see the NEW queue problem hurting too many people. If nothing gets changed in the NEW queue mechanism, people may gradually get used to it, following the "do not fix it if it ain't wrong" rule. The voice will gradually vanish. This is surely unhealthy. But as an individual developer I don't find many feasible ways to push things forward unless someone figure out a reason that as many people feel hurt about it as possible. > > Why not calm down, and try to do something else as interesting > > as Debian development when waiting for the NEW queue? > > Sure. That's what I do. My list of joyful and less joyful things to > fill > my days with is enormous. **BUT: I worry for the project if our > solution > to the problem at hand is "maybe just contribute less to Debian".** > Is > that really what we want? > I forecast this thread will eventually end up with "calm down and take a break" solution again.
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
On 2022-08-27 15:53, M. Zhou wrote: That's why I still hope ftp team to recruit more people. This is a very direct and constructive way to speed up everything. More volunteers = higher bandwidth. Recruiting more people doesn't seem to have a serious disadvantage. It does not seem to work. Either people don't want to do that, either the FTP team is too picky on the candidates. I forecast this thread will eventually end up with "calm down and take a break" solution again. Yes. Unhappy people will just continue to silently wind down their involvement in Debian.
Re: Current NEW review process saps developer motivation
Hello, On Fri 26 Aug 2022 at 11:58AM +01, Simon McVittie wrote: > More generally, I don't think it's always useful to talk about "the" > source or "the" preferred form for modification, as though there is only > one. I think it would be more appropriate to consider whether the form > in which some software is provided is suitable for exercising your Free > Software rights (as described in the FSF's "four essential freedoms", > for example) within the scope of whatever package we're talking about at > the time, or whether it's unsuitable for that use. If it's suitable, then > it's source, or close enough; if it's unsuitable, then that needs fixing. > > If we insist on a particularly puritanical view of what is source and > what is the preferred form for modification, then I think there is a > significant risk of producing a distribution which is unquestionably Free > Software, but either is missing useful Free software because it would be > too hard to get that software into a form that meets our self-imposed > policies, or can only contain that software as a result of individual > developers putting a heroic amount of effort into meeting those policies - > particularly if we always go back to the "true source" and generate from > there every time (which I will note that the ftp team specifically do not > insist on unless there is a technical reason to do so, they merely require > source to be *available*). Right. I think the ftpteam members agree, and hold far from the more extreme possible views about building everything all the way through. We just want to think through each case carefully enough to be satisfied that we're not failing the project in stewardship of the DFSG. Most times I send a "Comments regarding ..." mail from NEW saying "this seems a bit strange, can you explain" the result is an ACCEPT once an explanation has been provided. In the case of the Rust package that started the recent discussion, when I looked at it in NEW, I recall that I couldn't find a single non-generated file aside from metadata. That's the opposite extreme. In the discussion that followed I tried to respond to abstract cases in ways that were helpful, but with hindsight it would probably have been better just to say, "make some judgements about what's in its preferred form for modification, explain it in d/copyright, if you're doing so in the spirit of the DFSG then the ftpteam will probably agree." It's sort of like the "no detailed design work" for the TC. -- Sean Whitton signature.asc Description: PGP signature
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Hello, On Sat 27 Aug 2022 at 04:22PM +02, Vincent Bernat wrote: > > On 2022-08-27 15:53, M. Zhou wrote: > >> That's why I still hope ftp team to recruit more people. This is >> a very direct and constructive way to speed up everything. >> More volunteers = higher bandwidth. >> Recruiting more people doesn't seem to have a serious disadvantage. > > It does not seem to work. Either people don't want to do that, either the FTP > team is too picky on the candidates. Some combination of both, but I don't think I'm suffering from bias if I say that it's at least 80% the former. Very few people who say they'd like to be trained confirm they'd still like to once they've had a look at the docs for trainees, and after that, hardly any do enough trainee reviews for the other team members to feel confident they can let them at it on their own. I am the only trainee who made it through in recent years and that's because I was highly systematic about doing lots of reviews each month. There are some technical improvements that would be possible. For example, feedback to trainees is entirely done via IRC; I would much prefer us to be doing that by e-mail. But other team members disagree with me, I think, and I do recognise I like e-mail more than most people do. There are ways the tools could be better. In general, however, existing team members, including myself, are pretty sceptical that technical improvements would be worth the time it would take to implement them effectively. dak as a whole is less well maintained than other core Debian software, but the NEW queue parts are pretty good! So, the bulk of the problem boils down to project members not being interested in doing the work. I certainly understand this. It feels just like grading student essays. Everyone finds that highly draining at first, until you develop a sort of detachment from the activity, where your mind is going through the motions of the activity sort of like how your hands can be going through the motions of something like food preparation for a familiar dish -- you have to learn that you won't make worse judgements if you become detached in this way, just like how you won't prepare a worse version of the dish if you do it in the detached way. Then I just applied what I'd learned from grading to the NEW queue, and then it's pretty fun and even relaxing when you're not in a frame of mind to do harder thinking. But like I said, most people don't want to do any of this, and of course being a trainee is *not* like that. And then recruitment is less efficient -- not enough feedback on trainee reviews -- because there aren't enough team members. The usual compounding effect. -- Sean Whitton signature.asc Description: PGP signature
Bug#969482: ITP: glab -- An open-source GitLab command line tool
Package: wnpp Followup-For: Bug #969482 Owner: Julian Dreykorn X-Debbugs-Cc: debian-devel@lists.debian.org, dreykorn.jul...@gmail.com I appologize for the duplicated lines in my previos reply. It was really not my intention, just a copy-paste-mistake that happened accidentally from Vim in the console. I'm sorry for that and hope that it didn't cause any confusions here.
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
"M. Zhou" writes: > On Sat, 2022-08-27 at 09:50 +0200, Gard Spreemann wrote: >> >> I humbly disagree. Even from my own point of view, I may well be very >> motivated to package something I use seriously all the time, >> seriously. But then I see its dependency chain of 10 unpackaged >> items, >> start thinking about the probability that they'll *all* clear the NEW >> queue, and how long that would take, and I give up. And then there's >> the >> problem of attracting smaller contributions, as mentioned above: I >> really believe that people get put off from putting in 30 minutes of >> work for a nice MR on Salsa if they can't expect their work to hit >> the >> archives for months and months (suppose for example they contributed >> to >> a package whose SONAME is being bumped). > > I agree with your disagreement but I keep my opinion. My track record > involves maintaining loads of reverse dependency libraries. I've > already gone through all kinds of pains from the NEW queue and > eventually learned to take a break immediately after uploading > something to new. > I consider you quite the hero for your massive contributions to the Debian deep learning ecosystem. But I do worry that there aren't enough Mo Zhous in the world ;-) > That said, if someone presents a GR proposal I'll join. In Debian, > it is not that easy to push something forward unless it hurts everyone. > Our NEW queue mechanism has been there for decades, and people are > already accustomed to it (including me). From multiple times of > discussion in the past, I don't see the NEW queue problem hurting > too many people. If nothing gets changed in the NEW queue mechanism, > people may gradually get used to it, following the "do not fix it > if it ain't wrong" rule. The voice will gradually vanish. … or people quietly vanish from contributing. Best, Gard signature.asc Description: PGP signature
Re: General resolution: non-free firmware
Debian Project Secretary - Kurt Roeckx dixit: >it are available at: https://www.debian.org/vote/2022/vote_003 Hrm. Is there support for something like A but not enabled by default? That is, you have to actively select a nōn-default option in the boot menu so that the installer loads the non-free-firmware part and installs it (but updates will be enabled if they are installed in the first place)? Mraw, //mirabilos PS: Please do Cc me on replies. -- I believe no one can invent an algorithm. One just happens to hit upon it when God enlightens him. Or only God invents algorithms, we merely copy them. If you don't believe in God, just consider God as Nature if you won't deny existence. -- Coywolf Qi Hunt
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Am Fri, Aug 26, 2022 at 04:13:43PM -0400 schrieb M. Zhou: > If one's enthusiasm on working on some package is eventually > worn out after a break, then try to think of the following question: > > Is it really necessary to introduce XXX to Debian? May be I'm repeating myself but having packages in new fixing RC bugs (for instance bug #1015861 is waiting for five months) triggering testing removals of several packages is a good reason to answer with yes here. BTW, the vast amount of new packages I'm packaging are new dependencies for existing packages to get their new versions. Kind regards Andreas. -- http://fam-tille.de
Re: Comments on proposing NEW queue improvement (Re: Current NEW review process saps developer motivation
Am Sat, Aug 27, 2022 at 09:53:40AM -0400 schrieb M. Zhou: > In my fuzzy memory, the last discussion on NEW queue improvement > involves the disadvantages by allowing SOVERSION bump to directly > pass the NEW queue. I'm not going to trace back, because I know > this will not be implemented unless someone proposes a GR. I'm considering this once beeing back from vac. However, the problem in such a GR is that even if there is an outcome for the voting that sais SOVERSION bumps should pass new we need some code that implements this. So we also need someone to volunteer for this. Kind regards Andreas. -- http://fam-tille.de
Re: General resolution: non-free firmware
On Sun, Aug 28, 2022 at 12:56:43AM +, Thorsten Glaser wrote: > Debian Project Secretary - Kurt Roeckx dixit: > > >it are available at: https://www.debian.org/vote/2022/vote_003 > > Is there support for something like A but not enabled by default? > That is, you have to actively select a nōn-default option I don't believe so, because that doesn't solve the problem at hand. How exactly do you select a non-default option if you cannot see or hear it? > More and more graphics adapters now also want firmware uploads to provide any > non-basic functions. A simple basic (S)VGA-compatible framebuffer is not > enough for most users these days; modern desktops expect 3D acceleration, and > a lot of current hardware will not provide that without extra firmware. > Current generations of common Intel-based laptops also need firmware uploads > to make audio work (see the firmware-sof-signed package). https://blog.einval.com/2022/04/19#firmware-what-do-we-do https://peertube.debian.social/w/gpdBYkAuxJ5D8V9DmsTvJS signature.asc Description: PGP signature
