Re: [RFC] General Resolution to deploy tag2upload
Hi Ian On 2024/06/17 12:56, Ian Jackson wrote: * We made fairly formal appeals to two sitting DPLs. What we got was, basically, attempts at mediation, or facilitation of discussions. We didn't see that as helpful, since we saw an irreconcilable gap between our position and ftpmaster's. Sean and I were under the impression that the most recent response we got from a sittinug DPL was sent to us after consulting with ftpmaster. My response was to suggest that you find a way to talk to DSA/ftpmaster, ideally in person, and that you check whether the xz-utils postmortem in MDC Hamburg was happening, because that would be an ideal place to speak to both in person. I wouldn't necessarily expect that you get the exact resolution that you're looking for, but when you get enough people together in person that understands the infrastructure and the trust chain well, then there should be a good chance that at least an alternate solution could be presented. I know that they specifically said they don't want the service to have it's own upload key, but perhaps there are other ways to implement this without losing the key benefits that tag2upload provides. I'm sure you and Sean have thought a lot about it, but you might have some more leeway from DSA/ftpmaster if they have also taken a shot at it and exhausted all the possibilities. Personally, I think that tag2upload is a great idea and it has a lot of potential, and I want to see it succeed, but I think a more pragmatic approach might get you there faster than forcing it. As a project, I think we have some lessons to learn from overriding maintainers from the issues that arose from usr-merge/dpkg, and overriding two teams of people that are both highly skilled and competent at keeping critical infrastructure up for so long, won't sit well with many DDs voting on this either. As I suggested in my reply to you months ago, I still believe that working with ftpmaster to come up with solutions will be worth while, but I don't think email/irc are the best platforms for hashing out problems. As an aside, it might be worth while to integrate tag2upload into other services. I wasn't sure if I wanted to go down this rabbit hole in this mail, but Debusine looks like it has a lot of potential, and it could be a great backend for a PPA-like service, which could also have tag2upload integration or could even be *the* way it's implemented. That way tag2uplaod could get wider testing and more by-in from users using that service. It probably doesn't sound very useful to suggest that you integrate tag2upload with a PPA service that's effectively still vapourware, but sometimes you need to have some good long-term strategy in order to get change to happen. When it comes to tag2upload, I believe it's something that most people would want. At least it doesn't take away from any existing workflow or force people to change their habits right away, so in terms of being able to gain support for it, it has a lot going for it. The cost of overriding DSA/ftpmaster is really high though, and I'm not sure it's worth while doing a GR until all other options have been properly exhausted. Even if there is a GR, I believe a vote for "we all really want this, please find a way forward" would be better than "let's force this to happen right now". -Jonathan
Re: [RFC] General Resolution to deploy tag2upload
Hi Sean On 2024/06/15 02:14, Sean Whitton wrote: My point is that it's not doing any magic. It's less than 500 lines of shell. Where do I find this? I searched for tag2upload on salsa and did an 'apt-cache search tag2upload', but couldn't find anything. thanks, -Jonathan
Re: [RFC] General Resolution to deploy tag2upload
Hi Luca On 2024/06/12 10:21, Luca Boccassi wrote: Having a separate namespace with strong ACLs seems exactly what you want, even if it duplicates the individual repositories (the backend git store deduplicates it anyway, so in practice it should be quite cheap). Having an entire separate git forge that competes with Salsa seems orthogonal to this, and counterproductive for the project. I found the overview of tag2upload from Ian at MDC Campbridge quite useful (and the workflow diagrams that he presented). From my understanding (and I may still have the wrong end of a stick here), the additional git store used for tag2upload becomes a replacement for source packages that happens to use git. So from my understanding, it's more a competitor to source packages rather than to salsa. Video of the talk: https://peertube.debian.social/w/pav68XBWdurWzfTYvDgWRM -Jonathan
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
On 2024/04/10 16:08, Felix Lechner wrote: On Wed, 27 Mar 2024 13:57:55 +0200, Jonathan Carter wrote: every single hardware request over the last 4 years (whether from DSA or from a DD) has been approved. Mine wasn't, although I probably didn't follow the proper procedure. I just wrote a private email to Jonathan. His response is below. I'm not going to re-hash what I previously said, it's all on record from the 2022 DPL election period: https://lists.debian.org/msgid-search/bdc81fe2-4490-a839-27b4-e610de369...@debian.org After which, you lost to NOTA and then rage quit Debian, and now, two years later, you're still bitter that you didn't get an SSD that you never bothered to file a request for. There comes a time where you need to know that it's time to let it go. -Jonathan
Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi! On 2024/03/27 12:25, Pierre-Elliott Bécue wrote: Would you be ok spending 100k USD on buying hardware for a new Debian cloud, for example? I've always volunteered to operate it for Debian, but it never went through, because I haven't spent time to find where to host it and so on, but highvoltage liked the idea. Do you like this idea? Do you think it'd be useful for Debian? > Please, let's take some time to think about the implications of spending a shitload of money to buy hardware that we wouldn't know where to host, and that would require a load of maintenance and time. If any discussion should arise on these matters, I'd rather them to occur not as a platform for a DPL candidate but after a reasonable discussion with the concerned parties, eg, DSA. I'm trying not to respond to too many mails here because I don't want to take away too much attention from the candidates, but I also don't think we have a problem of money heaping up anymore. Across the project, our financial needs are mostly met, and it helps having some reserve cash for a rainy day. Also on the DSA front, they have just filed a request two weeks ago for upgrades at UBC in the range of $110-$160k, so it's not like we're spending nothing on hardware either! Also, every single hardware request over the last 4 years (whether from DSA or from a DD) has been approved. I hope that's something that our new DPL will continue doing so for every reasonable request going forward as well! -Jonathan
Re: Question to candidates: How do you plan to manage finances/accounting?
Hi Sruthi On 2024/03/22 19:51, Sruthi Chandran wrote: I agree on your point of lack of transparency about the finances. But from what I understood from highvoltage's platform last year, the problem is more to do with the current delayed, manual and tedious accounting process. The accounting processes have definitely been one of the stumbling blocks. We now have a new reimbursement system that's live (and even in use by some!) at https://reimbursements.debian.net Once we have everything going through there, it will be much easier to get all kinds of reporting and insights into our spending (where, right now, other than me polling the TOs and posting a summary, everything else has been close to impossible). It's still under development, but it's shaping up nicely, so I think in the future, the financial administration will be far less of a burden to the DPL than it has been for years already. -Jonathan
Re: Candidates question: politics and Debian
On 2024/03/23 18:48, Paulo Henrique de Lima Santana wrote: Maybe is it time to Debian has its own outreachy program? To have DDs mentoring paid interns to learn how to package, how to contribute for softwares/tools used by Debian, and so on. In the last Debian Outreach Delegation, this is one of the challenges that they're stepping up for: https://lists.debian.org/debian-devel-announce/2023/11/msg4.html -Jonathan
Re: This does not have to be a GR
On 2023/11/22 01:37, Kurt Roeckx wrote: I would also like to point out that, in the current state, on Saturday the discussion period is over and a vote is automatically called. Not so sure how automatic that was meant to be, but for what it's worth, I didn't see enough interest in extending the discussion period, so it ended on Saturday. -Jonathan
Re: Call for seconds: Delegate to the DPL
On 2023/11/26 21:24, Bill Allombert wrote: We should not just put out a statement just because others have done so, because we might inadvertently propagate FUD. Yep, it's a minefield. Anything we say can be used by a manipulative politician to make it seem that we support their cause. -Jonathan
Re: Call for seconds: Delegate to the DPL
Hi Bill On 2023/11/24 19:14, Bill Allombert wrote: I offer the following ballot option for your consideration. - GENERAL RESOLUTION STARTS - The Debian developers delegate to the Debian Project Leader the task of issuing a Public Statement about the 'EU Cyber Resilience Act and the Product Liability Directive' that addresses Debian interests in the matter. - GENERAL RESOLUTION ENDS - I follow your logic in proposing this, although my interpretation of ¶5.1.4[0] in our constitution leads me to believe that the DPL does not need any delegation for this, so perhaps the intention becomes more of "Let the DPL decide". In February I posted[1] about the CRA to debian-project[1]. My intention was to get a few good people to spend some time to focus on this, since my available bandwidth for this was low (and continued to be since then). I'm not sure that it's a good idea to leave it as a DPL task, it might delay an actual public statement by a month or even more. That said, I'm not completely against the idea, if this ends up happening I would likely combine the best current ideas in an etherpad and invite everyone to list and hammer out any remaining issues. -Jonathan [0] https://www.debian.org/devel/constitution [1] https://lists.debian.org/msgid-search/1b2aee43-cea0-2fa8-ba93-cbee1b965...@debian.org
Re: This does not have to be a GR
Hi Kurt On 2023/11/22 01:37, Kurt Roeckx wrote: While Debian has stakes in the CRA, and should issue a statement if only to show we exists, I am quite sure that a GR is not necessary for Debian to issue such statement, and I am quite unconvinced the GR process is the best option for the purpose of drafting such statement. I note that this is not the first law proposal that impact Debian and we never did used the GR process for issuing a position statement. The DPL could delegate to a group of people knowledgeable in EU law to draft a statement that is congruent with the interest of Debian. > I'm not sure that the DPL has such authority, since it's a power giving to the developers by way of GR. I don't think that works, because then it could be argued that any delegation's decisions can be overridden by a GR and has thenceforth already been delegated. So, I believe it is possible to have such a delegation. Although, whether it would be a good idea is an entirely different issue. I do think we should have a proper discussion about how we want to treat comments on legislation (although not during this GR), because we've refrained from doing so when it affects both free software and Debian in other regions of the world. I would also like to point out that, in the current state, on Saturday the discussion period is over and a vote is automatically called. While I think this could use more discussion, I'm not currently planning on extending the discussion period for this vote unless there is sufficient demand for it. If there's more than one person who still wants to work on a proposal or if there's some aspect we need to explore further, then it can be extended. -Jonathan PS: While I didn't cite our constitution in this mail, I'm including a link here for convenience, since I often refer to it myself when I want to make sure whether I remember some detail correctly: https://www.debian.org/devel/constitution
Debian's 30th Birthday (was: Re: Platform)
Hi Paulo On 2023/03/15 16:29, Paulo Henrique de Lima Santana wrote: I believe this year is a special because it's 30 years of Debian. So we need a speciall call for celebration I agree, last year I was swamped around Debian's birthday nearly even missed it altogether. I was thinking then that it would be a lost opportunity to not do something bigger for the 30th. How enthusiastic are you about this? Would you be willing to put together a team who could help manage a 30th birthday? This could be great for local teams, especially if we could try something like 30 birthday parties in 30 cities across the world, and perhaps 30 talks/events that could be broadcasted during the event. Might be nice to set it up DebConf-style, complete with a wafer site and have the video infra up for it, but I'm just spitballing here. Either way, I'm very happy to support a team who work on 30th birthday celebrations, and the budget for it won't be a problem. If some people from local teams could get together to brainstorm and plan it, I'm sure it could be something very memorable. -Jonathan
Re: On community and conflicts
On 2023/03/15 19:00, Thomas Koch wrote: Half a year later, would you mind sharing a comment on my exclusion? I'm glad that DAM didn't take too long to take action. Would you be open to have a (public?) call with me and maybe also people from the project (e.g. community team)? There have been conflicts in the last years that separated even families. Also the Debian project has been affected. These conflicts should be healed. If you care about healing, the best thing you can possibly do is to move on. From my side, I'm not interested in risking exposing the project to wasting even more time on more conspiracy theories. -Jonathan
Platform
Hey everyone I suppose some people might be wondering if I'm writing a platform for this election- and the answer is YES! I meant to have it ready by the end of the weekend, but got hit by some tummy bug that's been going around and just couldn't concentrate on the platform much. I'll work on it tonight and send it to the secretary ASAP. Even though I'm the only one running this time, I hope that we can use the time leading to the election as productive discussion time as we've done in some previous campaign periods. thanks! -Jonathan
Re: Debian Project Leader Elections 2023: Call for nominations
Hi Kurt On 2023/03/03 21:39, Debian Project Secretary - Kurt Roeckx wrote: | Period | Start | End | |+-+---| | Nomination | Saturday 2023-03-04 | Friday 2023-03-10 | I gave it consideration, and will run again this year. -Jonathan OpenPGP_0xB01D1A72AC8DC9A1.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: Requesting Extension (was: Re: Changing how we handle non-free firmware)
Hi Everyone On 2022/09/07 18:26, Jonathan Carter (highvoltage) wrote: As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension for the discussion period of 7 days. Thank you all for taking the time to polish or add voting options over the last week. I believe that the options we have available now broadly covers the views within the project, which should allow us to make a representative vote. Thanks again! -Jonathan
Re: Possible draft non-free firmware option with SC change
On 2022/09/09 18:37, Bdale Garbee wrote: "Jonathan Carter (highvoltage)" writes: I do think some parts are important to include though, how about: I disagree strongly on this. We should work REALLY hard to have the SC capture the commitments we're making to our users, and then stop. Specifically, we should avoid including text that attempts to tell them what they need to do, such as: We encourage software vendors who make use of non-free packages to carefully read the licenses of these packages to determine whether they can distribute it on their media or products. If you really think we need to say this to downstream consumers / distributors of our work, I'm sure we can find a way to do that. But the Social Contract is the wrong place. It is, and must remain, an articulation of our values and the associated commitments we're making to our users. The fewer words it must contain to achieve those objectives, the better. I happen to agree with you, although at the same time, we can't make hard promises on some things and then also purposefully go ahead and do something that's the complete opposite. If we were to include any non-free software/firmware on something that's called official Debian installer media that is said to conform to our standards, then we either can't include such software or we need some form of exception to our standards that is explained somewhere prominently. If we ship non-free firmware/software (the lines between those have become *very* blurred, as seen with GPU drivers especially), and pretend that the current DFSG/SC applies, then I think we're being very dishonest and that is worse to me than the problems you have listed. -Jonathan
Re: Possible draft non-free firmware option with SC change
On 2022/09/09 18:04, Russ Allbery wrote: We encourage careful review of the licensing of these packages before use or redistribution, since the guarantees of the Debian Free Software Guidelines do not apply to them. Looks good to me. It summarizes the gist of the issue very concisely without using any loaded terms. -Jonathan
Re: Possible draft non-free firmware option with SC change
On 2022/09/08 11:27, Phil Morrell wrote: 5. Works that do not meet our free software standards We acknowledge that our users may require the use of works that do not conform to the Debian Free Software Guidelines. Such packages are not part of the Debian system, but we provide the enabling infrastructure as a convenience to our users. This includes the bug tracking system, installation media, mailing lists and separate archive areas. I liked Russ's suggestion a lot, and also agreed with your comments (I had similar thoughts when reading it initially). I do think some parts are important to include though, how about: """ 5. Works that do not meet our free software standards We acknowledge that our users may require the use of works that do not conform to the Debian Free Software Guidelines. Such packages are not formally part of the Debian system, bug fixes and security updates depend entirely on their upstream developers. We provide the enabling infrastructure as a convenience to our users. This includes the bug tracking system, installation media, mailing lists and separate archive areas. We encourage software vendors who make use of non-free packages to carefully read the licenses of these packages to determine whether they can distribute it on their media or products. """ An added goal I'm trying to achieve with this change is to explain some practical consequences of redistributing non-free software. It's not like we provide the non-free archives and it's *wink* *wink* kind of official because Debian people provide it but it's not, instead it's the case that everything that makes Debian great really doesn't apply to these packages. Also, I think a change like this is fine for this GR, but if it complicates things, then I think it's also worth while to tackle some finer points of the SC/DFSG in a follow-up GR really soon. -Jonathan
Requesting Extension (was: Re: Changing how we handle non-free firmware)
Dear Debian Secretary and Debian Developers As per the Debian Constitution[1] (4.2¶3), I'm requesting an extension for the discussion period of 7 days. Apologies for jumping this on the last minute, I've been off-sick and have been fiercely triaging and catching up with issues the last day or so. My rationale is that we have some unresolved issues that I think would be prudent to consider before the vote. For one, some of the options may put some pressure on individuals or teams to implement some features at the wish of the project. We've already had (and even recently) situations like this that caused a lot of friction. So, I believe it would be worth while to discuss how we want to treat this specifically for the next releases. What happens if we decide on an option for Bookworm, and the implementation is nowhere ready by, say, August next year, do we delay the release? Or aim for Bookworm but make it RC for Trixie? Even if we have some consensus about how to address that and the details don't make it in the actual vote, it would still be an improvement. Other than that, we may have to accept the fact that this GR won't be (and possibly can't be) perfect and that we'll have to apply some touch-ups based on our experiences and further conclusions based on that, and improve upon it again by another GR some time in the future. In the meantime, I think another week of polish will be worth it over the bookworm release cycle, and I'm glad that this topic is at least moving forward and that we get to make some choices together as a project regarding firmware. Thanks for understanding, -Jonathan [1] https://www.debian.org/devel/constitution On 2022/08/18 21:58, Steve McIntyre wrote: Hi a11! I'm proposing to change how we handle non-free firmware in Debian. I've written about this a few times already this year [1, 2] and I ran a session on the subject at DebConf [3]. TL;DR: The way we deal with (non-free) firmware in Debian isn't great. For a long time we've got away without supporting and including (non-free) firmware on Debian systems. We don't *want* to have to provide (non-free) firmware to our users, and in an ideal world we wouldn't need to. However, it's no longer a sensible path when trying to support lots of common current hardware. Increasingly, modern computers don't function fully without these firmware blobs. Since I started talking abbout this, Ansgar has already added dak support for a new, separate non-free-firmware component - see [4]. This makes part of my original proposal moot! More work is needed yet to make use of this support, but it's started! :-) I believe that there is reasonably wide support for changing what we do with non-free firmware. I see several possible paths forward, but as I've stated previously I don't want to be making the decision alone. I believe that the Debian project as a whole needs to make the decision on which path is the correct one. I'm *not* going to propose full text for all the possible choices here; as eloquently suggested by Russ [5], it's probably better to leave it for other people to come up with the text of options that they feel should also be on the ballot. So, I propose the following: = We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will *normally* be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will *also* be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. We will publish these images as official Debian media, replacing the current media sets that do not include non-free firmware packages. = A reason for defaulting to installing non-free firmware *by default* is accessibility. A blind user running the installer in text-to-speech mode may need audio firmware loaded to be able to drive the installer at all. It's going to be very difficult for them to change this. Other people should be able to drive the system (boot menus, etc.) to *not* install the non-free firmware packages if desired. We will *only* include the non-free-firmware component on our media and on installed systems by default. As a general policy, we still do not want to see other non-free software in use. Users may still enable the existing non-free component
Re: Changing how we handle non-free firmware
On 2022/08/22 19:32, Gunnar Wolf wrote: = We will include non-free firmware packages from the "non-free-firmware" section of the Debian archive on our official media (installer images and live images). The included firmware binaries will*normally* be enabled by default where the system determines that they are required, but where possible we will include ways for users to disable this at boot (boot menu option, kernel command line etc.). When the installer/live system is running we will provide information to the user about what firmware has been loaded (both free and non-free), and we will also store that information on the target system such that users will be able to find it later. The target system will*also* be configured to use the non-free-firmware component by default in the apt sources.list file. Our users should receive security updates and important fixes to firmware binaries just like any other installed software. While we will publish these images as official Debian media, they will *not* replace the current media sets that do not include non-free firmware packages, but offered alongside. Images that do include non-free firmware will be presented more prominently, so that newcomers will find them more easily; fully-free images will not be hidden away; they will be linked from the same project pages, but with less visual priority. = Seconded, although I'd drop the "but with less visual priority" because depending on page design it might be good in some cases to have them equally prominent in lists (some might assume that this GR means that the free images /must/ always be less prominent than the non-free ones if they are listed anywhere). -Jonathan OpenPGP_signature Description: OpenPGP digital signature
Re: General Resolution: Liquidate donated assets as soon as possible
Hi Louis-Philippe On 2022/06/19 01:43, Louis-Philippe Véronneau wrote: This is a proposal for Debian to create a guideline for our TOs when they receive donations of non-fiat assets. It is a result of the constructive debate we had on debian-private, and hopefully it will not be too divisive :) Text of GR Donations to the Debian project of assets other than the TO's currency of choice should be liquidated as soon as possible. End Text of GR For what it's worth, I've asked SPI to sell our current stock assets that we received as a donation. They've confirmed that it will be sold, and it should reflect as such on SPI's next monthly treasurer report. I agree with the gist of your GR, and if it clearly becomes a problem in the future I would second it. Right now I'd really like us to get going with the firmware GR, since there is still time to do something about bookworm (although time is running out fast). -Jonathan
Re: General resolution: Condemn Russian invasion of the Ukraine
Hi Jonathan On 2022/04/08 11:44, Jonathan Dowland wrote: Correct me if I'm wrong, but Debconf is not formally a part of Debian, and so cannot be bound by the outcome of a GR anyway. Due to how DebConf started and how it evolved, and the pace that they had to move on to get things done, they were initially a somewhat separate (but close) organization to Debian. Over the last decade that has changed a lot, and DebConf is now as much part of the Debian project as any other Debian sub-project. We now mostly use the same Debian TOs (unless there's a good reason to add a temporary one for a conf), the DebConf committee is delegated within the project and there's no external setup of DebConf that exists anymore whatsoever. I guess you could nitpick on what "formally a part of Debian" means, I mean, we don't have formal agreements with most teams within Debian, but as far as DebConf is concerned, I wouldn't say it's any more or less a part of Debian than any other Debian sub-project. -Jonathan
Re: Question to all candidates: GDPR compliance review
On 2022/04/01 20:28, Adrian Bunk wrote: Would you commit to something more specific, like that our Data Protection team will reply to debian-project within 3 months discussing all issues mentioned in the discussion at [1] so far, and with their reply having been proof-read by our GDPR lawyer? [1]https://lists.debian.org/debian-project/2022/03/msg8.html That mail asks a bunch of very, very broad questions. My opinion is that it's better to direct specific problems at the data protection team as noodles suggested. -Jonathan
Re: Question to all candidates: GDPR compliance review
Hi Adrian (I'm including the data-protection team, perhaps they can expand on your question or comment on my feedback) On 2022/03/31 22:08, Adrian Bunk wrote: The discussion starting in [1] is about privacy in Debian with a focus on the GDPR of the European Union. It started with the GDPR, in my country we have POPIA, in California there's CCPA, there are now over a dozen similar legislations (and I suspect more countries will be implementing them as time goes by). Fortunately they seem to mostly overlap, so complying to at least GDPR properly should make it a lot easier to comply in the other territories that we operate. When I first read through a GDPR guideline, I was quite happy about it because for the most part, it forces websites to do things that I consider a bare minimum when it comes to the safety of users' data. Personally, I think it would be great if we exceed the expectations of these legislations around the world. There seems to be a general agreement that privacy in Debian falls short of the legal minimum requirements at least in the EU. Even the exact scope of the problem is not clear. Question to all candidates: If elected, will you ask our Data Protection team and our GDPR lawyer to jointly do a review of all handling of personal data in Debian regarding GDPR compliance, and make the results of the review available to all developers? I'm not sure bringing in the lawyer as a first step is optimal, they are expensive and will probably tell us a lot of things we already know. IMHO it's better to do some initial groundwork, compile a list of issues that we need help on, and then take that to the lawyer for further input. I can also think of some examples where we processed user data that you didn't mention. As one example, we used to use the DebConf wiki quite a bit to organize events, and those all got turned into static pages. People who signed up and provided information (potentially contact details, where they were at certain dates, etc) couldn't have possibly known that the data they entered would've been later archived as publicly accessible read-only material later on, well at least not by us. So, I would appreciate it if the data protection team could look into all of the issues we know of in Debian, but I'd also like there to be a process where people can file issues with the data protection team. I'll admit I had to search a bit to find the data-protection email address, it doesn't seem to prominently feature anywhere on our website. But it would be great if it was clear that someone could file a bug with a tag, or whether they should use the data-protection alias, so that it's possible to file and keep track of data protection issues that need to be resolved. So, I think it's more important to take care of known issues and low hanging fruit before getting a lawyer involved. I also think it's a good idea to make it easy to file issues as they are found, and would like to know if the Data Protection team has any ideas or if they would consider implementing anything like the above. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
On 2022/03/30 07:33, Paul Wise wrote: On Tue, 2022-03-29 at 20:47 -0700, Felix Lechner wrote: It furthermore seems that I did not follow the proper process when filing my request, as Paul Wise pointed out. My reference to the Hardware/Wanted wiki page was referring to the procedure for after you have bought hardware, no longer need it and want to pass it on to someone else. Admittedly the page also includes info about posting hardware wishlists, but that section of the page doesn't really apply to your case since it is more for a Debian service, so just buying hardware and getting a reimbursement is a better process, this is documented in the section on hosting, which I've just rewritten to be a bit clearer. Just in case it's still not clear to anyone, the process for approval for an expense is at: https://wiki.debian.org/Teams/DPL/Reimbursement PS: I also just added mention of hardware purchases to the page and uses of Debian money to the MemberBenefits page. I saw the diff e-mail, thanks! -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Richard On 2022/03/24 22:17, Richard Laager wrote: The disbursements that I've heard about seem to be relatively "small potatoes" things. Is there some huge wasteful spending occurring that I've missed? Most of it is small potatoes (typically less than $1000, typically for hardware or travel or meetings). Some are really big potatoes, when DSA does big upgrades it can be 10s of thousands of dollars. The only cases of waste I know of happens when people ask for sponsorship for DebConf and then hotel space is made for them (and possibly other expenses) and then they just don't show up without any heads-up. Even those are rare, but it's the only instances of really wasting any money that I can think of. One anti-pattern I've seen with spending money (not Debian, but elsewhere) is that a group will spend e.g. $10x worth of time debating $x expense. Sometimes that is appropriate, if you're confronting a new class of spending that will be repeated and you need to develop a policy to apply. But often, it's just a waste because people want to bikeshed. Oh I've seen this in Debian. 2 seperate meetings about the price of cups (that could potentially save a few $10) where the collective salaries of the people in the room would be over a hundred times that for one hour. Especially in DebConf people want to save money, and it's great, but I like to encourage them to spend a bit more where it can save a lot of volunteer time, and also where it can increase quality (I consider it wasteful if we, for example, buy a t-shirt so cheap that the only thing someone would want to do with it is wash their car with). In cases like those spending a bit more is using our money more efficiently. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Paul On 2022/03/26 01:27, Paul Wise wrote: We have these documents related to that: https://wiki.debian.org/Teams/DPL#Money https://wiki.debian.org/Teams/DPL/AskingForMoney https://wiki.debian.org/Teams/DPL/SponsoringGuidelines These were written by Stefano Zacchiroli in 2010 when he was DPL, he added the hardware guidelines in 2012 and since then only very minor edits have been made by non-DPL folks. Are there any expenditure requests you have approved that would not fit into the categories listed on the existing expenditure guidelines? They all fit into those guidelines, except for the DebConf20 proceeds that we donated to Framasoft for PeerTube development, that was the one notable exception, this was handled transparently and with consensus, so I doubt that would be a problem. What changes to the existing expenditure guidelines would you make? I'd like it to be a bit more consistent depending on who's DPL. So far I've approved every request unless there's a good reason no to (like if it goes against our guidelines, or against the obligations that our TOs have when working with money). In the past I've seen some DPLs make some relatively small approvals quite complicated, and also denying some requests that I think should've been approved. My goal is also to give a DD more confidence in sending through a request, I often have more work because someone tells me that they need something but then I have to do the work to convince them that it really is ok to submit a request. I want to make it easier for DDs to spend the money that was donated to them to make Debian better, and I squarely disagree with Felix that it should become any harder for DDs to spend money. One thing people have been really concerned about when asking for Debian to buy hardware is, is what happens to the hardware after they're done with it? So far I've just told them that they can try to pass it on to another DD who might want/need it (there's some wiki page for this that I think is rarely used), or sell it and donate the proceeds back to Debian, or just keep it as a spare in case they need it again. But it would be nice to have this in writing. I also make a point of telling people that Debian is /not/ responsible for the hardware. If it breaks or needs maintenance, then it's their responsibility to take care of it (although, they could also submit another request for that if needed). So, in some ways I'd like to make it simpler, but also add some more information, build some more confidence for someone who needs to make a request, and have some more policy that applies to the DPL so that it's more consistent based on who's DPL. And if a new DPL doesn't agree with it, they can also just update it again with a notice going out to the project. -Jonathan
Re: Questions about Debian derivatives
Hi Paul On 2022/03/27 05:53, Paul Wise wrote: Debian's relationship with the various distributions derived from Debian and approach to existing and new derivatives has had a wide range of states. Most derivatives recieve indifference from Debian. When it comes to the indifference, I think for the most part it's because it's just not possible for everyone to keep up with everything that's happening, even in Debian, and so it makes it difficult to know what's going on in derivatives other than what we see in the news. For most people, I think this is more a case of just being busy than being indifferent. Many derivatives, while useful, just isn't that interesting from a DD perspective. When I see a new debian-based distro that enables zfs by default and has a nice web interface for enabling samba shares (just to make up a hypothetical), I'd think "oh, that could be useful for someone" but won't feel much of an obligation to give it a second thought. Is that the kind of indifference you're referring to? Or do we need better interfaces with them all together? There has been animosity from Debian towards some derivatives. We have welcomed the creation of derivatives. We have welcomed developers from derivatives into Debian packaging teams. We have encouraged people to start blends within Debian instead of starting derivatives. I'm guessing that you're speaking about derivatives like Ubuntu and Devuan. I think enough people are familiar with the complexities behind those so I won't go into them now, but are there any specific animosity with a derivative that we could've avoided that I might not know about? What do you think of Debian's current relationship with derivatives? That's of course different for each derivative, each depending on their goals, how they work, how they feel about us and our values, etc. For a derivative like Ubuntu, there's been a whole lot of Ubuntu developers over the years that have also been DDs, which have made some areas of collaboration easier. Ubuntu is also a unique derivative in that we list Ubuntu information in our QA pages (like which version they carry, whether there's bugs filed, patches, etc). We also carry a bunch of ubuntu-specific packages in Debian, which makes it easier for someone to contribute to Ubuntu using Debian. So I'd consider Ubuntu to probably be our most tightly integrated derivative. That's not to say that there hasn't been some problems over the years, but the two projects have vastly different goals, and it's understandable that there would be friction at some point. In terms of relationship status, I think most of the derivatives are similar to Ubuntu in the sense that "it's complicated", and then it ranges all the way to the type of indifference described before. There are some derivatives that really shine: PureOS - debian derivative with nice look and feel and is endorsed by FSF Kali Linux - geared towards various information security tasks, such as Penetration Testing, Security Research, Computer Forensics and Reverse Engineering Tails - portable operating system that protects against surveillance and censorship In terms of relationship with these 3 listed above? I honestly don't know. Relationships with derivatives haven't even been on my radar as DPL for the last terms, not because I don't care, but because there's just been so many things that's high priority. Do you think the derivatives team could do something like host a video call, inviting all derivatives who would like to submit feedback about every 6 months or so? Then at least some more people from both sides could get to know the people on the other side, and likely some problems can get solved too. What would you like to change about our relationships? Well, I'll admit that I'm a bit ignorant on our biggest problems with our relationships with our derivatives. Can I through this question back to you and ask you to share some of your insight and concerns? What do you feel Debian's current approach to derivatives is? I suppose our approach to derivatives is quite similar to our users, we through all these source and binary packages and isos out there and then everyone gets to fend for themselves. Sure, we do have documentation and some support channels, but for the most part there's not lots of hand holding involved. Also, do you think that's a problem? What would you like to change about that approach? One improvement I'd like to see is PPAs. Derivatives tend to fumble about and re-invent package hosting systems, sometimes getting it wrong (like not signing their repositories). It would be nice to have a system where users could host their packages with us in a user repository, and also if we could offer package build infrastructure. It would also be nice to offer some infrastructure to build their installation media for them. All of this might make it easier for them to get started, and also,
Re: Question to all candidates: how is Debian doing?
Hi Lucas On 2022/03/17 17:54, Lucas Nussbaum wrote: As someone who used to care a lot about Debian, but who hasn't been able to pay much attention to the project lately, I was wondering: I don't think anyone would hold it against you that you've got busy with other stuff, having a life outside Debian is also considered very healthy these days. How is Debian doing currently? Excellent question! A few weeks ago I saw a headline "Is Mozilla ok?", and while I've thought about it on different levels for a while, it was the first time that I thought in the exact words "Is Debian OK!?" and mean to write something about it (possibly in a blog post, possibly in a "bits from the DPL" mail), but as with this mail, it ended up in various forms of drafts and I never made it half way with it, at least not yet. So starting with a tl;dr, I think Debian is doing ok. It's not doing great, but it is ok. When we ask how Debian is doing, it's also useful to qualify what we're asking. Is the Debian project (our structure, project members, larger community...) ok? Is the Debian distribution (what features our users need, severity of bugs, are we living up to our promises, etc...) ok? On the positive side, we are chugging along quite well. Packages (and lots of new packages) get uploaded, old crud eventually gets deleted (last release was pretty good in this front), bugs get fixed, since 2005 the project has managed to release every 2 years, the website team has great plans to make the website more friendly (*poke to www team to make some public update please*), we finally have a functioning community team (after some iterations and speedbumps), we now have the fasttrack project (although still quite young) to deal with things that move to fast for our usual archives, we're slowly but surely improving community processes that people have complained about for a while (like our current and previous GR to improve voting). Our finances are also really good, our donors show lots of confidence in us. Our corporate sponsors are already great, but I'm constantly amazed by the generosity of our individual donors! There are people who donate a $1000 at a time, some a few $100 every month, and sometimes even a sporadic $4 donation from the same person. It's all very valuable and appreciated! One person even donated $100,000 worth of shares to Debian (was worth $140,000 when I checked last week) which was extremely generous. Even though we've been spending a lot, our available funds are also the highest they've ever been, last year we surpassed the $1m mark in available funds for the first time. That's great. As DPL, that allowed me to feel comfortable saying yes to every single request every DD has made (which I did, and even some none-DDs. I'll focus on the challenging aspects further down since that is a seperate question. What are the recent successes I might have missed? I'll list just a few things since you got busy, there's probably a lot more. We're getting a bit better at working with industry. We have a person from Lenovo helping out with hardware support on their latest hardware, we just today had a DD join from Microsoft, and Microsoft also covered our LWN subscriptions for the last year (thanks!). There's lots of ways big Linux users out there are helping us out, Hetzner gave us a huge discount on our backup server hosting, Lenovo gave us a significant discount on some servers we bought for DSA hosted stuff, and the list goes on. Our local groups initiative is also taking form again. I can't wait to see more from this, covid put a real dampener on this, but between the Debian reunion even in Germany and DebConf22, I hope there will be some great local team packs made that can be sent around the world well before the end of the year. We've moved from Alioth to Salsa (GitLab instance) in 2017. This created a big leap forward in how easy it is to make contributions to Debian. Since then, Gnome, KDE, and many other free software projects have also implemented a GitLab instance, it's now a very familiar and common way to do things in the free software world, and I think this was a significant and important change for us, even though it came with its own set of speedbumps and challenges too. We've gained a riscv64 port. Along with the lowrisc project to make a fully open source CPU, it opens up the possibility to have a truly and fully free hardware and software stack using Debian. It seems like it may still be some years before you could easily buy a phone/e-reader/router/laptop/desktop/server/etc with a riscv64 cpu that can run Debian, but the foundations are being laid, and I consider that critically important. Hardware is increasingly being locked down, and we don't know how long it will be before you have to contact your manufacturer in order to get an unlock code in order to install an alternative operating system on a typical laptop (as
Re: Question to all candidates: Ongoing/future legal projects
On 2022/03/25 11:41, Jonathan Carter wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. That's odd, I usually approve them fast (as in, within 24h) because it's a quick and trivial mail, but I can't find your request in my reimbursements folder at all. I'm in meetings now but will take a look later on if it reached the dpl-archives at all. It's not in the dpl mail archives either (nothing from you in November, no request nor a follow-up). I even checked the rest of the year, mails from you on other topics in other months are there though. I've asked the treasurers to check if they have seen your request too, but from what I can tell in my local folders and on the leader@ archives, it doesn't seem that your request ever reached me. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Felix On 2022/03/25 02:18, Felix Lechner wrote: For example, I requested $217 for a one-time SSD & RAM upgrade to help operate lintian.d.o in November of 2021. My request was not granted. I didn't even receive a response from Jonathan (other than a request for more information, with which I complied) even though I followed up on my request. That's odd, I usually approve them fast (as in, within 24h) because it's a quick and trivial mail, but I can't find your request in my reimbursements folder at all. I'm in meetings now but will take a look later on if it reached the dpl-archives at all. My idea for a Disbursements Committee was thus born by a simple desire for greater accountability (or, at a minimum, a response). Plus, if elected, I could never issue that $217 check to myself. I disagree about some of your previous statements to make it more difficult to spend money, I still want to work towards having an expenditure policy, which I still hoped to finish the last month or so, but there was just really too much going on. The idea would be that there's some clear document that makes it really easy for someone to know whether they can apply for something or not, and I think if it hits a few checklist items that makes it a braindead yes, then we shouldn't even require DPL approval. So, I would go for making it even easier to spend money than not to. During my 2 terms we went from having around ~$750k in available funds to having about ~$1.25m now. Every time I mention what we've been spending on (like DSA upgrades, hardware for DDs, etc), we get more donations. As long as this is the case, I have no problem with DDs spending any money they want to if it helps them make Debian better. After all, this is literally the only reason why someone donates money to Debian in the first place. So, I don't believe that the Debian funds should be preserved like some kind of treasure. We should make it as easy as possible for people to give us money, and as easy as possible for DDs to spend money, all within our legal and social frameworks, of course. As for your question about "huge wasteful spending," yes, I do worry about Debian's expenditures in light of Jonathan's comment that he is happy to "give a lawyer a lot of money." [3] Happy is a loaded word that you chose there. If I have to spend money on lawyers to protect the project and its members I will do so without hesitation. I'd /rather/ not have to spend that at all, and find it disappointing that you would even hold that against me. I have worked with teams of lawyers. They get expensive fast. Well, at least there's one thing we agree on. Either way, the right person to address your question is Jonathan, whom I copied as a courtesy. Jonathan ran on financial transparency platforms in both the 2020 election [4] and again in 2021. [5] Besides the updates I've sent out on our financial status every few months, that's not something that will get better soon in the next term. That's to no fault of me (or a next DPL), I've had a bunch of meetings with the treasurer team and TOs to talk about this, and there's a lot of things that need to be fixed along the way in order for us to get the accounting that we need. I'm sure we'll get there. Our TOs have indicated that they are willing to switch accounting systems, use the same expense codes, etc to help make it easier to aggregate data much faster (as in, possibly even almost real-time). That's a whole rabbit hole on itself, but I do believe having a basic incorporation of Debian, along with better agreements with our TOs will be a good starting point to get our financial reporting on the standards that we want them. -Jonathan
Re: To all candidates: Debian and people with disabilities
Hi Sam On 2022/03/23 06:04, Sam Hartman wrote: This has gotten much much better. * You can hold down space bar in orca focus mode, when you release, you know you will be muted. (push to talk key) * The accessibility of the icons is much better. The buttons are "pressed" when muted and this displays through to orca. There are still a few things that are not perfect, but Jitsi accessibility is on par with Zoom and Teams from my standpoint these days. That is great to hear, thanks so much for the feedback, I'll feel a little less guilty whenever I invite an orca user to a jitsi meeting now, thanks! -Jonathan
Re: To all candidates: Debian and people with disabilities
Hi Devin On 2022/03/20 19:09, Devin Prater wrote: * Have you heard of the Debian Accessibility group? I have indeed. * If so, have you worked with them in the past, or are you currently working with them? I haven't directly worked with them directly, but I have been on the receiving end of criticism (and it was completely valuable and useful and valid feedback) on things that I did. Most notably, I received some very angry emails when I added the Calamares installer to our Debian live images. It introduced some horrible accessibility bugs because Orca couldn't see the Calamares window (iirc it was some combination also of Calamares being a Qt app and apps under Wayland not being able to peek at other windows), which made it quite useless for people who are blind. The situation has gotten a bit better, but it's still terrible. I also have lots of ideas I'd like to implement for accessibility, specifically in installers, but that's also a rabbit hole that doesn't quite address your questions at this point. We also have a few other DDs who are blind or visually impaired to some degree which brought some more attention to things that I've implemented that are terrible in terms of accessibility. I installed a Jitsi server for Debian (it's a system for making group video calls), and was really proud that we had this... until we had some blind people join some calls and learned how utterly inaccessible it is. For example, you can toggle your mic or camera (there's no way to set it as either on or off explicitly) and then you have to be able to see the mic or camera icon on your screen in order to tell whether those are enabled or not. I think in our case our DDs went ahead and checked the status in the javascript debug console to find the variables and their values... and I'm proud of them for being so resourceful, but totally embarrassed that we needed them to do that in the first place. On the bright side, video chat software has been good at raising funding during covid, and these issues are filed upstream, so I hope that jitsi gets a lot better and makes it a lot easier for people with visual disabilities to join video calls and participate in our community in the future. * Currently, Debian backports is how people with disabilities can get the most up-to-date accessibility fixes and improvements while remaining on a stable base system. For example, the newest version of the Orca screen reader, with all of its fixes, and newest version of ATSPI, the thing that makes Orca able to talk to applications. Would you be willing to entertain the idea of moving those updates directly to Debian stable? To be fair, it seems like a very valid use of backports. Is the main issue more about the hurdle of enabling the backports repository, or about issues like the level of security fixes available for backported packages? * How would you present Debian to a group of people with disabilities? What reasons would you give them for why they should consider Debian I would present it to them warts and all. I'd cover why I believe Debian is important, explain our problems, and explain how we want to be better. Some people in such a group might decide "nah, it's not worth the effort", but some might decide that it's at least worth while to try out it out, even if only in a VM, and might have the skills to submit bug reports or even get involved. Some things that seemed like tiny bits of feedback have made some important changes in the past (like losing a beep on live media when we use GRUB (for UEFI) instead of isolinux). I believe we can benefit from a lot more feedback, but it's also a question of priority in the project when it comes to dealing with such feedback. * In many desktop environments, a user cannot use their assistive technologies effectively unless they find and check a box enabling the use of assistive technologies. Do you think that this is good and fair to users? At DebConf15, I attended this talk from Samuel Thibault: https://peertube.debian.social/w/9hoptcMQiPsmJrb2fbRvxW Even though it's now a few years old, I can recommend that to anyone reading here who aren't very familiar with accessibility issues in Debian. The way he describes Debian as being in the stone age compared to Apple in terms of accessibility (where accessibility is always just a few buttons away) has convinced me that users should only have to do the bare minimum of effort to ever enable an assistive technology. -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
On 2022/03/18 20:08, Felix Lechner wrote: Which would you be prepared to provide as DPL? > Whichever the members perceive as proper. How would you gauge that, Felix? It's impractical to have a vote every time a decision is to be made, which is why voters want to know how a potential DPL would make choices so that they can make an informed choice on who to vote for. Even if you end up setting up that army of committees (I can't imagine all the bureaucracy that will come with), you would still have to make frequent decisions unlikely covered by those committees. So, again, how would you gauge what project members perceive as proper? -Jonathan
Re: Question to all candidates: Ongoing/future legal projects
Hi Molly On 2022/03/17 16:57, Molly dB wrote: In November 2021, it was discussed in debian-private that a team from Debian had been working with a lawyer for a while. (Not sharing details: issues remain ongoing.) How would you transition into taking on this particular responsibility and similar longer running issues should they arise in the future. One of the reasons that a small team was put together was so that I wouldn't become the single point of failure on that project (for lack of better word). Also, it turned out that the legal work around it was much hairier and involved than I had previously anticipated (I has hoping we could just give a lawyer a lot of money and they could deal with it, hah!). So, going forward, the other people working on that team would likely still be available, and there's a git repository that contains a lot of evidence complete with a timeline that links to all the individual bits, and I'm willing to stay on the team at least until the incoming DPL (assuming it's not me) is comfortable enough for me to move on from there. Having said that, we've been making some large strides and we are likely to hit a significant milestone even before the DPL elections start, so hopefully by the time the elections are done there won't be too much work left on that. So in this case I think a transition won't be a particular problem, and I think for future long-running projects a bit of planning and documentation always helps. -Jonathan
Re: Question to all candidates: rotation on positions of power
Hi Charles On 2022/03/16 14:28, Charles Plessy wrote: thank you for running ! I have a question for you (and only you). Yay, thanks for the question! What do you think of the reform of the Technical Committee that introduced a limit to the time people can serve in, and would you consider applying a similar policy to other positions of power in Debian? For the Technical Committee, this seems to have worked well so far. Currently all the Officers in Debian (not sure if that would fit your definition of people in power) do have expiring terms, DPL and and Secretary are both annual, and CTTE as per your example (Officers are listed out on https://www.debian.org/intro/organization) I also think that when we re-structure DAM and CT (or whatever form that will take), that they should also be brought into the officers section. Should we vote for the members that fill the role that DAM/CT fills now? I can't give you a concrete answer there, but at least if we as a community don't approve about how well someone performs on there, then we're not stuck with them forever. For DAM/CT I think we'll have more answers once we've spent a lot more time on this topic. For some teams with lots of power, having a strict term limit might also be a bad idea, since you sometimes really want the skills of the people who have been around for a while. For this, I really like the FTP Masters do, they seem to be the only delegation who have different tiers of members, ie. FTP Masters, FTP Assistants and FTP Wizards. The FTP Wizards seem like a good way to keep some valuable people around for their historical knowledge. So to answer your question on whether I would consider applying a similar policy to these other positions, yes, certainly! I think expiry is one of the available tools we can use to make teams/delegations better. Voting is another, and tiered memberships yet another. There's probably a lot that we can explore, but I don't think this is best driven by the DPL, it needs to come from the teams and from the project members. Unfortunately, after two terms, I think any prospective DPL who thinks that they'll have time to actively drive all of this by themselves is in for some disappointment. So to further answer your question, I think we need some cultural shift to spend some dedicated (ideally in-person) time on project structure and procedures, so that DDs who care about various topics can come up with suggestions and then either the DPL rubber stamps it or we have a GR where necessary. To some degree I think this is happening, we're just in our second GR in recent months to make changes to our voting process, and we have a somewhat understandably (considering how much is happening right now) stalled discussion on the future of DAM/CT too, which I'm sure will pick up again, for those teams, I think that's the right time and place to figure out something that would work as best possible for everyone. I'm sorry for being a bit long-winded here, if it doesn't answer your question, then please shout :) -Jonathan
Re: Question to all candidates: Monthly "Bits from the DPL"
Hi Louis-Philippe On 2022/03/16 20:12, Louis-Philippe Véronneau wrote: I would like to know what is the stance of the 3 candidates on producing monthly "Bits from the DPL" reports on their activities. I like them very much and I think they are a great way to keep us all informed of what the DPL has been doing. They do take time to produce though and some DPLs have preferred to write less frequently. I like them a lot too, and especially enjoyed the concise and punchy reports that zack and lamby wrote. And I guess this question might also be aimed at my total lack of releasing those. That's not a lack from wanting to, and in my last campaign I even committed to try harder on that front. The reality is that this is really difficult for me, I'm myself constantly information overloaded and the amount of incoming stuff just doesn't end. For smaller items this isn't so hard. Issueing a DD certificate here and there, approving some expense requests, updating a delegation, welcoming new DDs, attending meetings for various teams (like treasurer, DAM, CT, etc) or for external meetings, outreach administration, etc isn't too hard, but often not all that exciting on it's own (I have split out the welcoming of new DDs to mails to -project, at least). Also, things like approving sprints and upcoming DPL talks has just really been stunted by the pandemic. These used to make up quite a bit of the bits from the DPL, but... urgh. But the biggest problem by far is that the most time consuming stuff is the hardest to write about. Dealing with all the many inter-personal issues that occur takes a lot of patience and listening, and progress is really slow, and on top of that it's difficult to write about or summarize. I probably *could* just add a line every month "Deal with inter-personal issues" but it would be pretty boring. The same goes for the legal stuff we're working on. It's tedious and boring and lots of work but at the same time, not a lot I can really say publicly. So, yes, I really like Bits from the DPL, I'd probably do better if someone could help or give me a regular poke to put together some updates for it, but after having a very real and sincere goal to improve this last round and failing, I really can't give a hard commitment for this. Sadly though, I've often given long updates to people on IRC and thought "this would actually be great for a bits from a DPL post" and then quickly get distracted... so, if I do get elected for another term, feel free to remind me every now again and I will give it another shot. -Jonathan
Re: Debian Project Leader Elections 2022: Call for nominations
Hi Kurt On 2022/03/05 01:15, Debian Project Secretary - Kurt Roeckx wrote: Please make sure that nominations are sent to (or cc:'d to) debian-vote, and are cryptographically signed. I'll be standing for another term. -Jonathan OpenPGP_signature Description: OpenPGP digital signature
Re: Informal Discussion: Identities of Voters Casting a Particular Ballot are No Longer Public
On 2022/02/14 20:42, Felix Lechner wrote: Based on the way people with minority opinions are treated, you would have to expel a lot of people. Which people with minority opinions were mistreated? We're a group with a very, very large spectrum of opinions and so far it's only been in the extreme cases that there's been taken any action on them. -Jonathan
Re: Diffs for GR: Change the resolution process
On 2021/11/27 03:34, Russ Allbery wrote: Here is a Salsa diff with the current version of the constitution: https://salsa.debian.org/rra/webwml/-/compare/master...gr-2021-003?from_project_id=65952 Thank you! I've been meaning to do this for a while! -Jonathan
Re: Waiting for the voting vote to finish... :-)
On 2021/11/23 17:59, Steve McIntyre wrote: would you be willing to let peb and I propose the secret ballots GR? We were hoping we were in line behind Russ. > Sure, no worries. Ah, I also had one, but can wait my turn. I considered starting a thread in -project in the meantime, but I'm slightly concerned of information overload between a large discussion on -project and a running vote. Not to complicate things further, but perhaps some additional co-ordination of upcoming votes might help (assuming that's even possible)? -Jonathan
Re: Renaming the FTP Masters
On 2021/11/11 21:48, Bastian Blank wrote: I'm really surprised that ftp master is more important than the weird definition of DD and DM. You left out "non-uploading DD" :) -Jonathan
Re: Renaming the FTP Masters
Hi Marc On 2021/11/11 17:29, Marc Haber wrote: On Wed, Nov 10, 2021 at 05:37:55PM -0500, Daniel Kahn Gillmor wrote: PS For people who are concerned that a retreat from the term "master" is somehow the language police run dangerously amok, it's worth asking why you feel so committed to the term "master" that you would fight to keep the project we all work on using terminology > there might be people who would oppose the change not because they're comitted to the term "master" but they feel that we have darn more important things to do - for example re-gaining technical excellence and leadership. We haven't been concentrating on technology enough in the last years. Well, I would tell these hypothetical persons that you're concerned about that technical excellence and project maintenance go hand in hand, and that you can't have one without the other. On the scale of how large a project change is in terms of changes that we need to make in Debian, this one is really on the smaller end of the scale. There's a lot of work that I've been wanting to push, but I've been patient because we had the release this year, then DebConf, now we have a GR about GRs, and it is probably starting to sound that I'm complaining about these, but I'm not, it's just that making changes- especially changed in Debian, takes time and patience, but they are necessary, and they do not need to block technical work. We do have some serious project-level maintenance backlog, part of my DPL campaign for this year was to help address that. We didn't explore that in too much detail during the voting period, but I do expect that we'll have quite a few decisions coming up that will be significantly more complicated than a team name change, and I hope that we can figure out ways to make sure that everyone is heard and that we don't impede on anyone's work while figuring it all out. But we have to try, we cannot allow project rot to just continue and risk it spreading into other areas. -Jonathan
Re: Renaming the FTP Masters
Hi Joerg On 2021/11/04 23:14, Joerg Jaspert wrote: I would like to rename the FTP Masters team—ideally via a General Resolution. Ideally? Its the worst possible way to go about. I'm at a loss to actually find polite words to describe how off it is, That might be slightly harsh, Felix only became a DD last year, it takes some time to learn not to go for the biggest and bluntest hammer first. Also, changing the name is Step 1 only and if we leave it at that, quite pointless. Getting it all changed will take quite a while longer (start with hostnames for example). *nod*, although I don't see harm in starting with just a team name change. It doesn't have to mandate immediate changes everywhere else. The next step would probably be to file bugs for everywhere the name occurs with some tag and then track that, but I wouldn't want to force a surge of work because of this change. Starting with the delegation and then taking it one step at a time from there seems ok. -Jonathan
Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result
On 2021/04/18 23:36, Bernd Zeimetz wrote: > Complaining about the > voting system because you don't like the outcome or because you could > announce the outcome in an awkward way is not helpful. Who complained about the voting system because they didn't like the outcome of this particular vote? I've literally not seen one instance of that. -Jonathan
Ways forward regarding the RMS GR
Hi Debian Developers Over the course of the last few days, I've received many mails regarding the RMS GR, both on this list, on debian-private and in private. These mails contain a wide spectrum of concerns and even ideas on how to improve our situation, each of which come with their own set of upsides and downsides. There's been wide acknowledgement within our community that our GR process isn't perfect, and there's been some good ideas already that could help improve it, some might even need GRs themselves to update our constitution towards a better GR and/or voting/polling process. In this particular case, I feel that the process is more than just imperfect, and that it may be failing us. While it's premature to do a full postmortem on this GR, it's already clear where some cracks have formed early on. Initially, the RMS open letter[1] contained a list of individuals supporting the removal of RMS and the existing FSF board from their positions there. Soon after, some organisations were added and the list of organisations grew quite fast, begging the question for some: Should Debian also sign this letter? [1] https://rms-open-letter.github.io/ At this stage, many Debian Developers (including myself) have signed the letter. I felt that this was both sufficient in terms of a Debian presence there, and in terms of what needed to be achieved with such a letter. While I'm not scared of making a unilateral statement on behalf of the project when needed, at the time, I just didn't feel it would be appropriate for the DPL to unilaterally add Debian to the list of organisations there. Members within the project felt that we should represent Debian on that letter more formally, and whether it's the best tool or not, the only tool that we do have for that is the GR process, and it didn't take long for the initial proposal[2] to be sent and be seconded[3]. [2] https://lists.debian.org/debian-vote/2021/03/msg00083.html [3] https://www.debian.org/vote/2021/vote_002#proposer Now, I know and acknowledge that the circumstances we find ourselves in here are a bit extraordinary, but, even within that context, what happened here so far was perfectly in accordance with our constitution and the processes it mandates. The project members who wanted to ratify the letter followed the exact procedure they were supposed to. Although, this is also when the cracks start appearing. It seems that in both this vote, and some previous GRs that have happened, it seemed that a lack of metadata on the GR has hurt us. In this case, what we're voting on has seemingly subtly, but significantly changed since the initial proposal. Initially, the question that the original GR proposal raised was more or less binary in form. It basically asked, "Should we as a project sign this letter?", which ultimately, can only end up as a yes or no option. I say "more or less" binary, because of course, it ends up being more complicated than that. If that option ran by itself, we'd end up with an option on the ballot for the affirmative of the GR and for FD (Further discussion), which in itself causes some problems, since some might literally want further discussion on the topic, while it is also typically used as a "None of the above" option in votes with many options. I was comfortable reducing the discussion period on the vote, especially since the question it poses is relatively simple (even though it might be a difficult choice for some to make). I thought that there might have been another option proposed option for the GR, so that the votes would extend to the equivalent of "yes/no/FD", but didn't quite expect that there would be additional proposals that would change the nature of the GR. So to recap, initially the GR proposal was to ratify the RMS open letter, which is basically (albeit with caveats) a yes/no question. With the addition of more proposals, the question that the original poster was asking, "Should we signed this open letter" changed to a much broader question of "What should our public position on RMS be?". It might sound like a subtle difference, but it's really an entirely different kind of vote that may need a different kind of discussion period and even a different level of timeliness. At this point, I'd like to state that I'm not blaming any individual involved with this GR whatsoever, for the most part, everyone did what they were supposed to do or what they could do to get their voices heard, my problem is that this process is really a clumsy fit when it comes to nearly any decision other than constitutional changes or a DPL election. The privacy aspect has brought another dimension to the problem. There are concerns that some might not vote because this vote will be public, and might open themselves up to further real-world harassment. Unfortunately, our constitution doesn't seem to provide us with any tools to deal with this, I don't think the authors at the time could have anticipated the current social climate
Re: REPOST, SIGNED: Re: Amendment to RMS/FSF GR: Option 5
Hi Tina On 2021/04/08 06:15, Martina Ferrari wrote: > Ah, Adam, sending unsolicited private email? Fuck that, you were in the > first line on my bingo card. Personally, I would've ignored an unsolicited post like that and deleted it. Not that I'm telling you that's what you should've done, but you don't have to feel responsible to reply to everything that lands inside your inbox. On a broader level, please don't forward private mails to public lists, it's bad behaviour that we should really stomp out within Debian. If you receive a mail that happens to be abusive, please rather forward it to CT and DAM rather than giving someone the exact type of attention that they might have been seeking in a public forum. thanks, -Jonathan
Re: Cancel "culture" is a threat to Debian
On 2021/04/01 17:57, Sergey B Kirpichev wrote: > On Thu, Apr 01, 2021 at 04:50:15PM +0200, Pierre-Elliott Bécue wrote: >> The first option is one option, the others are different and less >> strong. Having strong options in a GR doesn't turn the whole GR in a >> blackmail > > I would disagree. Especially, given that the first attempt to > "sign on behalf of the Debian" - was without a GR at all. That's simply not true. No one who has any authority whatsoever has attempted something like this. The first I've seen of any formal move to make an official contribution to that document on behalf of Debian was in that GR. -Jonathan
Re: New option for the RMS/FSF GR: reaffirm the values of the majority
On 2021/04/04 05:47, Matthias Klumpp wrote: > I did actually read this as satire and was quite amused by it - I > didn't think it could have been read as a serious request until the > first response to it. I would appreciate it if we could keep satire and comedy a bit dialed back for a but. As much as I appreciate satire and comedy, there is a place and time for it, for example, you wouldn't practice your stand-up routine at a funeral for a loved one. Also, there are classes of humor that's really just not appropriate, and on top of all that, many of is in the project are suffering from huge information overload. That is, we have a backlog of information that needs to be processed, some which will also affect the choices of both votes currently running. Adding more noise that is difficult to filter and interpret is something that I consider somewhere on a spectrum of insensitive to reckless. So, I'm please asking again that posters to the list attempt to be more mindful of what they consider to be humor to the list and the effects it may have on others before doing so. -Jonathan
Re: Having a "DPL committee"?
Hi peb On 2021/03/26 20:54, Pierre-Elliott Bécue wrote: > I wonder in that case if such a person sould be either: > > 1. Nominated by the DPL > 2. Co-elected (ie voting for a couple of people) > 3. Elected separately on the same time frame (but that could lead to > issues if the DPL and vice-DPL fail to get along together) I was wondering about that too. I saw some DPL candidates in the past mentioned that they wanted a vice-DPL and iirc even named them already as part of their platform. I suppose that since this cycle is already in progress it probably only leaves #1 as an option for the DPL of the next term. I'm not sure if Sruthi would be interested in being vice-DPL if I get elected but I would also be happy to serve as vice-DPL if Sruthi would be elected. -Jonathan
Re: concern - proprietary software promotion in Debian
Hi Pasha On 2021/03/26 20:29, Pasha wrote: > I saw some people are sending github links to promote their cause. > > github is not a free software. It a proprietary service owned by a > company. > > My question is depending on the side a developer choose he has the > right not to use any proprietary software. right ? > > I saw in some forums discussin they are using discord beside github. (I > am not 100% sure - because I did not check or read details.) > > If it is true, how is it possible people are using non-free software > and proprietary communication to decide who should be in fsf board or > not ? > > I feel the developers are supporting this cause are forced to signed up > for proprietary software/service. > > Please, understand this email is about the software/service not the > cause. > I dont want to discuss about your personal opinion here. > > I would be happy to see Debian has some policy for discouraging > proprietary software/service for other developers. > > I have full respect for all Debian developers regardless of their view. > Thank you. I agree that using GitHub for that was in poor taste. In Debian we rely as far as possible on only free software, however, the letter you refer to were set up by people outside of Debian so we didn't have any choice in how they set that up. -Jonathan
Re: Amendment to rms-open-letter GR
Hi Sean On 2021/03/25 22:17, Sean Whitton wrote: > The point of this is not to call for the removal of the entire FSF > board, as the open letter does, while still supporting the main thrust > of the open letter, which is about Stallman himself. > > The vote to restore Stallman to the board was not unanimous, and there > is some confusion about how the procedure for elections to the board > actually works, so the call to remove *all* board members does not make > sense to me. And the FSF is going to need people with experience to > help it recover from this whole affair. > > There are probably others who think similarly to me about the call to > remove the whole board, so this amendment gives them something to vote > for in preference to just signing the open letter. It's an alternative > rather than a rival. > > I see that some people have raised concerns about the appendix to the > open letter. I haven't formed an opinion about that myself yet, but > perhaps this amendment could be something for such individuals to vote > for, too. I'm not sure I like this. I believe that removing the board is a critical part of the letter. They are 4 friends that RMS chooses that he chose because they never appose him. They are not elected by members of the FSF but a self-selected cabal. I'm not sure what the plans would be if the board would actually resign, clearly RMS and the board have no intention of doing so[1] (at least by their choice of language in that announcement), but ideally the board would be selected by the community and be held accountable by them, currently they answer to no one and let RMS do whatever he feels like without consequences. [1] https://www.fsf.org/news/preliminary-board-statement-on-fsf-governance -Jonathan
Re: How to motivate contributors to work on QA
Hey Christian On 2021/03/23 11:42, Christian Kastner wrote: > However, looking at this from the other side of the argument, I still > believe that relying on pure volunteer work has significant downsides to > the quality of our distribution, downsides that IMO could or should > easily be avoided by a project that receives non-negligible amounts of > donations (some of which, I assume, were given precisely to maintain and > improve the its quality). > > I'd like to give you two concrete, specific examples where I think that > pure volunteer work meets its limits, bothr related to QA work. Insofar > as you agree with me on these examples, I'm interested in hearing your > suggestions one what you, as DPL, could/would do to address these examples. > > [I'm clearly biased towards financially motivating developers, because > that's what I believe some of the donations are intended for. At least, > that's my motivation when I donate to other FOSS projects. But I'm > interested in hearing any form of solution.] > > > Example #1: Orphaned/RFA'd packages > ~~~ > Orphaned packages are packages that, by definition, no one is interested > in maintaining. There are no volunteers willing to commit to them. > > However, some of these packages are important to the Debian ecosystem. > For example, schroot is a key package for our infrastructure and for > many contributors, yet it's been orphaned since 2018. Other orphaned > packages are less visible directly, but may have dozens of affected > reverse dependencies. > > I think it's fair to say that RFA'd packages are closely related to this. > > > Example 2#: Undermaintained packages, especially in stable > ~~~ > > This is something that every contributor, including me, can probably > relate to. > > There are some packages that have a maintainer, but that maintainer does > not have sufficient time to devote to the package, sometimes to the > point where filing a bug is pointless. > > Some of these issues can be fixed by NMU. Many aren't. For example, I > think the share of non-DSA security issues and important bugs that can > be fixed in stable could be much larger, but that's quite a bit of extra > work compared to fixing something in unstable. > > [This is *not* intended to be a shaming or something. I myself have been > in the position where for personal reasons, I simply had zero time for > Debian, and didn't even read my Debian account mail for more than a year.] > > Addressing these two examples would clearly make Debian an even better > product. And I say this not as a contributor, but as a user who is > frequently affected by the above two examples. > > My question to you is: If you share my view that the above two examples > are significant problems, what could you, as DPL, concretely do to > address them? I mostly share your views, which doesn't leave too much for me to write :) I think Raphaël's Freexian initiatives will help address the two points you mention. I also think it would be ideal for either Freexian to register an additional non-profit to handle these kinds of funds/projects, or even for Debian to do so. But if you're asking for concrete things that I would do as DPL for this over the next term, that's really difficult right now since I don't want to make more promises on top of my existing ones. It does seem that the support to pay for at least some types of Debian work is larger within our community than I have previously thought. At the same time it seems that the demand for money for hardware is really low, it seems that our developer needs are completely met when it comes to hardware, so maybe we should consider spending some money for hours on some projects. I'd be willing to initiate some framework and discussion on this on -project in the next term, because we tend to decide things like this together in Debian and not top-down, I think we could also have some video call sessions in jitsi to discuss things like this and perhaps out of there we can generate some concrete steps to take that works for everyone in the project and our users alike. -Jonathan
Re: Question to Jonathan: What did you Mean
Hi Sam On 2021/03/25 17:58, Sam Hartman wrote: >>>>>> "Bart" == Bart Martens writes: > > Bart> On Wed, Mar 24, 2021 at 11:53:23PM +0200, Jonathan Carter wrote: > >> On this particular issue, I feel it's better that individual > >> developers go and make their voices heard. > > Bart> Thank you Jonathan! I really hope most DDs feel the same way. > > > Jonathan, it sounds like Bart is interpreting your text above to mean > that you don't think Debian should adopt a GR supporting the open letter > that you signed as an individual. Hmm, I don't see Bart inferring that anywhere in that e-mail, how do you get that from his response? > First, is Bart's interpretation of what you said correct? If that's indeed his interpretation, then not quite. > Second, if so, why? In just two days, we've shown tremendous support from project members in that petition, and it was completely spontaneous. There's over a hundred results if you search for "debian" in there currently, with 10 of them being people who have served DPL terms. I think that already speaks loudly, and it happening without any co-ordination or planning shows the world that those of us who signed it there wants this to happen, not that I want to bring in political terms into this, but it has good optics for the cause. If we have a GR about this, I'm very confident that it will pass, but I'm pretty sure it won't be unanimous, if we have a vote about it just to have Debian up there on the list, it might end up looking worse if 20% or 30% (or whatever) of our members voted against having it there. And, it's entirely possible for someone to agree with that text without thinking that it's appropriate right now for the project to sign that statement. As I've also said in the rest of the mail that Bart replied to, I will not stand in the way in the GR and will respect it's outcome. I don't yet know how I would vote in such a GR, I'll likely even vote in its favour, but I believe that our individual voices on that page will be more effective and a better use of time than having a GR to get the project name on there, I know others will feel different and I'm comfortable with that. -Jonathan
Perhaps we should start addressing shortcomings in our eco-system (Was: Re: What changes do you want in Debian?)
On 2021/03/19 11:13, Raphael Hertzog wrote: > 1/ Why have you all given up on the idea to lead Debian? This question still bothers me a bit. Firstly, I don't see my previous term or my upcoming term that way. I believe that considering the climate in recent years in Debian, and considering all the chaos in the rest of the world over the last year, the work I did on stabilization was the right way to spend my time and I don't regret that. I think if I do regret one thing (and this partially addresses the question posted in a mail[1] I might not have gotten previously due to a possible spam setting problem), it would be not communicating more properly. My plan was to set up a DPL blog and have more frequent updates than a monthly blog. Unfortunately, that didn't quite work out. I'll work on a strategy to fix that even before this term ends. I think that a combination of microblogging and summarizing them in larger posts for planet debian might work better. At the same time, I tend to be close to action where things are happening, I think many teams would be able to confirm that. Not everything in Debian happens in mailing lists. [1] https://lists.debian.org/msgid-search/68069c3f-b03b-4958-f950-6da5a02de...@freesources.org But I digress, I think even as Debian we can be more ambitious in the way we lead. I'd like to talk about the Free Software Foundation first. They've been a disappointment to me for a long time. At one point I were a very active FSF member, I followed the mailing lists where RMS and other FSF organisers would post links to misinformation out there and I'd actively go comment and correct things along with other members, I was also one of the top referrers of their affiliate program. I was invested in the Free Software Foundation and I trusted them and I realised how critical their role was not only in the software world, but I'd go as far as to say for the advancement of our species since free software is so incredibly critical when it comes to leveling playing fields in business, human rights and more. Even though I admired what they stand for, I was dissapointed in how they do things. Explaining things like source code and software is already difficult to the average user, but their campaigns are often just weird and sends mixed signals. For example, the windows7sins campaign painted Windows 7 as this thing of pure evil that should be avoided at all costs, often using terminology to explain it that likely only people would understand that have been involved in software for a long time. Anyway, then last year they have another campaign to release Windows 7 as free software, and the messaging makes it seem like Windows 7 is this precious piece of software that deserves saving and that we should all rally together to spend time on energy on that campaign. At the same time, they seem to do very little for some of the biggest actual issues that could do with campaigning. In Debian, non-free firmware is a really big problem for us. It pushes us in the corner where we either have to release installation media that won't work outside of the box for a significant percentage of users, or we have to go down a potentially slippery slope and consider having something like a firmware repository that's enabled by default. And trust me, it really irks me that an official Debian Live image will never work on my very own laptop because it needs the firmware-amd-graphics package in order to initialize my graphics. The issue comes up often and really, I applaud the people who actually work towards some solutions to this rather than just complaining about it. At the same time, the FSF is really harsh towards Debian. On their page explaining why they don't endorse several distributions, they write more paragraphs about why Debian is bad than any other distribution on that list (and this is a list that includes Red Hat, SuSE and Ubuntu... yikes). To the average person unfamiliar with all these distributions, it gives the impression that Debian is by far the worst offender of software freedoms on the list, ironically, they've even admitted that it's probably by far the best for software freedom on that list, and yet they refuse to fix that page. I've asked them to do so many times, even once when 2 FSF staffers asked for feedback in an FSF session at DebConf. They are just not interested. I think the FSF could spend their time better. Back in 1998, the OSI did a pretty good job of lobbying at Netscape to release their browser suite as free software. We need that right now for firmware more than we needed it for anything else than a browser since 1998. The FSF seems to be spending zero energy on this. If I could decide for campaigns for the FSF, I'd put together materials and go directly to chip makers and spend time discussing benefits of free firmware to them and how the benefits of releasing free software very likely far outweighs the benefits of keeping it closed. Also, once you have a few chips that
Re: General resolution: ratify https://github.com/rms-open-letter/rms-open-letter.github.io
Dear project secretary On Wed, 24 Mar 2021 13:54:16 -0700 Steve Langasek wrote: > Under 4.1.5 of the Constitution, the developers by way of GR are the > body who has the power to issue nontechnical statements. Due to the timeliness of this GR, please reduce the discussion period for this GR to one week. Thanks, -Jonathan, Debian Project Leader pgpD_j4_fBdYG.pgp Description: OpenPGP digital signature
Re: Asking DPL to shorten Discussion Period for rms-open-letter
On 2021/03/24 23:19, Sam Hartman wrote: > I suspect that the issues surrounding the open letter asking rms to step > down and for the FSF board to resign are fairly well understood at this > point. > It's been an ongoing issue. > > I don't think we're going to get much benefit out of a prolonged > discussion, and I think that there is significant benefit in acting > quickly in this instance. > So, I'd like to ask the DPL to consider shortening the discussion > period. > > It's possible that circumstances may arise requiring more > than a week's discussion. > But unless that happens I think we would all be happier spending less > rather than more time on this issue. > I suspect most people already have their minds made up. If Steve, as proposer of the GR is comfortable with shortening the discussion period to one week, then I will use the DPL powers as per section 4.2.4 of our constitution to enact that. -Jonathan
Re: Willingness to share a position statement?
Sorry, for some reason I didn't get Gunnar's original mail so going to reply here... On 2021/03/24 02:24, M dB wrote: >> https://opensource.org/OSI_Response >> https://rms-open-letter.github.io/ >> >> Now, as for my question: I thought repeatedly over the last couple of >> days whether to start something like this in Debian... But, what would >> it take for the project to issue a statement in this line? Would we >> have to pass a GR? Well, a GR has been presented and seconded, so let's see how that unfolds! >> I am sure there is a precedent of a position statement being announced >> without having a formal vote about it, but I cannot find it at the >> moment. Sruthi, Jonathan: What is your take on this? If you were a DPL >> today, would you feel OK issuing a position statement on behalf of the >> project? I'm comfortable making a statement on behalf of the project if necessary. On this particular issue, I feel it's better that individual developers go and make their voices heard. That said, I will also respect the outcome of the GR and follow it if it completes within my term. -Jonathan
Re: diversity
Hi Bart On 2021/03/23 11:11, Bart Martens wrote: > A question about diversity. We all know that some profiles are > underrepresented: gender, etnic group, disability, age, sexual preference, > education degree, rich/poor, spoken & written languages... > > 1/ One way of addressing this, is actively BENEFIT the underrepresented > profiles. Positive discriminiation is needed, at least to get over an initial > resistance. Put diversity in the spotlights, to speed up improvement. I'm not a fan of that approach, that means implementing something like affirmative action and implementing quotas of some kind and only accepting members of the types we're shot on quota on. I believe that with the right kind of promotion we can boost our numbers without any form of positive discrimination. Also, I'd be really sad to reject anyone's contributions for something they have absolutely no control over. I'm really looking forward to when we can have in-real-life events again, I think that's a crucial part of the puzzle to bring in a more diverse mix of people in to Debian. > 2/ Another way is active NEUTRALITY treating everyone alike. No > discrimination, > positive nor negative. Make room for diversity to evolve. Diversity > matters, although in the shadow of free software. That sounds close to what we have now, although we do have some outreach and diversity funding that helps a little to give more women and other minorities in Debian more exposure to the project. I think that this is an area where we can invest in more. > 3/ ... ? > > Now the QUESTION ---> What is your view on this? Your preferred approach? What > is the priority of diversity? Practical action points, how to measure > progress? There are probably 100s of ways in which we could be more diverse, but I think in terms of new members we should try to attract, we should put some focus towards women and non-white people. In my very first platform I mentioned that I wanted to initiate some kind of initiative where any women anywhere could organise a Debian meetup in their area and have some funding available for it (it could be as simple as a coffee once per week in a nice coffee shop). I didn't persue that for my last term because covid seemed to be quite a blocker. For bringing in more diverse people from all over the world, I think further investment into local teams is the way to go. We talked about this at DC20 and there were some follow-up meetings, I'm trying to encourage the local groups effort to prepare for when covid is over and start organising for that (things like making swag that we can distribute, posters, etc), but it seems like because it's such a delayed gratification, the motivation for that is currently low. MiniDebConfs are also great and last year was going to be a record year for that, I also believe that we should try to preserve that momentum as everything open up again. So in short, the two most solid ideas that I have in mind is to put together some framework/policy to encourage minorities in Debian to meet up (especially women), and also to keep pushing for more local team activities and events that could attract more locals from around the world. Did you perhaps have any ideas in mind too? -Jonathan
Re: How can we make Debian packaging more standardised?
Hi pollo On 2021/03/19 20:05, Louis-Philippe Véronneau wrote: > In becoming a DD, one of the main challenges I faced was the absence of > a standard way to package software in Debian. > > I've since seen first hand how having a very large number of ways to > package things in Debian confuse and ultimately discourage people that > would otherwise have been interested in joining the project. That's true for regular contributors and old-timers too. > One of the reasons I like team-maintained packages is teams often have a > single packaging standard. Sadly, each team has their own way of doing > things and working in multiple teams means working with multiple > "standards". > > If you were elected as DPL, what would you do about this? Sam Hartman > tried to lead discussions on using git, but sadly it seems it didn't > yield anything tangible. I consider this an item still on the collective project's todo list to figure out. I've received plenty of e-mails to the DPL alias regarding git workflows, but there has just been too many high priority things to take care of this term and sadly this just hasn't made the cut in terms of my DPL load. This is one of those issues which could be delegated but then again, it's also a discussion that's already open for anyone to drive, so that would be kind of redundant? > I understand change is never easy and often disrupts people, but I think > we should be striving for a more cohesive packaging ecosystem. > > Even if we don't ultimately enforce it, being able to point people an > officially recommended way to create packages in Debian would be a large > step forward. We both touched on git a bit above, but I do think that's the first place to start. It's probably the place where there's currently the most excess of options available and most confusion, at least compared to the rest of our packaging policies as far as I can tell. Like, do we call new branches "master" or "main" (or even "debian/main" (not to confused of course with "debian main)), do we use gbp or dgit or one of the many git helper tools out there (I admit I don't know how to use either properly and have somehow managed to get away with it, but I do plan on learning how to use dgit if I can find a good primer on it), etc. Usually team policies help a lot with all those, but as you say, they tend to be different. If it was up to me, I'd standardise on using git for a start. Based on a chart from[1] debian trends[2], we're inching close to squeezing out svn, but there's still a very large amount of packages not listed as being in VCS at all. That could potentially make a release goal. On that note, a release team member has indicated to me that even though they don't create release goals anymore, that DDs could still do so *wink* *wink*. I also think that we should really standardise on salsa for git hosting. Sure, it might be slightly more convienient for your particular workflow to host it on your own server, or on GitHub, but I really can't think of a single good reason to not have it on Salsa and there are plenty of downsides. There are a few other trends on that site that I think would be useful too, but as a start I think standardising on git and salsa would be a very good start. Now, to answer your question on what I would do about this as DPL in the next term, that's tough to say, on the git issues at least, I'd like to get the right people together and at least kick some proper discussion off in something like a BoF. Some discussion that doesn't start off on a mailing list but that's also well structured so that it's not some useless heated discussion that quickly evaporates. If I sound a little noncommittal about all this, it's because it's really hard to predict what the next year will look like in terms of the influx of DPL tasks, but I do think that the next year will be easier than the last, I've worked very hard to stay on top of things and I'm hoping that there will be more time for the DPL and the rest of the DDs to address this in a more structured and productive manner. -Jonathan [1] https://trends.debian.net/vcs_testing-stacked.png [2] https://trends.debian.net/
Re: Having a "DPL committee"?
On 2021/03/19 21:01, Pierre-Elliott Bécue wrote: > The idea was discussed two years ago. Sam chose a range of people to > help him with delegations. It's come up a few times in past platforms and discussions on -vote too! > Being a DPL is a high-energy thing even when one doesn't try to "lead" > the project /per se/. > > Do you think the Project should consider the opportunity of trying to > establish more clearly a role of "DPL advisors" who would be identified > as helpers for the DPL and additional entry points for the > developers/external people should the need arise? Perhaps a lesser known fact, but the current DPL has access to a channel where they can contact previous DPLs for some quick advice. I've found that quite useful in situations where I needed some quick feedback. For the rest, I think delegations work great. I think in general, when DPLs do their job right, then future DPL terms will get gradually easier. I certainly stand on the shoulders of giants and I've definitely appreciated some of the earlier work done. Teams like the Trademark Team and the Community Team catches many mails and issues that the DPL would've usually had to respond to. My strategy would probably be to bolster the existing delegation framework instead of setting up a committee. I'm not completely against a committee per sé either, but I also think that a single person who can make quick decisions when necessary works quite well. One area where I've felt that it falls short is that it's not fun when I got busy or would take a holiday. It would be nice if we usually had a vice-DPL of sorts that could be a backup and could take care of things when the DPL can't (for whatever reasons). That's something I'd like to consider if running for another term. -Jonathan
Re: What changes do you want in Debian?
Hi Raphaël On 2021/03/19 11:13, Raphael Hertzog wrote: > when I look back at my old platforms[1][2]3] I can already see a trend > where we move from "concrete changes that we want to see in Debian" to > "some vague idea of how we want to run the project" but this trend seems > to have continued and amplified to the point that this year none of the > platforms speak of any change that would affect something in how we build > our operating system or how we collaborate together or of how we > envision our role in the free software ecosystem! I'm kind of surprised to see you say that, since I didn't think that my platform was vague at all, and that it was quite focused on some very important issues within the project. > All the topics are around Debian (how we recruit, how we handle the > money) but I see no desire to lead Debian in any direction and I find this > particularly sad. The election time used to be a very active period where > we would confront our ideas for the future, but this has fallen short > as can be witnessed from the low-activity right now in debian-vote > and as can be seen by the small number of candidates. I also miss the more active discussion on -vote, and I value your questions here. For the 2019 vote we had 4 candidates and the discussion was especially lively and I think also useful. In terms of Debian, I think it's important to differentiate between the Debian project, and our products (just as you would differentiate between say, Canonical and Ubuntu). Sometimes conversation get muddied when we just refer to everything as Debian. Do I understand correctly that you'd also want to see more technical leadership from the DPL? Or do you mean that you'd like to see bigger project-wide changes being enacted by the DPL? > We're at the point where we congratulate ourselves because someone stepped > up to be DPL and we're happy that the process has not yet stopped working > entirely. > > With that said, there could be many questions to be asked but I will > concentrate on three: > > 1/ Why have you all given up on the idea to lead Debian? It seems >to me that you are happy with the DPL being a super-intendant >and nothing more. I think that's a rather presumptuous question. I also don't think that I've given up on the idea of leading Debian at all. My campaign for the last year was based on bringing stability and a sense of "business as usual" and normality to the Debian project. I believe that the project needed it. I read Sam's reply and agree with his reasoning regarding COVID-19, but I think the project needed this even if it wasn't for the pandemic. Overall, and personally speaking, I feel satisfied that we've managed to accomplish that over the last year. I know that might also sound somewhat self-congratulating, and it might even sound like it was a very passive accomplishment, but I can assure you that it was not. Behind the scenes I've dealt with many inter-personal issues that have either been boiling over for a while, or that was about to. In a few of these cases these issues have even been resolved. In others, resolution was just not possible and the best we could do was just to cool it down for a bit. Then there are some cases where I could just say "we'll deal with this later please be patient" and it's still on my todo list. I say we a lot here, because I don't take the credit for all that work myself. At some points DAM was very involved, in others the community team, in others a combination of people from both, sometimes input from previous DPLs, outside legal advisors, and other individual DDs. I'm not particularly good with time tracking but the amount of hours put in to dealing with inter-personal issues has been tremendous, and I think it was all worth it, and I think a stable project is *absolutely* critical in making fertile grounds for innovation. I think over the last year I've also gotten our members to be more comfortable with spending project money. I think we can improve that even further with some more policy. I also want to make people more comfortable with doing new things and taking risks, I know that you were a bit hesitant to post to -project about funding Debian projects in Debian with money from Freexian's LTS service, and surprised that there wasn't more opposition, but that's one of the rewards that stability brings, when there's a greater sense of stability, our members will feel more comfortable taking on some risk and try something new. In an alternate universe I'd be curious to see what would happen if that mail[1] arrived on -project a year earlier. [1] https://lists.debian.org/msgid-search/20201110100505.ga988...@home.ouaza.com Regarding "It seems to me that you are happy with the DPL being a super-intendant and nothing more"... Well, I agree that the DPL shouldn't just be an administrator that takes out the trash and replaces the light bulbs for a year, but I want to circle back a bit to the difference between the
Re: How to leverage money to accomplish high impact Debian projects
On 2021/03/18 23:33, Philip Hands wrote: > There were enough people keen on that happening that if we'd each had an > earmarked e.g. 1k budget to allocate, we could have just agreed it > amongst ourselves, and done it, without a lot of back and forth on the > lists trying to establish whether there really was something like a > project-wide consensus about it, and perhaps even not needing to ask > permission from the DPL[1]. Ah, I see what you meant now, yes that sounds interesting! -Jonathan
Re: How to leverage money to accomplish high impact Debian projects
On 2021/03/18 21:44, Philip Hands wrote: > I've been pondering how it might be possible to spend more of Debian's > money, and it occurred to me that we could allocate a budget to each DD > which they could spend on pretty-much anything (as long as, for Debian > funds, the expenditure is allowed under the relevant non-profit > restrictions that apply to the funds that we hold -- you could apply > your own criteria of course). > > That way you get to take advantage of the wisdom of the crowd, since > people in various areas of Debian are bound to know about things that > have been left undone for years or decades, that some targeted funding > would almost certainly sort out once and for all. > > You'd probably want to have some sort of oversight (e.g. some ex-DPLs) > just to ensure that the madder ideas get filtered out, but if you ask > people to only suggest ideas that they'd want to spend their own money > on if they had it to spare, that should ensure that most people don't > get too silly. > > Also, one could say that the people suggesting the project should not be > the beneficiary, and should write some sort of report indicating how > well it went before they would get any new budget allocated. People > that had thought of funding things that turned out to be successful > could then be given larger budgets to play with in future. > > Encouraging people to pool their budgets to fund bigger things would > hopefully result in them forming teams of mentors to oversee the work. I think as things stand now, every DD pretty much already has the entire Debian budget available at their disposal if they can think of a way to spend it that benefits the project. Something like the budget-per-DD idea might be good to encourage people to actually use Debian money if they can, this is also why I brought an expenditure policy into my platform, because I think people will feel more comfortable spending Debian money if it's really explicit that it really is ok to do so. -Jonathan
Re: How to leverage money to accomplish high impact Debian projects
Hi Raphaël On 2021/03/18 19:46, Raphael Hertzog wrote:> I announced this on debian-project[1] and on Planet Debian[2] a while ago. > But at this point, we have only funded a single project[3], leaving us > with more than 25 KEUR available for further projects. > > I did not expect this lack of interest... if I were not running Freexian, > I would have proposed projects out of the long list of distro-tracker > wishlist bugs... I enjoy working on this project and I wish I had more > time for it. > > 1/ How do you explain this lack of interest? I don't think that lack of interest is the problem here, but I do think that Debian contributors tend to be already starved for time, and trying to get them to do more is like trying to tap water out of an empty well. For some, a financial incentive might work if they're not currently working full time, and especially if they need money, but the median Debian developer seem capable of sustaining themselves reasonably well. > I have read recently from other Debian members that they have a feeling > that Debian is stagnating, and I share that feeling to some degree. If we > had plans and motivated people, surely some of those would have stepped up > to implement them in exchange of some remuneration. Do you share that > feeling too? We're always going to be growing in some ways and stagnating in other ways. What I've found is that the people complaining about stagnating parts are very eager to ignore all the parts where the innovation is happening. Motivating people is great, it's something that's been at the top of my mind regularly when it comes to Debian. In my experience, having co-ordinated events do more to make things happen than flinging some carrots at people. Over the last year we had DC20 online and another bunch of online events (Fique em Casa Use Debian, MiniDebConf Online, MiniDebConf Online Gaming Edition, MiniDebConf Online Brazil 2020 and MiniDebConf Online India). Each event brought with it its own innovations, unique flavours and some new people who are curious about Debian. I think that you'll have more success talking about the Freexian initiatives at these kinds of events and attract new people to work on ideas. Of course, if they're new they might work a bit slower and ultimately cost a bit more, but I think overall that would still be worth it. I've been telling a few people last month that I would really liked to have an Enterprise Edition Online MiniDebConf, unfortunately I don't have any time/energy to instigate that currently. It could cover aspects that already make Debian good for business, and cover areas where it could improve. I used to be on an Ubuntu mailing list called ubuntu-enterprise, it mostly contained feature requests from people who wanted more features for enterprise and large deployment use, but even those were really interesting. Also, I think even just some of our usual sponsors would already be interested in speaking at such an event, but I digress... > 2/ I really want this initiative to be successful so I'm now looking into > ways to make it work. I'm considering paying someone to identify useful > projects. That person could talk to various teams, make proposals based on > their own experience, and even run a poll among Debian developers. The > idea is that we want to find high-impact projects that can help Debian get > out of this "stagnation". > > What do you think of this idea? Sounds great! > 3/ While the DPL can't spend Debian's money to pay people, the funds > available in Freexian's reserve have been clearly earmarked in this > direction by the LTS sponsors. > > Do you think the DPL should be able to propose projects that would be > funded through this initiative, so that DPLs can have a bit more impact in > areas where they want to improve the current situation? It's probably best to have as many ideas come into that funnel as possible, so I'd say it would probably be a good idea to get some ideas from the DPL too. There's a very long list of projects within Debian that could do with more help, structure or even a complete reboot, although some tact and planning will also go a long way, you don't want to jump in to a team and tell them "oh we paid someone to fix all the problems in the team and this is how they're going to do it". Sometimes it's better to allow things to happen than to make them happen. I'm hoping that if we are able to have sprints/meetings again in person, that many of our teams will take advantage of it and spend some time and project money to get together and work on projects. If you invite and let Debian teams know that they could apply for some funding from Freexian to get someone to spend more time on some problem, then that's probably going to scale a bit better since they might already have a better idea on how to integrate this kind of work into their team. > Sorry for the hard questions and thanks for the time you spend for > Debian. :-) Thanks for the questions!
Re: Debian Project Leader Elections 2021: Call for nominations
Hi Kurt On Sat, 6 Mar 2021 20:39:44 +0100 Debian Project Secretary - Kurt Roeckx wrote: > Please make sure that nominations are sent to (or cc:'d to) > debian-vote, and are cryptographically signed. I hereby self-nominate for the DPL 2021 term. -Jonathan pgpr5E_bf053T.pgp Description: OpenPGP digital signature
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2020/05/22 20:08, Jonathan Carter wrote: > (and besides, the India team has already won for next year). If > they get Correction: I mean of course, Kosovo. - -Jonathan - -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl7IG34ACgkQsB0acqyN yaENpg/+MIEtpRIar0s4IiSPPTmY5Sk7vCy/dATZrcTBS9iNWoIwtbNUcFPObk3O H5vytjaEicKeFV9PAU4KN0DplUyZWsq9LvKf9mqrTjWHy5qJ1+xcaZkR0u4AUf20 /X3SzRNge3vKo/Tw/k4vyU1Ewx+r6X2ylBJOgq8M2GJu0zDHYpLTW5YbN9Dhz6iK NDIWC3GzDne+84X//9VZWUicoppd4c4V8R7ybiSb9dVgcnWy5UEXKCw6DYXCCrw5 yo6/B0AJFDGXlTMVKhAiq0THPRZKmNCGTbiY2nY2OXs/ACxUZwLsOKo1ehWM32Td AYmZTEQdO45lNmASBlbF+3N/zbSm1X5k2T3IwdQBrl4TS1Yhdilqxzvt6Xn/AhGi yIR9IdBRSKjceRlRfClPiiZ5xz3N5uW3jrB0PdemY9BGfMy4WRced6LzGh4dko+h wAYA+551gQmcIHFginzC3RrhHkO3Y6gEEd0Bl2xWTghUxZnCW5P5LvMfMTkkRjg2 e4R6wg81UlkgXap2Ob16CSEeMm05BA01J9kbgH3KAzMttSYWXkCJoXHXqlMfcBRl Lhv3NqLqujycqJP8SDfQC4s4djVl+dsIrxsYv3anH6aO3nJ2RcGj6pjY9xJd9sl/ aRSyT2lS+88FrWroQ1DXQL9Zp0LM04EaixHy7DA4V8ecf9IhG4s= =0qIz -END PGP SIGNATURE-
Re: [draft] Cancel this year's in-person Debian Developers Conference DebConf20
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi zobel On 2020/05/22 14:40, Martin Zobel-Helas wrote: > This is a draft for a GR I would like to propose. I can't block you from doing a GR (and I certainly wouldn't want to!), but I'd like you to consider the variables and consequences one last time before posting such a GR. First, the Isreal local team are made up of highly competent Debian members. I trust them, and believe that they are able to make a good decision based on the available information. Yesterday in the DC20 announcement, they made it clear that they're putting feelers out there to gauge how many people feel confident that they'd actually be attending in person. As far as I understand, they intend to make a final decision on whether (or to which extent) DC20 will be an in-person event in about two weeks from now. I believe that this GR is putting the cart before the horse, and while I 100% understand (and to large extents agree) with its content, I do think that the DC team will end up making a good decision and that using such a GR to take that decision away from will just cause unnecessary anguish. Secondly, so far this month they're infection rate has been really low. Low enough so that they can still effectively do contact tracing and cluster control (which is basically a lost cause in most countries at the moment). They have a very good chance of having this virus under control very soon. There are other countries that are doing well too, for example New Zealand who are in the single digits with new infections, and China, which was the original epicenter, has learned to deal with this virus quite well too. I acknowledge that it's too soon to tell, but there is still a possibility that at least people from countries like that might be able to travel, and maybe DC20 ends up being really small, maybe just a few dozen people in person with mostly locals, but is that so bad? We're planning an online minidebconf for the end of the month, there might be another before DC20 is supposed to happen. This gives us a good oppertunity to hammer away at our online participation tools so that those who can't or do not wish to travel can still participate remotes. And I realise that this experience will never be the 1st class experience that a full in-person DebConf is, but at least we can have some form of annual event together, and forcing us to improve remote participation will help future DebConfs be better like that. It's currently a sore issue and more and more people choose not to travel for environmental reasons, so it's something we'll have to be better at in the future. *Phew*, I'm just going to take a breath and say sorry for all the text so far... but there's more... Thirdly, if the specific event is totally cancelled, do you feel that the DC20 team should just lose their slot? Even if you move it to next year, the situation might still be somewhat similar to this year by then (and besides, the India team has already won for next year). If they get postponed (to 2022) instead of cancelled, do you realise that the political debates surrounding a DebConf in Israel will start afresh and that many people really don't want to be dragged through that again? I want to state again that I 100% agree with your sentiment regarding physical meetings, but DC20 was initially planned before the epidemic started. If they can manage to do a nano-scale DebConf and do it safely, why not let them? Or if they decide to let them do it online only, let it be their choice and responsibility to make. I think the chances of people from Africa, Europe, India, South America or North America being able to travel to Israel before the end of the year is super slim anyway, so I'd ask you to reconsider this GR and at least see what the DebConf team comes up with first. If they manage to either figure out the details to do either a tiny scale DebConf or an online DebConf, then we might still preserve most of the secured sponsorship, enjoy some level of interaction and problem solving online, and be able to wrap up DebConf in Israel this year and start to worry about the situation in India instead. So again, I'd ask you to consider the above at least one more time before posting that GR. - -Jonathan - -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Debian, the universal operating system. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl7IFR4ACgkQsB0acqyN yaHGnRAAsPab6v9gCgo2YK4UtmPztIpdSuGZkMSSBENNCZjCZo1fVsr1tPSllDQd MleamsrIGCI7+6ZUq4NH1LAm+9lx1UDzkvzH748d2r0LiV8BncXeHo2nWkBeWCKY /hUrhYdhSKtFuNOp3yDwFB8rB5xIdyBLDCudS8Us5sOAzpI3+cvlbmo86Qzq/KMG A877e8Ef/W/MzvGkE+sQaW5eMdD2KdDfqOxMZ0sPEK4i8pQzfHrZJoWiwj1roprc WWbdEb4n0/5ayLhrd+3ojsTrimGOq+KVdZZoFwN5fJnW54SlvBbzXWRrHQx2ODwm NDx+ALxbIJlrf6+G2RdIuESMtBx3dP3aP0uGD2/ZWBpiNBtJKFJnf3z5tAAPdC1t +ppk981/OQQd38FeUpifOS9
Re: DPL blindsides
Hi Teemu On 2020/04/17 00:00, Teemu Hukkanen wrote: > Sam Hartman writes: > The emails in question have been forwarded to both Sam and Jonathan. > As you have noted, DebConf Committee members already received these > emails. Thanks, I received it and replied to it, and after reading this mail along with that one, I think I understand your request better. > We now have the following information: > > - An (all-round) organiser did not know Perhaps a misunderstanding on your part, but an all-rounder in terms of DebConf organisation isn't necessary involved in everything, they typically pick up slack where necessary and try to be helpful to everyone else in the team. It would probably be quite normal in future cases that all-rounder people wouldn't know about these kind of incidents. > - The DebConf Committee did not know > - The DPL did not know These I think were a lot more problematic. There were also some DebConf related problems that exacerbated the situation. The DebConf committee was formed half-way into the DC17 cycle (in January 2017), and at the time was overwhelmed by another harassment issue where there were lots of meetings and time demands. Because of this, the local team didn't really know yet how to interact with the DCC and at times they even said that they felt alone, it took a while to fix the DCC / DC-17 team relationship as well, there was just a lot going on during this time. It's unfortunate that the timing for your incident was during a perfect storm of existing problems. In DebConf, a local team has every right to block any person for whichever reason they see fit. This is unlikely to change in the future, although I do agree that there should be some due process and at least the DCC should be kept in the loop because that's the best place to preserve some institutional knowledge on these matters. > Which leaves the (local) organising committee. > > This returns us to the original query: """ > How would you handle a situation where a Debian event planning team > would instigate a unilateral blacklisting against a DD for a Debian > event, and the team would refuse to provide any details or > explanation, even at the request of the DPL at the time? > """ As I mentioned above, the Debian event planning team has every right to make such a unilateral blacklisting, and I don't think that's going to change any time soon. Ultimately it's the organisers of an event who has the most control and responsibility to make sure that the attendees are safe, and they get to make the ultimate decision. I do agree that they also have a responsibility to share this information with the DCC in the case of DebConfs, or the DPL or Community Team when it comes to other DebConf events. This would help provide some additional sanity checks and also for posterity. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: DPL blindsides
Hi Teemu On 2020/04/12 21:04, Teemu Hukkanen wrote: >>>>>>> "Teemu" == Teemu Hukkanen writes: >> >> Teemu> Would you, in a situation like this, commit to providing the >> Teemu> information before becoming DPL in order to avoid a conflict >> Teemu> of interest? >> >> What is the conflict of interest you see here? > > The description of Jonathan Carter's (highvoltage) role in the event > planning team in the wiki page > <https://wiki.debconf.org/wiki/DebConf17/TeamRoles> says "Does > whatever needs doing:" and "kicking the chief organiser". Yep, I was listed as allrounder there, that doesn't mean that I was explicitly involved in every DebConf decision though. I only became aware of your case after the fact, the decisions around your involvement in DC17 was made purely by the DC17 local team. > In > (<1501234967.2211370.1055405832.1d2d7...@webmail.messagingengine.com> > message not available in public), by a previous DPL to the event > planning team, including Jonathan Carter, the email noted that by > actively not answering or responding, a particular sequence of events > was being forced. To the best of my knowledge, the event planning > team, including Jonathan Carter, has not responded to this request by > a previous DPL. Unfortunately I have no idea what you're referencing there. Feel free to forward the message (or relevant parts) to me if that could help. > The position of DPL, while not providing significant direct power, > provides significant influence, including the power to appoint people > who would be responsible for investigating any wrongdoing by the > DPL. The DPL can use the appointment power to influence investigations > into themselves - hence the conflict of interest. Sorry, you've lost me there, I again don't know what you're talking about. > The conflict of interest can be reduced, although not completely > removed, by committing to handing over *all* of the information, and > complying with requests from previous DPLs to respond, prior to taking > office as DPL. > > The question to Jonathan Carter, which has still not been answered, > (~2 weeks later) is whether they can agree to hand over information > before taking office as DPL. I wasn't sure what to make of your request, and from off-list mails it seems like some parts of it were being addressed. I think you might have to start from the beginning and explain what it is you're requesting from me. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: Question to Jonathan & Brian: Diversity in Debian
Hey Sruthi On 2020/03/29 20:39, Sruthi Chandran wrote: > Hello Jonathan and Brian, > > I have a couple of questions for both of you. > > - What are your thoughts on diversity in Debian? > > - Are we diverse enough? Since there's a big amount of overlap with these two questions, I'll try to answer them in one go. There's many kinds of diversity, and some of them we cover in Debian quite well. Others, not. It's clear when you go to DebConf that a very large percentage of our contributors are white and male. Nothing wrong with being white and male of course, but if you compare our project membership with the world outside of Debian, then it becomes clear that our demographics are very skewed. In particular, we have a very small percentage of women and non-white people in the project. There are some people (even within Debian) that feel threatened by the kind of text above, they feel that someone who's other than them will step in and make them less valued somehow. This is not how diversity works, we can all grow and become more enriched when we attract people who bring new perspectives and experiences with them. One of the problems I think we face is that the people who tend to be minorities in Debian tend to be people who are also already disenfranchised in the world. For example, just in my country (South Africa), more than half the people live on less than $5 a day and even just a decent internet connection cost a considerable amount of a typical income. Too many people rely on their income they generate today so that they can have dinner tonight. It's understandable that, people in that position, who already get up at 5am to get at work on time, and only get back home at 9pm again because public transport is so horrible, will be less enthusiastic to spend the little free time they have to work for free on a project. Another quick example are single parents, more than 80% of single parents are women. If you have to provide for your kids and take care of them, you're going to have a tough time learning new skills and contributing to new projects. It's an unfortunate problem that the very ability to contribute to free software relies on all the kind of privilege that gives you things like stability and free time. It's a bit of a catch-22 situation since learning about free software and contributing to it could also help people to get better jobs and ultimately improve their living conditions. I don't have all the answers when it comes to diversity in Debian, but I think we should do everything we can to be part of a solution and not part of the problem. We don't have control over all the gender and race problems in the world, but we can do our part to make Debian a safe and welcoming place for all contributors. With that I don't necessarily mean that we should all be friends in a perfect little world with unicorns that poo out rainbows and such, but I mean it in a practical sense. For example, if someone has an idea and want to argue for it, they should've feel that their opinion means any less because of their background or that they're some kind imposter because they might look or feel different than other people. And if their idea isn't all that popular, they should feel comfortable with the idea that it was on technical merits and not because of them. Recently there's been some concerns raised on return on investment with diversity spending. I'm fully aware that we'll invest some considerable time and money on some people who will end up disappearing working at some big company or find some other free software niche that they enjoy. I think this is just fine. Some have pointed out that we might be able to get more bang for buck if Debian had its own funded diversity programs. In that case I think it's better to add more spending than to switch out existing programs for it. I think it's important to talk about some things that we're doing right in Debian. Our relatively recent additions of the code of conduct and diversity statement lays some groundwork to making Debian a more accepting and diverse project. And even though our contributors might look similar at a quick glance, I don't think that we're a monoculture either. Talk is cheap, and I don't think yelling "diversity! diversity! diversity!" helps making a project any more diverse than yelling "developers! developers! developers!" will attract more developers. As DPL, I will be very eager to approve any spending that can bring new contributors to Debian, but we would still need people to step up and help make those kind of projects happen. I don't think that diversity should be squarely the responsibility of the DPL, but the DPL should certainly be there to help enable any initiatives and ideas that our project members have. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄⠀⠀⠀
Re: Q to all candidates: NEW queue
Hi Lucas On 2020/03/26 09:33, Lucas Nussbaum wrote: > For as long as I can remember, there has been complaints about the > delays caused by NEW processing (and > https://ftp-master.debian.org/stat.html shows that we constantly have > 250-300 packages waiting to be processed). There was even a brief period in 2017 where it was really low for a while, but I think this was mainly due to hero work from one individual. Watching some old DebConf videos recently, and it was interesting seeing a BoF where Debian was approaching 15000 packages and the idea was to figure out how to scale up and be able to support that. Since then that number has casually exploded and I think it's remarkable that everything has passed through NEW at some point. > What is your diagnostic of this issue? I think that's the most difficult question I've seen during my two DPL campaigns... thanks! I don't have all the details and have just recently been re-accepted as ftp-trainee, but I believe it's a case of it being easier to continue doing a lot of grunt work rather than to do a collective step back and redesigning the machinery. > What solutions do you envision about this issue? Is that just something > that we have to live with? I'll be honest in that I haven't envisioned anything for this yet, I'd like to take some time to get into it and understand all the problems properly first. I do not think it's something we have to live with, no. I think with a combination of process improvements as well as tooling improvements, this could be made a lot better. For example, copyright review seems to be a big chunk of the work. There's probably no reason why a larger group of DD's can't help with this too (currently the ftp-helpers/trainees helps with this, but it depends on them being part of the team and using the team's tooling). Perhaps mentors.debian.net could be augmented for better copyright reviewing, or a similar tool could be set up for DD's who want their copyright reviewed or maybe even just get a second pair of eyes over the package before it gets submitted to NEW, then that might already help. >From a mostly outsider view, it seems that packages that are problematic take up a significantly more amount of ftpmaster time than packages which have no problems. If we can add some kind of filters, whether it's based on code or on social solutions, then it may be possible to reduce ftpmaster load without even making any immediate changes to the ftp team. That said, I like the efforts currently underway with the new ftptrainees, there is now a dedicated person taking care of them (well, us :)) and I think those efforts will pay off. I also think that it's worth while for the ftpmasters to get together somewhere nice at least once a year. Nice as in, not DebCamp but somewhere where they can have relaxed conversation and be creative without being disturbed. > Specifically, Jonathan writes that he would like to "Reduce bottlenecks > that affect our contributors.". That sounds like a good example. Yep, perfect example :) > Personnally, I wonder if we are being overly cautious about NEW. I > wonder if we could move to checking a posteriori (accept the package in > unstable; maybe don't let it migrate to testing until it is reviewed). Not fond of that idea, because that means the packages already get mirrored (so basically distributed) already. It would be nice to be able to access NEW packages via an apt repository, or even links from the NEW page[1] to the package's git repository, so I think there might be tooling that can help but I don't want to get into specific ideas or solutions without having delved deeper into this. I do have confidence that the current measures with the new ftptrainees will start paying off over the next few months. Merely the fact that there's less stress on the team might help it to re-assess a few old processes and tooling and allow it to evolve again. Overall, I think it's good for a DPL to check in on the team and offer assistance, I don't think a DPL should be too pushy on these issues, the strategy should be removing pressure instead of adding more imho. If the team has more time to address their problems internally then the day to day problems will eventually get better too. -Jonathan [1] https://ftp-master.debian.org/new.html -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Response to jcc's rebuttal
Hi Brian On 2020/03/24 18:33, Brian Gupta wrote: > I certainly don’t think it will be possible to create both Foundations in one > term, and it may not be possible to even finish creating the US Foundation in > one DPL term, but a lot of progress can be made. In my platform, I estimated > 6-12 months, but there are things that are out of our control. These things > include waiting for approvals from municipalities, working on the details, and > time spent building consensus on the details. > > I commit that if I am elected DPL, that I will run for a second term, and > finish the creation of the US Foundation if it hasn’t already been completed, > whether or not I am re-elected as DPL. In my first term, I will also begin > working with European developers to create the European Foundation but have no > expectation of completing that during the first-term. I'm not going to reply to all the specifics in your mail since I've already covered a lot of it already, but your explanation just convinces me even more that a creation of one or more foundations should not be linked to a DPL term. > I am curious, what was meant by “yet another Debian mess”? In my eyes, the > biggest Debian “messes”, are the endless bikeshedding sessions that end up going > nowhere. Yes, I suppose you could consider those examples of Debian messes. Although I was thinking more in terms of what Alioth had become before it was flushed out. Single sign-on in Debian is also messy. It's not any person's fault, and I appreciate people who have worked on it because it's both complex and something I don't like working on, but I think that as a project, we should be more strategic in dealing with issues like that so that services that affect every developer is easier to maintain and even easier to cleanly move away from when we eventually need to move to something else for whatever reason. I don't always like the Salsa team's policy of keeping our GitLab instance pristine and not integrating the whole world into it, but after I take a minute to think about it I appreciate that they do that and I think that they're making the right choices for Debian and that it forces us to innovate and come up with better and cleaner solutions. > As I’ve stated earlier, I’m not a fan of unnecessary GRs. If we can find a way > to assess the project’s will without them, we should, just as I thought Jonathan > believed, based on his 2019 DPL campaign rebuttal [2].: > > "I think that GRs should remain a last resort and that there are better ways > to gauge the community's stance on a topic when you need it. If a poll is > needed, it's better to do a proper poll than to use a GR as a generic tool." > > I will say that during the development work to create the Foundations, if we > discover legal reasons that would require us to change the Constitution, I would > have no issue seeking a GR, and working to build consensus to make the necessary > changes. Great! Yes I still stand with the idea that a GR should be used for final votes, not as a polling tool, and the options should be clear enough that people understand what they vote for and what the consequences of each option mean. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
DPL blindsides
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 In a twist, my question goes out to Debian project members, but I'd also like to hear from the other DPL candidates on this one. Every year, the DPL candidates post platforms listing what they think they could do to improve Debian over the next term or so. Often, these ideas are similar to previous platforms. Sometimes it's because candidates draw some inspiration from previous platforms, and often its because those ideas are as relevant and necessary as they were in previous years. So, my question to all our project members is, what do you feel is a DPL blindside? That is, something that's important in Debian that neither the DPLs or DPL candidates every give (enough) attention to? And is there anything specific that the next DPL should really pay attention to that none of the candidates have mentioned yet? thanks for any answers :) - -Jonathan - -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl55JbQACgkQsB0acqyN yaEAQg/8CbTcfzNZ2jpwDzLrCKaB8+82B1YoIW0Ukf2jQrpTxs9TFtFWBee9apkh ozFc6TP0wI9oZRDFzbvk3IdYsscMunAM4hDbVssmfCddRiN2VNsatTTPK/ea3AHG gjLkNw7IJmAzQp4F9I34IeGDXsVprDJoQ+8bd/uTNbgAdiUWFFNbY6GocwnYeBcQ 5GoY6IWHWyt1i4/xFl1Wwk1URTmDBi+i7WXKLAuZFOzOAY44eBSaBevti/Ciow5W gBedPFrOKnHa3WBzMZ7azerPBMyweNeMHs/qW+6q50D+z6TYC+kMXpbuOsyUj67W kWdaSiKySaVbE281jBo84Hw3xszLKMScGbOt3LqZe578bREtZCxde9wDbmEC4q1B icdxvyUb/NlSpxltSXWT200a0zUNcf3ffHOCQfufOdyCoVJ0OXQn8wVe6GXz7Rk/ sPWZTsKBWRRCjJkGcZonRJUxiT3XdBh8B7W1yk4qlXx2f7Vswr7oAhAqvdYmHTzf kVjDRl1DK1WS/wQ16sJgVXIq0GdgOeNmoDTBRJOzUnNIfxwChry0VH7GER5aDf5p iFhgCKlBb2ltmqzKRxgbu+dn9qC9NVxiXa7keVZmQ9mA5kkdkK4oXROqzXr1xUi5 GnYUR1aIOzacfUQ4trsEugbcc6+4lN+VIYz+zdGcS3roaMPwcGY= =ILkZ -END PGP SIGNATURE-
Re: Question to all: Outreach
On 2020/03/20 02:12, Paul Wise wrote: > On Thu, Mar 19, 2020 at 3:30 PM Jonathan Carter wrote: >> Non-uploading DD's existed at the time, I just had no interest in >> becoming a non-uploading DD when it was already my intent to become an >> uploading DD. > > I don't think any one membership state should be perceived as "final", > people gain and relinquish both upload privileges and membership > (going from non-member to uploading DD and then non-uploading DD etc). > Also, I assume that non-member -> uploading DD and non-member -> > non-uploading DD -> uploading DD are basically the same amount of > time/work. I suppose the latter even has the advantage of splitting up > that time/work over time. I think I like the idea of de-coupling the > membership from upload privileges even more somehow. *nod*, I would really like to see that happen too. Just fixing the current naming of these membership types would already help a bit, but it would be nice to take it just a little further. I would advocate for partial decoupling rather than complete decoupling. For example, you could have dependencies eg. if you'd like to apply for full upload access rights to the Debian archive, then you have to be a Debian project member first. But as you say, this is something that can be taken further on -project. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
Hi Paul On 2020/03/19 15:19, Paul Wise wrote: > I'm saying that when we think someone deserves to be a delegate (or > join a core team), then at minimum they need to go through the > (non-uploading) DD process before becoming a delegate. If we trust > them to be a delegate, it would be weird to not trust them enough to > be a member. Yes, the above part is the part we definitely agreed on. > Is there something about the membership process (or the status itself) > that makes potential delegates (and their advocates) want to skip the > process or avoid being members? I don't think so. In my case, I was persuing the path of DM -> DD. Adding the extra step of DM -> DM and Non-uploading DD -> Uploading DD would probably not have happened much faster and probably would just have wasted a few people's time. I think at the time (2016) there were also some problems if you wanted to be both a DM and a non-uploading DD so I skipped that complication. But yes, in general, I think the time it takes is why people don't immediately go for it. That's not too say the process is too long or cumbersome, even if it's just a 2 day process, when you're neck-deep in DebConf matters, you're going to put your focus there until you have some time to focus on the NM process. In Bernelle's case, she's applying for non-uploading DD and is going through the NM process so it's again just a time thing, and I think it's just one of those things that's not really a big deal. > Did your skipping of the membership process before being a delegate > happen before the non-uploading DD vote or before the non-uploading DD > process was well established? Was it because of the historical > perception of separation between Debian and DebConf? Did you perceive > the process to be heavyweight? Did the DPL at the time and the DebConf > folks just not think about this? Were there other factors I'm failing > to think of? Non-uploading DD's existed at the time, I just had no interest in becoming a non-uploading DD when it was already my intent to become an uploading DD. Back in 2016 we were already doing a lot of work to bridge more of those historical disconnects between Debian and Debconf, so that wasn't a factor at all. Again, I didn't perceive the process as heavyweight per sé, but I was doing a lot of different Debian work and did become a DD 7 months later. I know it's not a record time but I didn't feel a need to rush it either. No one ever had a problem with me being a non-DD on the DebConf committee and it wasn't any kind of secret either. I was involved when the DPL and DebConf people talked about it, they simply agreed that it's not an issue and that you don't have to be a DD in order to be on the DebConf committee. TBH I'm having trouble following your line of questioning and exactly what you're concerned about, if I missed something, please ask again and keep it to one question per paragraph. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
On 2020/03/19 14:00, Sam Hartman wrote: >>>>>> "Jonathan" == Jonathan Carter writes: > > Jonathan> On 2020/03/19 12:39, Paul Wise wrote: > >> On Wed, Mar 18, 2020 at 9:54 AM Jonathan Carter wrote: > >> > >>> My honest answer? Yes, it would be nice if all the delegates > >>> could be project members, I understand your concern, but often > >>> it's best to be willing to work with people who are willing to > >>> do the work. > >>> > >>> I would suggest some minimal vetting for outsiders who become > >>> delegates, for example, just like when someone gets access to > >>> Debian machines have to agree to the DMUP, delegates should > >>> agree to uphold our community standards (like the CoC for > >>> example). > >> > >> I think if we can trust them to be delegates then we can trust > >> them to be Debian project members. For most potential delegates > >> who aren't yet members, I assume the non-uploading DD process > >> would be minimal enough. > > Jonathan> For sure, going through the non-uploading DD process > Jonathan> should remain a bare minimum for someone who wants to > Jonathan> become a project member. > > > You seem to be dodging the question a bit. > Paul is talking about the link between delegate and member. > You are focusing about the link between non-uploading process and > member. > I realize it's convenient to focus on that link because it's the side of > the equation that is less controversial, but it isn't really the area > Paul and Enrico have been asking about. I re-read the above, my understanding is that Paul made a statement about the non-dd process being sufficient for new delegates that should become members, and then I agreed and re-affirmed that that should be at least the bare minimum. I'm still not sure which question you think I dodged, but if either you or Paul could perhaps rephrase the question that I missed, then I'll give it another shot. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
On 2020/03/19 12:39, Paul Wise wrote: > On Wed, Mar 18, 2020 at 9:54 AM Jonathan Carter wrote: > >> My honest answer? Yes, it would be nice if all the delegates could be >> project members, I understand your concern, but often it's best to be >> willing to work with people who are willing to do the work. >> >> I would suggest some minimal vetting for outsiders who become delegates, >> for example, just like when someone gets access to Debian machines have >> to agree to the DMUP, delegates should agree to uphold our community >> standards (like the CoC for example). > > I think if we can trust them to be delegates then we can trust them to > be Debian project members. For most potential delegates who aren't yet > members, I assume the non-uploading DD process would be minimal > enough. For sure, going through the non-uploading DD process should remain a bare minimum for someone who wants to become a project member. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question for all candidates: Sam's non-platform: Delegates
On 2020/03/18 19:33, Sean Whitton wrote: > In his non-platform, Sam wrote > > If I were running as DPL, figuring out how to do a better job of > managing delegations, respecting both the current delegates and the > needs of the project, would be my priority for the next year. I > hope that the candidates who step forward take on this challenge. > > Do you agree? If so, how do you propose to take on the challenge? Yes, I agree with Sam that the next DPL should do a better job of dealing with delegations. That means being available and reserving some bandwidth for delegations even when other exciting things are happening. Also actively checking in on delegations that are known to need some support, like the DebConf team in the period before Debconf starts and probably also scheduled check-ins with delegations like the treasurers. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: What are your thoughts on discourse?
Hi Sean On 2020/03/18 19:34, Sean Whitton wrote: > I don't mind clicking on a link to read the answers too much, but I > think your answers should be preserved in our mailing list archives. Here is the permalink from my answer: https://discourse.debian.net/t/dear-dpl-candidates-what-are-your-thoughts-on-discourse/75/4?u=highvoltage (since it's a test site I guess that might be invalid one day) Here's the full text: """ Like many DD’s, I have mixed feelings about Discourse. I’ve used it before in my local Wireless User Group. I don’t use it much personally, but it works really well for that community. This current (discourse.debian.net) site is obviously not the best example of an active Discourse site, so if someone is interested in what an instance that’s been used for a while looks like, here is CTWUG’s instance: https://forum.ctwug.za.net/ 2 Ubuntu replaced their Community Hub site with a Discourse instance. You can read more about that at https://popey.com/blog/posts/ubuntu-community-hub-proposal.html and https://discourse.ubuntu.com/t/ubuntu-community-hub-launched/102. Forums and sites like Discourse are often used for support. I kind of like that they explicitly don’t want to use their site for support, which I think can become a distraction from wider community issues. Their instance is at https://discourse.ubuntu.com/ I agree that the features you mention in the debian-vote thread are great. Being able to upvote comments in a Debian discussion could be very useful. Personally, when it comes to web-based forums, I tend to use them for a while and then only remember I have an account on them a few years later. They tend to be obnoxious with email notifications, so I usually disable those. For some, just using the e-mail gateway may be sufficient, another DD did some tests on the usability of its email integration and wrote a report: https://writefreely.debian.social/paddatrapper/discourse IMHO only using the e-mail interface would kind of defeat the purpose (you might as well use a mailing list then) since all the nice features that’s available are exposed in the web interface. I might have to through your question back at you and ask you, what would you want a Discourse site for Debian to be used? I’m even going to go ahead and give a partial answer, because I’m a DD so of course I have an opinion about everything. I think for things like DebConf, Discourse might be a better way to co-ordinate a lot of things. Especially since we tend to get in a small influx of new users that, for example, struggle to get an account on the Debian wiki and once they do, figure out how to use it, how to deal with edit conflicts, etc. Our wiki is also full of stale documentation. And we don’t really use talk pages on there so leaving comments or having discussion about it on there is suboptimal. Perhaps a Discourse instance might be a better alternative for wiki-like documentation, I’m not sure. We can perhaps check how it works out for Ubuntu. My point with the above is, I think you need to find something that it’s really useful for, and that it’s really good at, and drive that use case to spark interest in it. (Also, why doesn’t it have backups yet?) Finally, I don’t think you should encourage Debianites to ask questions for the DPL elections on here. Both questions and answers could go unnoticed and unread. I think it’s better to choose a future discussion and plan it ahead, rather than test it in production mid-way of a DPL election. """ -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: What are your thoughts on discourse?
Hi Raphaël On 2020/03/18 12:00, Raphael Hertzog wrote: > I would like all the candidates to reply to this question on discourse: > https://discourse.debian.net/t/dear-dpl-candidates-what-are-your-thoughts-on-discourse/75 Done. > The kind of discussions that we have in debian-vote is very much suited > for something like discourse where we can +1 with like, etc. > > I would encourage others DD asking questions to try to use discourse and > just use the mail to inform of the discussion started on discourse. As I said on the post, I think it's better to keep questions to the DPL candidates on this list, rather than test Discourse for DPL Q midway through a DPL election. And I also forgot to mention, nice initiative I do think that it has potential. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
On 2020/03/18 13:16, Héctor Orón Martínez wrote: > That's one option, yes. > I would like people being in such case to at least be tested that > they know about DFSG and Debian core values. +1, as a DPL I would not add someone to a delegation unless I'm satisfied that they are at least familiar with those. It doesn't seem reasonable for someone to represent Debian in an official capacity if they don't even know what Debian is. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
On 2020/03/18 13:01, John Paul Adrian Glaubitz wrote: >> You hit a very important aspect of privilege in your mail here that I'm >> not sure you're fully conscious of. Back in 1989, me and my little >> buddies were typing BASIC in to a ZX-Spectrum so that we can play new >> games. It was great and we learned a lot considering we were just 6 and >> 7 year olds. >> >> At the same time, the girls in our street were playing with dolls >> because you know, boys are supposed to play with Lego and computers and >> girls are supposed to play with dolls and pink tea sets. At least, >> that's the rules society systemically imposed on the world. Back then if >> there were a microcomputer in the house, girls typically got very little >> time on it. > > I was playing with dolls when I was a small kid, that didn't keep me from > becoming interested in computers. Several female physicists I know probably > played with dolls as well, yet they are what they are now. I'm sure that you're smart enough to know that you're completely missing the point there. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
Hi Adrian On 2020/03/18 11:26, John Paul Adrian Glaubitz wrote: > You also don't need much to do programming. I started with a C64 from my > brother because I didn't even have my own computer and we didn't have > an x86 machine before 1997 which also belonged to my parents and not me. You hit a very important aspect of privilege in your mail here that I'm not sure you're fully conscious of. Back in 1989, me and my little buddies were typing BASIC in to a ZX-Spectrum so that we can play new games. It was great and we learned a lot considering we were just 6 and 7 year olds. At the same time, the girls in our street were playing with dolls because you know, boys are supposed to play with Lego and computers and girls are supposed to play with dolls and pink tea sets. At least, that's the rules society systemically imposed on the world. Back then if there were a microcomputer in the house, girls typically got very little time on it. It's easy to assume that "because I did it, anyone can", but the fact is that if you compare boys and girls and computers, especially at our age, the gender gap becomes massive because of all the problems that have been imposed on us by the world out there. And since it's not Debian's fault that the world is like this I suppose it's fair of people to ask "But why is this Debian's responsibility to solve!? Why should we commit any resources to solving this problem!?". Honestly, I don't think it's a problem we can solve right now, but at the very least, we should do whatever it takes to not be part of the problem, and we should take every small step we can take to be the good guys and help shift things toward equality. Sure, this means that we might invest a lot of time, effort and money in to some individuals that end up elsewhere. Maybe a woman who started out with us ends up going to work for Red Hat. Maybe she comes back to Debian and contributes skills she learned there back here. Maybe women that got started with OpenSUSE outreachy initiatives end up here. I think that's all ok, if all organisations keep contributing, then all of them will eventually get some ROI out of it in terms of investing in people. > I don't think the majority of people in the FOSS community can claims that > they received a sponsorship early on to be able to join the community. On > the contrary, most people will have probably spent a fair amount of money > and their own leisure time to get things done, Linus Torvalds being one > of the most prominent ones who didn't even have the money to pay for his > first i386 machine in full but rather had to finance it through a loan. Linus is an exceptional person and most people who had more than him ended up being very mediocre. But even he had a lot going for him. He went to a fancy university in Europe where he got to learn Unix/Minix and he had his own 386. I think you're setting an unrealistically high expectation if you want people who have less than that to have to aim as high as being like Linus. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
Hey Enrico On 2020/03/18 11:58, Enrico Zini wrote: > On Wed, Mar 18, 2020 at 11:36:24AM +0200, Jonathan Carter wrote: > >> My honest answer? Yes, it would be nice if all the delegates could be >> project members, I understand your concern, but often it's best to be >> willing to work with people who are willing to do the work. > > Note that another option available to address this, which has been used > before and isn't used as often as it could, is to ask DAM to have a look > at the missing membership problem. Excuse my ignorance, could you explain what this means? Do you mean that DAM could be asked to create a more formal level of contributor status that's not quite yet a project member? -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: Question to all: Outreach
On 2020/03/17 18:32, Hector Oron wrote: > Debian Outreach looks like an awesome initiative to bring new blood > into Debian and also people coming from minority groups, however, on > the other hand, it has been a quite expensive to run for the real > benefit provided to Debian project. Reading the delegation text: > https://lists.debian.org/debian-devel-announce/2019/03/msg00011.html. > I find 2 out of 3 team coordinators are not Debian > contributors/developers, and the other seems to be inactive. > > Q: How do you feel on having non-Debian contributors/developers > being DPL delegates? As it happens, I'm an example of someone who was a DPL delegate when I wasn't a DD yet. This was when the delegation for the DebConf committee was established: https://lists.debian.org/debian-devel-announce/2017/01/msg3.html My honest answer? Yes, it would be nice if all the delegates could be project members, I understand your concern, but often it's best to be willing to work with people who are willing to do the work. I would suggest some minimal vetting for outsiders who become delegates, for example, just like when someone gets access to Debian machines have to agree to the DMUP, delegates should agree to uphold our community standards (like the CoC for example). > Q: Do you see any flaws on the current Outreach setup? If so, how > would you address them? Yes, there are huge obvious flaws and big problems when it comes to outreach initiatives in Debian. I don't think anyone can deny that. The biggest of which is that we're simply not doing enough about it and we're not committing enough resources toward the problem. I agree that we *might* be able to come up with some more efficient programs that have greater impact for the same amount of money, but then we need Debian contributors who will do all the work and co-ordination to make that happen. Few people seem to have the time and energy for that at the moment. As for how I would address that, I know some Debianites hate the answer of "more discussion", but I think it's what's needed. We need more answers, more ideas, more people to step up and do work, frame the exact problems that we intend to solve and then use our collective skills to hone on on those. I know this answer won't be enough for some people, but I just can't make promises on this front as a prospective DPL, I think it takes the whole project to make this happen and drive it forward to make it a success and to get the best bang for our buck. In the meantime I'm glad that Outreachy can help take care of some of the work. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to all: Outreach
On 2020/03/17 22:45, Ulrike Uhlig wrote: > (I have no idea if I am allowed to reply to this, or if only DPL > candidates are supposed to reply. Hence forgive me if I'm overstepping a > boundary here. Please tell me if that is the case by the way.) Not problem whatsoever, imho it's important that DPL candidates also gain input from what's important from the project members. I also feel it's a bit silly that we only do this once a year, and I feel that we should have feedback sessions for the DPL at meetings like DebConf as well as online meetings. We've seen at least one lengthy mail from an individual DD on the list, so if someone would have a problem with your comments then that would be a double standard. I don't think there's a need to move a discussion to -project unless it starts to deal with things that are too detail orientated that's not relevant to this election. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Question to Jonathan: how do you intend to prioritise?
.debian.social/paddatrapper/remote-conference-software - but I'd like to keep encouraging this kind of work whether I'm DPL or not. For local teams, I was really happy to see Fabian Rodriguez excited about re-invigorating the local teams concept at DebConf17. He was also involved in Ubuntu local teams where it worked well for a while, so I believe he has the right combination of skills and ambition to pull it off. I think he initially found the lack of response a bit lackluster and lost interest. I don't think Debianites were particular unenthusiastic about it per sé, but I think it was just a case that his initiative wasn't announced widely enough, and that it could have had more support from leadership within the project (and with that I mean absolutely no criticism towards the DPL of the time). I'd like to reach out to Fabian and ask if he's still interested in this, and I think there should be a small budget for stickers and materials set up so that local teams could receive some free packs of goodies. I think it could help ingest at least a little bit of new energy into our local teams world wide. Stronger local teams have so many positive knock-on effects too, like more teams who could bid for DebConf. So many people would like to see a DebConf in Europe again, and there are so many big cities there, yet those cities generate few bids. More strong local teams will result in more bids everywhere. Strong local teams also help strengthen translations and help address locale-specific issues in Debian, and make support easier for newcomers, but I digress. When it comes to local teams, I don't intend to personally and directly lead local team efforts, but I'd like to help and encourage others who have had the ideas to try it out and give them every possible shot at making it work. I could give you concrete examples of the rest of my platform too if you'd like, although this mail is already long and I think I've shown that the ideas listed there are more than just a bunch of nice words on a platform. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: Typically self-nominations are short
Hi Sam On 2020/03/12 14:54, Sam Hartman wrote: > I'm concerned that by sending my longish message about why I am not > running, I may have started a trend that I do not value. No need for you to be concerned at all, your post had zero influence over the length of my email, so no need to stress about it. This was how I chose to self-nominate and it was my choice to make. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Why I'm running for DPL
, the project can learn from their experience. I'd work towards fostering a culture where we're supportive of new ideas and people who want to run with them. 3. Community building, working towards improving communication Many of us have been to DebConf a few times (and some even to a whole bunch of MiniDebConfs and similar events). Those are great! And if you live in a densely populated area like most of Europe or Asia, you usually have plenty of options for Debian events. For many contributors around the world, getting to those kind of events are hard. I think we should work at improving our communication methods and have better global remote participation throughout the year. Due to covid19 and an increasing number of people who wish to cut down on emissions, I think it's extra important this year that we work on this. == Time and support consideration == Just this morning, I was wondering how I can work more time into my schedule for more sleep and exercise. I know running for DPL is directly counterproductive to those goals, but if there are people who vote for me, then I hope and believe that I could count on those same people for support in the goals above, and that they could help lessen the load. I don't think that a DPL should try to carry the world upon their shoulders, and should be open to letting other project members help and form teams to deal with bigger issues. == Running for DPL == I didn't want to let the nomination period slide over to next week as it did last year, so I'm hereby announcing my intent to run for DPL, and early enough so that others can still post their self-nomination before the week is over. If you have better ideas than me, then please consider running, I ran for DPL last year too and thoroughly enjoyed the experience even though I wasn't elected, and when multiple individuals run for DPL it generates higher quality discussion that is ultimately good for the project. I'm running for DPL because I think Debian is worth protecting and worth working for making it an enjoyable and productive environment, I think in some ways we ended up in survival mode and we need to evolve past that and allow the project to thrive. I'm usually a lot more concise, but if you've made it this far, then a sincere thank you for reading :) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. signature.asc Description: OpenPGP digital signature
Re: Last minute cominbations G+D and/or G+E
On 2019/12/04 19:14, Ian Jackson wrote: ... > 7. Software is not to be considered to be designed by upstream to work >exclusively with systemd merely because upstream does not provide, >and/or will not accept, an init script. I believe that the combination is better than the original individual proposals. Have the original submitters consented to such a merge? I think that would be an important blocker before I could second this. If this merge would go ahead, I assume all the existing seconds would fall away and it would need new seconds. For the record, I don't mean to put any pressure on the secretary whatsoever to extend any deadline, I think there is enough options to put together a vote that can produce results that will be reflective of where we stand as a community, but I think with the proposed merge it would be a bit better and shouldn't delay things by much. And on a personal note, I think at some point you also need to let it be so that you don't lose any sleep about it and not forget to take care of yourself*. -Jonathan *Which is rich coming from me, because I've mulled a lot of the recent discussions in my head when I should have been sleeping myself. -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies
On 2019/12/04 19:11, Svante Signell wrote: > I've purposely kept out of this discussion, hoping that you all can > behave in a civil manner. Obviously not. I don't rank you mail > defective, there have bee several other on this list. Anyway, this > whole GR is about systemd or sysvinit, and everybody pretends they > don't know about alternatives, like OpenRC, initng, runit, monit, s6, > daemontools, and especially Shepherd. Are you all blind to Free > Software progressing steadily, in spite of something that would hurt > Debian as a distribution for many years to come? I don't believe that that kind of tone is welcome on this list. I understand how you could feel that way, but if you read a bit closer you would see that openrc, runit and other init systems have come up multiple times on this list and on debian-devel recently. A few people have mentioned that sysvinit scripts come up in discussion so much because they tend to be a common denominator that can be used across init systems as a fallback, the people who refer to sysvinit scripts in such a fashion do not intend to imply that the alternative to systemd should be sysvinit per sé. If you look at the current proposals[1], none of the options explicitly mention sysvinit, it talks about systemd and other init systems, I doubt it's at all necessary to mention all of them by name. Anyone who cares about init systems other than systemd probably already uses one or more of those. -Jonathan [1] https://www.debian.org/vote/2019/vote_002 -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Proposal to overturn init systems premature GR
On 2019/12/04 09:22, Scott Kitterman wrote: > I think short circuiting the discussion process casts into question the > legitimacy of the process. > > I think you are wrong here. How can one know where to rank option G when > it's > clearly incomplete. I don't know if I like it or not. Let's finish the work > on getting the ballot right and then vote. Absolutely, losing another day to get a proposal right is a very small price to pay in the grand scheme of things, where rushing it creates the risk of having to repeat it all again in the future. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Proposal: Init Diversity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2019/11/21 13:23, Ian Jackson wrote: > Those aren't the grammar fixes I would be thinking of. I expect > we will sort those things out :-). > > In the meantime, I also second this proposal. Notwithstanding some grammar/language issues already mentioned (and perhaps s/to be value/to be of value), I also second this. - -Jonathan - -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEExyA8CpIGcL+U8AuxsB0acqyNyaEFAl3Wd0cACgkQsB0acqyN yaF8lBAAnnJLAGS8SGzcoIcrWw34LJk0b93329byJoT7jruIMYJDS8gW15dK/x6d sswqss2VxXnDb19Xn2S0Ssfn6lRL1cbJCcg4k6sORXeSgald/SjBIgONkHGRKgdT fAa8d3prh2LMEs6lt4ye+l99QIxCaQkqZlgR9WnJIQq2sJbT1h5Z1yPwRPtNvjAD +htAYzChp2qjEAtAwVapkof60hx7b9LtRgoA4LiVVjy3gtuHGGODnLgpLkarxAf4 Nzt74soyQBf8LgCfA056D5yxheODV1lb7u9Tz6OLncgXpiOaU2x7Nv4N5gnSRskW NaBw7C3GmkQVK7DJJ9mkWsk0DWAIDKwXlSZsrufoTvRBjvHTCvxwd5Mtr4Lmbxx2 hze9gnwteYTNXUdSKrhacdxSGKyfPWLmRHe3q/xhummQ+ixrGPtm0vTg7Wtu5AZ/ zjLtvMMdwboW0pTXh4KlmxaQMg8Fjo2avyyj4RHcdEv1kNQcQGFS1+VkL8/gRFJ5 /LxFK8YBFNFRO6UWN6MRDa0mIJTxwtSCZkAczozCQSq/50Nn7SBGrdFztW86poU4 bvlZ/shfybu7sD+NWKjsupB3dqGfUYKNoV+H12qrL7nzU2BWuAAjUreDTviBcsAY 0bmSmiKCVW1oMOY4T2/3RZ5IhaPv+gffPfIsW7KDn0SqKi7ZGMc= =fE5u -END PGP SIGNATURE-
Re: First Debian community-wide IRC sessions scheduled: Meet the new DPL and ask him anything!
On 2019/04/21 19:21, Holger Levsen wrote: > will you use meetbot(.debian.net) to provide logs etc? > and maybe you want to annonce this somewhere else than -vote@ too. Yep, meetbot is there and publicity team will publish it to bits between 3-5 May and then again closer to the time again on micronews. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
First Debian community-wide IRC sessions scheduled: Meet the new DPL and ask him anything!
Hey Debianites As you probably know by now, Sam Hartman won the election and is now our new DPL (congratulations!). Sam and I have been talking over the last few weeks and Sam knows that he has my full support for his role as DPL, he also supports some of my ideas and we'll be collaborating on some of them. The first of these is re-booting the #debian-meeting irc channel (https://wiki.debian.org/IRC/debian-meeting) and schedule general community meetings there. Our first session has been scheduled: Topic: Meet the new DPL and ask him anything! Date: 2019-05-10 Time: 10:00 UTC IRC Channel: #debian-meeting on oftc The questions you'd be able to ask on IRC won't go as deep as they have on this channel, but it's still one of many good ways to stay up to date with the plans of the DPL and get some more details on what they entail. If anyone is willing to help moderate the session, please get in touch. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Thank you to all of the candidates
On 2019/04/06 19:00, Russ Allbery wrote: > Thank you, all of you, for volunteering and being willing to devote a > significant chunk of your life for the next year to the project, and for > the excellent discussions we've had over the past two weeks (which have > made me personally quite excited about Debian going forward). Thanks for all the kind words! I had lots of fun and will likely run again next year if circumstances allow. -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Thanks for the questions, any more before voting starts?
Dear debian-vote Thank you to everyone who has contributed questions over the last few weeks. They have certainly provided me with a lot of food for thought and will play a role in the directions I follow within Debian regardless of the outcome of this election. If there's any particular stance or something that you'd like more details on, or if there's something that's nagging you that hasn't yet been covered, then now is probably a good time to ask :-) -Jonathan -- ⢀⣴⠾⠻⢶⣦⠀ Jonathan Carter (highvoltage) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL
Hi Chris On 2019/04/03 15:00, Chris Lamb wrote: > On 2019/03/29 16:01, Jonathan Carter wrote: >> I agree that an overloaded DPL role can be harmful to both Debian and >> the individual in the role. I think it's important for a DPL to take a >> step back every now and again and look at the various properties of the >> role and ask "Is this working?". If elected, I do plan on filing bugs >> against the DPL role if I feel that something can do with improvement. > > I'd be very interested if you and the other candidates could elaborate > on their thoughts in this approximate area. > > As a bit of background, I've actually written this reply twice before > (or, admittedly ones somewhat similar) but it was difficult for it to > come across as not appearing churlish or otherwise grumbling about my > experiences. However, I hope with this paragraph, readers will read > it in its intended context regardless. :) > > So, in general, I fear that the candidates may be over-estimating how > much of the DPL's tasks can be delegated to teams or other individuals. I did notice that some candidates (not going to point them out) did put a lot of emphasis on this aspect, I think it may be because it was very topical right around the campaign start date. Having said that, I think if it's possible to even just reduce the DPL workload overall by as little as 10% by shedding some work that can be delegated, then it's worth while spending time on it. > A lot of teams have entirely-legitimate questions before acting (for > example, checking over some document) and often check-in with the DPL, > asking for advice, guidance or whether the Leader's experience or > contacts mean they have been exposed to a novel angle or approach to > what they are trying to achieve. This is, of course, eminently sensible > and healthy IMHO. Yep, I'm 100% with you on that one. > More importantly however the majority of tasks that land on a DPLs > plate may technically and «prima facie» be delegatable but the total > time and energy required to forward it, ensure it is correctly > followed-up on, context switch, ping later, forward any replies, etc. > etc. etc. regretfully exceed said time/energy of just "getting it > done" yourself to begin with. Ack. > I suppose part of the solution here might be to ensure and promote an > atmosphere where teams feel more empowered to push ahead without > quasi-approval (as well as ensuring some requests reach the "right" > place in the first place) but these are really far harder, long-term > goals that would require supreme dedication to even start to move the > needle on. I'm afraid I would be somewhat skeptical of any candidate > who thought they possess any sort of magic bullet to any of this > before being truly exposed to it outside of the abstract concepts I've > outlined above. :) Heh, I hope you don't consider me a «summa stultus» then, because if I couldn't move the needle on that one I would certainly not run for a second term. I'm sure you're aware that a core part of my platform is to address part of the above. At least I can assure you that I don't believe in any magic bullet. I believe it's something that we'll have to work on together systematically as a project. It sometimes feels like there's this mass delusion in Debian, where a large amount of people believe that they have good ideas and that everyone else is against them in implementing those good ideas. This is exacerbated by people who mean well, but instead of looking for reasons to support an idea and build on it, they see it helpful to play devil's advocate to their maximum capacity, which muddles the water and confuses bystanders, and ultimately distracts everyone from the actual issues. Whether it's going to be easy or not, and whether we're going to make huge progress or just little on these fronts is irrelevant to me. What's important is that we try and that we take any small win that we can and build on it. If we're going to have the attitude that community stuff is hard and that we want to have it all or nothing, then we're never going to make any progress on improving our «genius loci». > Indeed, some of these issues are not /really/ solvable in the sense > that I'm not sure I, as a member of the Debian community, would want > to be without the option of being able to ask the Project Leader for > their connections, experience or plain-old sanity checking before > doing something especially if that action might affect the reputation > or image of the Project. My cell phone number is in db, and I invite any DD to contact me on signal or on IRC or by e-mail any time they believe that I could help with anything, especially in the sense if they want a pair of extra eyes on something or to just to soundboard. This will continue to be true if
