Re: A policy on use of AI-generated content in Debian
Le Thu, May 02, 2024 at 02:01:20PM -0400, Tiago Bortoletto Vaz a écrit : > > I would like Debian to discuss and decide on the usage of AI-generated content > within the project. Hi Tiago, as a Debian developer I refrain from using commercial AI to genereate code used in my packaging work or native packages, because I think that these systems are copyright laundering machines that allow to suck the energy invested in Free Sofware and transfer it in proprietary works (and to a lower extent to un-GPL works). If I would hear that other Debian developers use them in that context, I would seriously question whether there is any value to spend my volunteer time in keeping debian/copyright files accurate to the level of details our Policy asks for. When the world and ourselves will have given up on respecting Free Software copyrights and passing attribution, I will not see the point spending time doing more than the bare minimum, for instance like in Anaconda, where you just get License: MIT and the right to download the sources and check yourself the year of attribution and names of contributors. This said, I have not found time to try debgpt and feel guilty about this. If there will be a tool that is trained with source code for which the authors gave their consent, where the license terms were compatible, and provides its output under the most viral terms (probably AGPL), I would love to use it and give attribution to community of contributors to the software. So in summary, I probably would vote for a GR calling against the use of the current commercial AI for generating Debian packaging, native, or infrastructure code, unless of course good arguments are further provided against. This said, I think that we can not and should not control for people not respecting the call. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Aw: Re: Community renewal and project obsolescence
Le Fri, Dec 29, 2023 at 01:14:29PM +0100, Steffen Möller a écrit : > > What hypothese do we have on what influences the number of active individuals? When I was a kid I was playing with a lot of pirate copy of Amiga and then PC games, and I had a bit of melancholy thinking that what appeared to be golden days took place when I was still busy learning to walk and speak. I wondered if I was born too late. Then I was introduced to Linux and Debian. That was a big thing, a big challenge for me to learn it, and a big reward to be part of it. At that time I never imagined that the next big thing was diversity, inclusion and justice, but being part of Debian unexpectedly connected me to it. Now when I look back I do not worry being born too late. I would like to say to young people that joining a thriving community is the best way to journey beyond one's imagination. Of course, we need to show how we are thriving. On my wishlist for 2024, there is of course AI. Can we have a DebGPT that will allow us to interact with our mailing list archives using natural language? Can that DebGPT produce code that we know derives from a training set that only includes works for which peole really consented that their copyrights and licenses will be dissolved? Can it be the single entry point for our whole infrastructure? I wish I could say "DebGPT, please accept all these loongarch64 patches and upload the packages now", or "DebGPT, update debian/copyright now and show me the diff". I am not able to develop DebGPT and confess I am not investing my time in learning to do it. But can we attract the people who want to tinker in this direction? Not because we are the best AI team, but because we are one of the hearts of software freedom, and that freedom is deeply connected to everybodys futures. Well, it is too late for invoking Santa Claus, but this said, best wishes for 2024 ! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://fediscience.org/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Debian is not X (was Re: Questionable Package Present in Debian: fortune-mod)
Le Fri, Aug 18, 2023 at 07:46:51PM -0500, G. Branden Robinson a écrit : > > "Debian is not X, it's an operating system" is an old trope Well, X is only one month old, and Debian is 30 years old, so the comparison is not fair. This said, X contains many more fortunes than Debian, and for many more tastes than we provide a the moment. I think that we should stay specialised. Random short texts for X, and system operation for Debian. Expecially that although one can not run Debian from X, it is possible to browse X from Debian. Charles
Re: Brief update about software freedom and artificial intelligence
Dear Mo, thank you for the heads-up. I was using permissive licenses in the past thinking about making life easier to individuals, but I feel robbed by massive scrapping to train AI models. Just in case I updated my email signature. Also, is there a DFSG-free license that forces the training dataset and the result of the training process to be open source if a work under that license is present in the training data? Would GPLv3 be sufficient? Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from home https://framapiaf.org/@charles_plessy - You do not have my permission to use this email to train an AI -
Re: Fortunes-off - do we need this as a package for Bookworm?
Le Wed, Dec 14, 2022 at 07:33:53AM +, Andrew M.A. Cater a écrit : > > Dropping fortunes-offensive completely (and the associated > translations/extra files in Italian It does not seem to be translations and at least contains original creations. Or maybe one can point me to the equivalent of fanculo in the English package ? I wondered about the absence of a French version. If I would make one, would it have to offend me or to offend others ? Actually, I am not sure to want the answer... Or maybe the answer is the following: if I write a pet package containing pieces of opinion texts that I think are important and upload it to NEW because I believe it is cheap for Debian to distributes it, I bet the answer will be something "please distribute it yourself until it demonstrates relevance beyond your own circles". Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Fortunes-off - do we need this as a package for Bookworm?
I got curious at the offensive fortunes so I looked at English and Italian ones. I wrote a couple of comments in this email, that I then deleted... I think that in the XXIth century an ambitious replacement would be to train a "Deep Learning" model with social network trolls to generate offensive statements on the fly. Somtimes, the mismatch between the output and the expectation, while deeply offensive, could be funny or even reveal some neglected traits of our societies. But maybe the model would be too large for our archive, not to mention that the source to train it would be huge. In the absence of such a first-class modernisation, and given the abundance of internet connectivity our current slice of the XXIth century, a good fortune packages could focus on delivering tips on how to find and download the cookie package that fits each users taste. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Re: Evolving away from source package realms
Hi Nilesh, Le Sun, Oct 16, 2022 at 03:16:11PM +0530, Nilesh Patra a écrit : > > IMHO the "risk assessment" for most DDs is already done via NM process. > Usually people are mindful of when they upload, and do ask others > for opinions when they do NMU's. The risk assessment I suggest is for the archive, not for each people individually. Simple questions (please let's not discuss answers) such as: - What if a DD gets their keys plus password lost and found or stolen by a third party ? - What if a DD turns so spiteful that harming Debian becomes more important than protecting their reputation ? - What if a hostile upload happens and is undetected for a while ? - What if a hostile upload happens and is removed before it does harm ? - What if a hostile upload happens and is blocked even before it reaches the mirrors ? Will the world applause or will our reputation be harmed anyway ? - What is a hostile upload ? Have we thought about all possible case ? Not all answers to these questions imply that limiting upload rights is of high importance. But I think that it is important to take the time to think about them. > I can understand. However that is not true for a lot of DDs (including me). > Many people do need archive-wide previledges. Tobias gave a rather crisp > reason > in their mail. That is very true. Upload restrictions come with a cost. The main message I would like to pass is that maybe in the course the development or maintenance of our infrastructures, that cost will drop. If it is easy for those who need to get archive-wide priviledges, it is also easy to start without that priviledge as a default. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Evolving away from source package realms
Le Wed, Oct 12, 2022 at 12:14:35AM +, Scott Kitterman a écrit : > > What fraction of security issues we've had in Debian do you think > narrower upload permissions would have prevented? Exactly zero. But my comment is not about the past, it is about the future. I think that a proper risk assessment would be worth doing, an I also think that this mailing list is not a proper place for doing it, not because of secrecy but because of noise and lack of focus. Discussing the conclusions here would of course be important. On my side, I would be fine if my upload key would be restricted to the packages that me and my packaging team maintain. I am very unlikely to need archive-wide privileges in the near future. Have a nice Sunday, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Evolving away from source package realms
Hi Didier, An interesting side effect of your proposal is that Debian's security will be higer as uploading permissions will not be broad by default. And I think that a lightweight processe can be designed to allow DDs to expand their permissions. Have a nice day, -- Charles
Re: We need to define a path for Debian to climate neutrality
Le Wed, Sep 21, 2022 at 06:49:59AM +0100, Jonathan Dowland a écrit : > On Wed, Apr 20, 2022 at 10:36:34AM +0100, Jonathan Dowland wrote: > > Other early steps should include establishing a sub-project/group to > > coordinate discussion and actions around the issue. > > I still think this. Perhaps starting with a dedicated mailing list; > debian-sustainability or debian-climate or debian-? Hi Jonathan, I think that such a list could be very useful and I would join it, hoping that eventually I will learn or acheive something that will help to reduce the environmental footprint of my research center. Just to clarify, in your opinion would each of the following topics be appropriate on this list ? - Reducing the environmental footprint of the Debian project. - Reducing the environmental footprint of systems running Debian. - Using Debian to reduce the environmental footprint of individual or societies. If the answer is no, I would recommend to pick a name that clearly hints to the preferred topic. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Can the Debian Project ever fall?
Le Mon, Jun 06, 2022 at 09:55:40PM +0200, Adam Borowski a écrit : > > We are doing well. The RPM world is collapsing > > The popcorn world: Gentoo, Slack, Arch, Alpine -- they do produce quite a > bit of innovation that _is_ relevant, but as for number of users -- naah, > they hardly count. > > Ubuntu on the other hand is WTF-level unstable. Hi all, I would like to pay tribute to Arch Linux in this thread. When I have a problem, its solution is most often in the Arch wiki. Hats off, Arch ! Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: We need to define a path for Debian to climate neutrality
Le Thu, Apr 21, 2022 at 11:38:20AM +0800, Paul Wise a écrit : > > I would be wary of the legitimacy and effectiveness of carbon offset > products. In Australia the carbon credit/offset scheme was recently > revealed to be fraudulent in many cases and I would not be surprised if > it were found to be similar in other countries. I think a better path > would be to work on transitioning our energy usage to renewable sources > and reducing our energy requirements. I fully agree. I recently started to assess my own energy consumption (in joules which is the International System of Units standard; but note that 1 kWh = 3.6 MJ by definition) and found it to be way more straightforward than estimating CO2 emissions, while at the same time being very useful to provide estimates of scales (to decide where to put the efforts) and of success (how much reduction is achieved). And reduction is a simple but impactful goal, as reduction of polluting energy is a gain, and reduction of green energy used by ones is an opportunity for others to replace polluting energy by the green one being saved. I work in a university of science and technology where high-performance computing is among our heavy equipments, and I calculated that the energy I spend at work is one order of magnitude higher than what I spend in my private life, even including intercontinental flights to visit my family. I would be very excited to find a way to know if efforts such as reducing container size or passing -O3 to the scientific software we package has any chance to make a visible impact on how we can reduce the environmental cost of our research. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Version of Chromium and Firefox ESR available on Stable (Re: Chromium on Debian 11)
Hi all, Maybe we can all cool down and focus on the take home message: "packages.debian.org misleads users about which version of major browsers are available in Stable" On my side, I had the exact same problem with Firefox ESR. So if there is somebody who is familiar with the code running behind packages.debian.org, proposing a fix to the admins would be, in my opinion, very helpful for our users. Have a nice Sunday, Charles
How about using moderation as a delay system for bad threads? (Re: A quiet reminder: please be considerate.)
Hello, Le Fri, Mar 25, 2022 at 11:54:02AM +, Steve McIntyre a écrit : > On Fri, Mar 25, 2022 at 09:09:20AM +0100, Philip Hands wrote: > > > >Unless I've misunderstood completely, we do not judge the content of the > >messages, except that we filter out very obviously abusive trolling that > >the list was suffering prior to moderation, and obviously drop > >SPAM/Phishing/etc. if we see it. > > Agreed, that's exactly the policy. It just takes more time to check > more messages, and I think that's all that Andy was suggesting. How about we make that a feature and introduce a delay of a couple of hours between all messages in threads like this one ? Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: What does it mean to be inclusive
[Busy ? Read the two first lines of each paragraph and skip the rest.] What is inclusion ? For me, inclusion means taking care of letting everybody participate. Aspects of this related with expressing ourselves in a more careful way in order to avoid hurting others have been amply expressed already. I fully agree and am grateful that participating to Debian opened my eyes in many ways. What I would like to tell today is that building a participative consensus requires to give an opportunity to all to contribute to the discussion. The contrary of this is to rely on spearhead groups to prepare a set of well-thought alternatives and ask people to pick their preference by themselves following their own sense of justice and intellect. This is cleaving. In a participative environment, the pace of consensus building is adjusted to the speed of the community. After making a good suggestion to your family, friends or colleagues, have you never refrained from making another one, because you felt that somebody else would do it, and everybody will be happier if the credit for making a good move is more widely shared ? In contrary, on the main Debian lists, there is little attention to this aspect of inclusivity. Often, people who take care of family members, who can contribute only on week-ends or only on business days, who were sick that day or celebrating important moments of their life, etc., or simply are not as comfortable as others in writing English, are left out by spark threads where a couple of good points are made by a few core people, and dilluted by a pile of casual conversations, arguments, fights for having the last words, etc, rendering the whole topic closed, and giving the feeling that nobody is going to listen to what is said by people coming too late if they do not have a big name. I already wrote it too much, but I want to reiterate my call to refrain to post more than once a day in our main mailing lists. Have a nice day! Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: New DEP: Usage of SDPX in debian/copyright
Le Tue, Feb 08, 2022 at 04:02:20PM +0100, Stephan Lachnit a écrit : > I would like to request to take the next available DEP number (17 as > of today). It is about using the SPDX specification as an alternative > to the machine-readable debian/copyright (previously DEP-5). An > initial discussion was started on debian-devel [1], and since there > have been no large objections I would like to formalize it. > > For now, am I the only driver of this DEP. I would like to maintain > the DEP in the DEP Team's repository [2]. Dear Stephan, thank you for your initiative. I just added you to the dep-team/deps project on Salsa. Please open issues if you have technical problems while adding DEP17. Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy signature.asc Description: PGP signature
[solved] Re: My first spam on lastname-firstn...@debian.org address.
Thanks everybody for your quick answers! In summary, the debian.org mail server accepts "-" as local extension character, and it is documented in: - https://wiki.debian.org/DebianServiceForDD#Step_4:_Setup_your_email - https://db.debian.org/forward.html (On my side, I did not manage to get the "+" to work). Have a nice week-end, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
My first spam on lastname-firstn...@debian.org address.
Hello everybody, I am not sure where to post this, so please forgive me if I missed a more suitable medium. This week I received one spam at mylastname-myfirstn...@debian.org (or mylogin-myfirstn...@debian.org, as in my case, login == lastname). Today I tested the address and could confirm that it sends email to me. I was wondering if this alternative address was intended for a purpose, or just an accident. I ask on this list and not directly to DSA in case everybody who filled first and last name information also has this alias. This is not so important on my side but made me curious, so feel free to take plenty of time before answering. Have a nice day, Charles -- Charles Plessy Nagahama, Yomitan, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: [BTB] Asking vs enforcing (was: [Summary] Discourse for Debian)
Le Fri, Apr 17, 2020 at 11:47:36AM +0200, to...@tuxteam.de a écrit : > > - If someone obviously apologizes in public, by all means, >take his/her word for it. Yeah, people lie sometimes (I >know *I* do), but don't assume a lie unless you have >strong evidence for it Hi Tomás I found it great that the Community team reminded that the best apologies are brief and do not get into explanations. I think that it does not question the honesty of the apology. Learning to apologise is actually difficult (we do not want more opportunities to train, don't we), and I think that we also should learn that there is nothing wrong in receiving such advice, even in public like here. Have a nice week-end, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: [Summary] Discourse for Debian
> On Thu, Apr 16, 2020 at 11:26:48AM -0400, Sam Hartman wrote: > > > > I spoke up, a couple people said I missed the mark. > > If I had gotten the mark right, I have high confidence that several > > more people would have chimed in at that point. > > So, yeah, thanks for calling out that I appeared to be in the rough on > > this one. Le Thu, Apr 16, 2020 at 08:47:53AM -0700, Ross Vandegrift a écrit : > > Sorry for not speaking up, but I agreed with your concern. I thought > the summary overemphasized cons and dismissed the pros. +1 I felt that the effort to summarise the pros was not as strong as for the cons. For insance: "easier moderation (for moderators)." For me, this sounds like the problem to solve is to save the time of the moderators. However (and I am not going to rehearse the arguments here), the Discourse platform proposes an entirely different moderation approach. "easier +1 for polls". It is not just for polls and it is a +1 system that our mailing list system does not feature at all. It is not just easier. "attract younger audience". It is not about age. It is about all people who are turned off by mailing lists, regardless when they were born. I also felt that the vocabulary was biased, for instance with "supposed to …" in the pros or "forces existing users to …" in the cons. Altogether, the big missing point is the cons of mailing lists, which are why we are intrested in testing Discourse. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Testing Discourse for Debian
Le Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar a écrit : > > >From my tries with Discourse, it just silently stripped all quotes out > from the reply. Hello everybody, as we discuss about proper quoting, I would like to take the opportunity of Ansgar's email to note that each time a line starts with "From" in a plain text email, something in the pipeline that delivers emails (at least to me) inserts a ">" sign, which is then misinterpreted as a quotation character. See above… In that sense, the syntax for quotes in Discourse is perhaps better. If mutt would learn to color them in green, that would be enough for me. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Testing Discourse for Debian
Le Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton a écrit : > > For any technical topic (including DEPs) it is important that we can > find old discussions in the future, easily, and without there being too > many entrypoints into the search. Hi Sean, in my experience of DEP driver and Policy editor, long discussion archives, especially when they spread over multiple years, are a barrier to contribution. Not only they are increadibly noisy (think for instance of discussion archives in the BTS mostly made of quotes of the previous messages), but also they are not even comprehensive (for instance when part of the discussion happens on IRC or at Debconf). In that sense, I would expect structured discussion systems such as Discourse to be a potential time saver, and therefore lower the barrier for contribution to everybody: those who contribute their point of view, and those who summarise them. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: distributed moderation of mailinglist
Le Sun, Feb 23, 2020 at 06:48:44PM +0100, Didier 'OdyX' Raboud a écrit : > > Email is by definition asynchronous, and some large delays (up to, say, 24h) > are IMHO clearly acceptable for our large, central lists such as -devel or - > project, if one's email address is not already known to send legitimate > content. I sometimes wonder if adding a random delay of 1 to 24 h for every message (I mean: rolling the dice again for each message) on -project, -devel, -vote and similar lists could help to make us more resilient to trolling and at the same time more likely to have more constructive discussions. I think that it would incentive people to spend more time to write well-thought answers, because it would reflect badly on posters of half-backed messages to have them delivered after well-written ones. As a consequence I also hope that it would also increase the diversity of opinions and posters by reducing the audience of fast writers – who still may end up broadcasted ~23 h after other people more lucky – and also by reducing time zone effects. There may be redundant answers but they might have the merit to present the same argument with a different point of view or a different background or vocabulary, and since they would be written independantly and without the purpose of supporting each other by sheer number, the redundancy would facilitate consensus building. Although the measure would not prevent trolls from posting, it would limit their capacity to induce heated ping-pong discussions in which upset people write things that they regret later because it irreversibly hurt others. Have a nice day, Charles (The idea of random delays is taken from the R posting guide https://www.r-project.org/posting-guide.html) -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Do we still value contributions?
Hello everybody, and happy new year ! not sure where to post this comment in this thread but, regarding how to save time from the FTP Masters and the package maintainers, I wonder if it there were an easy way to make it technically possible to let the package maintainers change by themselves the list of architctures on which their package is being built. In science packages, any -> almost any -> only amd64 -> amd and arm -> only amd64 again, -> etc ... is not an unusual pattern, and each iteration requires manual work on both sides. I think that it would be great to save everybody's time there. Have a nice day, Charles PS: we are all on holidays, how about waiting 1 day before answering ? -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Do we still value contributions?
Le Thu, Dec 26, 2019 at 02:59:25PM +0100, Bernd Zeimetz a écrit : > > While I'd appreciate to have a faster ftp/NEW process, I do not think > letting more people participate (as in: DDs not part of ftp-masters) is > a good idea. We've often seen mud-fights about the interpretation of > licenses, missing licenses, patents and whatever else. Hi Bernd and everybody, my vision with the copyright reviews was to filter obvious issues in packages before the FTP team spends time on them. Thus, the focus should be on facutal points such as finding obviously non-free files (information to be sent to the maintainer, who can update or remove the package from the NEW queue) or finding an obviously new license (useful information for FTP masters, who can organise their work accordingly), etc. > Also we have the issue that if we let other people actually read trough > the source code, we might have distributed it already and in the same > time we might be violating licenses. I understand that we need to be conservative on what is redistributed by the FTP team. But often the source package can also be found elsewhere than in the NEW queue, such as on mentors.d.n, ... > So in my opinion the option we should implement is a (mostly) automated > license check. Indeed. Ideally, a bunch of tools should be run automatically on new packages (by people willing to take the same amount of legal risk as the mentors.d.n admins), so that anybody can report potential issues. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Do we still value contributions?
Le Tue, Dec 24, 2019 at 11:11:43AM -0500, Scott Kitterman a écrit : > > More generally, New is being processed as fast as it can given available > volunteer time. Any delays are not reflective of a lack of value placed on > people's contributions. Hi Scott, John, everybody, In the past I proposed a system of peer review to pre-screen the packages that are in the NEW queue. https://wiki.debian.org/CopyrightReview It never took off but maybe some process along these lines could help reducing the time needed by the FTP Masters to process the packages ? Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Some thoughts about Diversity and the CoC
Le Sun, Dec 22, 2019 at 10:46:54AM +0100, Enrico Zini a écrit : > > The responsibility for a healty community, where everyone can feel > included and accepted, is nominally the responsibility of everyone in > the community. In practice, however, it is *primarily* the > responsibility of the people who are *in a position of privilege and > power* within that community. Hi Enrico, please do not take what follows as a criticism or a sarcasm, but more as an encouragement at taking action: as a member of the Front Desk and as a Debian Account Manager, you are among the people in position of power in our community. Gerardo's persistance in writing statements that are more or less threats to misgender people in the future, after he was explained how wrong it is, after the Community team made itself available for providing him further guidance in private, and after the DPL called the discussion closed, is clearly in violation of the code of conduct. Clarty, warnings, and timeliness were among the main points people were asking for when expulsion procedures were discussed last year. Personally, as a simple member of Debian, my red line is to always refrain to ask others to leave. But your delegations makes it possible and appropriate for you to take that decision when needed. Have a nice day, -- Charles PS: you also wrote: > politely and patiently educate the privileged ones. Just a side comment: at the moment in France "priviledged ones" is a derogatory term to fingerpoint people who use their right to go on strike. So please do not be surprised if at least some French people dislike being told that they are priviledged. (Not to mention the heads of priviledged people cut off a couple hundred years ago.) I think that everything you rightly say about how hard it is to understand how other suffer if we do not suffer it ourselves, can be written as effectively without categorizing others as "priviledged". -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Some thoughts about Diversity and the CoC
Le Fri, Dec 13, 2019 at 04:13:09PM +0100, Ondřej Surý a écrit : > > I concur with Scott, personally, I find content of Geraldo’s email(s) > totally unacceptable at the same time as I find the language of Tina’s > email inappropriate. For the avoidance of doubt: I do not know Geraldo, did not know Geraldo contributed to Debian, and actually thought Geraldo was a troll. Well, it may be true that if one looks like a troll, one is a troll, and it sometimes happen that even Debian contributors do troll, and reviving old threads out of the blue with emails engaging in fast-paced reactions on topics that would deserve more proofreading, moderation and emotional intelligence is leaning towards trolling. In any case, I expect members of the Community team to be able to control themselves better in these situations, because these are the very situations that they volunteer be in charge of. Same as a technical committee needs to be technically competent or an accounting team has to be good with handling money, a community team has to behave. Otherwise, we are easy targets for trolls. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Some thoughts about Diversity and the CoC
Le Fri, Dec 13, 2019 at 03:47:43AM -0300, Martina Ferrari a écrit : > > Whether my phrase was directed at Gerardo only or also to you, you decide. Please do not write that, Martina. You are undermining the very code of conduct that you are striving to defend. To all: how about a "maximum one mail a day" self-policy ? Cheers, -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Community Team - where we want to go
Le Wed, Nov 13, 2019 at 10:55:41PM +, Martina Ferrari a écrit : > > A short reply in a personal capacity.. Hi Martina and everybody, I have always found replies “in a personal capacity” or “with [the team's] hat off” very confusing; probably because I rarely see this communication style outside Debian. Especially when coming from teams that have quite some power, I think that it would be better for us to receive statements that reflect the consensus of the team, if necessary with some kind of addendum explaining the minority's point of view when the opinions of the team members are split in a way that it is hard to resolve. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Community Team - where we want to go
[content summary: interpretation with delegation, role separation for definition and enforcement of rules, distinction between guidance and warning, timeliness.] Hi Steve, Community team and everybody, I think that the current changes in name and role of the A-H team go in a good direction. Here are some comments that I hope are in line with and will help your efforts. Le Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre a écrit : > > The (CT) is the team responsible for interpreting the Code of Conduct > (CoC) when necessary. Like others and for the same reasons, I think that to be responsible for interpretation it would necessitate a delegation. I would like to add if you follow that direction, then it would be better that the team does not take responsabilities such as judging the behaviour of others, that would lead it to be both raising a question of interpretation and giving an authoritative answer at the same time. > Where desired, the team will work with contributors to help them > express disagreement without violating the CoC. I think that providing behavioural guidance is an excellent goal. However I think that it will be more effective by addressing the community in general. To be frank, I do not have the impression that the people who usually express themselves "bluntly" will actively seek your advice. > When people do breach the CoC, the team will give guidance on better > ways to interact in the future. I also feel that it is important that people are being explained when they hurt others. But I have one comment and one question: - Given what happened in the past, I think that it is crucial that there is a crystal clear difference between being given guidance and being given a warning. For instance, it could be that any message from the CT is not a warning unless stated otherwise. - I think that it is bound to happen that one day, a message of guidance will be badly received, and will lead the receiver to behave worse than if they did not get a message. What is your plan in that case ? > * Responding in a timely manner to incidents reported by members of >the Debian community and those interacting with the Debian project; This timeliness is extremely important and I think that it is great that you mentionned it. In case of overload, I think that timeliness should be given priority over exhaustiveness. That is: drop the less grave cases if there is no time to respond to all at the same time. > * Where there might be a Conflict of Interest, individual members of >the team will be expected to inform the rest of the team, about it >and recuse themselves from relevant discussion. Thanks for including that point. > * Writing and providing reports to other teams concerning incidents >or habitual behaviors; and Given what happened in the past, I think that it would be important to put a clear limit on how far in the past the behaviour of people will be investigated, and how behavioural patterns will or will not be aggregated. Timely and focused reaction will reduce contention. > * Proactively writing emails to those who habitually make the >community a hostile place, informing them that their behavior is >harmful to the community, that action may be taken in the future, >and that the Community team is a resource to provide explanation or >guidance. This implies that the CT will contact these people when it is available to answer in a timely manner to their rebuttals, which is great, Have a nice day, and thanks for your work on the reboot of the team ! Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Debian and Non-Free Services
> On 10/5/19 1:10 AM, Charles Plessy wrote: > > > > I make this comment as the person who some years ago took the initiative > > to take over the "Debian" Github group, that was more or less abandonned > > and apparently not controlled by somebody related to Debian. It was a > > definitely a bitter experience that I do not feel to reproduce... Le Wed, Oct 09, 2019 at 04:10:12PM +0200, Bernd Zeimetz a écrit : > > does that still exist? Might make sense to share some work there. Not > sure, though, with so many github haters out there, I might want to keep > my stuff under my own account which makes it easier to stop whatever you like here> people from doing not so sane things. Hi Bernd, no pressure at the moment. It was painful to make something new happen, but now it is low-maintenance routine, that I share with Yaroslav. Still I would not mind be replaced. The workflow is to get GPG-signed emails, check the web of trust, and add people to the group. Have a nice day, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Debian and Non-Free Services
Le Fri, Oct 04, 2019 at 06:40:15PM +0200, Jonas Meurer a écrit : > > And a side note: please accept that others in the project have opinions > that object to yours. Not agreeing with your point of view doesn't mean > that you're silenced or censored, despite you behaving like this. Quite > on the contrary, that's what vibrant democratic debates are about ;) Hi Jonas, it is important that both sides of the argument accept to respect each other. Sadly, it is a strong pattern on the Debian mailing lists that unkind impolite thankless naysaying comes first, since it is simple to express and quicker to type... I make this comment as the person who some years ago took the initiative to take over the "Debian" Github group, that was more or less abandonned and apparently not controlled by somebody related to Debian. It was a definitely a bitter experience that I do not feel to reproduce... In other contexts, this could be called environmental harassment. No matter if the pressure comes from different people at each time, what is sure is that working on certain areas is going to be emotionally expensive. Have a nice week-end, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Using Debian funds to support a gcc development task
Le Sat, Sep 28, 2019 at 11:44:26AM +0200, John Paul Adrian Glaubitz a écrit : > > In the future, gcc upstream expects all backends to be using MODE_CC for the > internal register representation as the old CC0 is supposed to be removed. > > Since the lack of modernization would eventually mean that m68k support would > get removed from gcc, I'm currently running a campaign to prevent that. I > have already opened a tracker bug upstream in gcc's bugzilla [2] as well as > linked the issue to BountySource [3]. (...) > I thought of something around $1000 to $5000 depending on how much the project > is willing to spend. Hi John and everybody, given the reminders that Debian refrains from paying developers for their time, I wonder if it would still be possible to make a small contribution that expresses Debian's interest and sympathy to your goal, with the hope that our name will help the crowdfunding effort. Something on a scale that would allow us to answer positively to similar requests without putting a significant burden on our finances... Maybe $100 ? This is the same amount as what Debian is willing to reimburse for travel costs to bug-squashing parties, for instance. Have a nice day, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Upstream metadata to help our users contribute back to projects we redistribute.
Hello everybody, (posted on -project because of the context, but answers probably belong to -devel, where I am not subscribed...) there is an intersting discussion going on about Git and the preferred form for modification of the programs we redistribute. Indeed, as of today would be hard to say « just run “apt-get source ” and voilà, you can hack and contribute back upstream ». There has been now and in the past (for instance when discussing the proposed format “3.0 (Git)” for dpkg) some important points raised explaining the challenge of redistributing the upstream VCS instead of a flat file archive. This is why some packges are shipping metadata indicating where to find the upstream sources, send upstream bugs, or even where to dontate money, in order to help our users contribute back to the developement of the software that Debian is made of. For many of you, I am sure that it is only a reminder. But in any case please have a look at https://wiki.debian.org/debian/upstream and https://wiki.debian.org/AppStream for details. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan Debian Med packaging team http://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home, https://framapiaf.org/@charles_plessy
Re: Debian supports pridemonth?
Hi all, Le Tue, Jul 02, 2019 at 11:25:41AM +0100, Colin Watson a écrit : > > point out that, on average, members of those groups have an easier time Le Mon, Jul 01, 2019 at 03:26:37PM -0700, Russ Allbery a écrit : > > if there are gestures we could make that would make those people feel > welcome, I'm all in favor. I really wish to not be categorised, and to not be averaged. I have not joined Debian for that. We can support members of our community with actions like the Pride event on our website. That is reaaly great and I wish to see more of such events in the future! We will divide ourselves by categorising and lecturing on what we perceive as negative in each other, especially on email list media which are extremely efficient at forstering misunderstandings. In line with our Diversity statement, there is a lot that can be said positively and effectively to make everybody feel safe and proud, without putting other developers in a catch-all category that they did not choose. Have a nice day, -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog
Hi Phil, Le Wed, May 22, 2019 at 01:37:07PM +0200, Philip Hands a écrit : > > I see no reason to assume the worst. Maybe growth and the law of big numbers ? The more we are the more it is likely to happen. As somebody who had my work reverted temporarly by somebody who acted alone (although motivated by good faith and his common sense), I can tell that even though my work was later reinstantiated and the other person (indireclty) punished, it costed me a disproportionate amount of time and frustration. So as a conclusion of this thread, I would be happy to read something like "when tempted to block somebody elses contribution, do not trust your common sense and seek the opinion of other people in charge before taking action". Have a nice day, Charles -- Charles Plessy Debian Med packaging team http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Apology and DAM decisions
Norbert, Enrico, Joerg and Jonathan, many thanks for all your patience, efforts, and dedication, today is a great day for Debian. -- Charles signature.asc Description: PGP signature
Please do not publish private emails on the Debian mailing lists.
Le Wed, Feb 06, 2019 at 10:12:33AM +0100, Pierre-Elliott Bécue a écrit : > > I changed my mind. No more email from Pocock will end en on this list through > me. I don't want to give him a tribune. > > Sorry for the noise, and have a nice day, all ! Hi, I think that publishing private emails on the Debian lists is highly inappropriate. Thanks for your apologies, but please bear in mind that this is not just about noise. Please do not do that again, with any sender. Cheers, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Proposal: mediators
Dear all, I would like to propose a system for mediation that can be used before or during expulsion processes, and for other purposes. Please note that while I use the word "mediation", there may be a better one. Thus, it is not needed to reply to me that what I propose is not a real mediation if this is the case. Please focus on what I propose and not on how I named it ! ### Goal The goal will be to help all parties or their proxies to prepare fact-driven synthethic position statements that can be presented to others, in particular to the decision makers, both to help them to take their decision and to help announce it in a way that is the most resilient to misunderstanding and the criticisms that it triggers. It is also hoped that the mediation process may also sometimes help both parties to settle their disagreement, although it will not be considered a failure when settlement is not reached. ### Who I think that the mediator should not be doing this task on a regular basis, to avoid burn-out, to avoid being in contact with too many private information, and to avoid being perceived as partial. In order to ensure that the mediators are available and have demonstrated some williness to communicate with others, I propose to select them randomly among the Developers who have been the application maintainer of at least one person. A call would be valid one day; in case of no answer, another mediator would be called, and so on (better strategies using further filtering could be done if it does not look realistic that a volunteer could be found after 10 calls). The call would be initiated by the decision makers, when they feel that this mediation process would help them. ### How The mediator will contact both sides separately and will never connect them nor request or suggest direct communication between them. The mediator will minimise the volume of communication, aiming at addressing each issue only once. The mediator will ask each party to sort the points they want to make in order of relevance (I hope that this process will help to reduce the number of points), summarise them, and ask if the summary is clear and accurate (I think that when somebody can recognise one's views in the words of another person, it is a good indication that there is mutual understanding). The mediator will then present the views of each side to the other side, and ask if there is agreement, disagreement, and recommend to avoid lengthy rebuttals. The mediation is only part of the conflict resolution, and it is already a great achievement to agree to disagree. Lastly, even when clear action points emerge from the discussion, the mediator will never propose an implementation, leaving that choice to the decision makers. ### Privacy Communication will be written, encrypted and kept confidential. It may be given to the decision makers if needed and must be destroyed after a reasonable delay (advice welcome). The mediator will never disclose the contents of the messages and information exchanged. ### Limitations To avoid any legal consequences and to avoid damage that could be caused by improper consideration of a victim's suffering, this mediation system should never be used when the facts being discussed are so grave that they could be punished by a justice court. ### Summary In light of the expulsion being discussed at the moment, my impression is that such a process could, or even still can, be useful to underline what are the points considered most important by each side, and which action of the other side can solve them (I am not going to speculate here). I also hope that this proposal may be more broadly useful, especially for the issues at the inteface between behaviour and technique (typical examples are when an NMU are a commit revert trigger a latent conflict). ### Next step I personally would prefer to avoid long point-to-point discussions on the weakest parts of what I wrote above. How about reacting on what you liked (if you liked some part), and just sending the rest to /dev/null ? Thank you for reading so far, and have a nice day ! Charles PS: please pardon my English, it might betray my thoughts. -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
On demotions to DM status.
Hi all, last month I expressed concerns related to the idea of demoting DDs to DM status. I quote them at the end of the message for convenience. Later, there has been a discussion on the theme that technical excellence should not be a reason for tolerating misbehaviours (https://lists.debian.org/debian-project/2018/12/msg00066.html). Thinking about this, it came to me that demotions to DM status are also problematic in that sense, because they are justified by the existence of a tangible techical technical contribution, that the DM status shows that it is still welcome. Debian is nearly as sensitive to the behaviour of DMs and DDs, as they interact with the same group of people, with similar regularity (activity level is not a good predictor of who is DD and who is DM), and will often face similar frictions (email misunderstanding, race conditions and commit rights, conflict of interest when two packages interact in a way that creates extra work that everybody is reluctant to do, etc). To some extent, the claim that DMs are not members of Debian, while factual, is already questionnable when thinking about membership under other perspectives, such as the collective responsibility of keeping Debian's environment and reputation as excellent as possible. Thus, in addition to the concerns that I quote below, I would like to add think that demotions to DM status are also questionnable because they seem to imply that repeated disrespect to our Code of Conduct will have different consequence depending on how we value the person's technical contribution. I understand the difficulty of managing the fallout of the expulsions and I am not pushing for a fast answer, but I hope that it can be eventualy addressed by the DAMs, DPL and AH team. Have a nice day, Charles On Wed, Dec 26, 2018 at 05:35:38PM +0900, Charles Plessy wrote: > But concerning the demotion to Debian Maintainer (DM) status, I think > that it is sending a wrong message to the community, that DMs do not > need to hold the same standards of behaviour as Debian Developers > (DDs) do. > > Moreover, when the DM status was proposed in 2007, it was not thought > as a way of punishment for DDs. Even if one of a thousand DM has this > status because of demotion, I think that this completely changes the > balance on how this status serves our project. Instead of being a > positive way towards joining more formally, it becomes an inferior > status. > > Whether DD -> DM demotions will happen again and are going to become a > new tool for solving social conflicts is an important decision that > needs an open discussion where conesnsus is being sought. <https://lists.debian.org/debian-project/2018/12/msg00035.html> -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Compassion For Those Worried Whether They are Welcome
> >>>>>> "Steve" == Steve McIntyre writes:
> >
> >Steve> For those trying to undermine it with statements like "I'm
> >Steve> worried I'll be thrown out of Debian if I make a single
> >Steve> mistake", please give it a rest already. These are basic
> >Steve> principles on how we want all people to interact. If you make
> >Steve> a mistake and do a bad thing, people will tell you and ask
> >Steve> you to re-word, apologise, whatever.
> >
> On Wed, Jan 02, 2019 at 07:45:55AM -0500, Sam Hartman wrote:
> >
> >Asking for reassurance that we'll be treated with compassion and
> >empathy, given a chance to understand what is going on and heard when
> >we speak our part of the story is natural.
> >THESE INSECURITIES AND ASKING FOR THAT REASSURANCE DOES NOT UNDERMINE
> >THE CODE OF CONDUCT.
Le Wed, Jan 02, 2019 at 01:26:07PM +, Steve McIntyre a écrit :
>
> Nod. Apologies if my message sounds insensitive here! There are some
> who I think might appear to be trying to undermine it, but I agree I'm
> being unfair. Thanks for the correction.
Hi Steve, and happy new year to you and everybody,
thanks for your clarification; I found your original message very
troubling and accusatory indeed.
Frankly speaking, your reply to Sam does not entierly dissipate the
discomfort that I had when I read your first message. When you write
"There are some who I think might appear to be trying to undermine [the
CoC]", I think that you unfortunately create a climate of suspicion.
The more I read the CoC, the more I think that its point 2 ("assuming
good faith") is very important and effective. (Mildening your words
with "might appear to be trying" does solve the problem, think for
instance if I would add that it perhaps may possibly make it even
worse). I think that referring to specific statements (and not to
people, even collectively under "some") would have made your point much
stronger.
Adding "I agree I'm being unfair" adds to the confusion, in my opinion.
If you have doubts on the facts, but feel that you need to react in
order to counteract "those trying to undermine" our CoC, may I suggest
to focus on the post that you find most ambiguous, state your concerns
and ask for a clarification ? You would not need to follow up as people
can then judge the facts by themselves after reading the clarification
(or seeing its absence).
Have a nice day,
Charles
PS: thank you nevertheless for expressing your views in public (as
opposed to debian-private).
--
Charles Plessy Tsurumi, Kanagawa, Japan
Debian Med packaging team http://www.debian.org/devel/debian-med
Tooting from work, https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy
Re: Planet Debian revisions
Le Wed, Jan 02, 2019 at 06:54:25PM +0100, Enrico Zini a écrit : > On Wed, Jan 02, 2019 at 05:39:58PM +0200, Jonathan Carter wrote: > > > 4. Avoid posting personal fights or insults. Planet Debian is not an > > appropriate medium for this. > > If I'm still on time, I'd suggest: "personal fights, insults, or slurs", > as I'm not sure how much we can give for granted that everyone > understands that using slurs counts as insulting. Hi Enrico, on my side, I have no idea what a "slur" is: this word is new to me and I would need a dictionary to understand that rule. I would like to suggest to keep a simple English vocabulary when writing rules. Have a nice day ! -- Charles
Re: Debian's Code of Conduct, and our technical excellence
Le Sat, Dec 29, 2018 at 04:23:02PM +, Matthew Vernon a écrit : > > There have a few posts in recent discussions by people suggesting (or, at > least, appearing to suggest) that there is a conflict between technical > excellence and our Code of Conduct (or aiming to increase the diversity of > our membership, or similar). > > I think there is no such conflict, and that the idea that there is is in > itself harmful. Hi Matthew, regarding people who "appear to suggest" harmful ideas, the Code of Conduct solves the problem by requesting that we assume good faith... That means: appreciation for good work is not a suggestion to disregard the CoC unless explicitely written as such. Emphasising on peoples positive traits and contributions in an important tool for reminding that the main subjects of expulsion processes are not emails or blog posts pages, but human beings. Have a nice day, -- Charles
Re: Censorship in Debian
Le Wed, Dec 26, 2018 at 05:35:38PM +0900, Charles Plessy a écrit : > > Whether DD -> DM demotions will happen again and are going to become a > new tool for solving social conflicts is an important decision that > needs an open discussion where conesnsus is being sought. Unsurprisingly there are monster threads on explusions on debian-private. Parts are specific to some people, and parts are about procedure. I am not going to read the threads, because I do not want to be bound to secrecy about the discussion on the procedure. I think that this disucssion must be public. This disucssion can be done in a civil, slow-paced way that foccuses on exploring together the pros and cons of multiple directions. Redoing it from scratch on one of our mailing lists would be a good opportunity to reboot it in a more productive and less divisive way some time in January when everybody has cooled down. I invite the decision makers to start and lead this discussion. Have a nice day, and for those who celebrate a new year, my wishes for a happy new one ! Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Akano, Uruma, Okinawa, Japan
Re: Censorship in Debian
Le Wed, Dec 26, 2018 at 01:13:53AM +0900, Norbert Preining a écrit : > > * The demotion to Debian Maintainer is - as far as I read the > consitution [3], the delegation of DAM [4], and the DAM Wiki page > about their rights and powers [5], not legit since besides expulsion > there is not procedure laid out for demotion, but I refrained from > raising this for the sake of peace. Hi everybody, I have read so many distrurbing things on this expulsion that I won't comment on everything, not the least because I am not a native speaker and worry to make the situation even harder by writing things that can be misunderstood. But concerning the demotion to Debian Maintainer (DM) status, I think that it is sending a wrong message to the community, that DMs do not need to hold the same standards of behaviour as Debian Developers (DDs) do. Moreover, when the DM status was proposed in 2007, it was not thought as a way of punishment for DDs. Even if one of a thousand DM has this status because of demotion, I think that this completely changes the balance on how this status serves our project. Instead of being a positive way towards joining more formally, it becomes an inferior status. Whether DD -> DM demotions will happen again and are going to become a new tool for solving social conflicts is an important decision that needs an open discussion where conesnsus is being sought. Have a nice day, -- Charles Plessy Illkirch-Graffenstaden, Alsace, France Debian Med packaging teamhttp://www.debian.org/devel/debian-med Tooting from work, https://mastodon.technology/@charles_plessy Tooting from home,https://framapiaf.org/@charles_plessy
Re: [summary] Re: wanted: educate us please on key dongles
Le Sat, Sep 09, 2017 at 08:09:00PM +, Sotirios Vrachas a écrit : > > - https://wiki.debian.org/GnuPG/StubKe > This page does not exist. > Sorry, it was <https://wiki.debian.org/GnuPG/StubKeys>. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan
[summary] Re: wanted: educate us please on key dongles
Hello everybody, that thread was very interesting, and I tried to input in wiki.debian.org the information that seemed to not be covered yet. Most of the input went in two new pages: - https://wiki.debian.org/OfflineMasterKey - https://wiki.debian.org/GnuPG/StubKe I did my best to preserve attribution by relating each edit to one email in the thread, for instance: - https://wiki.debian.org/OfflineMasterKey?action=info I hope you will find them useful. Due to their cut-n-paste nature, they are still is quite draftish, and I will not mind if somebody extensively reworks or relocates them, etc. Have a nice day, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: should debian comment about the recent 'ransomware' malware.
Le Tue, May 16, 2017 at 03:59:18AM +0530, shirish शिरीष a écrit : > > I was looking at p.d.o. but much to my disappointment nobody had > discussed the newest 'wannacry' ransomware there. > while it was primarily targeted towards Windows machines, maybe we > could tailor a response which shows how Debian is more secure and > possibilities of such infections are low/non-existent . Hi Sirish, Actually, if there were a large enough number of users still running Squeeze or earlier versions, for which there is no official nor [LTS security support](https://wiki.debian.org/LTS), the same could happen to Debian. Thus, if there were a response from Debian to the ransomware attack, it could be a reminder that it is true for Debian as well that old systems must be upgraded or at least very thoroughly isolated. But I think that it would more fit a blog article than an official news release (after all, we will call for updates soon with the next Stable release). So... feel free to blog on the topic :) Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Debian contributor Register of Interests
Le Thu, May 11, 2017 at 10:10:39PM +0200, Philip Hands a écrit : > > Also, I suspect that anyone that might be tempted to misbehave as a > result of CoI will not have filled in their entry anyway, which makes me > wonder what useful purpose this could serve beyond a virtue signalling > opportunity. Hi Philip and everybody, Preventing misbehaviours is only one side of the issue. Situations of conflicts of interests also arise when the public, stakeholders, colleagues, etc. may have strong feelings that a decision is biased, which undermines the credibility of persons or decision-making bodies. In this case, declarations of conflicts of interest leading to step aside of a decision-making process protect people and institutions from potentially harmful controversies. This said, since the situations of conflict of interest arise in specific contexts, I wonder if a broad list like the one of the wiki is going to be meaningful, although it is a good exercise for people to think about possible situations they may encounter in the future. On the other hand, I would welcome a more systematic declaration of conflict of interests when some decisions with far-reaching consequences on the project are being taken. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
Le Fri, Apr 07, 2017 at 03:00:10PM +0530, shirish शिरीष a écrit : > > Could you or anybody else please share even if unintentionally, I have > been demeaning to anybody in my writings. While I have repeatedly > apologized, I would like to know where I have demeaned people. > Everybody is welcome to point to me either publicly or privately what > is/was demeaning in my writing. Hi Shirish and everybody, I think that there is a broad consensus that the core problem is the image that you included, not the writings. On my side, do trust you that you did not intend to hurt anybody, and that you did not intend the use of this image to be eye-catching to attract readers, nor to convey derogatory messages about women. But Debian is a very broad community, so if you are told that the image has made Debian less welcoming than it should, and that it has put people at risk to lose their jobs, you (and me) have to trust that. If I could sugest a good way out of this situation, it would be that you acknowledge (briefly) that you understood that images are sensitive materials that have much more potential to harm others than just plain text, and that you will be careful in the future. In return, I think that it would fair if the anti-harassment team would also acknowledge that you are not a harrasser, to cleary any possible misunderstanding if a third party stumbles in the archives of this discussion at some point in the future. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: contacting Debian is too easy to get wrong
Le Tue, Mar 21, 2017 at 12:01:06PM +0800, Paul Wise a écrit : > > I've noticed that it is far too easy for folks unfamiliar with Debian > to contact the wrong addresses for their queries. I expect all of the > Debian teams with @debian.org aliases have found something similar. > > This causes various problems, including: > > Wasting the time of both Debian and people contacting us. > > Having queries ignored due to busy teams or frustration. > > People getting angry at us for redirecting them to user support > channels, when they should have gone there first. Hi Paul, to this list I would like to add that from time to time, some people write to debian-...@lists.debian.org as instructed by our website's footer, and get frustrated that their message will stay public and archived until the end of the Solar system. ask.debian.net was a good idea, but as of today it looks half broken. If a replacement engine is looked for, maybe one can have a look at Biostar (https://github.com/ialbert/biostar-central). It does not have many features, but perhaps that is the feature. > Is anyone interested in working on this problem? I am really sorry but I do not have enough time. But if ask.debian.net is repaired, I would try to visit it more often. Have a nice day, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Bits from the DPL -- 2016Q4
Le Fri, Dec 30, 2016 at 01:19:45AM +0100, Mehdi Dogguy a écrit : > > During the conference, I scheduled a few talks/BoF sessions: > - The customary "bits from the DPL" talk [1] > - "Debian from 10,000 feet" BoF [2], co-organized with Lucas Nussbaum > - Roadmap BoF [3] to discuss with interested contributors about the > goal behind the idea and how to get started with idea. > - "DebConf handover" BoF [4] > - Using Debian Money to Fund Debian Projects [5], co-organized with > Raphael Hertzog > > [1] https://debconf16.debconf.org/talks/51/ > [2] https://debconf16.debconf.org/talks/134/ > [3] https://debconf16.debconf.org/talks/122/ > [4] https://debconf16.debconf.org/talks/123/ > [5] https://debconf16.debconf.org/talks/41/ > > > Project Roadmap > === > > First, if you haven't read my slides [3] on the roadmap, please have a > look before reading what follows. Hi Mehdi, sorry, but in [3] I could not find slides; only a 45-min video. Can you upload your slides somewhere ? Have a nice Sunday, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: Replace the TC power to depose maintainers
Le Sun, Dec 11, 2016 at 03:00:22PM +0900, Charles Plessy a écrit : > > Dear TC, you have my support, and please feel empowered to require high > standards from the confronting parties that ask for your decisions, so that > your task is made easier, for everybody' good. > > - The TC members should not be asked to read through long threads [...] > - Of course, since this requires significant involvement from both parties, > [...] > - With this guarantee, I think that it would be fair if the TC would give > deadlines [...] > - Similarly, if some TC members do not have time to get deeply involved [...] > - To keep the discussion in clear boundaries, [...] > - In general, do not hesitate to be severe with those who play the clock. > - Also, I think that the main expectation about the TC is that it will > resolve conflicts [...] Sorry, I forgot one suggestion: - I think that it would be totally fair if the TC, based on its task list and based on the urgency of the questions that are raised, would sometimes decide upfront to leave one case untouched for some weeks or even a copuple of months, to avoid dispersing its attention on too many problems. As long as the decision is not re-postponed, I think that it can be in everybody's best interest. I hope that my comments will not be taken as a lecture on how being better efficient. The message is rather that if you already thought about following that kind of way, don't worry and go for it ! Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: Replace the TC power to depose maintainers
Dear Ian, TC members and everybody, the discussion about maintainership is interesting, and maybe I will post a comment later, but I think that the main problem is the speed of the TC to take its decissions. And one very important comment that was made in this thread is that the TC needs wide support from Debian members. It needs trust and respect. So I would like to tell my personal opinion here, which I hope is shared by many other project members: Dear TC, you have my support, and please feel empowered to require high standards from the confronting parties that ask for your decisions, so that your task is made easier, for everybody' good. - The TC members should not be asked to read through long threads and dig history in the mailing lists. Instead, each side should maintain a synthethic position with a proper rebuttal of the other side's opinions, and maintain it up to date. - Of course, since this requires significant involvement from both parties, the TC has to protect maintainers from deliberate obstructions or attempts to suck up their time and demotivate them with TC procedures. To block that kind of "negative energy", the TC should not hesitate to dismiss a complain if it is poorly argumented, or if nobody on the complaining side has time to follow up. - With this guarantee, I think that it would be fair if the TC would give deadlines to the conflicting sides to explain their views. Its closed mailing list would be a good tool for negociating the deadlines without disclosing personal information. (And of course, in the case of non-responsive maintainers, it will still be a bad argument if one answers that there is enough time to take care of the package, but not enough time to provide answers to the CTTE in a reasonable delay). - Similarly, if some TC members do not have time to get deeply involved in a discussion, that is life, and that is one reason why there is a committee of multiple members. In the worst case scenario, do not hesitate to skip a given vote, I am sure that the project as a whole will not blame you for this. Rather, we will be grateful that you helped that way to speed up the process. - To keep the discussion in clear boundaries, random opinons from third parties that are not integrated on one or the other side's argumentation can be ignored. External imput is welcome, but it should be the role of both sides to adopt it in their argumentation if they think they are important enough. Late minute minor comments should not be a blocker either. Otherwise, there is never and end and it opens the way to tactical behaviours for delaying decisions. - In general, do not hesitate to be severe with those who play the clock. - Also, I think that the main expectation about the TC is that it will resolve conflicts, and in that sense, I would say please do not feel pressure to find an even better solution to a problem by yourselves, that would leave on your shoulders the pressure for implementation when noboy else volunteers for it. Just unblocking a frozen situation is already great ! Altogether, thanks a lot for your work ! Have a nice Sunday, Charles -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: GR: Declassifying debian-private: second call for votes
Le Sun, Oct 16, 2016 at 01:10:02AM +0200, Debian Project Secretary - Kurt Roeckx a écrit : > > This is the second call for votes. > > Voting period starts 2016-10-09 00:00:00 UTC > Votes must be received by 2016-10-22 23:59:59 UTC > > The following ballot is for voting on declassifying debian-private. > Choice 1: Repeal previous GR > Choice 2: Acknowledge difficulty > Choice 3: Remain private Hi Gunnar, Ian and Iain, out of context, it is hard to chose between the options that each of you are presenting in this GR. Could you briefly rebut each other's options ? I think that it would help a lot. Have a nice day, -- Charles
Re: Debian slogan / tag line / emphasizing freedom
Le Tue, Jun 07, 2016 at 11:20:53AM +0200, Daniel Pocock a écrit : > > Debian has been using the slogan / tag line "The Universal Operating > System" for as long as I can remember. > > It is a good choice and it represents the aims of many contributors, but > is it the optimal choice today? > > For example, has there ever been discussion about replacing it with a > slogan that puts an emphasis on freedom, another value that is important > to many contributors? > > E.g. "Powering your freedom", "Enabling your freedom", "The free > platform", "The universal free OS", etc Hi Daniel, good point, in my opinion. "Universal" has been quite efficient in fuelling disagreement on what it means, on the same level as other keywords such as "choice", etc. On the other hand, by definition we stand united on what Free means for our project. So on my side I would welcome putting "freedom" somewhere under the Debian logo. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: third-party packages adding apt sources
Hi Daniel, Le Thu, May 19, 2016 at 05:18:28PM +0200, Daniel Pocock a écrit : > > From a technical perspective, can we do more to prevent users being > surprised by packages putting new entries in /etc/apt/sources.list.d? maybe you are looking for an Apt option that would only install a package if it comes from repository signed with a key that itself is signed by a trusted key ? This way, from inside or outside Debian, chains of trust could be used to certify the compliance of third-party repositories with good practices, or other rules. As suggested in this thread, dpkg triggers or other kinds of hooks could check that packages installed directly without Apt would not change the trust keys without the user being aware of this. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: third-party packages adding apt sources
Le Fri, May 20, 2016 at 07:34:59AM +0200, Vincent Bernat a écrit : > > I am always flabestered by the popularity of fpm to build Debian > packages (and by the increasing popularity of pleaserun by the same > author on the same concepts). It provides a way to easily build a Debian > package from a directory but produces somewhat crippled/incomplete > packages and is no help to us since it's completely outside of any of > our tools. It also handles RPM (and now other package formats), but I > don't think this would explain its popularity alone. For software using CMake, there are also CPackDeb and CPackRPM. https://cmake.org/cmake/help/latest/module/CPackDeb.html Were I an upstream developer, I would definitely be interested by tools like this that leverage the build system to build installation packages for various platforms. Have a nice week-end, Charles -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan
Re: shutting down httpredir.debian.org?
Le Thu, Apr 14, 2016 at 10:53:10AM -0400, anarcat a écrit : > > Can people show specific bug reports they have filed that describe > problematic behavior? Hi all, On my side of the World, httpredir never worked correctly. Here is an example showing that despite it detects correclty that I am based in Yokohama, Japan, I am redirected in Turkey ! -- IP: 134.160.83.73 AS: 18128 Continent: AS Country: JP Region: 19 City: Yokohama Had you requested a file to /debian/, you would have been sent to one of the following mirrors: http://debian.gnu.gen.tr/debian/ Out of a population of: 40 mirrors Matched by: nearby-continent -- In the past, I have been frequently redirected to Korea or Taiwan. I have let Raphael know by email but did not open a bug since at that time it was still a debian.net service. Also, http.debian.net (at that time) was supposed to redirect Amazon cloud users to the CloudFront CDN (https://lists.debian.org/debian-cloud/2013/05/msg00066.html), but in practice it did not work (https://lists.debian.org/debian-cloud/2013/10/msg00044.html) and it still does not. Here is what I get from whithin the Japan-based Amazon cloud: -- $ GET -e http://http.debian.net/demo/debian/ 200 OK Cache-Control: no-cache Connection: close Date: Fri, 15 Apr 2016 01:03:44 GMT Pragma: no-cache Server: Apache Client-Date: Fri, 15 Apr 2016 01:03:43 GMT Client-Peer: 128.31.0.66:80 Client-Response-Num: 1 Client-Transfer-Encoding: chunked Link: <http://debian.lagis.at/debian/>; rel=duplicate; pri=13590; depth=0 X-Arch: X-AS: 16509 X-City: Tokyo X-Clacks-Overhead: GNU Terry Pratchett X-Closest-Distance: 135.8997 X-Continent: AS X-Country: JP X-Distance: 135.8997 X-IP: 54.95.145.228 X-Match-Type: nearby-continent X-Population: 2 X-Region: 40 X-Std-Dev: 8.30850467894193 X-URL: -- The reason why I refrained from reporting these bugs further is that I have do not have time to help solve them, and I was seeing http.debian.net as a "best effort" service. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan
Re: Re: Systemd
Le Sat, Nov 29, 2014 at 06:55:16PM +0100, Svante Signell a écrit : Unfortunately it is mandatory, not only the default :( New installs: yes, upgrades: probably, we'll know December 4. Odds for a non-systemd upgrade are low :( Maybe join devuan instead? Svante, your email is off-topic on this list. We need a bit of self-discipline otherwise it makes our mailing lists useless. You constant rants are getting unbearable for me. If it is accepted by others that they are welcome on debian-devel, then so be it, but I will not read that list anymore. If it is also accepted that you post the same on -project, then I guess I will also unsubscribe from this list. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141129225223.ga16...@falafel.plessy.net
Re: Resigning from the Technical Committee
Hi Russ, many thanks for the amazing work you did in the TC. You definitely deserve being relieved from that pressure and having a good relaxing time after enduring that storm. After your break, if you are not fed up with activities which tend to attract long discussions, I am looking forward working with you on the Policy again ! Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141117021437.ga...@falafel.plessy.net
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
Le Tue, Oct 14, 2014 at 08:58:22AM -0400, Miles Fidelman a écrit : Isn't the point of posting on debian-devel-announce to increase the visibility and liklihood of seconds in the first place? Hi Miles, according to https://lists.debian.org/debian-devel-announce/, the purpose of that list is the Announcements of development issues like policy changes, important release issues c. Its purpose is not to boost visibility of topics, in contrary it is the place to display only topics that were already the most visible from the start. I find it quite ironical that, after devastating the signal-noise ratio on debian-devel and debian-project, some supporters of a init GR regret that they missed the information, which whas cross-posted on this list. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141014131424.gb5...@falafel.plessy.net
Re: CoC / procedural abuse
Le Fri, Sep 19, 2014 at 07:09:15AM +0900, Norbert Preining a écrit : On Thu, 18 Sep 2014, Don Armstrong wrote: limits as placing a permanent ban, which isn't what I mean. By not But what it is. It is a permanent ban that *might* be lifted by listmasters' graciousness. So perpetrators have to beg for redemption. I guess that the story is simpler than this: time-limited bans do not seem to be supported natively in Debian's mailing list engine (SmartList), so if one wants to see our listmasters use time-limited bans more often, then somebody has to spend time to implement this function. This is the reason I refrained to suggest it before despite I also think that time-limited bans are better: I am totally unlikely to write this piece of code. This said, I think that time-limited bans would be a progress, since they would make it easier to cool down non-constructive discussions where people are heating up and start to send dozens of emails as failed attempts to release their anger by ranting in others ears. Also, the concept of lifting bans only on demand creates a black list as a byproduct, and it is strange to imagine such a list in 10 years containing random people who happened to have misbehaved some time ago, of whom we had no news since, but whose names we remember forever. I think that forgetting would make things easier for everybody after a while. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140918235212.ga12...@falafel.plessy.net
Re: DEP-5 (copyright file format) ... gap with practice
Le Mon, Sep 08, 2014 at 08:12:01PM +0200, Jonas Smedegaard a écrit : Quoting Osamu Aoki (2014-09-08 17:38:41) DEP-5 as defined in http://dep.debian.net/deps/dep5/ does not have any clause allowing us to skip license entries for certain class of files. I believe the problem is not DEP-5 but Debian Policy. Hi Osamu and Jonas, the final authority to decide what debian/copyright must contain is the FTP team. There is a long-standing tolerance for not documenting the files autogenerated by the autotools system, but it has not been formally codified, so the Policy can not reflect this flexibility. Note that for the M4 macros, some do not come from the autotools system, and while one may find packages in the Debian archive where the license and copyright of these files has been omitted, my gut feeling is that it is not compliant with the FTP team's views on the debian/copyright file. But the best is that you ask for a first-hand recommendation from the FTP team. If you get an answer, you are welcome to forward it to #462996 or open a new bug so that we can reflect it in the Policy. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140910044423.gc24...@falafel.plessy.net
Re: [PHP-QA] Debian and the PHP license
Le Wed, Jul 30, 2014 at 02:38:58PM +, Thorsten Glaser a écrit : That, too. But AIUI that licence also forbids us from shipping a modified version of PHP without rebranding (like Firefox(tm)). I think that we are ridiculing ourselves by ignoring the arguments that have been given to us by the PHP developers in the past. See, we are getting famous in Wikipedia: https://en.wikipedia.org/wiki/PHP_License#Debian_packaging_controversy Debian maintainers have had a long-standing discussion (since at least 2005) about the validity of the PHP license.[4] Expressed concerns include that the license contains statements about the software it covers that are specific to distributing PHP itself, which, for other software than PHP itself therefore would be false statements. I think that the situation is different: - It has been proposed by a developer to remove PHP modules licensed under the PHP license, in application of a policy that had been neglected for years. This proposition was eventually represented by release-critical bugs. - For some PHP modules, the bugs have been closed, and there was no further reaction. - In the meantime the usual vocal people sending the majority of emails on our mailing lists are giving the impression that removing PHP modules is a position of Debian as a whole, while it is definitely not. This drama can be ended by closing the remaining bugs and going back to work. This has been done for packages that some people care most, like php-memcached, and could be done for other packages. When things have cooled down, it can be proposed to correct the REJECT-FAQ according to current practice of accepting PHP-licensed code. Back to the question of rebranding, the PHP developers have already explained that because PHP is a three-letter word, they are not in a position to protect their name with a trademark. Therefore, they do it with a license. We can not take Mate and distribute it as “Gnome Plus”. We can not take a fork of PHP and call it “BetterPhp”. People can not take a Debian CD, add non-free software, and sell it as “Debian Enhanced”. We and other protect our names, and PHP does it too. I do not see a problem. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140730230300.gb24...@falafel.plessy.net
Re: Where are the May and June 2014 archives of debian-private.
Le Mon, Jun 16, 2014 at 11:16:35PM +, Luca Filipozzi a écrit :
bendel:/srv/lists.debian.org/smartlist/{debian-admin,debian-email,debian-private}/rc.forward
were configured to forward to debian-archive-$l...@debian.org rather than
debian-list-$l...@master.debian.org
I have updated them and let the listmasters know.
Thanks ! The archiving restarted and I could read the last 4 emails, which were
enough for me to get the point.
Please fellow developers... please do not make discussions on debian-private
that should not be private; it either undermines our commitment to real privacy
or make it hard to move the discussion to the public mailing lists where they
belong.
Cheers,
--
Charles Plessy
Tsurumi, Kanagawa, Japan
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140617073221.gc8...@falafel.plessy.net
Where are the May and June 2014 archives of debian-private.
Hello everybody, plessy@master:/home/debian/archive$ cd debian-private plessy@master:/home/debian/archive/debian-private$ ls -lahrt | tail -rw-r- 1 debian Debian 96K sept. 30 2013 debian-private.201309.gz -rw-r- 1 debian Debian 333K oct. 31 2013 debian-private.201310.gz -rw-r- 1 debian Debian 79K nov. 27 2013 debian-private.201311.gz -rw-r- 1 debian Debian 149K déc. 31 19:34 debian-private.201312.gz -rw-r- 1 debian Debian 159K janv. 31 01:54 debian-private.201401.xz -rw-r- 1 debian Debian 114K févr. 28 17:15 debian-private.201402.xz -rw-r- 1 debian Debian 99K mars 29 18:08 debian-private.201403.xz -rw-r- 1 debian Debian 211K avril 22 12:28 debian-private.201404.xz drwxr-x--- 59 debian Debian 4,0K avril 25 20:50 .. drwxr-x--- 2 debian Debian 12K mai4 18:34 . plessy@master:/home/debian/archive/debian-private$ Am I missing something ? Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140616091124.ga9...@falafel.plessy.net
Re: Why discussions don't move from debian-private
Le Wed, Apr 16, 2014 at 08:56:00PM +0200, Jakub Wilk a écrit : Someone complained about a lengthy off-topic discussion taking place on debian-private Hi Jakub, I think that the best is to unsubscribe from debian-private altogether (which I did). Debian-private does not have an essential role in Debian's organisation, and can be ignored completely. If tomorrow there is an event that puts Debian's existence at a risk, I am confident that DDs will be contacted directly. If I remember correctly, this is for instance what happened in the past with the OpenSSH incident (where DSA SSH keys may have been compromised). Also, it is easy to have a quick look at the archives once or twice in the year when needed (mutt can open them). Last time I looked was when I was curious to see how extensive were the mailing list bans (announced threre). This said, I completely understand that people are fed up to see long threads on debian-devel, where a large number of message came from non-contributors talking to each other, and prefer using debian-private instead. On my side, I would not mind if listmasters were in a mood for more tempoary bans on debian-devel. I think that it is good to have a communication channel where people can relax and be more causual, without having permanent public records that can be used against them by employers etc. decades later. It is just that email is a very suboptimal tool for that task. But if we accept the idea that debian-private is not just there for emergencies and announcements about private life, I think that there is still one big failure in the system: the extra privacy on debian-private does not seem to bring any improvement compared with our public mailing lists regarding the strong bias of who is posting: white occidental males. In that sense, debian-private is not much useful to our Project. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140417002344.ga14...@falafel.plessy.net
Re: Debian services and Debian infrastructure
Hello everybody, I do not think that it is possible to solve all the points of misunderstanding in a long thread of long emails. Personally, I am totally confused by what I read, and do not understand what is even the basic stand point of each participant. May I suggest that you talk directly face to face or by videoconference ? For me, the take home message is: - Do not develop services that need you to have administrator access, because this is hard to transpose on DSA-hosted machines. - Sevices on debian.net should be hosted by Debian as much as possible. After many years as a DD, I became better at using a machine via root privileges than via collective hosting. For instance, I completely forgot how to use CPAN, and I am much more comfortable configuring apache via /etc/apache2/sites-available than via .htaccess files. Also, by my activity of a DD, I am more familiar with Testing-Unstable mixtures than with Stable. For example again, I did the apache 2.4 transition, where the Debian Apache team made a great work, and I would prefer to forget how the 2.2 systems work. I think that if I enjoyed collective hosting, I would have used it through numerus commercial providers, and would not have become a DD. At work, I would happily install software in my home directory on our CentOS servers, and would not mumble regularly that we need access to a cloud system instead. For upstream-metadata.debian.net (still broken, sorry, but I am working on it), I packaged the system (umegaya) so that others can clone it easily if needed, and will be happy to take care myself of the hosting if needed (because I jumped on apache 2.4 too quickly and blends.debian.net is running Wheezy...). But now I have the impression that self-hosting it is very unwelcome, and that the bar for setting up a .debian.net service is very high. I am not asking for an answer now since you need to clarify a lot of points together. I understand the need for transparency, but on the other hand, posting your discussion on -project gives the implicit message that the other subscribers should read it. Please take your time and consider using parallel and more casual discussion channels, to focus the postings on -project to the points of agreement that you reached, rather than the points of disagreement, which we all hope are just transient. Have a nice day, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140122232508.gb12...@falafel.plessy.net
Re: Debian Enhancement Proposals website temporarly broken.
Le Fri, Jan 03, 2014 at 02:54:51PM +0900, Charles Plessy a écrit : Le Thu, Dec 26, 2013 at 07:33:41PM +0100, Martin Zobel-Helas a écrit : assuming the content is entirely static, we could move dep.debian.net to dillon.debian.org. Would that be an option for you? I see that ikiwiki is installed on dillon.d.o and is used for dsa.d.o, but I am not sure if the same can be done for dep.d.n, because in our case we have the additional constraint that any Debian developer must be able to commit to the repository on alioth.d.o and trigger a rebuild of the wiki. Since gcc is not installed on dillon.d.o, ikiwiki wrappers can not be compiled, which rules out the use of the ikiwiki pingee plugin. Or would you install gcc ? The alternatives are to stay on Alioth (and install libimage-magick-perl), or host the ikiwiki somewhere else, or fall back to a simpler solution such as abandonning ikiwiki and using wiki.debian.org instead. Hi Martin and DSA team, do you think it would be possible to install libimage-magick-perl on Alioth or to help me to mirror a git or svn repository between Alioth and dillon.debian.org, or shall I move dep.debian.net on a third party infrastructure or a wiki.debian.org ? Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119123337.gf32...@falafel.plessy.net
Re: Documentation of the Dpkg triggers in the Policy (please).
Le Fri, Jan 17, 2014 at 11:22:50PM -0800, Russ Allbery a écrit : I don't think your attitude is at all the cause. Quite to the contrary, I really appreciate your continued effort to push this forward, since I think it's a major gap in Policy at the moment. I'm sorry that it's been so frustrating. Thanks a lot for your support! I think that the Dpkg triggers are a competitive advantage of Debian over other systems, that we do not advertise enough. RPM triggers are not the same (http://charles.plessy.org/Debian/debiâneries/triggers-dpkg-rpm/), and I am not aware of similar mechanisms elsewhere. Have a nice Sunday, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140119034656.gc32...@falafel.plessy.net
Documentation of the Dpkg triggers in the Policy (please).
Hi Guillem, regarding the Dpkg triggers (#582109), could you find some time to have a look? Alternatively, do you agree that other developers are encouraged at looking by themselves and second the patch, that is, that the integration of the Dpkg triggers in the Policy can go without your review ? I stil fear that people are thinking that only Dpkg developers are competent to second that patch (which would put an unreasonable burden on you). In the absence of help from other Developers, could for instance one of the four Policy editors, who were recently delegated and therefore re-stated their interest in editing the Policy, do something about it ? Lastly, if people think that my attitude is the cause of the blocked situation, please let me know (in public or private) so that I will stop disturbing with my attempts to participate. Frankly speaking, the current situation makes me bang my head on the walls. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140118023600.ga2...@falafel.plessy.net
Re: Updating the Policy Editors delegation
Le Sat, Jan 11, 2014 at 05:22:01PM +0100, Secretary - Kurt Roeckx a écrit : On Wed, Jan 08, 2014 at 12:10:08PM +, Neil McGovern wrote: As there has been no comments on the draft text I'll make that the official response. I want to thank Neil from writing this all down. Hi Kurt and Niel, thank you for the prompt in-depth analysis that you gave us. I was slow to react because I was puzzled by the discussion (why trying to change a delegation text that the delegates themselves agree with ?) and wanted to give to others the opportunity to express positive opinions first, before coming with my criticism. It think that it would have been fair to either set upfront a deadline for answering, or make a last call for comments. Also, less than a week (not even including a week-end) is quite a short delay. * Debian policy editors are a delegatable position by the DPL, but only if the DPL wishes to delegate the power to *set* policy, rather than to simply document current practice. I do not see a difference between documenting current practice and setting the policy, because in many cases it is unclear what the current practice is, and somebody needs the final call on this, similar to the role of the Secretary for interpreting the Constitution. Note that the delegation text anyway does not restrict the work of the Policy editors to follow the current practice. --- The Debian Policy Editors: - Guide the work on the Debian Policy Manual and related documents as a collaborative process where developers review and second or object to proposals, usually on the debian-policy mailing list [1]. [1]: https://lists.debian.org/debian-policy/ - Count seconds and weight objections to proposals, to determine whether they have reached sufficient consensus to be included, and accept consensual proposals. - Reject or refer to the Technical Committee proposals that fail to reach consensus. - Commit changes to the version control system repository used to maintain the Debian Policy Manual and related documents. - Maintain the debian-policy package. As package maintainers, they have the last word on package content, releases, bug reports, etc. --- Here are my interpretations point by point. Disclaimer: based on material posted earlier on mailing lists and the wiki, I wrote the text of the delegation. 1) The possibility of editing the Policy out of a collaborative process is not delegated. This does not say how the Editors should decide within a collaborative process, it only says that changes decided in closed comittee are not in the scope of the delegation. The link to the mailing list might be removed, however, for newcomers I find it more useful than harmful. 2) Count seconds could be removed indeed, to allow the Editors to accept a proposal that did not attract enough attention, but that they estimate consensual. The whole paragraph could also be removed, on the grounds that it is redundant with the Constitution's section 8.3 asking to the delegates to seek concensus. But on the other hand, because it is redundant, I think that it can not be anticonstitutional. 3) is indeed redundant with the section 6.3.6 of our Constitution. Maybe we should point to this section instead or even quote it. 4) and 5) may be too obvious as well, but I like the idea that, on top of making decisions, the Editors are also expected to do some more trivial work regarding formatting documents and commiting changes, therefore I think that these paragraphs, which do not restrict how decisions are taken, are useful. Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140112055610.ge4...@falafel.plessy.net
Re: Updating the Policy Editors delegation
Le Mon, Jan 06, 2014 at 04:21:52PM +, Ian Jackson a écrit : The policy editors' decisions on the contents of policy (or their failure to make such decisions) are subject to review by the TC, as I note above. The TC may overrule the editors with a simple majority. I still do not understand what is the problem we are trying to solve here. The bottleneck currently is who is doing the work, and the way it is done for the Policy is not so different as in other areas: we look for consensus, and when there are more complains than positive reviews, progresses are difficult. Said differently, it is easier to find somebody saying that something is not good than somebody proposing a concrete improvement to the thing. (I guess this is also why the Debian website is still managed with CVS…). We lose momentum because we are are too cautious in the amount of time we give to people to react to answers. If I had one change to propose, it would not be about delegating or not, but about making people's objections void if they do not answer to a rebuttal within 10 days. Even something like “please wait for my answer, I am busy”. Otherwise, negative opinions become paralysing. Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140106233651.gs22...@falafel.plessy.net
Re: Updating the Policy Editors delegation
Le Fri, Jan 03, 2014 at 05:58:19PM +, Ian Jackson a écrit : I think that the current policy maintenance approach is too bureaucratic and relies too little on the technical judgement of the policy editors. I would like to see the policy editors assess proposals not only for consensus and support, but also to consider proposals on their actual merit. Support (in the form of seconds) and consensus can be a very helpful guide to the merit of a proposal, and seeking consensus and second opinions is a very helpful way to avoid making mistakes, but IMO it is the merit of the proposal that should matter. Hi Ian, I think that the main problem is not the excess of neutrality of the Policy editors, but the lack of involvement from the Developers as a whole. For example, I am still amazed that despite we are expected to be hundreds, only one Developer managed to second the documentation of the Dpkg triggers (#582109), despite it does not introduce changes to the current practice (therefore, the challenge is only to check the accuracy; there is no arbitrary decision to take). This said, if the participation does not increase, it would make sense for the Policy editors to relax the current process. If I still have time next year and the situation does not improve, I can volunteer for the task. (For the moment I need to care of the big backlogs at all my other projects in Debian). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140104133759.gg22...@falafel.plessy.net
Re: Debian Enhancement Proposals website temporarly broken.
Le Thu, Dec 26, 2013 at 07:33:41PM +0100, Martin Zobel-Helas a écrit : On Fri Dec 27, 2013 at 02:03:38 +0900, Charles Plessy wrote: Since Alioth is not intended for hosting, I am also considering migrating the site, which is running Ikiwiki, to another host, and convert the Subversion repository to Git by the occasion. Unrelated to this techincal considerations, I also just pinged the drivers of the DEPs that are not either ACCEPTED or REJECTED. Some proposals tend to lose momentum, at least temporarly, and I hope that it is not chilling effects for other people insterested in improving Debian in related ways. assuming the content is entirely static, we could move dep.debian.net to dillon.debian.org. Would that be an option for you? Hi Martin, thanks for the offer. I see that ikiwiki is installed on dillon.d.o and is used for dsa.d.o, but I am not sure if the same can be done for dep.d.n, because in our case we have the additional constraint that any Debian developer must be able to commit to the repository on alioth.d.o and trigger a rebuild of the wiki. Since gcc is not installed on dillon.d.o, ikiwiki wrappers can not be compiled, which rules out the use of the ikiwiki pingee plugin. Or would you install gcc ? The alternatives are to stay on Alioth (and install libimage-magick-perl), or host the ikiwiki somewhere else, or fall back to a simpler solution such as abandonning ikiwiki and using wiki.debian.org instead. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20140103055451.gc22...@falafel.plessy.net
Debian Enhancement Proposals website temporarly broken.
Dear all, Yesterday I just realised that http://dep.debian.net now serves an outdated version that ends with DEP 9. This is likely caused by the merger between vasks and wagner. I am investigating the issue and will let you know when it will be repaired. Have a nice day, -- Charles Plessy Illkirch-Graffenstaden, France -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131224092203.ga2...@falafel.plessy.net
Re: The tell me if I'm being stupid statement
Le Wed, Dec 04, 2013 at 02:32:18PM -0500, Paul Tagliamonte a écrit : http://people.debian.org/~paultag/conduct/conduct-statement.txt Hi Paul and everybody, Here is an extract of the statement linked above. - I am willing to receive such messages: [ ] in private [ ] in public (but|and) I would prefer it to be done (in private|in public). - In my opinion, traffic is an issue, so I think that it should be up to the complainer to chose if his message is public or private. On the other hand, for private messages the receiver is free to block, or ignore them altogether. Lastly, the listmasters are the ones to decide if somebody is posting too many complains in public. If there are really too many private messages and the sender is a member of Debian, then the new anti-harrassment team may do something about. Personally, unless it becomes Debian's policy to advise against private messages, and I think that has been ruled out during the discussions about the code of conduct, I will keep sending some (hopefully most) of my complains in private instead of adding to the noise in public. Altogether, I think that the preference is quite correlated to the time one can dedicate reading public mailing lists, so I beg that the time-rich contributors make efforts for the time-poor contributors. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131204231239.ga2...@falafel.plessy.net
Re: Please update the DSA delegation
Le Thu, Dec 05, 2013 at 01:35:38AM +, Ian Jackson a écrit : But the main point here is that the team should normally be able to manage its membership directly. That's how these things have often been done (sometimes with no explicit DPL rubber stamp, even). I think that we need both. While the DPL is not the best person to bring new members to the team, it is the best person to ensure that the team does not accumulate too many inactive or barely active members. I think that such teams are dysfunctional, because they look overstaffed while at the same time they suffer from the lack of manpower. Also, the presence of old-timers who have just enough time to press the stop button from time to time but no time for the grunt work can be quite intimidating. If membership is fluid, there is no need to keep a title just in case, and I would prefer the DPL to be actively questionning memberships each time the delegation is renewed. Cheers, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131205015329.gg15...@falafel.plessy.net
We can not give lessons to others about trademarks (Re: Proposed MBF - mentions of the word Ubuntu)
Le Fri, Nov 08, 2013 at 05:35:36PM +, Ian Jackson a écrit : It appears that Canonical have gone to war with anyone who mentions the word Ubuntu in a way they don't like: http://arstechnica.com/information-technology/2013/11/canonical-abused-trademark-law-to-target-a-site-critical-of-ubuntu-privacy/ Hi Ian, haven't we twisted the arm of debian-multimedia.org to make them change their name ? I think that trademarks are a trap, but before reacting on others trademarks, we should take the lead and switch to a trust model where the Debian trademark does not play a role. We have much of the infrastructure there, but the bulk of the (enormous) work is communication and teaching people to stop relying on our trademark, and rely on signatures instead. (One could even consider asking for a .deb or a .debian TLD ?) Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131109002739.gb28...@falafel.plessy.net
Re: Should mailing list bans be published?
Le Mon, Nov 04, 2013 at 02:33:34PM -0500, Brian Gupta a écrit : I don't know the answer but perhaps, we can try experimenting with a system where the first action is a polite public warning by listmaster, pointing to code of conduct. (Assuming that the code of conduct is updated to cover this.) Hello everybody, I think that we should also encourage anybody (not just the listmasters) to send complain messages in private first. Public reminders should be the last ressort, not because of considerations on the person receiving the reminder, but because the very high probability that it triggers the sending of more and more off-topic messages. To take a concrete example, in last month's thread about systemd, I sent a public comment about assuming good faith, and I hesitated a lot about making it private. I sent it in public because at that point, I thought that it was important to compensate the harsh message by an appreciation to the Gnome developers, but the cost of it was an extra 8 messages that probably would never have been posted otherwise: censorship ! - no it isn't - angriness is not surprising - no it is - no it isn't, go figure yourself - you are contradicting yourself - what do you mean ? - please stop off-topic discussion (which thankfully was listened). Altogether, I am not sure that I made the right choice. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131104210524.ga1...@falafel.plessy.net
Re: Should mailing list bans be published?
Le Sun, Oct 27, 2013 at 07:58:03AM +, Lars Wirzenius a écrit : On Sun, Oct 27, 2013 at 09:00:20AM +0900, Charles Plessy wrote: Given how arbitrarly other bans have been proposed, I think that the outcome should stay private unless the banned person wishes so. I don't understand this at all. Are you saying Debian listmasters, who decide on bans, have been making arbitrary, and therefore badly justified, bans? Dear Lars and listmasters, no, this is not what I wrote, I am not saying that listmasters are making arbitrary bans (after checking an on-line dictionary, let me clarify that I read arbitrary in the sense of Determined by chance, whim, or impulse, and not by necessity, reason, or principle, not Established by a court or judge rather than by a specific law or statute). But I am saying that everybody, me, you, the listmasters, and anybody else who do some work will eventually take a decision that is not the best. Only the ones who does nothing does no mistake. More in particular, I have seen on another list this year a public call for banning a contributor, that was written in a precise authoritative style and looked well argumented, but was quickly contradicted by at least four debian developers, who unerlined that the contributor was polite, constructive and respectful. The point I want to make is that decisions are hard to take and the listmasters will eventually be presented contradicting informations, that might not even come on the same day. So why don't we mitigate in advance any possibility of error on our side ? Anyway, the tone of this debate gives a strange taste that we are trying to decide for the listmasters. On my side, if they are reluctant to publish a list of banned people, I say: I would be as well if I were in your position, and I would certainely not blame you if you would keep this information private. (For the reasonning, it was written by me and others before, and I will save everybody's time by not repeating it). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131028223043.gc14...@falafel.plessy.net
Re: Should mailing list bans be published?
On Sun, 27 Oct 2013, Charles Plessy wrote: In parallel, I think that we need some technical or social pressure for limiting to 1 or 2 messages a day each individual contribution to long threads. Le Sun, Oct 27, 2013 at 07:35:56AM +0100, Alexander Wirt a écrit : That is nonsense. There will always be people that have to write more mails to a thread. For example the maintainer of a discussed software, dpl, or the ctte member. And so on. Such a general limitation just won't work. Hi Alex, Just to clarify: I am not asking for new inflexible rules. I refrain myself from sending more than 1 or 2 messages per thread and per day, and I would be grateful to others if they would do so. If this means that somebody else will be the one posting an opinion or proposing an idea that is same to mine, I think that it is a gain for the project in terms of diversity, and it is not much of a loss for me as I hope that my contribution to Debian is far more than just telling what I think on mailing lists. I also make exceptions, and expect others to do so when it makes sense. But in many large discussions, there are a large number of messages that are not particuarly urgent. Not even judging on the contents, these messages are driving out of the discussion a lot of people who will not have time to read a dozens of them in a day. To implement technical measures is quite far-fetched; I should probably have not mentionned it. But the social pressure is simply to see the main contributors in term of achievements (not posting) moderating the pace of discussions by the rythm of their answers. (PS: still about reducing traffic, I am not sure if I would have answered if your reply had not started by this is nonsense…) PPS: Reducing the traffic is also why I refrain from posting +1 messages. Let's not making it important, otherwise, our mailboxes will explode. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131028002048.gb7...@falafel.plessy.net
Stepping down as a Policy Editor.
Le Mon, Oct 28, 2013 at 10:54:02AM +0900, Charles Plessy a écrit : I have just uploaded the Debian Policy 3.9.5.0. Dear all, this upload represent one year of work, and it was a very interesting experience, where I leaned a lot about the Debian packaging system. Unfortunately, my enthusiasm as Policy editor lead me to neglect my other packages, so I will take a break now. In particular, I will spend more time on the mime-support package. Because I would like that the list of delegates reflects well the present commitments, I am stepping down. I hope that in a year or two I still will have enough free time for a comeback. I also invite the othe delegates to consider if their current contribution matches their position. I think that rotation of delegates is healthy. Empty seats call for fresh people ! In particular, in addition to the work on normative changes, the Policy would benefit a lot from volunteers to convert it to DocBook XML. Do it and as a byproduct you will become an expert ! Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan signature.asc Description: Digital signature
Re: Should mailing list bans be published?
Le Sat, Oct 26, 2013 at 10:46:41AM -0700, Steve Langasek a écrit : What do the rest of you think? Given how arbitrarly other bans have been proposed, I think that the outcome should stay private unless the banned person wishes so. This will also reduce the pressure on the listmasters, by reducing the consequences of giving unequal treatments to people. Why not making the list readable on a machine open to the Debian Developers only ? In parallel, I think that we need some technical or social pressure for limiting to 1 or 2 messages a day each individual contribution to long threads. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2013102720.gb14...@falafel.plessy.net
Re: Debian companies group
Le Fri, Sep 06, 2013 at 09:07:22AM +0200, Lucas Nussbaum a écrit : Regarding the secrecy requirement, I can totally see how sketching a business model involving several business entities on one of the two examples above could require some secrecy. I prefer to see it happening on a Debian-provided list where the only criteria is related to the size of companies, rather than in private discussions between a self-selected set of companies. Hi Lucas and Michael, here are brief comments that I hope to be useful despite I have no stakes in this initiative. The term secrecy is vague and may misrepresent what you are proposing. If the companies list would function with a secrecy agreement like debian-private, then we could end up in the same absurd situations where people start an intersting technical discussion that did not need to be secret, and that becomes hard to integrate or be summarised outside until it is made sure that every participant agrees. I do not recommend this policy. Maybe simpler restrictions (no archive, moderation, ...) would also satisfy the participants ? Obviously, companies that are fine with public archive, high-traffic, long threads and stochastic follow-up are already with us on debian-devel... In that sense, for a new list there is by definition the need for an entry bar that limits the number of messages and ensures that a large number of subscribers are interested in reading them (let's not require participants to be proficient with procmail). Perhaps if you set a given (and flexible) number of goals (hardware support and long term support sound excellent to start with), and make them public, then you will reduce some of the crispation of not being able to know what is going on the list in real time. Have a nice week-end, and good luck for your project. -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130907061851.gb23...@falafel.plessy.net
Re: Doing something about should remain private forever emails
Le Wed, Jun 19, 2013 at 07:35:26PM +0200, Raphael Geissert a écrit : I believe sgran's question was intended for Charles' proposal that is basically more time consuming than declassifying. Actually, I do not understand the question, because only the listmasters can create new mailing lists and this is the essence of my proposal. The list for vacation, weddings etc. would not be archived, which results in zero work for declassification. The high-traffic list would stay in the same state as it is, this is also no extra work. For the announce list, I think that the best person to work on the declassification would be the posters theselves, proactively by ensuring that what they send is declassifiable by default three years later. For the public summary, maybe it was not a good idea after all. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130620091641.gl13...@falafel.plessy.net
Re: Doing something about should remain private forever emails
Le Tue, Jun 18, 2013 at 10:49:55PM +0200, Raphael Geissert a écrit : At present, new DDs can access emails that were sent to -private years ago. People who might (or might not) be a member of the project and sent an email may not necessarily agree to that. Or a less controversial example: put simply, if an unauthorised person gets a hand on master.d.o there is no hope for those messages. Hi Raphael and everybody, couldn't we first have a split of the list into: - one people list for messages related to people's private life. For this list, the the most easy way to solve the problem of declassification would be to not archive it. - one project for messages related to Debian but that the senders beleive should not be shared with non-members. For the project list related to Debian, as a first step of declassification, we should regularly inform the public of what was discussed. This could be aided by a third list, similar to debian-devel-announce, where people who start a thread can inform others about issues and timelines. The messages should then be written with declassification in mind. For instance, I see two monster threads in the archives of May, which make very happy that I an not subscribed. It is our culture that our disucssions give more space to the DDs who have enough free time to read and write dozens of emails per day. Luckily, the end result in term of decisions is not too bad. But still, I would be happy if there were an easy way to know what is going on, and that does not require reading or deleting hundreds of emails. If we reach that level of transparency, then the declassification of each message becomes less important, as it becomes about who thinks what, and not about what the project decided and was not made public. (PS: feel free to paste the proposal in the wiki if you like it). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130618224736.gc...@falafel.plessy.net
Re: Proposal #3: Upstream/Debian Project donations (was: PaySwarm-based donations)
Le Tue, Jun 18, 2013 at 09:55:11PM -0400, Manu Sporny a écrit : This is a highly re-worked proposal for performing upstream donations and donations to the Debian project. Major changes include: * Debian developers are not allowed to receive any direct monetary contribution or change the upstream DONATE file in any way. * The solution isn't specific to apt. * The solution isn't PaySwarm specific. Upstream developers can list Bitcoin addresses, PaySwarm addresses, or URLs that lead to payment gateways like PayPal, Google Wallet, etc. There will be a package called 'donate' that will install a program called 'donate' on the system. If someone wants to send $5 to an upstream project, they can do something like the following: donate PACKAGE $5 Dear Manu, I think that this was a good discussion, including the latest answers made to you by Paul and Russ. I wish you good luck, as much of the work is ahead. I hope that further discussions with the FreeDesktop, FSF, and other distribution communities will be fruitful and that one day Debian will redistribute a tool such as the one that is taking shape. Just as a small comment: while it looks nice to have a command called donate (especially for English-speaking users), I think that such a direct dictionary word should be avoided, so that alternative programs can flourish if needed. But I do not have a better name to suggest. (note also that there are other point of views on how to best name a program). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130619034605.gk13...@falafel.plessy.net
Re: PaySwarm-based Debian donations (was: Re: KickStarter for Debian packages)
Le Sat, Jun 15, 2013 at 11:20:47PM -0400, Manu Sporny a écrit : The files are composed together to suggest where donations should go to the sender. They are composed in this order: 1. Upstream project's DONATE file. 2. Package maintainers DONATE file. 3. System's DONATE file. So, when a benefactor types 'apt-donate apache2 $5', assuming 90% goes to ASF and 10% goes to Debian, they are provided with the following suggestion: Of your $5 donation: 1. $4.50 will go to the Apache Software Foundation 2. $0.50 will go to the Debian Project If you would like to adjust the amounts, enter the number beside the amount that you'd like to adjust. Do these amounts look good to you? (y/n) Dear Manu, I like the idea of a DONATE file to facilitate donations to upstream projects. At this point, I wonder what would be the role of apt. - If the goal is to donate for packages installed in the system, the DONATE files can be treated in a similar way to the FreeDesktop menu files: packages would install them in a given directory, and any donation system would parse them and detect additions and removals with Dpkg triggers. One advantage is that software using the DONATE files to help the user to send money or bitcoins could be written independantly of the packaging system. - Apt would be useful if the goal is to gather the information in control files of the Debian archive (see DEP 11 for something a bit similar: http://wiki.debian.org/AppStreamDebianProposal). But I think that this is not desirable, as it opens the risk of having conflicting settings when using third-party repositories. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130617120411.gg7...@falafel.plessy.net
Re: KickStarter for Debian packages - crowdfunding/donations for development
Le Sat, Jun 15, 2013 at 12:25:26AM -0400, Joey Hess a écrit : Charles Plessy wrote: In the case of Debian, I share with others the concern of having the packages as a source of revenue How about making fixed bugs a source of revenue? I do not see how to fit this in the PaySwarm model proposed here, unless there are URLs for billing ? In that case, the bounties could accumulate until somebody takes them by fixing the bug. We would probably need some review system unless there are easy way for refunds. For instance, one person would claim the bounties by sending a patch, and a Debian Developer or Maintainer would acknowledge that the patch actually solves the problem by uploading the package. But there are probably better ways to do it. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130615061824.ge11...@falafel.plessy.net
Re: 2nd draft (was: Re: Revising the Code of Conduct)
On Tue, May 21, 2013 at 07:08:17PM +0900, Charles Plessy wrote: - I think that we shoud encourage more private replies. For instance, If you want to complain to someone who sent you a carbon copy when you did not ask for it, do it privately (from the current CoC), but also for +1 messages, etc. To balance this, we may mention that people starting and fuelling a long thread would be very welcome to post a summary at the end. Le Wed, May 22, 2013 at 10:52:42AM +0200, Wouter Verhelst a écrit : I disagree with that. First, in our social contract, we encourage openness, not privacy. In addition to that, sending a reply in private has several issues: - People don't see the replies, which tends to result in having the same argument be repeated. Several times, if all of them reply in private. This is an issue not only for technical arguments, but also for please behave style of messages. In fact, in the latter case it can be more problematic, since receiving a high number of such messages may amount to a mobbing and have the opposite effect from what was intended. Hi Wouter, it is all a question of trade-off. On my side, if I stay as busy at work as in the past months, I will soon drop off lists like debian-devel. For the moment I do my best because I expect the volume to decrease once the the post-release enthousiasm flattens. But the +1, do not CC me, you do not behave, stop shouting, etc. messages are making it harder for me to keep up. I wish they were private. By the way, thank you for answering to many people in a single message. Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130522230232.gb4...@falafel.plessy.net
Re: Revising the Code of Conduct
Hi Wouter, many thanks for this initiative ! Here are some comments. - I think that we shoud encourage more private replies. For instance, If you want to complain to someone who sent you a carbon copy when you did not ask for it, do it privately (from the current CoC), but also for +1 messages, etc. To balance this, we may mention that people starting and fuelling a long thread would be very welcome to post a summary at the end. - I think that in typical threads where the number of messages is expected to be large (perhaps this one for instance), people should really do their best to limit the number of messages they post. If others agree, I recommend to add this to the CoC. - How about recommending to let a discussion start before answering to an email ? Here is one interesting extract from another CoC: When responding to a very simple question, use the following algorithm: - compose your response - type 4*runif(1) at the R prompt, and wait this many hours - check for new posts to R-help; if no similar suggestion, post your response (This is partly in jest, but if you know immediately why it is suggested, you probably should use it! Also, it's a nice idea to replace 4 by the number of years you have been using R or S-plus.) http://www.r-project.org/posting-guide.html - How about separating the technical and social aspects ? I feel that comments about Cc headers, length of lines or presence of HTML tags tend to inflate tensions, rather than helping others to optimise their communication. For instance I find some recommendations against to posting borderline insulting. Hopefully, this will be my only message in this tread. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130521100817.gl17...@falafel.plessy.net
Re: Registering the Debian Logo as our trademark?
Le Wed, Apr 24, 2013 at 07:51:06AM +0900, Charles Plessy a écrit : Le Mon, Apr 22, 2013 at 04:04:34PM -0400, Brian Gupta a écrit : Cons: - - Filing costs of ~$700 - Labor/work required to file (With assistance from SFLC, I am willing to do much of the work required.) I wonder how will be the cost of a registered trademark on the mid term, for instance 5 or 10 years. Will it trigger more payments to other offices, similarly to our effort of maintaining debian domain names in multiple top-level domains ? Is the payment to be renewed periodically ? In parallel, since the assistance of SFLC is a resource that we can not expand nor buy with money, will the possession of a registration trademark take a significant share of the assistance we can receive ? Hi Brian, as suggested by Lucas on debian-devel-announce, before Debian proceeds with formally registering its logo, I would like to ask again a clarification on the strategy for the registration. A simulation on http://www.wipo.int indicates that registering in all possible countries would cost 60,425 Swiss francs (~65,000 US dollars). For the renwal, I figured out that it is once every 10 years in each countries that I checked. So the upper bound for the annual cost would still be in the order of thousands of dollars. The lower bound would be to register in a single country, with a cost of less of a hundred dollars per year. I would like to know what is the strategy that is taken (is the registration in the USA the starting point, or is it the only country that we aim), and what is the expected effect (if there is a hostile company or group that is determined to use our image and reputation where we fail to protect it adequately, how effective would be the strategy of registering in a single country). Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130504042147.ga22...@falafel.plessy.net
Re: Debian participation into GNOME Outreach Program for Women
Le Wed, Apr 03, 2013 at 09:32:47AM +0200, Stefano Zacchiroli a écrit : If not, we can do mission-specific fund raising, I wouldn't mind that either, as we do something similar for, say, DebConf already. It wouldn't be possible, in my opinion, to raise all the needed money before OPW application deadline. But I'm 100% sure that given few months we can raise the needed money. Hence, I do not see this as a blocker to go forward (as long as people believe in my prevision). Would you consider this acceptable? Hi Stefano and Sune, I think that projects such as the OPW are best suited for fundraising and I would personally be keen on donating money. Also, I think that it would be fair to use Debian's money for the first round of OPW if the admins are committed to use fundraising for the next rounds. This said, if the GSoC admins would like to redirect the money they bring in Debian to the OPW I think that it would be fair to accept (do-o-cracy...). Bonus question: do we have good fundaising-management sofware packaged in Debian ? That could be an interesting project for the OPW ;) Cheers, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130404073515.gh9...@falafel.plessy.net
Re: About the statement about Debian and the CC licenses on Wikipedia.
Le Fri, Mar 01, 2013 at 08:19:44PM -0800, Russ Allbery a écrit : Charles Plessy ple...@debian.org writes: You may not distribute, publicly display, publicly perform, or publicly digitally perform the Work with any technological measures that control access or use of the Work in a manner inconsistent with the terms of this License Agreement. Notice that this says you may not use any technological measures that control access while you're publicly displaying or performing the work *regardless of whether you're distributing it*. In other words, this wording, on its face, restricts how you *use* the work in your own environment, provided that's public in some sense, even if you're not redistributing it. The new wording avoids this problem: When You Distribute or Publicly Perform the Work, You may not impose any effective technological measures on the Work that restrict the ability of a recipient of the Work from You to exercise the rights granted to that recipient under the terms of the License. ...by explicitly limiting the requirement to the context of conveying the work to a third party and saying that you can't limit their usage, which is what was really intended. It also avoids other edge cases, such as when you might introduce DRM for some technical reason but simultaneously convey a non-DRM version of the work. For example, suppose that you want to use it on a device that *requires* everything be controlled with DRM. The previous wording would prevent you from ever making the work available on that device; the current wording allows you to do that as long as you *also* provide the recipient with the necessary pieces that they aren't restricted by the restrictions of that device for other uses. Hi Russ and FTP team, I am not so convinced by the arguments, but if I get the confirmation from the FTP team that the above is the exact reason why versions inferior to 2.5 are not suitable for Debian, then I volunteer to update the Wikipedia page. Here is what leaves me unconvinced. 1) A public performance or display is a redistribution of the work. If a text is licensed under CC-BY-2.5, and if one publically speaks it, then others may record or memorise it. I see this as a distribution and I think that this is the intent of this license, which does not mention anything about private use. Therefore I think that it does not disallow the use of DRMs when the work is only redistributed privately. 2) From http://wiki.creativecommons.org/Version_3#DRM, it looks like the intent of CC 3.0 is to prohibit as as much as CC 2.5 did the parallel distribution of a work controlled with DRM and a receipe to evade the DRM (even if this receipe is as simple of giving an URL to an unrestricted version). Conversely, if we do not take Creative Commons' intentions into account, but only focus on the license texts, then I think that for both version 2.5 and 3.0 it is also possible to argue that they allow parallel distribution. Altogether I think that the difference between 2.5 and 3.0 is not clear on that matter. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130302053735.gc12...@falafel.plessy.net
Can CC BY 2.0 be upgraded to 3.0 ?
Le Sat, Feb 23, 2013 at 10:39:04PM +0900, Charles Plessy a écrit : Le Mon, Jan 28, 2013 at 03:05:34PM +0100, Torsten Werner a écrit : Am 27.01.13 02:04, schrieb Charles Plessy: Torsten, do you konw what is the FTP team's position on this ? Such version upgrades has been accepted some years ago but I forgot the packages names. Thanks for the information; I upgraded the Debian wiki accordingly. http://wiki.debian.org/DFSGLicenses?action=diffrev2=57rev1=56 Creative Commons Attribution Share-Alike (CC-BY-SA) v3.0 In contrast to the CC-SA 1.0 license, version 3.0 is considered to be compatible to the DFSG. In addition, the version 2.0 and 2.5 are transitively compatible because of clause 4b that allows redistribution of derivative works under later versions of the license. (see https://lists.debian.org/510685ae.4000...@twerner42.de) Dear FTP team, I found #675435 where it was written that CC-BY-SA-2.0 was not suitable for Debian, and now I am confused. Could you let us know your position on the possiblity to accept CC-BY-SA-2.0 by upgrading it to 3.0 through its clause 4b ? Have a nice day, -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130225134638.ga3...@falafel.plessy.net
Re: Can we change our position on CC BY 2.0 and 2.5 ?
Le Mon, Jan 28, 2013 at 03:05:34PM +0100, Torsten Werner a écrit : Am 27.01.13 02:04, schrieb Charles Plessy: Torsten, do you konw what is the FTP team's position on this ? Such version upgrades has been accepted some years ago but I forgot the packages names. Thanks for the information; I upgraded the Debian wiki accordingly. http://wiki.debian.org/DFSGLicenses?action=diffrev2=57rev1=56 Creative Commons Attribution Share-Alike (CC-BY-SA) v3.0 In contrast to the CC-SA 1.0 license, version 3.0 is considered to be compatible to the DFSG. In addition, the version 2.0 and 2.5 are transitively compatible because of clause 4b that allows redistribution of derivative works under later versions of the license. (see https://lists.debian.org/510685ae.4000...@twerner42.de) Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130223133904.gc3...@falafel.plessy.net
Re: Copyright assignement for Debian tools?
Le Sat, Feb 09, 2013 at 05:23:59PM +0100, Thomas Koch a écrit : I've no interest to be the copyright holder. I'd much rather like to write Copyright 2013 The Debian Project. (Actually I'm totally annoyed by anything related to copyright...) Hi Thomas, I share the same feeling and in some of my latest packages, I simply make no mention of copyright for my contributions, so that they are distributed under the same terms as the whole. Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130209223343.gb17...@falafel.plessy.net
