Re: Question to all candidates: what to do with the Debian money, shall we invest in hardware and cloud?
Hi Thomas, I overlooked this the first time, but On 2024-03-29 16:03, Thomas Goirand wrote: > FYI, if I didn't go forward with the project, that we've been discussing > with Jonathan over at least 3 years, is because I have no idea where to > host it. I have clearly stated that having this hosted at *my* company > (ie: Infomaniak) is *not* what I want to do to avoid any type of > conflict of interest. I am staying firm with the idea that I shouldn't > do that. I understand your position morally but from a practical POV, speaking as someone who's currently hosting servers in his living room, any hosting option would be an improvement to me and one with by a Debian Project Member even more so. And strictly speaking (1) I don't see a conflict of interest and (2) even if there were one, these can be disclosed and dealt with. Hosting isn't that opaque. Best, Christian
Re: General Resolution: Liquidate donated assets as soon as possible
On 2022-06-20 20:31, Louis-Philippe Véronneau wrote: > I don't see GRs as "adversarial" or "a last resort to put a nail in the > coffin of a divisive debate", but as a great tool we have to take > collective decisions. I find it difficult to not see a GR as adversarial when deciding things on a particular topic has been entrusted to delegates, though. Best, Christian
Re: Question to all candidates: GDPR compliance review
On 2022-04-02 10:55, Adrian Bunk wrote: > Where does our Privacy Policy[1] describe personal data where Debian and > the community team are joint controllers? > Where does our Privacy Policy describe personal data where Debian and > DAM are joint controllers? Has it been established yet that Debian fits the definition of a controller as per Article 4 lit. 7 GDPR? I can see DAM, or CT, or the DPL possibly being controllers. But without some form of officially recognized organization, I don't see how Debian could be one. "Debian" doesn't even have an address, you couldn't even determine which data protection authority has jurisdiction. This is just one of the things that, I think, would be a lot simpler if Debian would register as an organization, hence my question [1] to the candidates. [1] https://lists.debian.org/debian-vote/2022/03/msg00135.html
Re: Results for Voting secrecy
On 2022-03-28 01:22, Christian Kastner wrote: > > On 2022-03-27 19:31, felix.lech...@lease-up.com wrote: >> Would you please explain why Option 2 defeated NOTA by 124 votes but at >> the same time defeated Option 3, which was identical to NOTA, by only 35 >> votes? > > This seems to be inline with what the proposer intended, though. From > the text of Choice 3: > >> [...] which is also why I explicitly want to see "keep the status >> quo" on the ballot, and not only as "NOTA", but as a real option. Having thought about this some more, I think the suggestion that the options are identical is quite simply incorrect. Somebody inclined towards voting secrecy but unhappy with either of the two proposed solutions of this particular GR might have voted 4123, leaving room future GRs with alternative voting secrecy proposals. Somebody unconditionally opposed towards voting secrecy would have reaffirmed the status quo with 3412, indicating that any future voting secrecy proposals would also be rejected. The latter explicitly reaffirms the status quo, the former does not. I guess this is why Holger proposed Choice 3.
Re: Results for Voting secrecy
On 2022-03-27 19:31, felix.lech...@lease-up.com wrote: > Would you please explain why Option 2 defeated NOTA by 124 votes but at > the same time defeated Option 3, which was identical to NOTA, by only 35 > votes? This seems to be inline with what the proposer intended, though. From the text of Choice 3: > [...] which is also why I explicitly want to see "keep the status > quo" on the ballot, and not only as "NOTA", but as a real option. Best, Christian
Re: Question to all candidates: registering Debian as an organization
On 2022-03-21 12:05, Holger Levsen wrote: > On Mon, Mar 21, 2022 at 09:41:49AM +0100, Christian Kastner wrote: >> A common pattern to address this within the open source world is to >> create a non-profit legal entity, e.g. the FSF Foundation or the GNOME >> Foundation. > > or SPI? SPI is Debian and 39 other projects, as far as I can see. I think Debian should have its own identity.
Re: Question to all candidates: registering Debian as an organization
On 2022-03-21 09:41, Christian Kastner wrote: > Currently, the Project has no legal standing of its > own, meaning that within any legal context, there is no Project. You > can't donate to Debian, you donate to some other organization (SPI). The > DPL can represent the Project only formally, as formally, it doesn't ^^^ only "informally" Apologies.
Re: Question to all candidates: registering Debian as an organization
On 2022-03-20 13:10, Felix Lechner wrote: > I'm sorry no one has gotten back to you so far. I do not know which > ideas Jonathan Carter and Brian Gupta (copied as a courtesy) have been > pursuing. > > My own thinking on this point is also evolving, as detailed below. I > copied Christan Kastner to make sure he sees this expanded answer. I was actually less concerned with regards to malicious litigation (although that is a valid concern), and more with the day-to-day stuff. Currently, the Project has no legal standing of its own, meaning that within any legal context, there is no Project. You can't donate to Debian, you donate to some other organization (SPI). The DPL can represent the Project only formally, as formally, it doesn't exist yet. The Project can't own hardware directly, or hold copyrights directly. It's all down to individuals. A common pattern to address this within the open source world is to create a non-profit legal entity, e.g. the FSF Foundation or the GNOME Foundation.
Question to all candidates: registering Debian as an organization
Jonathan has already addressed this in his platform, acknowledging Brian Gupta's 2020 campaign focus on this, so this is mostly a question for Hideki and Felix: What is your position on registering Debian as an organization? I'm curious as to (1) what you think of the idea in general, and (2) insofar you think this is a good idea, to what extent you'd consider pursuing it during your term(s).
Re: Reaffirm public voting
On 2022-03-04 13:15, Holger Levsen wrote: > On Fri, Mar 04, 2022 at 12:14:56PM +0100, Pierre-Elliott Bécue wrote: >> Is init systems GR a political GR? > > yet there are people maintaining systemd and sysv in public. How is that relevant? I'm neither a systemd nor sysv maintainer, but considering the grief that some other non-maintainers got just for expressing that they favor systemd, I'd rather not vote at all if it's not secret. You of all people should know this. You've spoken out against exactly this kind of grief. You asked for a shield back then, and that's what the people in favor of voting secrecy are asking for now. Best, Christian
Re: Announcing new decision making procedures for Debian
On 01.04.21 10:11, Santiago R.R. wrote: > What happens if Kurt also wants to take part in the discussion? Should > we decide on who will review the messages and announce the winner of > that discussion? I was worried about this, too. I'm not sure that deciding on another reviewer is feasible. Actually, that would probably set us back to right where we started. I think we have to differentiate between two cases: (1) Kurs agrees with the winner (2) Kurs disagrees with the winner (1) is a non-issue, I think. For (2), I could imagine that a best-of-5 rock-paper-scissors tournament as a possible quick solution. That, of course, assumes that Kurt won't manipulate the contest (he still chooses the opponent, after all) but we're all assuming good faith here. Thank you for bringing this up.
Re: ***UNCHECKED*** Re: Re: Willingness to share a position statement?
On 26.03.21 01:06, Simon Richter wrote:
>> (2) how deeply Debian gets involved
>
> We are in a prominent position. The OSI's Open Source Definition is
> derived from the Debian Free Software Guidelines, after all, not the
> other way 'round.
>
> There is no way for us to not be involved in something that affects the
> whole free software community.
Sure, but we have a choice as to how we get involved -- the specific
actions, or inaction. See the ongoing GR.
All I'm saying is that when people speak out about the wish to be
apolitical, the term 'apolitical' should not be taken in the widest
possible sense, which covers any action or inaction, and then dismissed
for being impossible.
Rather, in should be understood in a stricter sense, namely of favoring
inaction ("political inactivism", if you like).
Re: ***UNCHECKED*** Re: Willingness to share a position statement?
On 25.03.21 22:32, Simon Richter wrote: > Pretty much everything Debian does is political > the "technical" decisions we make based on that also have political > consequences. That's taking meaning of the word 'political' in the widest possible sense, and in that sense, literally any action (or inaction) carried out by an individual within a society is political, because they all have consequences. I interpret the calls for Debian being apolitical (to some degree) as calls differentiating at least between (1) whether specific political consequences are intended or not (2) how deeply Debian gets involved (3) effects are directly or indirectly caused (4) degree of effect.
Re: How to leverage money to accomplish high impact Debian projects
On 23.03.21 17:28, Jonas Smedegaard wrote: > If Debian paid for working on orphaned packages, then I would probably > orphan some of the packages I now maintain as a volunteer, to then work > on those same packages for pay. First, I think that at least two alternative scenarios have to be taken into consideration: (1) Someone else who is interested in the package picks it up (2) There is not much interest in the package anyway, and it gets removed from the archive > I would not consider that cheating: Some of "my" packages are > genuinely less fun to maintain, and would certainly be *lesser* fun > if knew that others were paid for doing similar tasks. Playing the devil's advocate, and assuming (1) and (2) from above do not apply: what would be wrong with that? * You got rid of a package that you're not having any fun maintaining, and can focus on other fun tasks * Someone gets paid to improve Debian * Debian's users get an improved Debian * Debian's donors see their money put to actual good use I am *not* advocating for this solution. *If* one were to go down this path, then clearly this would need far more debate. I'm just saying that sometimes, it's necessary to look at a problem from many angles.
Re: How to leverage money to accomplish high impact Debian projects
On 23.03.21 16:40, Gard Spreemann wrote: > Jonas Smedegaard writes: >> Seems backwards to to me to pay for keeping packages alive that we have >> lost interest in. > > That's a good point, I agree. What about packages that we have lost > interest in, but that our users very much have not? Admittedly, I have > no idea of what the cardinality of that intersection is. > > Or alternatively: are there hard-to-maintain packages that are highly > useful to users, but where there just isn't enough interest to overcome > a very high maintenance burden? Could paid work help offload the > maintainer of such packages (leaving them with more of the fun parts and > less of the non-fun ones)? Indeed, that's exactly the point I was trying get at in my other question to the DPL candidates. I've amended that other questions with a quantifiable, and thus hopefully better example of what you describe above: RC bugs in stable.
Re: How to leverage money to accomplish high impact Debian projects
On 23.03.21 16:04, Louis-Philippe Véronneau wrote: > On 2021-03-22 16 h 43, Didier 'OdyX' Raboud wrote: >> Le vendredi, 19 mars 2021, 17.49:54 h CET Louis-Philippe Véronneau a écrit : >>> I for one would be less motivated to help with videoteam tasks if I knew >>> someone was paid to organise a miniconf. >> >> Would your motivation also be affected if an individual was paid only for a >> specific task that noone in the team found particularily interesting to do? > > I'm not opposed to paid labor per-say. I think the previous examples of > Debian paying TOs to do accounting is a good one. > > So to answer your question, I wouldn't be opposed if we contracted an > enterprise to handle our gear for us. > > I don't think it's something particularly fun to do and I see that more > as an administrative task, akin to accounting. > > "Organising a miniconf" isn't though. Why would someone get paid to organize one, though? I've never organized one, but it was my impression from others that this was always done voluntarily and from own initiative.
Re: How to motivate contributors to work on QA
Dear DPL candidates, I would like to expand on the following example with a data point: On 23.03.21 10:42, Christian Kastner wrote: > 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. According to [1], there are currently 485 RC bugs affecting stable. I assume that the number of non-DSA security bugs affecting stable is notable, too. Clearly, most of those packages have active maintainers, so it's not an issue with orphaned/RFA'd packages. I'm going to go out on a limb here and make a bold assumption: these bugs aren't fixed because reproducing, diagnosing and fixing a bug in stable is generally far more resource-consuming than fixing something in unstable, and thus hits the limits of volunteer work earlier. Our commitment to quality is apparent in the process of a new release, with the song and dance of transition/soft/hard freeze, and all that they entail. But what can the Project do to uphold this commitment even *after* a release? Isn't that the release that most of our users will be using? And, more specifically (again showing my bias), why shouldn't the Project use its significant financial resources to address this problem? Not necessarily to motivate the maintainers, but other contributors, say, in the form of bug bounties, or whatever? Best, Christian [1] https://bugs.debian.org/release-critical/other/stable.html
Re: How can we make Debian packaging more standardised?
On 24.03.21 15:37, Simon Richter wrote: > The vast majority of the software we ship works fine with a two-line > systemd unit and three debhelper control files, and that is exactly what we > should be using for these cases, but we cannot generalize that to a > requirement, and people wishing to contribute to packages not served well > by the abstraction will continue to need to look under the hood. Not to diminish your detailed assessment (which I agree with), but just to clarify: with "standardize", I was thinking more of a de-facto standard as you describe it in the first sentence, and not a hard requirement. I just vividly remember how difficult it used to be to contribute to some of the other packages even as a DD, and appreciate how much easier it has become. And for packages that make use of Salsa's rich features (like merge requests, pipelines, etc), I think the experience is even better. Although I admit that this is highly subjective. Best, Christian PS: I mentioned debhelper a few times, when I actually mean "dh". Recognizing the fact that most software more or less follows one or the other build procedure, auto-guessing it, and then enabling the escape hatches that you mentioned was a brilliant idea.
How to motivate contributors to work on QA
Dear DPL candidates, the topic of paying developers for Debian work has been raised a few times in abstract terms, and in your answers, I think you made it more or less clear where you stand. 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? Best, Christian
Re: How can we make Debian packaging more standardised?
On 22.03.21 19:41, Paride Legovini wrote: > Louis-Philippe Véronneau wrote on 19/03/2021: > https://michael.stapelberg.ch/posts/2019-03-10-debian-winding-down/ > > I think that the lack of standardization and the fragmented > infrastructure is in good part the root of most of the problems he > outlined, as the "old infrastructure" ones are made difficult to fix by > the fact that Debian notoriously supports infinite workflows, which > makes introducing wide-scope changes very challenging. It's not that long ago that we supported 6(?) different SCMs, and probably as many build helper tools. A good share of all the bugs I have reported where submitted without further analysis or solutions, simply because doing so involved learning some fringe build tool. The (1) adoption of debhelper by my most packages and (2) the move to Salsa have been an absolute blessing. They have made contributing to other packages so much easier. I hope we continue further down this path.
Re: Should the project hire one or two persons to help the DPL?
On 19.03.21 19:47, Sruthi Chandran wrote: > The complete volunteer nature of Debian is one of the important > and attractive point that makes Debian different from other distros. The complete volunteer nature also means that certain tasks/chores get done slowly, or sometimes not at all. For example, I don't think LTS support would be what it is without Freexian funding. The funding makes it a win-win for both users and developers.
Re: How to leverage money to accomplish high impact Debian projects
On 19.03.21 11:29, Enrico Zini wrote: >> 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. > > Thinking at how we set our bar for membership in building a reputation > within the project, I imagine we implicitly select people who are able > to sustain themselves reasonably well without Debian's help. That might be the case, but generally speaking, that self-sustainment is achieved by devoting one's time to some other cause, like $DAYJOB, hence the lack of time for Debian. I have the suspicion that quite a few Project members have somewhat flexible jobs (freelancers, or project work, or part-time work), and I believe that a financial incentive might enable them to dedicate more of their time to Debian, than to other projects. I also think that it's important to make a distinction of what gets paid and what doesn't. A frequent counter-argument I hear to getting paid for Debian work is that it would be unfair to those not getting paid. I disagree with this. Not all tasks are equal, and I many Debian chores come to mind that nobody wants to do, but still have to be done, and we're grateful to that one person doing it once very four weeks. I think financially motivating it someone to do that chore once a week, or even more often, would be worthwhile.
Question to Brian: Why multiple foundations?
Brian, I very much support your plan to establish a Debian foundation. Looking back over even just the last few months, I saw numerous challenges that would have greatly simplified if there were a legal entity representing the Debian Project. Having various Project-wide issues, but representation within these matters, and especially liability for them, boiling down to individuals, is IMO no longer a way to run a project of this size and significance. Furthermore, > The Foundation's board would be elected by the Debian Project Members, and > the DPL would automatically be a full member of the Foundation's board. is just fantastic. It gives my the direct power to influence the foundation with my (digital) vote, and limits the influence to just Debian Project Members. My question though, is: Why three foundations (US, FR, CH)? I get that being directly represented in these jurisdictions would have its advantages, but overall, wouldn't the downsides over-weigh? For example, in case of a trademark, which entity would legally own it, and how would the other entities represent it in their respective jurisdictions? Legally, of course there are solutions, and probably not even that hard to figure out. However, I have the impression that the overhead/bureaucracy this would add would be noticeable. Christian
