Re: 2023 Debian Project survey: Sustainability now open!
I'm sure it wasn't the intention, but the questions presented in that survey feel more like they are phishing for specific people/information than curious about regular activities. It includes a number of open-ended questions with three text boxes for each, expecting the user to provide identifiable information. The wording also feels like there's a specific point that someone is trying to make, especially when it gets to "predatory practices." There is no chance you will get "useful" data (worth studying) from this survey, especially not with those questions. You could just as well be asking, "do you agree that predatory practices are bad? by the way, this includes being an end user." On Wed, Nov 15, 2023 at 2:09 AM Mathieu O'Neil wrote: > > Hi Debian :-) > > > > Thanks again to all the participants in the 2016 Debian Project survey. An > astounding 1,479 people responded to this first edition. The 2016 survey > results are available in an open-access report published in 2021: 2016 Debian > Project survey: Work and volunteers. > > > The follow-up 2023 Debian Project survey: Sustainability is now open! > > https://dcpc.limesurvey.net/382488?lang=en > > > We (researchers Mathieu O’Neil, Sebastien Broca, Xiaolan Cai, Angela Daly, > Molly de Blanc, Cecilia Rikap, Sebastien Shulz and Stefano Zacchiroli) > created this new survey, for three reasons. > > > 1-We want to track the project’s evolution since 2016: what has changed, what > remains the same when it comes to roles, contributor characteristics and the > presence of paid work in the project. > > > > 2-We want to focus on the economic sustainability of Debian and FOSS, in the > context of threats to openness posed by new mechanisms such as Software as a > Service and potential threats to sustainability such as ‘free riding’. What > should happen so that FOSS projects continue to be maintained appropriately? > > > > 3-We are interested to find out what the community thinks about the > environmental impacts of FOSS development, and possible ways to reduce these > impacts. > > > > We want to hear from as many Debian contributors as possible—whether you've > submitted a bug report, attended a DebConf, reviewed translations, maintained > packages, participated in Debian teams, or are a Debian Developer. Completing > the survey should take 10-20 minutes, depending on your current involvement > with the project. > > > > About the survey: > > We are using LimeSurvey, an online survey platform developed with free and > open source code. > > Survey responses are anonymous, IP and HTTP information are not logged, and > all questions are optional. As it is still likely possible to determine who a > respondent is based on their answers, results will only be distributed in > aggregate form, in a way that does not allow de-anonymisation. > > The results of the survey will be analyzed as part of ongoing research work > by the organizers. A report discussing the results will be published under a > DFSG-free license and distributed to the Debian community as soon as it's > ready. > > The raw, disaggregated answers will not be distributed and will be kept under > the responsibility of the organizers. > > > We hope you will fill out the Debian Contributor Survey. The deadline for > participation is: December 15, 2023. > > https://dcpc.limesurvey.net/382488?lang=en > > > > If you have any questions, don't hesitate to contact us via email at: > > Mathieu O’Neil mathieu.on...@canberra.edu.au
Re: libAWSL: Improving Human Efficiency for debian/copyright Reviewer
On Tue, 26 May 2020 08:13:24 -0400 Sam Hartman wrote: > Unfortunately, being a member of Debian, I find myself getting stuck in > the details and think you may have gotten a few things wrong. > > * I think that reviewing a file every time the salt changes is too > frequent. > It is a sign that we might need to review, not that we certainly do. > We don't tend to review files every time they change today, and I > think pushing toward this would be problematic. At the moment, when a package hits binNEW or NEW, *all* files need to be re-checked by the reviewer. There is no single-file review. This is appropriate because there are many times where code copies have been added to the source but not added to d/copyright. Some of these code copies are even embedded in previously-reviewed files that have another license. Pushing this direction would reduce efforts, not increase them. > * Unfortunately the srcpkg-bool problem does not decompose into a set of > file-bool problems the way you describe. > The issue is license compatibility. > Two licenses may be DFSG-free, but their combination may not be > distributable (and thus not DFSG-free). Two DFSG-free but incompatible licenses is a non-trivial concern and likely only caught in more extreme cases. This is really something that should become a lintian check that only reads through d/copyright. > Next Steps > > The biggest thing I see missing here is what are the next steps? > If we agree with your principles, what next? > How does this work go forward? Mo has made it clear that his ambition has run out. However, we had many discussions, including with ftpteam members, prior to either of our announcements. In a sense, libAWSL is aimed at being both a stand-alone utility as well as a module usable by the project I previously described. It's probably worth noting, based on previous conversation, I don't expect anyone in ftpteam would want to see anything discussed implemented as a formal review tool. Therefor, my own goal is to ultimately build a tool that focuses on package uploaders, so that they can be confident their package will be approved. If there are developers interested in working on this tool, I'd be happy to discuss further in #debian-review and write an actual requirements document to aid collaboration and development.
Re: Testing Discourse for Debian
On Sun, 12 Apr 2020 13:15:23 -0700 Russ Allbery wrote: > Ihor Antonov writes: > > On Sunday, April 12, 2020 11:51:27 AM PDT Russ Allbery wrote: > > [...] > So, I should be clear that I personally have only a small amount of > experience with Discourse and haven't looked into the details of its > features. But there are a lot of reasons for investigating that sort of > forum software, more generically. Here are a few. > [...] +1 Obligatory: https://xkcd.com/1782/ [I really wanted to just leave it at that, but...] I think being able to easily indicate a +/-1 would be a huge benefit for debian-style conversations. There are four distinct long-winded discussions that I can immediately recall over the last year where people have reached out to me or others over IRC to express frustration/agreement with a topic/email, but they never mentioned it on the mailing list. These same people (myself included) would likely have added a simple indication of approval/disagreement, especially knowing it is not an entirely new email to be read by every reader. I haven't used discourse yet, but if it's able to send me an email for new conversations and updates for conversations/categories I'm subscribed to, that means an infinitely smaller inbox, less noise, and more time/attention on the things I care about. ... I'm sure it can, those seem like standard features. Speaking of more recent events, I can see where certain longer-lived topic categories would be helpful, such as a help-needed (or team-needs-help) category. Rather than the FTP-Masters team firing off periodic emails hoping that someone this round reads it and bites, they could create the topic in that help-needed category and leave it for people interested in seeing how they can help Debian. I'm sure that same logic applies to many teams, where burn-out and and serious demotivation happens long before anyone external to the team is aware of the problem, which exasperates simpler problems. Continuing to pick on my favorite team... this is applies ftp-masters, where the training process itself is extremely demotivating simply because of the lack of manpower available for reviewing our reviews. A lot of these supposed benefits are speculation, since I haven't used the service yet, but it's probably time to check out this new-fangled forum stuff. At a glance, it looks like these features (and other subscription refinements) are available. They sound like they could (possibly) drastically improve how we communicate, raise concerns, gather consensus, etc. Cheers, -- Michael Lustfield
Re: Salsa as authentication provider for Debian
On Sat, 11 Apr 2020 12:02:40 +0200 Jonathan Carter wrote: > [...] > This thread has had lots of discussion so far and no one has listed a > single reason against your proposal yet, IMHO if no one is standing in > your way it's time to just go ahead and do it. Multiple concerns have been raised and subsequently shrugged off. It's clear that no concern raised will make any difference so, yeah... go for it. There's no point continuing typical debian drama for something that's going to be pushed forward regardless.
Re: Salsa as authentication provider for Debian
On Thu, 9 Apr 2020 09:44:38 +0200 Enrico Zini wrote: > On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote: > > > > If you're instead generally expressing a fear that once we migrate to > > > Salsa, we'll be in a local optimum that is going to be considered good > > > enough to be worth bothering migrating to anything else, then I would > > > argue that the problem wouldn't be having moved to Salsa as an OIDC > > > provider, and rather that the next step that is proposed wouldn't be > > > bringing enough compelling advantages to the problem at hand. > > > > Indeed, a local optimum is worrisome. > > If you mean that we should block a workable proposal for incremental > improvement in case it turns out to be good enough, I think I don't want > that. I've already mentioned a couple points that are worrisome. It also appears that there is an intent to drop -guest naming. I haven't seen any technical discussion about this beyond learning about the current structure. I am very concerned that this will have significant consequences in regard to DSA-managed LDAP. Perhaps the -guest naming should (definitely) be retired, but that sounds like a very different can of worms that's better opened later. > What we have /now/ is unsustainable, to the point that I'm afraid and > ashamed of keeping some of the services I'm responsible for online. As mentioned, we understand this. It is a very significant issue... one that most were unaware of and some of us (hand raised) thought was already dealt with. It's ... ugly, at best. > [...] > Then we can talk about a better, long-term, technically excellent, > actively supported and sustainable solution, and by all means, I'd like > to see that. I do enjoy that there is consensus on the long-term goal. > We could also do a post-mortem of why we have had what sounded like a > good solution for more than one year and never managed to get it > deployed. Not for pointing fingers: for avoiding getting in such a > stalled situation in the future. > > I am not at all in the mood for any of that, though, while I find myself > starting responding to users' requests for help by apologising for the > state things are. (please forgive me if this sounds terse/blunt/rude... it's not intended) I'm concerned that this sounds a lot like tunnel-vision, where only the fastest and easiest way out of this cruddy situation is worth considering. FWIW, that's very understandable, especially considering just how bad the status quo has been for the past year or so. It's truly an ugly situation and one where I can empathize with your pain. I can also understand the motivation to find the nearest exit and I would probably be doing the exact same thing in your shoes. For the moment, I would love to do whatever I can to help you with user issues. I know this isn't a substitute for fixing the problem, but perhaps I can help ease your burden and night terrors? Meanwhile, there are now five people with an interest in doing what we can to rectify the situation. It's unfortunate that we weren't aware of the stall a year ago, but we're here now, and I don't intend to work slowly. I'm confident you're aware of my "requirements gathering" phase. Design has been roughly discussed and I'm now taking a day to bury myself in documentation. Since I'm still playing the social distancing game, you can probably guess where my weekend priorities will be. :) Cheers, -- Michael Lustfield
Re: Salsa as authentication provider for Debian
On Tue, 7 Apr 2020 13:50:06 +0200 Enrico Zini wrote: > On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > > I would like to avoid stalling progress on sso on things like analysis > paralysis, or like sorting out deployment details, as happened in the > last years. I can very much appreciate a desire to get a replacement rolled out as quickly as possible. The more I learn about the current situation [1], the more alarming it is. However, please don't consider the work Lucas and I are doing as stalling. I was unaware that the whole effort stalled. I'm currently between contracts and have plenty of free time to make something happen. I also like to think of a myself as a good masochist. You can expect me to stick around for the long term. :) [1] oh my... https://wiki.debian.org/DebianSingleSignOn#If_you_ARE_NOT_.28yet.29_a_Debian_Developer > I'll ask you the same question I asked Luca: is there something in the > Salsa proposal that would prevent further experimentation with LLNG and > eventually possibly integrating it into the ecosystem, or migrating to > it? Aside from the security concern I raised earlier, it's largely a "gut feeling" that comes from seeing how quickly legacy quirks develop in any new deployment. If Salsa needs to make any assumption or enforcements that Alioth did not, those will need to be accounted for in the new solution. Additionally, we already have a clean path Something that comes to mind is what it would take to migrate accounts from Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as it is that alioth's DB is now a flat-file managed by hand, it provides a very simple and easy way to import all of that data. > [...] > As a side effect of an interim on Salsa, services can begin to migrate > from client certificates to OIDC, switching to a mode widely used, > usable, and flexible standard, which I wouldn't be surprised if it would > make things easier when moving to something else later on. If there aren't any practical issues with migrating away from salsa in the future, then I wouldn't have any objection, but the voice in the back of my head is screaming pretty loudly right now. -- Michael Lustfield
Re: Salsa as authentication provider for Debian
On Mon, 6 Apr 2020 20:38:59 +0200 Enrico Zini wrote: > On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote: > > > That said, please consider an approach that would see keycloak used as > > an idenitity broker, allowing external users to create accounts using > > social identities that are then promoted to full Debian identities (in > > LDAP) if they complete the onboarding process. Could be used as > > replacement for debsso, could be used for wiki, could be used for > > debconf, could be used for salsa. What does keycloak provide over something like lemonldap or similar tools? > [...] > and well known. Gitlab's codebase, while large and complex, is widely > deployed, and we already have know-how about it in Debian. I was previously involved with a company that audited various git-hosting services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so please forgive the lack of specifics. Gitlab is a tool that gets many things right, and many things wrong. Access control is an area where I have seen some critical bugs. Some of those bugs lead me to not trust it as a non-internal authentication source. Security aside, and perhaps more importantly, is the vendor lock-in problem that can be seen with Alioth. If that system were not being used as an authentication source, then the whole migration would have been entirely agnostic to such concerns and changing auth sources would never have come up. Choosing to migrate to gitlab as an authentication source just introduces a painful(?) migration for the sake of another similar migration in the future. > I would not want to see a workable proposal that we could implement over > the next two weeks and that we have the resources to maintain long-term, > blocked by something that risks getting us stuck with sso.d.o for > another bunch of years until we get it right, and possibly ending up > being maintained long term by a team with a dwindling bandwidth and bus > factor. I was previously (before gitlab's deployment) lead to believe that the problem was already being dealt with. Since this is still a problem, then I volunteer to implement and maintain whatever solution is most appropriate. Is there any summary of where those previous discussions lead and/or their conclusions? I saw something about GSoC mentioned. Is there anything viable which can be taken from that effort? Also, please, don't focus on time to deployment. I'll do whatever we need in order to implement a proper long-term solution. As you may have noticed- I take my time to plan projects before execution. If anything, this is a change that should involve more planning than anything else. -- Michael Lustfield
Re: The copyright checking question
p 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
Re: Debian and Non-Free Services
On Sat, 5 Oct 2019 23:42:50 +0200 Thomas Goirand wrote: > So, if someone is not using Github's "advanced" features, like pull > requests and so on, why that person would care about using Github more > than using Salsa? > > > You may guess that people using github accept pull requests, but you > > even can't see whether they actually like them -- there are many reasons > > why people use github, and PRs may not necessarily the specific reason > > for the repository. > > I'm just trying to understand here... > Apart from the "close to upstream" bit, what would be the reasons? I prefer GitHub over Debian's GitLab instance because: - It's significantly more stable + I've seen "GitLab is not responding" more times than I can keep track of + I've also seen a large number of 500 and 504 errors (at least 1x/wk) + This reliably fails: https://salsa.debian.org/api/v4/groups/debian - GitHub often addresses problems quickly; this is rare with salsa - GitHub takes efforts to provide root cause analysis & lessons learned - Decisions are discussed, instead of drunken thoughts over chips and salsa - I've witnessed more changes accepted by GitHub + Salsa concerns have been met with, "fix it in upstream or go away" + GitHub concerns have been met with, "this is now an internal incident" & often fixed within a month or two - It's a well-known standard solution where many people already have accounts - GitHub admins are *much* more responsive (for obvious reasons) I prefer GitHub over GitLab, in general, because: - GitHub doesn't require javascript just to browse repos - GitHub is often *much* faster to respond to feature requests - GitHub stages upgrades; improving general stability - GitLab has a *lot* of weird ACL bugs + I can create projects in groups that I have no access to maintain + I can create branches that won't let me force push (git push -f) + I can create projects that let me push to anything except master + I can be given maintainer access to a team owning those projects, but still run into all the same problems I can provide a much longer list, but it shouldn't be necessary. There are plenty of reasons why someone would prefer GitHub over other alternatives. Attempting to force one option only going to further divide our community. -- Michael Lustfield
