Re: Do we still value contributions?
Hello, We need to change something. I am just not exactly sure what this is. Since software/workflows that we cover in Debian has increased in complexity, we have come up with salsa. And we are increasingly automating our testing. The package review has not yet seen any methodological change but we expect it to just somehow keep up. And complex software having some essential module waiting in new is - unfortunate for everyone. Just to give you an example, I am packaging for the same biological workflow since two or three years now. What keeps me going? Read through https://bcbio-nextgen.readthedocs.io/en/latest/ and ask yourself if you think that should work on Debian - it works via conda on Debian, but that is not what I meant. Why is this difficult? For many reasons. One is that it uses software that is written in "nim", which is not so very much known, yet. But this is also how Debian benefits from this effort as a whole. A serial dependency on five or so non-biological modules it has. And the first (nim-unicodeplus) sits silently in the New Queue since 8 months. Folks at conda do everything on github, including a peer review. For most scientific packages I sense this to be just fine. Maybe we could somehow stage our developments? A peer-reviewed (as in "get at least three signatures" maybe?) instant upload into a "periphery" distribution with a transition into a "as time permits" FTPmaster-scrutinized "main" distribution? Also, I find it somehow sad that FTPmasters after their ingenious isolation of a problem that would then be fixed real easy don't have the chance to just do the fix in salsa and have the package accepted from there. The workflow now is that the package goes back to the uploading developer who then fixes the typically trivial bit and the package impose the same work on the FTPmasters again, often with a llooonngg delay again. Instant trivial fixes would dramatically reduce the rejection rate, I presume, and may also increase the fun to be an FTPmaster. Best, Steffen
Re: New Year's Resolution: Clean up Debian in 2020
From: Charles Bond To: debian-project@lists.debian.org Subject: Re: New Year's Resolution: Clean up Debian in 2020 Date: 26/12/2019 23:15:34 Europe/Paris ‐‐‐ Original Message ‐‐‐ On Thursday, December 26, 2019 10:07 PM, W. Mole wrote: From: Charles Bond To: debian-project@lists.debian.org Subject: New Year's Resolution: Clean up Debian in 2020 Date: 26/12/2019 22:44:51 Europe/Paris Serious questions were asked during DebConf about the conflicts of interest between Molly de Blanc and Chris Lamb. Mollygate, Mollamby and all that. Debian, GNOME, FSF and the OSI cabals all told us it is a private matter. None of them denied it. Just don't talk about it, that's all. I'm sick of this shit. You take us volunteers for granted. You think that because we all love free software we will be as gullible as the doe-eyed Outreachy interns you f*ck at DebConf each year. We're not. Bring on the debian-private leaks and all the other incriminating evidence. DebConf18 and DebConf19 they didn't even try to hide it mentors are only volunteers so no code of conduct for them ha ha ha code of misconduct is what it is The Outreachy money has become a farce. We all work to get contributions to Debian and it is hijacked to run this casting couch for the elite. One third of our money goes to their maties at Software Freedom Conservancy to manage the program. The GSoC admin team are volunteers and do the same work for free. The holier-than-thou group fly the interns to meet them at conferences. Say no more. we're only volunteers! we're only volunteers! we're only volunteers! or so they tell us what a pathetic defense let's put that in reverse: do you only have to behave ethically when somebody is paying you to?
Re: New Year's Resolution: Clean up Debian in 2020
‐‐‐ Original Message ‐‐‐ On Thursday, December 26, 2019 10:07 PM, W. Mole wrote: >> From: Charles Bond >> To: debian-project@lists.debian.org >> Subject: New Year's Resolution: Clean up Debian in 2020 >> Date: 26/12/2019 22:44:51 Europe/Paris >> >> Serious questions were asked during DebConf about the conflicts of >> interest between Molly de Blanc and Chris Lamb. Mollygate, Mollamby >> and all that. >> >> Debian, GNOME, FSF and the OSI cabals all told us it is a private >> matter. None of them denied it. Just don't talk about it, that's all. >> >> I'm sick of this shit. You take us volunteers for granted. You think >> that because we all love free software we will be as gullible as the >> doe-eyed Outreachy interns you f*ck at DebConf each year. We're not. >> >> Bring on the debian-private leaks and all the other incriminating >> evidence. > > DebConf18 and DebConf19 they didn't even try to hide it > > mentors are only volunteers so no code of conduct for them ha ha ha > > code of misconduct is what it is The Outreachy money has become a farce. We all work to get contributions to Debian and it is hijacked to run this casting couch for the elite. One third of our money goes to their maties at Software Freedom Conservancy to manage the program. The GSoC admin team are volunteers and do the same work for free. The holier-than-thou group fly the interns to meet them at conferences. Say no more. C
Re: New Year's Resolution: Clean up Debian in 2020
From: Charles Bond To: debian-project@lists.debian.org Subject: New Year's Resolution: Clean up Debian in 2020 Date: 26/12/2019 22:44:51 Europe/Paris Serious questions were asked during DebConf about the conflicts of interest between Molly de Blanc and Chris Lamb. Mollygate, Mollamby and all that. Debian, GNOME, FSF and the OSI cabals all told us it is a private matter. None of them denied it. Just don't talk about it, that's all. I'm sick of this shit. You take us volunteers for granted. You think that because we all love free software we will be as gullible as the doe-eyed Outreachy interns you f*ck at DebConf each year. We're not. Bring on the debian-private leaks and all the other incriminating evidence. DebConf18 and DebConf19 they didn't even try to hide it mentors are only volunteers so no code of conduct for them ha ha ha code of misconduct is what it is
New Year's Resolution: Clean up Debian in 2020
Serious questions were asked during DebConf about the conflicts of interest between Molly de Blanc and Chris Lamb. Mollygate, Mollamby and all that. Debian, GNOME, FSF and the OSI cabals all told us it is a private matter. None of them denied it. Just don't talk about it, that's all. I'm sick of this shit. You take us volunteers for granted. You think that because we all love free software we will be as gullible as the doe-eyed Outreachy interns you f*ck at DebConf each year. We're not. Bring on the debian-private leaks and all the other incriminating evidence. Kind regards, C
Re: Merry Christmas more debian private leaks
Message d'origine > De : Ansgar > À : debian-project@lists.debian.org > Sujet : Re: Merry Christmas more debian private leaks > Date : 25/12/2019 10:47:10 Europe/Paris > > Zlatan writes: > > Can we ban this email account (and be persistent with such effort)? > > We should, but it's playing whack-a-mole as one can just again create a > new, anonymous mail account anywhere. > > Targeted abusive behavior is much harder to get rid of than spam as most wake up. debian-private is a cesspool of what you call Targeted abusive behavior, from so many DDs past and present. we all know it. people who code in glass houses shouldn't throw stones at Norbert Preining or any other DD. if you want people to stop throwing rocks back at Debian, ask the cabal to stop the bullying, dirty politics and evil experiments Now I'm going to back to the North Pole to unfreeze more leaks for 2020. Merry Christmas and Happy New Year Regards, -- ,''`. : :' : Whacked Mole. `. `'` mo...@debian.org `-
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 11:21:08PM +0500, Andrey Rahmatullin wrote: > On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote: > > > Make the machine-readable copyright file mandatory. > > > It is much easier to "parse" than just a bunch of copyright information. > > hear hear. (as in: what's blocking us from doing this?) > I'm sure some people will orphan or RM their packages instead of writing > machine-readable debian/copyright. I suspect it will be worse than > mandating source format 3.0. that can be worked around easily be only requesting this for NEW packages... -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On December 26, 2019 6:21:08 PM UTC, Andrey Rahmatullin wrote: >On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote: >> > Make the machine-readable copyright file mandatory. >> > It is much easier to "parse" than just a bunch of copyright >information. >> >> hear hear. (as in: what's blocking us from doing this?) >I'm sure some people will orphan or RM their packages instead of >writing >machine-readable debian/copyright. I suspect it will be worse than >mandating source format 3.0. The notion that it's easier for a human to parse isn't universal. I don't find it's the case. Hard to follow copyright files can be written in any format. Scott K
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 04:29:57PM +, Holger Levsen wrote: > > Make the machine-readable copyright file mandatory. > > It is much easier to "parse" than just a bunch of copyright information. > > hear hear. (as in: what's blocking us from doing this?) I'm sure some people will orphan or RM their packages instead of writing machine-readable debian/copyright. I suspect it will be worse than mandating source format 3.0. -- WBR, wRAR signature.asc Description: PGP signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 06:01:40PM +0100, Jonas Smedegaard wrote: > Quoting Roberto C. Sánchez (2019-12-26 17:29:52) > > On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote: > > > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote: > > > >So, what does the FTP team consider that we, as the wider > > > >community of Debian Developers, can do to help? > [...] > > > When there is a REJECT and the maintainer used a tool like > > > licensecheck, file a bug and let the tools become better. > > > > One interesting thing about this is that I have often wondered if it > > would be beneficial to have checks on debian/copyright during the life > > of a package. > > lintian does some continuous checks. > > Doing it more aggressively requires (I guess¹) more work than is > currently available with licensecheck and related tools. > > > > Checking only once when a package first enters the Debian archive > > seems to leave open the rather likely possibility that some change in > > a future upstream release changes or adds some component license that > > should be documented in debian/copyright. I try to be diligent in > > this regard and even at times have found that I overlook things. > > Keeping debian/copyright up-to-date is certainly an important and > *required* part of package maintenance! > > Some use cme for automating this, I currently use licensecheck2dep5 - > again, please look at https://wiki.debian.org/CopyrightReviewTools for > options, and anyone having experience with other approaches please add > them to that wiki page! > > > > In any event, a tool that can scan a source tree and produce a base > > debian/copyright file that I as a maintianer could edit would be a > > marvelous thing. Would be possible to make the licensecheck tool dual > > use in that way? > > You mean this?: > > licensecheck --recursive --deb-machine * > > Other tools listed at https://wiki.debian.org/CopyrightReviewTools can > do similar/related tasks - in particular cme and licensecheck2dep5. > > Thanks for the pointers. I clearly need to update my knowledge regarding the available options. Regards, -Roberto -- Roberto C. Sánchez
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
Quoting Roberto C. Sánchez (2019-12-26 17:29:52) > On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote: > > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote: > > >So, what does the FTP team consider that we, as the wider > > >community of Debian Developers, can do to help? [...] > > When there is a REJECT and the maintainer used a tool like > > licensecheck, file a bug and let the tools become better. > > One interesting thing about this is that I have often wondered if it > would be beneficial to have checks on debian/copyright during the life > of a package. lintian does some continuous checks. Doing it more aggressively requires (I guess¹) more work than is currently available with licensecheck and related tools. > Checking only once when a package first enters the Debian archive > seems to leave open the rather likely possibility that some change in > a future upstream release changes or adds some component license that > should be documented in debian/copyright. I try to be diligent in > this regard and even at times have found that I overlook things. Keeping debian/copyright up-to-date is certainly an important and *required* part of package maintenance! Some use cme for automating this, I currently use licensecheck2dep5 - again, please look at https://wiki.debian.org/CopyrightReviewTools for options, and anyone having experience with other approaches please add them to that wiki page! > In any event, a tool that can scan a source tree and produce a base > debian/copyright file that I as a maintianer could edit would be a > marvelous thing. Would be possible to make the licensecheck tool dual > use in that way? You mean this?: licensecheck --recursive --deb-machine * Other tools listed at https://wiki.debian.org/CopyrightReviewTools can do similar/related tasks - in particular cme and licensecheck2dep5. - Jonas ¹ I am not intimately familiar with linitan, so I only guess that the reason it does not e.g. makes use of licensecheck is that it is too unreliable to correlate with machine-readable debian/copyright files. -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we still value contributions?
On വ്യാ, Dec 26, 2019 at 17:33, Jonas Smedegaard wrote: Ninka, Licensecheck, and other related tools are tracked at https://wiki.debian.org/CopyrightReviewTools license-reconcile is my favorite from the list of tools mentioned there. Though it seems this tool is looking for maintainers. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933126
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote: > Make the machine-readable copyright file mandatory. > It is much easier to "parse" than just a bunch of copyright information. hear hear. (as in: what's blocking us from doing this?) -- cheers, Holger --- holger@(debian|reproducible-builds|layer-acht).org PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C signature.asc Description: PGP signature
Re: Do we still value contributions?
Quoting Ryan Kavanagh (2019-12-26 17:12:05) > On Thu, Dec 26, 2019 at 04:54:19PM +0100, Jonas Smedegaard wrote: > > Quoting Mo Zhou (2019-12-26 16:31:34) > > > On Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz wrote: > > > > So in my opinion the option we should implement is a (mostly) > > > > automated license check. > > > > If you have any notes on that thought process - even vague > > scribblings - then I would appreciate them as inspiration on my work > > on licensecheck. > > You might also be interested in checking out "Ninka, a license > identification tool for Source Code" by some software engineering > researchers at the University of Victoria and at Osaka University. > > http://ninka.turingmachine.org/ > > I don't know how it compares to licensecheck. Thanks. Ninka, Licensecheck, and other related tools are tracked at https://wiki.debian.org/CopyrightReviewTools Anyone knowing about other related tools, please update that wiki page (no need to also post about it here on the list: Me and others interested monitor the wiki page and get notified on changes there). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 04:30:58PM +0100, Thorsten Alteholz wrote: > > > On Thu, 26 Dec 2019, Roberto C. Sánchez wrote: > >So, what does the FTP team consider that we, as the wider community > >of Debian Developers, can do to help? > > What about being more careful when creating the debian/copyright for a > package? > I know it is boring, but writing a REJECT-mail is not much fun as well. > Seeing a copy error once is ok, but seeing that in a bunch of > packages, makes me wonder. > Don't neglect fonts, pictures, sound files. > I agree that this is a terribly boring thing to do when packaging new software. I cannot imagine how much more boring it would be for the person performing the verification on the FTP team. > When there is a REJECT and the maintainer used a tool like licensecheck, > file a bug and let the tools become better. One interesting thing about this is that I have often wondered if it would be beneficial to have checks on debian/copyright during the life of a package. Checking only once when a package first enters the Debian archive seems to leave open the rather likely possibility that some change in a future upstream release changes or adds some component license that should be documented in debian/copyright. I try to be diligent in this regard and even at times have found that I overlook things. In any event, a tool that can scan a source tree and produce a base debian/copyright file that I as a maintianer could edit would be a marvelous thing. Would be possible to make the licensecheck tool dual use in that way? The FTP team could use it when validating and developers could use it for creating the initial debian/copyright. Then it might also serve as the basis for a lintian check (when the quality is sufficiently high), or some other process whereby ongoing checks of debian/copyright could be performed. > (I tested some commercial tools a while ago and they were extremely bad in > detecting correct licenses.) > > Make the machine-readable copyright file mandatory. > It is much easier to "parse" than just a bunch of copyright information. > Yes. Regards, -Roberto -- Roberto C. Sánchez
Re: Do we still value contributions?
Le Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz a écrit : > > While I'd appreciate to have a faster ftp/NEW process, I do not think > letting more people participate (as in: DDs not part of ftp-masters) is > a good idea. We've often seen mud-fights about the interpretation of > licenses, missing licenses, patents and whatever else. Hi Bernd and everybody, my vision with the copyright reviews was to filter obvious issues in packages before the FTP team spends time on them. Thus, the focus should be on facutal points such as finding obviously non-free files (information to be sent to the maintainer, who can update or remove the package from the NEW queue) or finding an obviously new license (useful information for FTP masters, who can organise their work accordingly), etc. > Also we have the issue that if we let other people actually read trough > the source code, we might have distributed it already and in the same > time we might be violating licenses. I understand that we need to be conservative on what is redistributed by the FTP team. But often the source package can also be found elsewhere than in the NEW queue, such as on mentors.d.n, ... > So in my opinion the option we should implement is a (mostly) automated > license check. Indeed. Ideally, a bunch of tools should be run automatically on new packages (by people willing to take the same amount of legal risk as the mentors.d.n admins), so that anybody can report potential issues. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, 26 Dec 2019, Roberto C. Sánchez wrote: So, what does the FTP team consider that we, as the wider community of Debian Developers, can do to help? What about being more careful when creating the debian/copyright for a package? I know it is boring, but writing a REJECT-mail is not much fun as well. Seeing a copy error once is ok, but seeing that in a bunch of packages, makes me wonder. Don't neglect fonts, pictures, sound files. When there is a REJECT and the maintainer used a tool like licensecheck, file a bug and let the tools become better. (I tested some commercial tools a while ago and they were extremely bad in detecting correct licenses.) Make the machine-readable copyright file mandatory. It is much easier to "parse" than just a bunch of copyright information. Thorsten
Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 04:54:19PM +0100, Jonas Smedegaard wrote: > Quoting Mo Zhou (2019-12-26 16:31:34) > > On Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz wrote: > > > So in my opinion the option we should implement is a (mostly) > > > automated license check. > > If you have any notes on that thought process - even vague scribblings > - then I would appreciate them as inspiration on my work on > licensecheck. You might also be interested in checking out "Ninka, a license identification tool for Source Code" by some software engineering researchers at the University of Victoria and at Osaka University. http://ninka.turingmachine.org/ I don't know how it compares to licensecheck. Best, Ryan -- |)|/ Ryan Kavanagh | GPG: 4E46 9519 ED67 7734 268F |\|\ https://rak.ac | BD95 8F7B F8FC 4A11 C97A signature.asc Description: PGP signature
Re: Do we still value contributions?
Hi Mo, Quoting Mo Zhou (2019-12-26 16:31:34) > On Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz wrote: > > So in my opinion the option we should implement is a (mostly) > > automated license check. There are various tools listed on the wiki > > page, but there are also commercial tools out there which do that > > task. Although I know it will sounds completely wrong in the ears of > > some of readers here, I think asking one of the companies if they'd > > sponsor their tools to examine the new queue sounds like a very good > > idea to me, if it helps the ftp team to be faster. At the same time > > we'll get hints to license violations from our upstreams... > > Very long time ago I had a bold idea to formularize the license > checking, a somewhat repetitive process into a machine learning > problem. However, experience indicates that there are an amount of > special cases hard to be modeled in a math system. Plus, the NEW > reviewing process is not falt-tolerant, which definitely further > increased the difficulty to automate ftp-master's work with > "artificial intelligence". > > As a trainee, I ended up browsing every single file manually. If you have any notes on that thought process - even vague scribblings - then I would appreciate them as inspiration on my work on licensecheck. (I don't plan to implement machine learning to licensecheck - that is way above my skills - but imagine that your possible notes might help aid in improving how to recognize and categorize copyright and licensing statements in free-form texts). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz wrote: > > So in my opinion the option we should implement is a (mostly) automated > license check. There are various tools listed on the wiki page, but > there are also commercial tools out there which do that task. Although I > know it will sounds completely wrong in the ears of some of readers > here, I think asking one of the companies if they'd sponsor their tools > to examine the new queue sounds like a very good idea to me, if it helps > the ftp team to be faster. At the same time we'll get hints to license > violations from our upstreams... Very long time ago I had a bold idea to formularize the license checking, a somewhat repetitive process into a machine learning problem. However, experience indicates that there are an amount of special cases hard to be modeled in a math system. Plus, the NEW reviewing process is not falt-tolerant, which definitely further increased the difficulty to automate ftp-master's work with "artificial intelligence". As a trainee, I ended up browsing every single file manually.
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 08:53:43AM -0500, Roberto C. Sánchez wrote: > > So, what can we, as the wider community of Debian Developers, do to > help? Replying to myself. I recognize that this thread contains varying suggestions as to how to improve the situation. My question should have perhaps been phrased more definitively: So, what does the FTP team consider that we, as the wider community of Debian Developers, can do to help? Regards, -Roberto -- Roberto C. Sánchez
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Thu, Dec 26, 2019 at 04:05:20AM +, Mo Zhou wrote: > However, accelerating the recruitment process of ftp team looks quite > difficult to all participants, including the ftp-masters and the trainees: > > ftp-master: > * time and energy is limited. doesn't have enough resource to provide >too much feedbacks to the trainee > * wants to make sure every new member will be qualified enough to take >this important role. > > trainee: > * limited time and energy. generally not able to produce a large amount >of reviews to the NEW packages in a short period of time > * lacks feed back. they don't know how are they actually doing in >reviewing the NEW packages. > > So accelerating the recruitment process is not easy, given that we will > not lower our quality standards. > An application of the principle that "adding more programmers to a late project makes it later" (from _The Mythical Man-month_) to this situation leaves us with possible ways forward: 1. maintain the status quo and accept that FTP master tasks will necessarily include a very large built-in delay in completion time 2. accept a further reduction in responsiveness/slow down now and for some, perhaps indeterminate, period of time to allow for dedicating a certain amount of effort to train extra team members (which seems to require a high degree of close collaboration and supervision with lots of feedback); after some time the team's productivity should increase and surpass its current level Speaking as someone who has had uploads processed through NEW in a matter of days (and been very pleasantly surprised) and also still with a package that is approaching a year in NEW (and being a bit disappointed with that), the second of the above scenarios seems to be by far the more sustainable and productive approach from the long-term perspective. So, what can we, as the wider community of Debian Developers, do to help? Regards, -Roberto -- Roberto C. Sánchez
Re: Do we still value contributions?
On 12/26/19 4:48 AM, John Goerzen wrote:> That is a fantastic idea. If we could open up these reviews to let more> DDs participate, that would be fantastic. No doubt some of the tools at> https://wiki.debian.org/CopyrightReviewTools could help people with> this. tl;dr: automate this task to avoid mud-fights between DDs over license questions. While I'd appreciate to have a faster ftp/NEW process, I do not think letting more people participate (as in: DDs not part of ftp-masters) is a good idea. We've often seen mud-fights about the interpretation of licenses, missing licenses, patents and whatever else. Also we have the issue that if we let other people actually read trough the source code, we might have distributed it already and in the same time we might be violating licenses. So in my opinion the option we should implement is a (mostly) automated license check. There are various tools listed on the wiki page, but there are also commercial tools out there which do that task. Although I know it will sounds completely wrong in the ears of some of readers here, I think asking one of the companies if they'd sponsor their tools to examine the new queue sounds like a very good idea to me, if it helps the ftp team to be faster. At the same time we'll get hints to license violations from our upstreams... -- Bernd ZeimetzDebian GNU/Linux Developer http://bzed.dehttp://www.debian.org GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Re: Some thoughts about Diversity and the CoC
Hi Sam, thanks for trying to help explain things. On Mon, 23 Dec 2019, Sam Hartman wrote: > I think your messages here over the last few weeks and your blog posts > (not sindicated on planet) would reasonably lead someone to the Indeed, I have made the same failure I criticized Pierre-Elliott for, namely extrapolating from one person to a larger group. I have updated the blog post to make this clear, including an apology, but remain clear with my critic on Martina. Best Norbert (btw, it seems I am the only one in the whole group who ever admits to an error - funny how **perfect** you all are!) -- PREINING Norbert http://www.preining.info Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13
