Re: We need to define a path for Debian to climate neutrality
Le vendredi, 13 mai 2022, 17.38:13 h CEST Thomas Goirand a écrit : > Most of the time, "green energy" is just "green washing". If you buy > "green energy" in France or Swiss (these are the only places I know for > sure what's going on), you get a higher electricity bill, and a slot in > the green energy consumers. But the electricity may well come from the > nearby coal power plant, even if you bought a slot of green electricity. Electricity on wires is like water in tubes; it might be "green", but tastes equal. [0] What matters is what provider your payment gets wired to. The point of buying "green" energy is not to guarantee its provenance in your plug, it's to guarantee that the "green" providers get compensated for your energy consumption. It doesn't make any sense to build separated electricity transport networks, to avoid accusations of "green washing". It _does_ make sense to direct consumer energy bills' money to sustainable producers. -- OdyX [0] I know I know, water systems are usually way less interconnected than electricity networks, and water doesn't taste universally equal.
Re: Keysigning in times of COVID-19
Le jeudi, 6 août 2020, 17.54:21 h CEST Enrico Zini a écrit : > What do you think could be alternative key signing policies, that would > be acceptable to you, that would not require traveling and meeting face > to face? Several others have eloquently described key signing policies close to mine, but I'll phrase mine here nevertheless. Since the rumbles of "someone showed up with either a fake passport, or a passport from a not-universally-recognised coutry at a keysigning party", I became quite dubious about key signing parties: I am not trained, skilled or equipped to validate identity papers from any country, and would probably be fooled by a reasonable copy of a swiss identity card. It's of much more value to me to get random non-official papers (a driving license, a business card, a library member card, etc) that are coherent between themselves: that at least shows an "identity continuity", that I would expect to be also coherent with the identity on the key. The line I try to stick with is "crowd knowledge": is this person I'm about to sign the key of "known" as the name they claim to carry? Does their key "name" correspond to one or some of the names they go by? In recent times (during which physical encounters were still a possibility), I have actually asked someone else around "can you tell me the name of this person I'm about to sign the key of?" I have also often had a very small chit-chat: "what do you do in Debian / free software?", "what brought you here?". It's not an interview per se, but answers still matter. Pseudonyms are totally OK for me, as long as the pseudos are in use: person A has an "official" "John Doe" identity, but they usually go as "Eric"; sign their emails with Eric, and get called by (free software) friends "Eric". In absence of any identity paper, provided they answer as "Eric", are known as "Eric", I would clearly sign their key even without any trace of John Doe anywhere. I don't need to know their "official" name is "John Doe", actually. My own key is a good case for thought: my "Oriole" identity (and email) got signed a lot by DDs (but not always) despite me not mentionning this pseudonym of mine much, or at all: I am not known, nor would be called "Oriole" in Debian (but would likely respond to that name), but it's still an identity I carry in some circles. Thanks for sparkling that conversation Enrico, it's very interesting! Cheers, OdyX, or is it Didier, or Oriole ? signature.asc Description: This is a digitally signed message part.
Re: distributed moderation of mailinglist
Le dimanche, 23 février 2020, 18.48:44 h CET Didier 'OdyX' Raboud a écrit : > Le dimanche, 23 février 2020, 18.29:32 h CET Felix Lechner a écrit : > > > Do you really expect such a mechanism to be needed? > > > > Moderators have opinions. The mailing lists are our primary public > > forum. Feelings may run higher, and accusations may abound. > > It always seemed obvious; but for moderation to work while still standing > for our values, we need: … I figured I'd clarify. All of this is something we should aim for, not request as an upfront condition. What we need now is basically _any_ moderation, to put a halt to the ongoing abuse of our infrastructure. Frankly, I don't care the slightest if the system ends up blocking too many users or emails: it's not a free speech issue and there are tons of other avenues available to people with good intentions to reach out and discuss things about Debian. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: distributed moderation of mailinglist
Le dimanche, 23 février 2020, 18.29:32 h CET Felix Lechner a écrit : > > Do you really expect such a mechanism to be needed? > > Moderators have opinions. The mailing lists are our primary public > forum. Feelings may run higher, and accusations may abound. It always seemed obvious; but for moderation to work while still standing for our values, we need: - traceability (which moderator took which decision, when) - accountability (the moderators need to decide based on clear, published guidelines, that clarify which categories to moderate, and how) - transparency (allow senders to know if their mail is waiting for moderation, or was rejected; also probably publish numbers) - feedback (senders need to know _why_ their email was delayed or rejected, and be pointed to…) - a clear appeal process (super-moderators? review by 3 other moderators?) The point of an efficient moderation is to rule fast on clear categories: - allow obviously good email in; - reject (or hold) obviously bad email. … and to take the time needed for the non-obvious cases could require 2-3, or $n opinions. 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. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
Le jeudi, 20 février 2020, 01.14:19 h CET Anthony DeRobertis a écrit : > On 2/19/20 2:00 PM, Didier 'OdyX' Raboud wrote: > > At the risk of poking a little fun at recent US politics: this _really > > really_ reads as a /quid pro quo/. > > Not really; a quid pro quo there means more than the literal "something > for something". Otherwise going to the grocery store and buying an apple > is quid pro quo; perhaps you can use the term like that, but then it > loses any negative connotation. Fair enough. I failed at my attempt at drawing parallels; and triggering smiles. Sorry. > Here, it seems pretty clear that Sam is working to benefit Debian, not > himself. The DPL trying to get things of value for Debian is not > corrupt, it's part of his job. For the record; I have _absolutely no doubt_ that Sam is working to benefit Debian. But in that particular instance, I happen to strongly disagree that his actions have a positive effect on Debian (the community). -- OdyX signature.asc Description: This is a digitally signed message part.
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
(Re-reading your statement). Le mercredi, 19 février 2020, 16.17:00 h CET Sam Hartman a écrit : > Debian is Asked to Support a Protest of a Debian Activity > = > > The Montreal organizers could have simply organized an alternative for > those who were not traveling to DC20 for whatever reason. > That's something Debian could support with no reservations. > > By making the political statement in their announcement, they have > turned the conference into a protest. It's being billed as an > alternative to DebConf for political reasons. > > (…) > > So in effect the Debian Project is being asked to support a protest of > its own activity. The crux of my strong disagreement is here: as DPL, you just _framed_ the Montreal miniDebConf as a protest. signature.asc Description: This is a digitally signed message part.
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
Le mercredi, 19 février 2020, 20.04:12 h CET Sam Hartman a écrit : > Then we miss an opportunity for the Montreal organizers to clearly and > unambiguously say to the world and Debian their fight is with the > government of Israel not with the DC20 volunteers. They never said otherwise. They never said _this_ specifically, but they never said otherwise. Of course, there's a sad shadow of negativity in their announce mail, that could have been avoided; I'm not disputing this. But I really feel you're reading more than they wrote, or intended. Let me quote this again: > Following the announcement of the DebConf20 location, our desire to > participate became incompatible with our commitment toward the Boycott, > Divestment and Sanctions (BDS) campaign launched by Palestinian civil > society in 2005. Hence, many active Montreal-based Debian developpers, > along with a number of other Debian developpers, have decided not to > travel to Israel in August 2020 for DebConf20. > > Nevertheless, recognizing the importance of DebConf for the health of > both the developper community and the project as a whole, we decided to > organize a miniDebConf just prior to DebConf20 in the hope that fellow > developpers who may have otherwise skipped DebConf entirely this year > might join us instead. Fellow developpers who decide to travel to both > events are of course most welcome. I have now read this dozens of times; I _still_ find this fairly nuanced and very well-written; I'm quite sure they spend quite some time fine-tuning this. It is explaining _their_ participation incompatibility to a DebConf in Israel, and _their_ motivation to organize another, separate, but still connected event. They _explicitely_ make sure people willing to attend both events are able and welcome to do so. Asking them to commit to an explicit declaration of support to another Debian team (not lower than withdrawing their request for logistical support from the project; really !?) that they never "not supported" is unnecessarily humiliating, and uncalled for. -- OdyX
Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team
I have taken my frustration to Sam, and he clarified one thing: Le mercredi, 19 février 2020, 16.17:00 h CET Sam Hartman a écrit : > So, I'm going to approve the budget with one change requested by the > DebConf committee. But see below. I (now) understand this to mean "both the budget and the use of Debian ressources" _are_ approved. This makes the following request _very_ bizarre. > My Request to Montreal Organizers > = > > (…) > So, I ask you to find and make some meaningful, clear statement to show > support for our volunteers putting on DC20. > > I think the easiest way for you to do that is to withdraw your budget > request and for you to do the conference logistics on your own. (…) > > If that's not your choice, then I ask you to find some other meaningful > way (stronger than just words) to show support for the volunteers in > Debian, even though you disagree with the location. > > The choice is entirely yours. > This is a request. You can reinterpret it or even ignore it. At the risk of poking a little fun at recent US politics: this _really really_ reads as a /quid pro quo/. You are still saying "one way is to withdraw your budget request (…); if that is not your choice, I _ask_ you to find some other way". So what happens if they put your request to /dev/null, if you're not withdrawing the DPL approval? You are asking the Montreal miniDebConf Team to "show support for our volunteers putting on DC20" while, at *no point*, they have said *anything* contrary. They said "we cannot _attend_ DebConf20 for personal reasons", and now you're asking them to show their allegiance to the Debian project; or what is it?. That's not (quoting your own words): "valuing the other members of Debian even when you disagree with them". I'm really disappointed and sad that you found no other way to support both the DebConf20 _and_ the Montreal miniDebConf teams other than asking the latter explicitly to do without Debian's logistical support. OdyX signature.asc Description: This is a digitally signed message part.
Re: Announcing miniDebConf Montreal 2020 -- August 6th to August 9th 2020
Le lundi, 17 février 2020, 19.19:02 h CET Sam Hartman a écrit : > > "Jerome" == Jerome Charaoui writes: > Jerome> Following the announcement of the DebConf20 location, our > Jerome> desire to participate became incompatible with our > Jerome> commitment toward the Boycott, Divestment and Sanctions > Jerome> (BDS) campaign launched by Palestinian civil society in > Jerome> 2005. Hence, many active Montreal-based Debian developpers, > Jerome> along with a number of other Debian developpers, have > Jerome> decided not to travel to Israel in August 2020 for > Jerome> DebConf20. > > > I'm quite frustrated, disappointed and angry reading the above. > > I had expressed a fairly strong discomfort with the anti-DC20 messaging > I got from the original contact about Montreal. To offer some contrast, although I can agree such introduction _could_ have been left out of the announcement email, I find the phrasing to be honest, transparent, and fair: it is not against Debian, not against DebConf, not against the DebConf Committee. It is merely explaining in full sight their reasons to a) not attend DebConf; b) organize that event at that time. Specifically, I find the announcement OK _because_ the event dates do not directly conflict with DebConf20's. > I'm going to take a couple of days to calm down before making any > decisions, but this is not appropriate messaging in an event that Debian > supports. For the record, I disagree that such messaging is inappropriate on debian- devel-announce@, nor as framing for an event "that Debian supports". > In particular, we as a project made a decision about where we were > holding DebConf 20. I'd rephrase this as "the DebConf committee, as DPL delegates, made a decision about by whom DebConf20 was to be organized and where; this decision has not been overriden by a GR" [0,1]. There's nuance away from "we as a project made a decision". > The above messaging comes across as a condemnation of what the project > has decided to do, rather than something that supports our diversity and > compliments DC20 while supporting those who choose not to attend. Sam; I think you're overreacting and would encourage you to re-read the full annoucement mail, and _specifically_ the part that you quoted; it "just" explains why some people from our community cannot consider attending DebConf20, and how they converted this constraint into organizing _another_ Debian gathering, at different dates. Frankly, leaving this reasoning out of the announcement email would have felt disingenuous; as their unease with regards to DebConf20's location was known already. Regards, OdyX [0] https://lists.debian.org/debconf-team/2019/03/msg00021.html [1] Disclaimer: I was a delegate when the decision was taken. signature.asc Description: This is a digitally signed message part.
Re: MiniDebCamp 2021 pre-FOSDEM?
Le vendredi, 31 janvier 2020, 18.57:16 h CET Holger Levsen a écrit : > so it seems to me, the MiniDebCamp 2020 pre-FOSDEM was - in many ways - > a nice and useful event, which people enjoyed and where some stuff got > done. IOW: I hope you liked it! I did, thank you very much for making this possible! > So, shall we repeat this for 2021? > > And shall we do it again at HSBXL? The venue is a bit challenging but > also quite nice and has a lot of potential we didn't use. The (mostly obvious if you were there) challenges are: - 3 large flight of stairs (~ 5-6 floors), no elevator, - 2-3 numbered locks with secrets to be passed around, - the heated room got quite crowded; and some hacked in the much colder space just outside of the main room. > And btw, Debian could also give some money to HSBXL. This time I was > very happy that $random_DDs_employer is willing to pay 3*50 EUR > attendence fee to HSBXL but IMHO Debian could also just donate > $some_money to HSBXL. I'd recommend making it clearer that it's possible to get invoices for attendance; something like: "Attendance is free, but if you or your employer can contribute a modest amount towards helping making this event possible, the recommended daily amount is #€; please get in contact with $ to get a formal invoice". > P.S.: last year I was wondering if we should have a pre- or post FOSDEM > event and today I think pre FOSDEM is better. pre- is good, agreed. -- OdyX signature.asc Description: This is a digitally signed message part.
Re: BSP Reimbursements
Le jeudi, 3 octobre 2019, 12.54:53 h CEST Kyle Robbertze a écrit : > On 2019/10/02 22:17, Didier 'OdyX' Raboud wrote: > > Third: what rules-of-thumb, or guidelines do we want for travel support? > > In the context of relatively _short_ events (2-5 days), I think we ought > > to > > put upper limits in term of amounts, and in terms of distance. Put > > differently: set economical and ecological limits. In this day and age, I > > don't think Debian should be supporting flying long distances for short > > events [2]. So we could have a duration-to-distance, or similar, > > criteria, as well as "qualitative" incentives. I'd prefer Debian to > > sponsor a 600€ train ride than a 150€ flight, for instance. As a rule of > > thumb, what about: "Travel distance is max ~400km per event day duration, > > prefer land transportation where applicable"? > > (Also, connected to that "distance" question is also "who gets > > supported?") > > A distance limit effectively prevents people from remoter areas of the > world from attending events unless they organise them themselves or have > the means to afford internation travel. Note that my intention was to have a linear relation between duration and distance; and my 400km factor was perhaps a bad choice. But sticking to that factor for the merits of example, it would mean: * 1 day event: max 400km away * 2 days event: max 800km away * 3 days event: max 1200km away * … etc … you get the idea. The point of that idea is to encourage longer events and, inversely, to discourage long travels for short events. But I understand that it doesn't meet enthusiasm nor consensus; and I do realize that my own privileged center-european situation makes it clearly easier for me than for some others. I also arguably picked a prohibitively low number. > While I would not expect Debian to sponsor my travel entirely to attend > a 3 day conference in Europe, often partial funding makes attending > these events possible for me (when the duration and content makes it > worth the travel). Partial funding should often be possible, and encouraged, yes. But then we hit the "who have no other means to cover the costs" phrasing: if someone _can_ spend 800$ to fly, do they really "have no other means to cover" for 1000$, or 1200$ ? (I have in the past been part of the Bursaries team for DebConf. These problems are hard™.) > The trade-off between potential value and distance/means of transport is > inherently personal and shouldn't be decided by Debian for everyone. Well. We're discussing what Debian would financially support, not what Debian would allow. Even with this idea implemented (and it doesn't look like it will), one could fly for as long as they wanted to attend the shortest Debian event, provided that they would either cover for their travel costs (or only ask for support from Debian for the maximal amount granted under the circumstances). Thank you for bringing a different viewpoint. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Expense Rules for Mini-DebConfs
Le mercredi, 2 octobre 2019, 23.33:10 h CEST Sam Hartman a écrit : > >>>>> "Didier" == Didier 'OdyX' Raboud writes: > >> TL;DR: Do we want BSP organizers to take on the responsibility of > >> batching together travel reimbursement requests. > > Didier> Yes, but… I think we, as a project, need to be clear about > Didier> what this means, along at least three axes. > > Didier> First: what types of events qualify for travel > Didier> reimbursement? You have mentioned BSPs, but would a > Didier> miniDebConf also qualify? Of course, it is the expectation > Didier> that miniDebConf attendees attend to "enhance Debian"; but > Didier> also that they might present, or attend talks, > Didier> presentations, etc; during which they are not (should not > Didier> be) hunting bugs. I think such micro- conferences, although > Didier> not explicitly Bug Squashing Parties, should also benefit. > > Seriously, I think it is well established that (mini) DebConfs are > available for travel reimbursements. I think the procedures for > mini-DebConfs and sprints are reasonably well understood and working > well, so I wasn't planning on revisiting them at this time. I realize I had not read https://wiki.debian.org/Sprints/HowTo recently; my bad. It has: > Debian, within the limit of available resources, tries hard to cover travel > and accommodation costs for those who have no other means to cover the > costs. Participating in developer sprints should be no personal financial > burden to any of the participants. Usually, participants are expected to > cover food costs by themselves, although exceptions might be considered. Thanks for the reminder; this makes sense. > I strongly believe that Debian should be about free software. Every > time we mix in some other issue, we reduce our contributor base and > dilute our mission. For that reason I'm not in favor of Debian making > environmental preferences like preferring more expensive train travel > over cheaper flights. Very fair point. On one hand I concur totally with the "Debian is about free software only" argument. But on the other hand, I don't think it is wise for Debian to completely ignore the growing ecological concerns, and the environmental impact Debian (and its infrastructure, events, etc) has. But I understand (and can live with) where you (and others) want to draw this line. > From personal experience I note that trains are a lot less accessible to > people who are blind (and quite possibly a number of other disabilities > in some areas of the world) than planes. I was not aware of this, so thank you for making this concern known to me. > You can say that you'd make exceptions for disabilities. What I actually wanted to say was that I'd be willing to make exceptions; but didn't say which would be "good" or "bad" exceptions. There are various good reasons for exceptions; but you rightfully point out that justifying some of these (because of too restrictive conditions) can be prohibitive. So: less rules leads to less exceptions, I guess? > Didier> So what I'd would enjoy to see is exchanges along the lines > Didier> of: > > Didier> - BSP Orga: hey DPL; we organize a 3-days/2-nights BSP and > Didier> would like to support travel for potential attendees. We > Didier> expect about 12 travel requests; what can you do for us? - > > I'd much rather event organizers come with a rough budget. > As DPL I certainly don't have time or desire to put together a budget > for someone. Fair enough. But then I wonder what guidelines will be used to grant, amend, or deny travel support budgets. Surely not "any" budget is fine (or is it)? I tend to think it'd be of great support for the BSP organizers to know in which ballpark the travel support budget should fall. Best regards, OdyX signature.asc Description: This is a digitally signed message part.
Re: BSP Reimbursements
Hello Sam,
(I'm hereby answering out of my experience of helping organizing the
miniDebConf Vaumarcus this year, but without coordination with the rest of the
team).
Le mercredi, 2 octobre 2019, 16.43:37 h CEST Sam Hartman a écrit :
> TL;DR: Do we want BSP organizers to take on the responsibility of
> batching together travel reimbursement requests.
Yes, but… I think we, as a project, need to be clear about what this means,
along at least three axes.
First: what types of events qualify for travel reimbursement?
You have mentioned BSPs, but would a miniDebConf also qualify? Of course, it
is the expectation that miniDebConf attendees attend to "enhance Debian"; but
also that they might present, or attend talks, presentations, etc; during
which they are not (should not be) hunting bugs. I think such micro-
conferences, although not explicitly Bug Squashing Parties, should also
benefit.
(Shameless plug; the miniDebConf Vaumarcus still welcomes attendees and
proposals! [0,1])
Second: from which account is the money taken?
The answer might seem obvious, but let's make sure we're on the same line of
thought. When organizing a BSP (or a miniDebConf), it is of good measure to
try find sponsors and supporters to help lower the cost for attendees. In
plenty of cases, for a multi-day event, one needs a venue, help cover food and
accomodation costs, etc. But these events rarely last for more than a couple
of days; so adding significant charges to support travel makes the funding a
larger challenge. So the only realistic money source seems to be external;
hence "Debian" money, not "event" money.
(The annual DebConf is different in terms of scale and duration, which reduces
travel support in proportion to the other charges of the budget.)
Third: what rules-of-thumb, or guidelines do we want for travel support?
In the context of relatively _short_ events (2-5 days), I think we ought to
put upper limits in term of amounts, and in terms of distance. Put
differently: set economical and ecological limits. In this day and age, I
don't think Debian should be supporting flying long distances for short events
[2]. So we could have a duration-to-distance, or similar, criteria, as well as
"qualitative" incentives. I'd prefer Debian to sponsor a 600€ train ride than
a 150€ flight, for instance. As a rule of thumb, what about: "Travel distance
is max ~400km per event day duration, prefer land transportation where
applicable"?
(Also, connected to that "distance" question is also "who gets supported?")
So… To wrap this up. As potential organizer; I'd be all for granting travel
support to attendees ourselves provided that:
- Debian money is available;
- common guidelines for the allowance of Debian money for travel support for
attendees are public.
Without common rules-of-thumb, you, as DPL, would be de-facto delegating the
setting of travel support policies to events; with potentially large
differences in how we address the requests, and I'd regret this.
So what I'd would enjoy to see is exchanges along the lines of:
- BSP Orga: hey DPL; we organize a 3-days/2-nights BSP and would like to
support travel for potential attendees. We expect about 12 travel requests;
what can you do for us?
- DPL (or treasurer): the guidelines say that Debian will support travel for
attendees coming from less than ~ 1000km and for max 400€ per individual. We
grant you an initial 12 persons envelope for travel support. Would you be
willing to make an exception (larger distance or larger price), please consult
with $team first. Should you need to support more attendees, please come back
to us. Reimbursements will be processed after the event, provided
justifications and your approval by this $TO.
With my best regards,
OdyX
[0] https://wiki.debian.org/DebianEvents/ch/2019/Vaumarcus
[1] https://wiki.debian.org/DebianEvents/ch/2019/Vaumarcus/TalkSubmissions
[2] Disclaimer: I have flown back and forth from Europe to various DebConfs in
the past; sometimes partially or fully thanks to Deb{Conf,ian} money.
I am not proud of this, and am searching for ways to attend that have a
lower carbon impact: stay longer; combine with other events; skip too far
DebConfs; etc.
signature.asc
Description: This is a digitally signed message part.
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
Le samedi, 4 novembre 2017, 01.39:31 h CET Scott Kitterman a écrit : > On November 3, 2017 9:09:31 PM EDT, Sam Hartman wrote: > > I think that Debian does need a decision making body of last resort. > > I personally think these communication skills are critical for such a > > body. > > One critical thing I think the TC misses is to consider if it's time to > invoke last resort processes or not. My impression is that if someone > brings an issue to the TC, there's an assumption that the TC has to deal > with it. That's currently quite true; unfortunately. I do think the TC has the moral obligation to properly _acknowledge_ all requests filed before it, it should really do a better "initial conditions" check. > The last time I was involved with an issue brought to the TC, it had been > brought after zero discussion between the person filing the bug and the > relevant team. Complaining to the TC about a bug that's been dormant for > years only a few days after resurrecting discussion about it (AIUI) seems > similarly aggressive. Absolutely. During the TC's last IRC meeting [0], we have identified the need of a bug-handling checklist, which could do a lot of good there. With such (lightweight) formalism in place, the TC would force itself to react to issues by first checking if they fulfill some preliminary conditions. Off the top of my (tired) head: * have the maintainers had enough time to interact with the complainant? * have efforts to resolve the issue via consensus been tried and failed? * is the disagreement sufficiently well described? * etc. Also, it seems the TC is bound to be focused in the technical problems, and how to address these [1], that's just a natural consequence of its name and its composition mechanism. Instead of directly addressing the issue, I tend to think the TC could instead often start by addressing the "meta" around the issue: where, and how is the problem described ? was it debated, and by which stakeholders? is the complainant "jumping the gun" or has the discussion really reached a point where a formal involvment of the TC makes sense? etc. > Diving into issues in these kinds of circumstances turns the TC into nothing > more than a stick to beat other developers with. I think we need something > like the TC, but I also think part of being the decider of last resort is > sticking to the last resort part. I agree; to some extent. Indeed, for any use of the constitutional powers of the TC, it shall really make sure all reasonable venues have been tried and failed, as a prerequisite to discussing the technical issue. But there's a wide range of issues where it makes sense for TC _members_ to go out and help the discussion. We also want people to feel comfortable coming to the TC for advice. The fact that the TC uses public bugs also puts some discussions under different lights: it's different to have TC members participate in a discussion (with or without hats) than have the same conversation on a tech- ctte bug; a TC bug is (or at least, was) quite likely to end up with a formal decision, even if just for closure. The mere prospect of a potential maintainer override ad the end of the line is certainly quite offputting; a side of the conversation has a finger on the trigger. That leads me to think the TC could sometimes close the TC issues (or reassign them) earlier, without necessarily stopping the conversation. > P.S. Having been through a couple of TC issues that involved packages or > teams relevant to me, I totally get orphaning a package. I don't know what > fraction of packages I maintain I care enough about to deal with a TC > complaint over them, but I'm pretty sure it's way less than half. That's a quite saddening statement. Could you share (eventually in private) for which reasons? In what way could the TC evolve to make you feel comfortable having a conversation with it about one of your packages? With my best regards, OdyX [0] http://meetbot.debian.net/debian-ctte/2017/debian-ctte. 2017-10-18-19.01.html [1] For example, see the start of https://bugs.debian.org/877024 (sorry Keith :-) )
win32-loader (was: Re: Bug#856139: certspotter: long description advertises commercial service)
Le samedi, 12 août 2017, 10.06:40 h EDT Christian Seiler a écrit : > win32-loader probably doesn't run on Wine or ReactOS (though I haven't > tried it, so I may be wrong here) - should that be in contrib if that's > the case? win32-loader runs fine on wine, for what is worth. It's also built entirely within Debian main, of course. (Actually, it probably works best on wine rather than any too recent Windows, because of bootloader changes, SecureBoot, etc) OdyX
Re: Debian contributor Register of Interests
Le dimanche, 14 mai 2017, 08.08:09 h CEST Tollef Fog Heen a écrit : > I think «geniunely acting as independent individuals» is a meaningless > concept, since everything we do is coloured by the context we're in and > that includes social relations. Oh, absolutely, my choice of words was wrong. I am now who I am (and express what I do express in the way I do it) also because of what I did in life so far, and what I'm currently experiencing. But what has influcenced, or does influence my way of thinking, should not be a preample to any new social interaction. -- OdyX
Re: Debian contributor Register of Interests
Le mardi, 9 mai 2017, 09.16:21 h CEST Jonathan Dowland a écrit : > However in the interests of transparency I feel that a voluntary, opt-in > "Register of Interests" is a good idea for the project. I feel that such a > list (populated) would demonstrate the transparency and openness that are > part of our project's values. I disagree that is is such a good idea, for a specific (and not yet mentionned) reason: conflicts of interest are _very_ much situational, _especially_ in the Debian context. Assuming a hypothetical Debian contributor with financial interests in a hotel business, part-time software engineer and affiliated to a political party: not all three connections matter in all Debian work, or discussions. The first might matter though iff people start considering paying for accomodation in hir hotel; the second might matter in a discussion about a piece of software they are paid to work on, and the latter might matter when discussing the Debian project's eventual reaction to a complicate situation somewhere in the world. But these only matter in specific discussions, not constantly. Where I'm going to is that I feel we're much better in a situation where we don't load all our conversations with references to _all_ our "real-life" interests. It opens the floodgates to interpret any position under the light of these interests, neglecting the mere idea that for plenty (if not all) of Debian interactions, we are genuinely acting as independent individuals. That said, I still think that there are situations in which declaring one's conflicts of interest _does_ matter, but I do expect the affected individual to either explcitly retract (or stay away) from the discussion, or declare the conflict of interest at that point. -- OdyX
Re: producing, distributing, storing Debian t-shirts
Le lundi, 1 mai 2017, 19.45:06 h CEST martin f krafft a écrit : > However, at the end of the day, all things considered, if Didier or > Person X would mark those items up, say, 5% to cover the incidentals > (not the time spent), then I wouldn't have a problem with that. Oh, just to make the records straight: this was done under the debian.ch umbrella, with essentially Debian-like money. When I wrote that "we" were not making margin, I implied "Debian made an approximately zero-cost zero-benefit operation". I even paid my own knives. -- OdyX
Re: producing, distributing, storing Debian t-shirts
Le lundi, 1 mai 2017, 18.28:37 h CEST Daniel Pocock a écrit : > On 01/05/17 18:14, Didier 'OdyX' Raboud wrote: > > The cost structure for that one-time project made it possible to sell the > > Debian-branded knives for the same non-branded retail price. That's really > > cool, but also meant an inexistant margin. > > > > But add to that the effort it took to collect pre-orders, then orders, and > > then manage the stock and the international shipping for small and > > expensive little gems that were acquired initially in an expensive > > currency (CHF); wedidn't make a penny worth of margin, for _a lot_ of > > administrativia and effort. > > Thanks for the update on that > > Would you consider it worthwhile doing an exercise like that again if > people were ordering them in batch to be delivered at DebConf? The administrativia overload still stands: pre-orders, stock management, money collecting (in various currencies, of course), etc. Such orders come with minimal monetary amounts (to reduce the cost-per-unit of the branding), which then implies carrying around merchandise worth thousands of dollars, in easy to steal (very small) items. It's been fun in 2011, but I would not do it again, no. I have better uses of my Debian time. :) If there's interest, I would _really_ recommend finding a trustable and specialized partner (such as EnVenteLibre) to manage that, even if Debian is to provide the initial funds and/or let a certain percentage go. OdyX signature.asc Description: This is a digitally signed message part.
Re: producing, distributing, storing Debian t-shirts
Le dimanche, 30 avril 2017, 17.42:53 h CEST Andrew M.A. Cater a écrit : > Debian.ch did one very cool piece of merchandise - customised Victorinox > knives with Debian logo. Fantastic, useful - and potentially illegal to > carry but a lovely thing. I think it took a huge time to organise the > logistics although the cost wasn't huge since the manufacturers do this > regularly and the retooling isn't massive the overhead was high. The cost structure for that one-time project made it possible to sell the Debian-branded knives for the same non-branded retail price. That's really cool, but also meant an inexistant margin. But add to that the effort it took to collect pre-orders, then orders, and then manage the stock and the international shipping for small and expensive little gems that were acquired initially in an expensive currency (CHF); wedidn't make a penny worth of margin, for _a lot_ of administrativia and effort. OdyX P.S. We transfered the stock to EnVenteLibre, and they still have some: https://enventelibre.org/goodies/17-couteau-suisse-debian.html signature.asc Description: This is a digitally signed message part.
Re: Replace the TC power to depose maintainers
Le mercredi, 7 décembre 2016, 08.49:57 h CET Russell Stuart a écrit : > Why not have a formal rule that says if a package in Debian is out of > date for more than one release cycle any DD can package it under a > different name, after going through the usual ITP procedures coupled > with a bug report to the original package citing the ITP and a delay? > It's not like we don't do the parallel versions bit now - squid / > squid3, exim / exim4 and so on. Or just the same, but without too many formalities: If one feels the source package isn't kept up-to-date enough, she can "just" file an ITP for a new source package name, pointing to hir attempts at convincing the existing maintainers. As ITPs are CC'ed to -devel, it becomes a matter of cultural shift in how we (and FTP Master, Release Team, etc) accept parallel versions in the archive (same software in different source & binary package names). With snapshots.debian.org and LTS in place, we could also start accepting that there is a variety of cases where it's entirely fine to instruct users to install versions from past stable versions. (lsb-desktop in Wheezy had such instructions, if one needed to get Qt3, e.g.) -- Cheers, OdyX
Re: Replace the TC power to depose maintainers
Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit : > The bug was filed on the 19th of October. That was nearly 7 weeks > ago. Sure. I'm not saying the TC couldn't be better. > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. I agree with that. > 6+ weeks during which members of the TC have been prevaricating. I had to lookup prevaricate in a dictionary: > to speak falsely or misleadingly; deliberately misstate or create an > incorrect impression > to deviate from the truth This is not helping, really. Please tone down. Frankly, with the timing, content and tone of your meta-interventions around the "recent case" we're talking about, you have just added two more weeks to the process. I now took some time to address these meta-concerns, while I could have have focused on gathering commitments from the actual and prospective maintainers of src:global instead, and drafted a ballot. OdyX
Re: Replace the TC power to depose maintainers
Le vendredi, 2 décembre 2016, 15.42:58 h CET Ian Jackson a écrit : > Hey, I have an idea that maybe you will support, which takes us much > more in that direction and may reinvigorate our existing processes: > > DRAFT GENERAL RESOLUTION STARTS As a general comment, I am in discomfort with GR proposals which have too much preamble and context as part of the decision. Specifically… > OPTION A > > 1. Our priority is our users and free software. > > 2. Debian maintainership is a position of power and responsibility. > It is an earned position, which arises from work and leadership. > Maintainership should continue so long as the good leadership > continues. These two points should be in an argumentary in favour of the actual GR, and not in the GR text. Having the body of developers "emit" that kind of wording (not that I disagree with it…) opens the door to later interpretations, debate about wording, etc. It's uneeded for a GR to re-state that our priority is our users and free software. We have it a foundation document, and re-stating it out of the blue is doing more harm than good, IMHO. > 3. We give advice to the Technical Committee: Giving "wildcard advice" about maintainership, as output of a discussion triggered by "I think the TC will not decide my way", _before_ the TC is just about to take a decision about maintainership, would (as Phil eloquently put it) imply that the project is not trusting the TC and its members to exercise the powers and duties as defined in the constitution. Would that GR pass, I would most probably resign from the TC. That said… the TC's constitutional mandate _is_ up for discussion, it always was, and should always be. It's entirely fine to discuss how the project wants to distribute its powers and duties internally. But if one wants to address how maintainership is handled, emitting a no-op GR giving advice to the TC members is the wrong hammer for that nail, I think. > 4. The Technical Committee should consider all opinions and options > based on their merits, not based on the authority of the speaker. This wording assumes that the TC currently isn't (same goes for further articles. > OPTION B > > (1-6 as above) > > 7. We amend the Constitution section 6.1(4) to remove the words > "requires a 3:1 majority" and "this requires a 3:1 majority". A GR doing that (amending the constitution to lower the TC majority needed when overruling a developer), and only that, would be a strong message from the project upon the importance it gives to maintainership and developers' decisions. I'm not decided whether I like that specific idea or not, but I certainly feel that such a GR would be much less paternalizing to the TC and its members than any flavour of your Option A. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Replace the TC power to depose maintainers
Le jeudi, 1 décembre 2016, 15.46:05 h CET Ian Jackson a écrit : > There is a recent case where: > * The maintainer has done nothing to the package for many years, >other than infrequent (and usually short) emails to NAK >contributions from others; > * The package is years out of date compared to upstream, afflicted by >bitrot, and many users are asking for the new version; > * Several times, proposed updates have been prepared by contributors >but blocked by the maintainer; > * There are new maintainers ready and waiting, with a new package >ready for upload to sid for stretch; > * Now that the TC is involved the maintainer has written many emails >explaining their decisions to NAK uploads, but TC members are >clearly unconvinced on a technical level that those decisions were >right. > Even in this extreme situation the TC has not seen fit to wrest the > package away from the mainainer's deathgrip. I think you're really jumping the gun here. While the TC is not known for acting rapidly, I (would like to) think it is becoming better. In the "recent case" you're using as trigger to this very discussion [0], although some TC members have already expressed opinions (mostly both ways, I feel), the TC hasn't taken a decision yet. It therefore feels quite premature to launch a "Replace the TC power to depose maintainers" discussion. By launching the discussion through assuming the TC will not decide how you think is most fit, you are exercising unwarranted pressure on the TC members who will eventually need to take a decision. You have been on the TC long enough to know how uneasy a TC members' job can be; what about letting those are now in charge with some room ? OdyX [0] #841294, for those not following the tech-ctte pseudo-bug or the debian- ctte@l.d.o list signature.asc Description: This is a digitally signed message part.
Re: Proposed GR: Acknowledge that the debian-private list will remain private
Le jeudi, 7 juillet 2016, 14.39:21 Holger Levsen a écrit : > (should the text be reworded, I'd like to propose s#Debian > Developers#Debian members#g.) Point is; only "Developers" (the term our constitution uses) are supposed to ever have been subscribed to d-private. That said, we could amend the constitution in a separate GR. -- Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: cdimage?? What should we call it?
Le mardi, 18 août 2015, 17.09:19 Steve McIntyre a écrit : > We called our main installer images distribution site > cdimage.debian.org a long time ago, when that was all it published and > most people downloaded images of CDs. > (…) > So, I'm looking for suggestions. What should we call it? (…) What about get.debian.org ? (There is get.debian.net) Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
Le mardi, 14 octobre 2014, 10.54:19 Lars Wirzenius a écrit : > On Tue, Oct 14, 2014 at 09:17:27AM +0200, Kurt Roeckx wrote: > > If on -vote the required amount of seconds have been reached, I > > will announce that the GR process has been sarted on > > debian-devel-announce. > > Sure, and that's excellent. It would, though, in my opinion to be good > to announce the proposed GRs even before the required number of > seconds is reached I disagree, because I think that the current value for K is sufficiently low to make it part of the proponent's responsibility to make sure that his proposal gets enough seconds. Again, we're currently talking about finding _5_ other Debian members. -vote is the canonical public way, asking per private mail or IRC or on team-specific lists are other possible ways, but I don't think it's reasonable to automatically make use of the only pseudo-mandatory (devref §4.1.2) list for GR proposals. A message to debian-devel-announce once the ballots are seconded enough must stay though (as devref §3.2.3 underlines). Cheers, OdyX -- 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/6545796.C1tePvsYep@gyllingar
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
Le lundi, 13 octobre 2014, 16.11:56 Miles Fidelman a écrit : > Stefano Zacchiroli wrote: > > FWIW, Constitution §4.2.5 says: > > (…) > Ahhh... this is like RFPs and legal announcements - as long as you > post it somewhere, you're covered. As opposed to requiring posting > in a highly visible place. Wrong. That's detailed there: https://www.debian.org/vote/howto_proposal Which says: > The following procedures have been instituted regarding general > resolution proposals and sponsoring. > > The electronic mailing list designated is debian- > v...@lists.debian.org. This is the authoritative source of the full > text of all resolutions, as well as the supporting arguments and other > material. Proposals, or sponsorship motions shall not be recognized if > sent to any other mailing list. The page is easy to find from debian.org => Developers'Corner => Voting information => How To Submit a Proposal. I don't think we have a documentation problem here. Cheers, OdyX -- 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/2644371.u0TgOhpbrd@gyllingar
Re: Code of Conduct violations handling process
Hi all,
Le mercredi, 3 septembre 2014, 18.55:04 Ian Jackson a écrit :
> I hope that regardless of your opinions about the specific incident,
> you would support the ideas that:
>
> - If we have a CoC it should be enforced.
(Snipped a lot of administrativia suggestions.)
"To enforce" is the wrong verb, I think.
I've always read and understood the CoC as a declaration of intent, a
generic behavior framework; in short, what I understand as a "Code of
Conduct": "this is how we collectively intend to behave to make our
face-to-face events the best possible experiences for all attendees".
Such a code will always lay down blurry lines, which trespassing will
always be highly subjective.
Seeing the CoC as a guideline, I don't think we should add _more_
administrativia to _enforce_ it, much the contrary.
People will hurt others' feelings in various situations, but most of
these situations don't need to be treated with a big administrative
overhead. In fact, approaching another attendee and telling her "I
didn't feel treated with respect when you {said,did} that and that." or
"Did you notice that this statement of yours might have been taken as an
offense by this other participant?" [0]. There's no need to refer to the
CoC when saying so, but it helps adjusting each other's behaviors for a
healthy conference.
The CoC should not be seen as law, it certainly isn't: by its nature, it
doesn't say "this class of actions will give you a yellow card, this
other class will get you expelled from the conference" (and it most
certainly should not). I think that we should all consider ourselves
guardians of the CoC and push towards its goals throughout the various
Debian events we attend. When severe violations occur, we do have
antiharassment@d.o which _must_ have some interpretation and action room
to proceed to useful feedbacks to offenders or actions against them. All
severe violations _will_ be different and will call to different
actions.
In conclusion, I think we should stop building administrative procedures
to enforce the CoC but start integrating it as a part of our collective
and individual responsibilities as Debian events attendees; there's
antiharassment@ for the upper tier of violations. We should stop seeing
the CoC as ways to restrain others, but rather as a set of tools to
collectively make our conferences better places to be. We can all make
this happen without layers of appeal bodies.
Cheers,
OdyX
[0] I've got this type of feedback twice during the conference, and I'm
very thankful of both.
--
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/12506381.TS1L0OLTsz@gyllingar
Re: Updating the list of Debian Trusted Organizations
Hi all, (answering to debian-project) Le mardi, 8 juillet 2014, 18.02:42 Lucas Nussbaum a écrit : > In most jurisdictions around the world, the Debian project is not in a > position to directly hold funds or other property. Such assets are > therefore owned by a number of so called 'Trusted Organizations'. > > (…) > Note that there are still a few other organizations holding Debian > assets without being official Trusted Organizations (e.g.; > Debian.ch). Work is ongoing to clarify their status. Indeed. We have so far failed to push this discussion out, although I do hope that we will be able to start it in a few weeks' time. Sorry for that, OdyX, current debian.ch president -- 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/16337143.d5of2FSrhG@gyllingar
Re: GR: Selecting the default init system for Debian
Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit :
> Russ Allbery writes ("Re: GR: Selecting the default init system for
Debian"):
> > As a TC member, I dislike the supermajority requirement for the
> > project to overturn a TC decision by GR, particularly in this case.
> > I think we would all be extremely unhappy if the TC voted one way
> > on the default init system and the project then voted a different
> > way by a 60% majority.
>
> I agree. I think that would be quite bad. We could explicitly state
> in our TC resolution that the TC decision can be vacated by General
> Resolution on a simple majority.
I don't think our constitution allows a resolution of the TC to change
how §4.1.4 has to be interpreted for a GR overriding it[0]. It would
certainly need to be checked with the secretary (CC'ed, just in case).
Cheers,
OdyX
[0] If §4.1.4 stood with something along the lines of "unless the TC
explicitly lowered that requirement", that would be different, of
course.
signature.asc
Description: This is a digitally signed message part.
Re: Updating the Policy Editors delegation
Le lundi, 6 janvier 2014, 16.21:52 Ian Jackson a écrit : > I think the constitutional position of the policy team is as follows: > > They are a package maintainer team. They normally make their > decisions themselves under 3.1.1. I think that framing the policy team primarily into a package maintaining team is unwarrantedly limited: the "Debian policy" is primarily a reference document much more than its massaging into a package [0]. As the work of that team has quite some impact on the rest of the developers' work [1], I feel it is perfectly normal that it is delegated, and therefore don't understand how Lucas' latest delegation suddenly became a constitutional problem in your eyes. Cheers, OdyX [0] How the Debian policy is shipped in the debian-policy package is indeed "packaging work", but I see that as an almost-completely separate activity. [1] Policy becomes encoded into lintian checks, which then can become FTP-master auto-rejects; making the compliance effectively mandatory. signature.asc Description: This is a digitally signed message part.
Re: Should mailing list bans be published?
Le lundi, 4 novembre 2013 15.08:05 Stefano Zacchiroli a écrit : > On Mon, Nov 04, 2013 at 02:51:52PM +0100, Tollef Fog Heen wrote: > > > So, what would be the beneficial social effects of publishing the > > > ban *duration*? > > > > The ban duration is an indication of how severe we think the > > violation is. You don't get a lifetime ban for a minor > > transgression and you don't get a one-day ban for serious > > harassments. > > Of course. The question is: do you think disclosing ban duration will > discourage bad behavior on our mailing lists more than just disclosing > the bans currently in effect? (I don't.) That's a good point. I think (and apparently you agree) that the banned person must get notified of the duration of the ban; I think that this is absolutely essential for the avoidance of blanket punishments. "Infinite ban" should be used as very last resort [0] and subject to re-examination anyway. I do see some value in having the ban durations published along with the rationales, as both these constitute the listmasters' decision for which review should be possible. Where rationales (offending posts) carry value for everyone because they show what behaviours are not OKay, I can agree that durations mostly matter to those exercising the review. Cheers, OdyX [0] I don't doubt it is. signature.asc Description: This is a digitally signed message part.
Re: Should mailing list bans be published?
Hi Jonathan, Le dimanche, 3 novembre 2013 14.06:33 Jonathan Dowland a écrit : > I think bans should be time-limited in > almost all cases, with perma-bans being very rare indeed. I don't > think that ban durations should be disclosed publically or to the > person banned (otherwise badly behaved people will just count down to > the ban lifting before posting.) I disagree on the point of not making the ban durations public. Although I understand the effect you're afraid of, I think that the benefits of having the durations public outweigh the downsides: even if the banned persons could try to trick the system, that would be easily detected I think. Also, most of the effects of the ban are social, not technical. The ban durations should be made public (and very much communicated to the banned person) because that gives a dimension to the punishment, you can then get "short" or "long" bans, depending on how far you crossed the line. An offender could first get a short ban, and when coming back, if crossing the line again, a longer ban (exponentially). The only limit to that would be the listmasters' patience. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Re: Should mailing list bans be published?
Le samedi, 26 octobre 2013 10.46:41 Steve Langasek a écrit : > This led to a philosophical debate about whether bans should be made > public. Alexander expressed concern that having them published could > be harmful to a person's reputation, since employers will google your > name and see that you've been banned from a large project such as > Debian. > > I think we should publish them, for several reasons: > (…) While I do agree that we should publish the bans, I think we should really do it carefully and that these publications should satisfy the following criterias: * forgiveness. This goes along with the concerns about harming one's reputation. As we all change during our lives, I think it shouldn't be of Debian's role to keep an eternal track record of past bans. I would therefore propose to only list active bans on a non-indexed webpage. Notifications of new bans could be posted to a private non-archived list such as -private (because posting them to an archived list would defeat the purpose). This would ensure people that later get unbanned also get their names removed from that list. They would start afresh (at least publically, not for the listmasters of course) and I think that's a good thing. * least surprise and non-retroactivity. I think that the legal concerns can be circumvented by warning offenders in advance that in the case of a ban their names would be published. As Alexander puts it [0], "Banning is usually the last action we take and we only use it if we really have to.". This implies that the offenders get mails from the listmasters before the actual ban is put in place. If they get informed of the consequences, they can simply stop posting and don't have to face the consequences. With this in mind, I think we should also only publish new bans and not the ones already in force (non-retroactivity). [0] <20131027164642.ga15...@smithers.snow-crash.org> * transparency. This is very much along the lines of Steve's original words: > So I don't think bans need to be posted anywhere prominent like > debian-devel-announce, but I do think basic facts like who is banned, > for how long, and the rationale (with links to specific mailing list > posts as reference) should be made public. It is IMHO very important that published bans go along with a list of links to offending mails, a rationale (short-ish explanation of why the mails are a problem) and the duration of the ban. This makes the listmaster's job public, defendable and challengeable, which are good things™ too. Cheers, OdyX signature.asc Description: This is a digitally signed message part.
Alioth is up! (was: alioth is down)
Now that alioth is back up, I feel I owe an apology to those that made that possible. While you guys were facing hard-work to bring our beloved alioth back to life, I was here nitpicking about mailing lists usage. You clearly didn't need that at that time. Retrospectively, that was clearly not the right timing for that. So please accept my apologies and my great thanks for the hard work that brought alioth back to us all. Le 29.01.2012 22:46, Didier Raboud a écrit : > According to the respective descriptions of the lists, people relying on > Debian-provided infrastructure (which alioth is) should be monitoring d-i-a, > and there's no explicit reason for them to be monitoring d-d-a. If that's not > the case, we should either "teach" people to be subscribed to the correct > mailing-lists (e.g. by sending all "infrastructure annoucements" to d-i-a) or > just consider d-i-a useless instead (and close it) and send all such > announcements to d-d-a. I think my point stands though: lists descriptions don't fit the usage we do of them. According to those descriptions, non-DD alioth users should be monitoring d-i-a and not d-d-a. If d-d-a is used to reach non-DD alioth users, that means that d-i-a is essentially useless and should be closed, IMHO. (But well, I won't argue more than that as I'm subscribed to both anyway.) Cheers, OdyX signature.asc Description: OpenPGP digital signature
Re: Upcoming Cherokee webserver providing a webapp-market - Opinions please?
Hi Gunnar, Thanks for asking -project, I think it's good to query a wide community for this sort of questions. Le Tuesday 22 February 2011 23:41:03 Gunnar Wolf, vous avez écrit : > > • Important portions of what the Marketplace is offering is already > offered by Debian. > • Counterargument: Webapps in Debian are usually not ready to be > installed and used when running anything other than Apache I think there is possibly a lack of a standard way to install and configure web applications (although I am aware of the Webapps policy); but it is certainly a very hard thing to do correctly, especially within the "Universal Debian", with its gazillion possible combinations of http servers, programming and interpreted languages, databases, etc. If those marketplace offerings can't be easily used with cherokee, then it's probably a (wishlist) bug. > • How does this fit in the FHS? Marketplace apps are downloaded into > /var/lib/cherokee/ows/root; they use the OS provided applications, > languages and libraries (i.e. PHP, MySQL, etc). In my understanding, this basically means a looong possible nightmare for the maintainers of those marketplace applications, with various versions of various software to handle during the Wheezy lifecycle. Of course PHP doesn't change every two weeks; still "our" distributed PHP will have an influence on all those marketplace applications. But maybe it's less of a concern than I might think. > Their installer will give the user the precise apt-get command to issue to > satisfy the dependencies. … but now with this I have a concern. How would this "command" be handed to the user? A line to copy-paste? (And why apt-get and not cupt/aptitude/synaptic/whatever?) A "please gimme your root pass and I'll do it for your" sort-of-thing ? I am particularily concerned about a possible "endorsement" by cherokee and/or its marketplace of non-Debian packages/repositories, etc. Whatif an application wants a package from contrib, non-free or debian-multimedia? > • Although the Marketplace should be active by default, it is not > usable until the user registers and provides the adequate > credentials to cherokee-admin. That is, the user must be aware he is > getting outside of Debian-land when installing their apps. That'd be a bare minimum (IMHO). > But I feel I need your input before packaging this functionality. I also must say I am very ambivalent with this prospective functionality. On one side I see a nice way to push web applications in a (cherokee-)standard way, and probably a convenient way for administrators to install cherokee-baked applications (which is probably a positive thing for Octality). On the other side tough, I don't feel comfortable in handing control of the packaging system to a particular application, even less so if this application comes from outside Debian (as any marketplace application might very well be). Letting non-Debian software impose conditions on installed packages doesn't sound sane to me (e.g. whatif one application wants mysql-5.0 and another one wants mysql-5.1). If there are flaws or problems in Debian policies that makes the creation of packages for those cherokee-fitted applications impossible, then the solution shouldn't be to create a marketplace outside Debian, but to fix those flaws and problems. Debian already has a coherent way of distributing packages towards its users, taking care of dependencies, etc. why not using it directly? A much saner way of providing cherokee-fitted applications is IMHO to create debian packages out of them, pushing them to Debian if they are DFSG-free software and pusing them to non-free if they are not. And if the Debian framework is too tight for this, then creating external repositories is the lesser evil (then they don't even need to comply to the Policy [bleh]). So, if I try to summarize my POV; I'm far from being in favor of such a system in Debian. Altough it's certainly a nice and uniform way for Octality to push applications towards Cherokee users, it opens a far too big can of worms (intrusion in package handling, security concerns, non-free applications on which we have zero control, …) that can only escape off Debian hands. Maybe it could find a place in contrib or non-free, but I can only hardly see this type of marketplace integration in a stable release. Cheers, OdyX -- Didier Raboud, proud Debian Developer. CH-1020 Renens o...@debian.org signature.asc Description: This is a digitally signed message part.
Re: what is the new name for testing
BasaBuru wrote: > hello > > Do you now what is the new code name for the new testing? > > thanks > > BasaBuru Current testing is "Squeeze"; next will be "Wheezy". This was announced on debian-devel-announce [0] and could have been found by googling or heading to Wikipedia [1]. Cheers, OdyX [0] http://lists.debian.org/debian-devel-announce/2010/09/msg0.html [1] http://en.wikipedia.org/wiki/Debian -- 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/iie4ll$f16$1...@dough.gmane.org
Re: What is annoying in the flattr buttons?
Kevin Mark wrote: > On Thu, Nov 11, 2010 at 01:22:54PM +0100, Didier 'OdyX' Raboud wrote: >> For a simple reason, the DMUP [0]; which every user of Debian resources >> must follow. It says (in its introduction, point 1). >> >> * "Don't use Debian Facilities for private financial gain" >> >> (…) >> > Debian Facilities -> debian webserver ->Planet-> blog posts->flattr > links ..-> debian email server->email -> email signature > that links to: ...their > personal webpage with paypal or flatter > ...their business website > both these can generate income. are they both potential DMUP violations? Ha. At first I thought: damn, good argument. But after thinking of it a bit, I think there is one slight difference though: the use of Debian email servers does _not_ require the acknowledgement of the DMUP (anybody can send a mail transitioning trough Debian email servers, see e.g. the amounts of spam), where "being syndicated on planet" does (it is not possible to send spam to the planet without first getting the blog added to it by a DD), if I understand the issue correctly. So I'd say that emails are not under the scope of the DMUP, hence cannot be a violation of it. IMHO, huh… -- 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/ibgrv5$m6...@dough.gmane.org
Re: What is annoying in the flattr buttons?
Tshepang Lekhonkhobe wrote: > On Thu, Nov 11, 2010 at 02:44, Russ Allbery wrote: >> Michael Gilbert writes: >>> Raphael has every right to attempt to pursue his field of endeavor in >>> any tolerant/respectful manner he chooses. >> >> ...using his own property. But not using Debian project resources. > > Raphael is among the most notable (visible) of all DD's, so why not? > If he became a millionaire using flattr, why not? Why not create money > where there wasn't? Why is the money topic so sensitive? I'm the sort > of person who gets excited by seeing Release Managers get paid for > their heroic work. For a simple reason, the DMUP [0]; which every user of Debian resources must follow. It says (in its introduction, point 1). * "Don't use Debian Facilities for private financial gain" The problem here is not about Raphael being "allowed" to become millionaire with flattr or not; it is about people using the Debian planet (which is "Debian resources") for private financial gain. This has nothing to do with the "money topic", but with the rules in place regarding the Debian machines. [0] http://debian.org/devel/dmup.en.html -- 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/ibgn6e$rn...@dough.gmane.org
Re: debian-kernel / KVM
kont...@reisemedizin-giessen.de wrote: > Hello debians! > > Everyone is talking about virtualisation. But as far as i know the > debian-kernel isn't ready to use KVM. For me as a non-prof-user > kernel-debugging isn't a nice every-year-adventure. Maybe it's possible to > get a KVM-kernel-version in the repositories for easier installation and > checking dependencies ? > > Thanx and Regards, > > J. Feldner Actually it is. Just install the qemu-kvm package and it will "just work" if you have suitable hardware. Cheers, OdyX -- 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/i2a6gp$b4...@dough.gmane.org
Re: Debian decides to adopt time-based release freezes
Teemu Likonen wrote: > On 2009-07-30 13:12 (+0200), Sven Joachim wrote: > >> Probably not, but the release synchronization with Ubuntu may make >> them feel that they are working for him, which can be a great >> demotivation. > > That's why it would be interesting to hear some concrete ideas how > useful this would be for the parties. How pros and cons balance? I'll > start: > > Ubuntu > == > > + Ubuntu always gets a frozen and pretty stable system even if they > don't communicate at all with Debian. (This is just a mind exercise, > I'm sure there is some collaboration.) > > + Better-quality LTS releases. Happier users and customers. > > + More collaboration between Debian and Ubuntu package maintainers and > teams. > > Debian > == > > + More collaboration between Debian and Ubuntu package maintainers and > teams. > > - Debian developers may feel that it's Ubuntu which they are working > for in the end. Possibly with the feeling that some of the > decision-making escapes the Debian developer community. Can be > demotivating. > > - OK, Ubuntu x.04 was released in April but because of their lower > quality standards and the 6-month release cycle they most likely > won't be helping Debian to fix the rest of the difficult RC bugs. > They are already working on their next 6-month period. Ubuntu gets a > lot of publicity because of the release but Debian always comes "too > late", literally always after Ubuntu. (It's worth the wait for many > people but the possible negative publicity can be demotivating for > Debian community.) > > A couple of months later eventually the RC bugs are fixed in Debian > and there is a release. Ubuntu will apply some of the bug fixes to > their LTS x.y.1 releases (3-month point release cycle). This can > make some Debian developers feel that Ubuntu gets something for free > again without contributing back. Can be demotivating. > > + Debian's quality probably won't decrease (except for Squeeze maybe). > > + [Please invent more concrete benefits for Debian developers and > users.] + Security fixes prepared for Ubuntu will be (sometimes ?) applicable directly to Debian, which would be a reduction in workload for the Debian Security team. (Or phrased differently: Debian and Ubuntu security teams will be able to prepare security fixes together, for the same frozen versions.) - At the release date, the gap between released software and upstream development versions is bigger in Debian stable than it was in Ubuntu LTS when it released. This gap is maybe not important for stability and for the quality of Debian stable, but it can be in the users' eyes. Remember that most non-corporate Ubuntu users will use the "latest released version" of Ubuntu. By such, they are getting "stabilised" versions 3-4 times during one Debian stable release cycle. Having Debian stable outdated (with regards to upstream released versions) is normal and intended. But having the releases synchronised will IMHO make Debian and Ubuntu LTS very similar. I initially thought that this would favor Ubuntu, but it might not be necessarily true in the end. > Thanks you, all developers! :-) Thank you for summarizing my thoughts in a somewhat more constructive and calm way than I did. Regards, OdyX -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Debian decides to adopt time-based release freezes
Tshepang Lekhonkhobe wrote: > > There's some (many) of us who feel that the great Debian culture is > irreplaceable, and therefore won't use Ubuntu as their primary OS. So > why worry about losing relevance. Because if you lose relevance, you lose users (might them be individuals on the desktop or corporate entities on the server). When you lose users you lose contributors and you finally lose developers. In the end, the momentum (sic) slows down and you die. It *might* be that losing relevance on the desktop side is of little importance (which I believe it is _not_), but if corporate entities turn to use Ubuntu LTS because instead of Debian stable, I fail to see how developers from these corporate entities will contribute to Debian and not to Ubuntu. A distribution without users is just worth nothing, no matter how irreplaceable its culture might be. In the end, synchronising Debian stable and Ubuntu LTS freezes will only make Debian stable appear as weaker (no commercial support, older software, not-so-greater stability, no longer support, less fancy) than Ubuntu LTS. Why would _anybody_ reasonable (and outside of the cultural thing) choose Debian stable over Ubuntu LTS ? Regards, OdyX -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
