One of the things that attracts me to Debian the most is it's consistency. We all tend to follow a standardized policy and have tools to make sure the policy is followed. This means we've collectively built a system that we all (generally) agree on.
The benefit to this is that I'm still able to run almost (32 of 34) every single system of mine without SysD. I may occasionally need to copy/paste/tweak an init script, but that's it. (... he said, before looking at the last GR results) These standards, gradual changes, etc. also mean it's /usually/ extremely easy and safe to do upgrades between major Debian releases. On Tue, 31 Dec 2019 23:39:32 -0600 John Goerzen <jgoer...@complete.org> wrote: > On Mon, Dec 30 2019, Steven Robbins wrote: > > > In another thread, Russ Allbery makes a salient observation [1]: > > > > Requiring ftpmasters to [review debian/copyright before accepting an > > upload] is a choice that Debian has made. Maybe it's the right choice, > > but other choices exist, and other entities make different choices. Another major thing I like about Debian is it's review process. I know it's currently a pain point, but having the review step means that we can be reasonably sure what software on our systems is legally free. Sure, in practice, that hasn't been a problem, but let's imagine/pretend evil corporations exist... Microsoft decides Gitea is proving too much competition to Gitlab. They take a look through the source and find a number of unlicensed modules and offer the original creator(s) some money for them. They now have the ability to stick their own license on it, call it their own, and sue anyone using that module, which would include Gitea and Gogs. I spent >50hr/wk for over half a year attempting to get Gitea packaged for inclusion in Debian main. Working through that showed me just how often incorrectly licensed or unlicensed work winds up in larger projects. I also found that code copying is very common, making it nearly impossible to update or track. [Fortunately, a majority of project maintainers are more than happy to find out their library was useful and quickly add an open source license. A few don't, but the majority do.] Here's an example of what sort of headache that can look like: - https://github.com/go-gitea/gitea/pull/2241/files - https://github.com/go-gitea/gitea/pull/2383/files When I install something from Debian main, I get to have a reasonable level of confidence that I can't wind up a victim of this sort of problem. As someone who's been involved in copyright conflicts, this is something that is extremely valuable to me. > > Russ goes on to list several alternative strategies, concluding with > > > > But I do think it's worth occasionally explicitly asking the question > > and > > then making an intentional choice, rather than assuming we're obligated > > to > > continue doing what we're doing. > > > > I agree. This seems to me something worthy of a general resolution on, > > since > > these discussions pop up every 6-12 months and don't go anywhere. I don't > > have the stamina to go through with proposing a resolution but I hope > > others > > will. I don't think this copyright/license/qa check is a "legally responsible" /requirement/. In some ways, we're acting like a web hosting company, but for packages. We have reasonable efforts (policies, auto-reject, peer-review, etc.) to keep "bad" packages out and if we're made aware of something that's problematic, we can remove it at the request of any cease & desist. This extra step probably doesn't protect the distribution, but it /does/ protect it's users and it protects the people uploading the packages. > I'm not sure about the GR, but these are exactly the sorts of questions > and ideas that need to be raised and discussed. I'd prefer hold off on a GR. > It is particularly odd to me that there is absolutely no review required > to introduce code to Debian in general (particularly if a package is > already in sid), but we have this one-time thing. I agree with Russ; > maybe it's needed, but it's high time we give it careful consideration > again. I think the cause-effect relationship might be backward here. From my observation, the number one reason we don't do license checks with updates is because we don't have the capacity for just what's handled in NEW, and part of that is related to burn-out. Sure, we could do away with this amazing bit of peer-review, but I strongly believe that the cost is too great. ... We might be known as the bickering distro, but we bicker because we care and because we let passion fuel our emotions. The options I see: 1) Stop doing this review step ^ I reviewed an upload today that had extra DLL files and the entire .git/ ^ Ask me about Gitea... 2) Get more DDs volunteering their time to be on the team ^ yeah... not gonna happen, especially not with the learning curve 3) Improve the tools so uploads can be reviewed more efficiently 3a) Decreasing review burden and time-block commitment 3b) Perhaps making it more exciting to be on the team? 4) Keep doing what we're doing ^ and keep getting what we're getting Personally, I like #3. I've been trying to think of ways to improve the process since the day I became a Trainee. Lately, I've found the motivation to start turning ideas into code, partly fueled by Mo Zhou's discussion. I started talking to him about my plans to see where our thoughts overlap. For the moment, I think I'd prefer avoid public discussion of the plan, just to prevent lots of wasted discussion before getting it out the door. If you'd like to discuss it because you're interested in contributing source, then I'd love to chat. A good front-end web dev would be extremely helpful, and someone that understands dak very well. As for the follow-up checks, well... I /might/ have a plan. The automated tool I'm working on is going to provide a summary of certain scans, including preliminary license findings. I picture a future where at least a few of these checks can become part of a dak auto-reject rule, once they've been fine-tuned a bit. This would introduce a way to verify that a package is still very likely to be legally free. I apologize for the lack of details, but I'm digging in and have some down time from work. I'd like to make use of that time to just build. :) Cheers, -- Michael Lustfield
