Re: Evolving away from source package realms
Hello, On Sun, 23 Oct 2022, Didier Raboud wrote: > (Sorry for the delay in getting back to that thread. #life) Me even worse ;-) > Specifically, this is something I'd like to discuss in more extensive terms. > I > think I'm postulating that Debian would be in a better place with a "Debian > core" topic team, in charge of certain "base source packages", but _ALSO_ of > core Debian decisions: filesystem layout, default init systems, etc; all > these > things which responsibility is _not_ clearly within a specific source > package's > realm. But how would this new "Debian core team" take decisions? De we need consensus? Will they do a mini-GR among them if there's no consensus? What level of formalization is really required? At least, your proposal has the merit of empowering some persons to take decisions on some topics... because our current model clearly doesn't work well at that level as soon as we cross the boundary of a single package. Some packaging teams have written "sub-policies" and this goes clearly in your direction. IMO we need to take inspiration from the Python community, everybody can propose ideas and draft DEP[1], and there would be a Debian Steering Council that would ack or nack the various DEP. Once acked, everybody should be empowered to make changes as required by the DEP. Whether the technical committee should be that council, or not, is not clear to me. Maybe depending on the scope of the DEP, and the number/set of packages it affects, it could be validated by topic-team-councils... Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Survey proposal about the usage of money in Debian
Hello, On Mon, 24 Jan 2022, Jeremiah C. Foster wrote: > To this end we are currently preparing a survey. We expect to use > surveys.debian.net (Limesurvey) to generate private links that can be sent > to each Debian developer. (This is so that only Debian developers can fill > out the survey.) Once the survey has concluded, collated statistics will be > shared publicly with the Debian community; individual responses will > naturally be kept private. Nobody reacted to this part but we got some feedback that some Debian developers will be surprised to receive a survey directly in their inbox instead of through some mailing lists, so after discussion with the Debian project leader, we decided to change our approach to switch to something opt-in. We will share a public link to the survey on debian-devel-announce and any participant will have to enter their debian.org email to receive the private link to fill the survey. We will send two reminders on debian-devel-announce with at least one week between each reminder. Before analysing the result, we will discard any answer coming from a non-debian.org email (or from an email that we can't map to a DD through analysis of the Debian keyring). We will also exclude answers from non-DD that do have a debian.org email (although their inclusion would likely have no significant impact from a statistical point of view). We also plan to add a question “Do you want to be included by default in future Debian-related surveys?" to start building a GDPR-compliant database of Debian developers that accept to be contacted directly to answers surveys in support of work made by other Debian developers. If you see any issue with this approach, please let us know. Cheers, -- Raphaël Hertzog
Re: Survey proposal about the usage of money in Debian
Hello,
I have received some private feedback that a few questions were heavily
biased towards technical roles. That bias is certainly real as this is where
I come from and the kind of work that I'd like to fund with Freexian is
mostly technical.
That said the survey would certainly be more useful to Debian if we could
expand it to cover a few non-technical areas.
I left below the 2-3 questions that would benefit from being expanded. I
put in copy a few teams that are currently not listed and that might be
able to suggest new possible use of money in the context of their team.
For the full context, please read
https://lists.debian.org/debian-project/2022/01/msg00024.html. We welcome
your suggestions, either by reply to the mailing list or by MR against
https://salsa.debian.org/freexian-team/misc-drafts/
> Select the teams to which you regularly contribute:
>
> * Release team
> * FTPmasters (archive team)
> * System Admistrators ("DSA")
> * Security team
> * Long Term Support team
> * Quality Assurance ("QA")
> * Debian Installer
> * Debian CD images
> * One (or more) packaging teams
>
>
> For each possible use of Debian's money quoted below, please indicate if
> such a use is a "good idea", "good idea in some specific cases", "bad
> idea" or if it's "totally unacceptable". Select "uncertain" if you can't
> make up your mind.
>
> * Paying for package maintenance (handling bugs, new upstream release,
> improving packaging, etc.)
> * Paying for the initial packaging of software new to Debian.
> * Paying for development of new features/improvements for
> Debian-specific infrastructure (e.g. bugs.debian.org,
> tracker.debian.org, dak, etc.)
> * Paying development of new features/improvements to Debian specific
> software (e.g. dpkg, apt, debhelper, lintian, etc.)
> * Paying development of new tools to experiment new workflows or new
> services
> * Paying technical writers to improve the documentation for new
> contributors
> * Use Debian funds to help the Debian Project Leader (DPL) role in some
> way
> * Pay Debian contributors to complete large scale changes in a
> reasonable time frame
> * Pay specialist porters to support release architectures at risk of
> being dropped from Debian releases due to lack of porters.
>
>
> For each role listed below, please answer the following question: Should
> this Debian role include a stipend or otherwise be funded to allow more
> time to fulfill the obligations of the role? (yes/no/unsure/no opinion)
>
> * Debian Project Leader (DPL)
> * Debian Release Manager
> * In general
> * During the freeze
> * Member of the archive team ("ftpmasters")
> * In general
> * Those who process NEW and RM
> * Member of the Security team
> * Member of the LTS team
> * Member of the Technical Committee
--
Raphaël Hertzog
Re: Survey proposal about the usage of money in Debian
On Mon, 24 Jan 2022, Jeremiah C. Foster wrote: > You can find a draft of the survey here: > https://salsa.debian.org/freexian-team/misc-drafts/-/blob/master/2022-dd-survey/survey-content.md FTR, thanks to the feedback of Ulrike Uhlig, I merged some changes compared to the initial version that was attached. Here are the relevant bits: diff --git a/2022-dd-survey/survey-content.md b/2022-dd-survey/survey-content.md index c5be589..9a68e85 100644 --- a/2022-dd-survey/survey-content.md +++ b/2022-dd-survey/survey-content.md @@ -76,6 +76,7 @@ What other media do you use to connect with Debian acquaintances? * IRC (`#debian-*` on OFTC) * IRC (other networks) * forums.debian.net +* XMPP * Matrix * Telegram * Discord @@ -90,7 +91,7 @@ In what context(s) are you contributing to Debian? * In both of them -Is your current Debian involvement level sustainable in the long term? +Is your current Debian involvement level sustainable on the long term? * Yes * No @@ -109,6 +110,13 @@ Would you like to spend more time contributing to Debian? [ Show the next question only if the person answered "In my personal life only" to "In what context(s) are you contributing to Debian?" ] +Are you currently working a job that pays some or all of your +contributions to Debian? + +* Yes, some of my contributions are paid +* Yes, all of my contributions are paid +* No + Would you like to get a job where you can contribute to Debian ? * Yes @@ -230,14 +238,18 @@ make up your mind. software (e.g. dpkg, apt, debhelper, lintian, etc.) * Paying development of new tools to experiment new workflows or new services -* Paying technical writers to improve the documentation for new - contributors * Use Debian funds to help the Debian Project Leader (DPL) role in some way * Pay Debian contributors to complete large scale changes in a reasonable time frame * Pay specialist porters to support release architectures at risk of being dropped from Debian releases due to lack of porters. +* Paying technical writers to improve the documentation for new + contributors +* Pay Application Managers to ensure we deal with new contributors in a + timely fashion +* Pay Package Review/Sponsorship when a new contributor has been unable to + find a sponsor to review his work. Assuming that Debian contributors can request "grants" to help them pursue @@ -270,6 +282,7 @@ time to fulfill the obligations of the role? (yes/no/unsure/no opinion) * Member of the Security team * Member of the LTS team * Member of the Technical Committee +* Member of the Debian Account Managers Are there other roles that should be funded to allow more time to fulfill Cheers, -- Raphaël Hertzog
Re: Debian Roadmap 2030
On Sun, 14 Nov 2021, Felix Lechner wrote: > Hi, > > Three folks on -vote recently responded to a GR proposal that we—as a > group—have more important things to do, yet no one articulated what > those things were. With this message, I hope to collect your ideas. [...] > Please feel free to respond privately with answers to any of the > questions below. Before replying on-list, please consider that you may > spark a discussion even though it is too early for that. I will > present a summary of all submissions in January 2022 and moderate a > debate then. I'm sorry but while you have the right to try this, coming from someone that is not our DPL, it seems very awkward to try to centralize privately our best ideas. We already have https://salsa.debian.org/debian/grow-your-ideas to try to gather ideas and build momentum (with the +1 buttons). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Creating a Debian Spending proposals and discussion mailing list
On Mon, 19 Apr 2021, Phil Morrell wrote: > On Tue, Apr 06, 2021 at 10:14:50PM +0200, Raphael Hertzog wrote: > > We could have a "debian/spending-ideas" if you want so that all DD have > > write access by default. We could restrict access to issues for project > > members (that automatically includes all DD + selected non-DD directly > > added to the project). > > Understood, I'm happy to organise it that way too if folks would prefer. Kentaro Hayashi already started something in this direction after having read this discussion: https://salsa.debian.org/debian/grow-your-ideas You might want to work together. I saw his announce on planet Debian but AFAIK he never mentioned it in this thread: https://kenhys.hatenablog.jp/entry/2021/04/10/221301 It should be more widely announced, at least with a "Developer News": https://wiki.debian.org/DeveloperNews > It just *seems to me* that the email workflow of seconds and inline > quoting is less structured and very familiar to DDs for fleshing out an > idea, perhaps augmented with an ad-hoc jitsi call. I don't think that a gitlab issue is much more structured. It's still quite readable and works well by email as well. As far as I am concerned, I think we are way too much email centric and we are missing out on opportunities to retain new contributors due to this but I digress... Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Creating a Debian Spending proposals and discussion mailing list
Hi, On Sun, 04 Apr 2021, Phil Morrell wrote: > Please keep in mind that I'm proposing this list purely as a practical > experiment, it does nothing that can't already be done elsewhere, and if > it doesn't work out after say 6 months, then so be it. All I'm looking > for is an indication that it would not be a complete waste of my time to > set up, that doing so has the potential to help Debian, and that some > DDs would be willing to review and Second proposals. I think it's important to experiment in this direction but for a low-key experimentation I'd rather go with a gitlab project where you file ideas as issues, people vote up and down various ideas with the usual +1 -1 buttons (gitlab can then show you a sorted list by popularity). You can have draft projects in text files and people can collaborate with MR on enhancement to those drafts. We could have a "debian/spending-ideas" if you want so that all DD have write access by default. We could restrict access to issues for project members (that automatically includes all DD + selected non-DD directly added to the project). > > It's certainly good to lower the barrier for proposals but for your Kotlin > > example, the issue is more "who will be paid to to the work"? Someone has to > > select a winning bid and having that kind of responsibility within Debian > > is the historical friction point related to use of money in Debian. > > Isn't that the same issue you have for Freexian? Well, no. Freexian is not Debian. I said _within Debian_. > Presumably the Proposal > would be either an Executor or (implied by default) Reviewer by your > terminology, so then the Seconds are agreeing who will review the work. If freexian decides to trust a Debian contributor to select a winning bid, or trust a Debian contributor to implement a project, it's not the same as if the money was given by Debian directly to a Debian contributor. Obviously that decision can still have an impact on the community and that's why I aim to have a clear and transparent process. > a point where that is a concern. For now I am happy giving more > visibility to actionable projects with *any* reasonable impact on > Debian. Ack. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Creating a Debian Spending proposals and discussion mailing list
Hi, On Fri, 02 Apr 2021, Phil Morrell wrote: > I've thought about what such a system could look like, perhaps signed > commits to a salsa project or a simple site like mentors. I came to the > conclusion that there's already a working system in place for counting > DD support of suggestions. debian-vote has proposals, low-bureaucracy > seconders, and the Project Secretary validating signatures. > > I propose creating an experimental debian-spending mailing list based on > the same rules to test this idea. The equivalent of the GR here would be > a filled out project proposal for consideration by the DPL or Freexian. That's a simple way to ensure some basic level of support to an idea or some way to gauge whether a need is shared by multiple persons. But it doesn't really help to turn those ideas into actionable projects that can be funded. It's OK when the project is as simple as "give 5 KEUR to peertube" but definitely not enough when the idea is "build a web interface to manage Debian reimbursement request" (taking an example that I just got on https://salsa.debian.org/freexian-team/project-funding/-/merge_requests/5). I would be saddened if this system turned only into a way to give our money to other free software projects instead of using that money to help us towards our common mission. > Another example is that debian-android-tools has all the DD availability > for sponsoring Kotlin uploads, and most initial work done by GSoC > students, but no-one had free time to work on it betwen Oct and Mar. Now > it turns out that no less than 3 other teams are depending/awaiting a > kotlin upload: Java, Freedombox for Jitsi, Games for Mindustry. That's a > lot of potential DDs who could have seconded a tender for a third-party > contractor to bid on say a week to a month's work. Ack. > I think this will lower the barrier for proposals. I looked up what the > current process is and it's literally "email the DPL and convince them", > which could be offputting without knowing how many other people support > your idea. Similarly I would expect a lot of teams to know their own > problem areas but be unaware of the level of support outside the team > through multiple levels of reverse dependencies. It's certainly good to lower the barrier for proposals but for your Kotlin example, the issue is more "who will be paid to to the work"? Someone has to select a winning bid and having that kind of responsibility within Debian is the historical friction point related to use of money in Debian. I tried to solve this by defining up-front for each project who will be the reviewer and thus the person who will have to select the winning bid (in cooperation with the person/organization who will pay the bill). Or by encouraging developers to propose projects that they want to implement themselves... so that there's no choice of person to make, it's more a "do we want this project at this time" and it can be answered collectively (in Freexian's case by the paid LTS contributors since it's money saved from the offering where they are involved). > Hopefully that's enough to convince you, and it's clear I'm only > offering to do the administration, not make any actual decisions. I'd > also like to help the list get started in a personal capacity by digging > up old BudgetIdeas and writing up proposals say once a week. IMO the bulk of the work is not in finding ideas, but on transforming them into actionable projects, and on selecting which project can have the largest impact on Debian. That said I would welcome if we could query the Debian developers at large to find out what kind of ideas/changes would be most beneficial to Debian. Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Funding Debian projects with money from Freexian's LTS service
Hello, as you probably know, my company — Freexian — has been running the commercial side of the Debian LTS project, collecting money from sponsors and dispatching it to contributors handling the security updates. This is working pretty well by now and the amount of funding is sufficient to cover the workload. This led me to think about expanding a bit the scope of the LTS funding that Freexian is managing to answer two different needs that I identified: 1/ First, the LTS work necessarily had an impact on other Debian teams that made the project possible (security team, DSA, buildd, ftpmasters, debian-www mainly) and I wanted to be able to give back to those teams. 2/ we have always allowed paid contributors to go beyond just preparing security updates for the LTS release. They can pick tasks that improve the LTS project at large (we try to collect such tasks here: https://salsa.debian.org/lts-team/lts-extra-tasks/-/issues) but they should not go over 25% of their allocated monthly hours so this limits their ability to tackle bigger projects and we would like to be able to tackle bigger projects that can have a meaningful impact on the LTS project and/or Debian in general. So I thought about it and I made a proposal to the paid LTS contributors that has been accepted: every month we are putting 10% of the LTS funding aside to be able to fund larger tasks/projects. We will regularly seek project proposals, review them and pay someone to implement the proposals that have been retained. We have tried to formalize a process for this in this salsa project: https://salsa.debian.org/freexian-team/project-funding https://salsa.debian.org/freexian-team/project-funding/-/blob/master/Rules-LTS.md (I'm pasting a copy of the two relevant markdown files at the end) We highly encourage the above-mentionned Debian teams to make proposals. A member of those teams can implement the project and be paid for it. Or they can decide to let someone else implement it (we expect some of the paid LTS contributors to be willing to implement such projects), and just play the reviewer role driving the person doing the work in the right direction. Contrary to Google's Summer of code and other similar projects, we put the focus on the results (and not in recruiting new volunteers), so we expect to work with experienced persons to implement the project. But if the reviewer is happy to be a mentor and spend more time, then it's OK for us too. The reviewer is not a paid position. I really want to try out something on this level but I also know that the topic is sensible so I want to get your feedback to make sure we find a good balance and make it acceptable to Debian at large (I'm not aiming at 100% acceptance, but I'd like this to be accepted just like LTS funding has become normal for most Debian developers). So I welcome your comments on this proposal. I'm really busy lately so I might not be super-reactive but I have postponed this discussion for too long already so I'm sending it out anyway (at this point we already have 13200 EUR that we can use to fund projects!). Cheers, PS: Here are the relevant files from the project-funding git repository: README.md: -- :warning: This document is currently in draft state. Is subject to frequent and significant revisions until it is finalized. # Project Funding This repository is used to track free software projects that Freexian is willing to fund to some extent. Freexian can fund projects for different reasons and the rules applied in each case will vary depending on the origin of the funding: * As part of its Debian LTS offering, Freexian has a budget to invest into projects that will directly or indirectly improve the Debian LTS project. Any Debian member can submit project proposals and they will all be considered. See [LTS-specific rules](Rules-LTS.md). * Freexian can also put out projects proposals on its own. In that case, they are usually justified by internal needs or customer requests. See [Freexian-specific rules](Rules-Internal.md). # Project Workflow Each project progresses through several stages. In order to ensure complete high quality work on fully vetted projects, a project must be proposed, approved, executed, and completed. ## Vocabulary * Project submitter: the person or team that submits a project proposal * Executor: the person who "executes" or "implements" the project, it's the person whose work will be funded by Freexian * Reviewer: the person who ensures that the executor completed the project and that the result is compliant to the project description. * Bid: an offer made by someone to execute a project at a given price following a given timeline * Project Managers: person(s) appointed by Freexian to handle issues and merge requests in this GitLab project. Usually Raphaël Hertzog. * Freexian manager: Raphaël Hertzog ## Project Proposal The project development process begins with the completion of a project propo
Re: Debian infra services and tools looking for programming contributions
Hello Antonio, nice initiative ! On Thu, 21 May 2020, Antonio Terceiro wrote: > For services, my starting point is https://wiki.debian.org/Services For > tools, I currently have a list of the ones I usually contribute to, but > can add more. > > Not the part where I need your help. I'm looking for people who maintain > or contribute to a Debian infrastructure service or tool that could use > some help with programming, have the availability to provide some > mentoring for someone who is already a programmer but not necessarily > already involved with Debian, and would like your project to be > highlighted in such a talk. I would definitely like to have tracker.debian.org be highlighted in such a talk. I spent a fair amount of time to have proper documentation for new contributors and we have CI on merge requests, i.e. we're well prepared to welcome contributors but few show up and even fewer keep contributing on the long run. https://qa.pages.debian.net/distro-tracker/contributing.html IRC: #debian-qa Mailing list: debian...@lists.debian.org Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Mon, 13 Apr 2020, Steve McIntyre wrote: > Hell, there's a strong confirmation bias here too - how many > potentially great future developers have we lost at a very early stage > because our email-centric workflow didn't appeal to them initially? We already lost existing Debian developers due to this. I remember a discussion with Ryan Murray (who was very involved a long time ago!) and he expressed concerns over our use of email and GPG. And the fact that you must share your email to everybody to be able to take part into conversations (in particular given how this leads to spam). He was also concerned with the need to do all work under our real identity. Looking into contributors.d.o and db.debian.org, he might have requested his data to be dropped... Email mailing lists are driving some people away. It's a fact. Web forum discussions are also driving some people away. I'm an email guy too, but I find discourse really interesting and I'm ready to give it a try (even if I'm above 40!). Cheers, -- ⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog ⣾⠁⢠⠒⠀⣿⡁ ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/ ⠈⠳⣄ Debian Long Term Support: https://deb.li/LTS
Re: Community Team - where we want to go
On Mon, 11 Nov 2019, Norbert Preining wrote: > On Mon, 11 Nov 2019, Gerardo Ballabio wrote: > > That is, the team would rule on individual cases, rather than issuing > > "lists of things not to do". IMHO that pretty much would make it a > > court with the power to judge project members. And I'm not sure that > > the team not taking actual measures, but just making "recommendations" > > to other people who are empowered to take action, would make a > > difference. In fact, that would be curiously similar to how the > > Inquisition proceeded: technically they never executed anyone, they > > just sent people to the secular authority with the "recommendation" to > > burn them at the stake. > > > > And if the people empowered to take action can disagree with the > > recommendation and apply their own judgement, well, that would make > > the "ultimate authority" concept void, and I would say, would nullify > > the whole point of having the team "interpret the CoC". > > +1 -10 for introducing a comparison that has no place in Debian. We're not executing or burning people. That's the kind of comparison that contributes to the bad atmosphere and is pushing reasonable people to add more rules, so this goes towards your own goals of wanting less thought police and more freedom. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Using Debian funds to support a gcc development task
Hi, On Sun, 29 Sep 2019, Hector Oron wrote: > > Not sure what the problem with LTS is. I thought companies pay for the > > extra effort. I think it's a perfectly fine business model. > > As a very simple summary, companies pay another company (Debian > unrelated) to use Debian volunteers time and Debian resources. > Debian does not get any share of that work. I'm afraid that this summary is too simple and thus misleading. * Freexian (the "another company") is not owned by Debian, but it's not unrelated to Debian. I funded that company, as a Debian developer, to let me contribute to Debian while being paid by customers who are Debian users. * Freexian doesn't "use Debian volunteers", nobody is forced to work for Freexian, they all asked to join the team of paid contributors. But Freexian pays them for the LTS work, that's correct. * While we use Debian resources, we are using Debian resources just like any other Debian contributor, the fact that we are paid doesn't change anything. Many Debian contributors are being paid as part of their work. It's just more visible in this case. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Cultural differences and how to handle them
On Wed, 03 Jul 2019, Roberto C. Sánchez wrote: > On Wed, Jul 03, 2019 at 05:33:25PM +0200, Ole Streicher wrote: > > Being german, I think that Debian should honor discriminated minorities, > > Being a discriminated against minority, I think Debian should *not*. And since Debian is do-ocracy, it's not your call. You can disagree with the publicity team, but it's their call and a call they made while trying to put our diversity statement into application. Can we stop this discussion now, please? Unless you really want to revert their decision via a general resolution... but even in that case, the discussion here doesn't help to go forward with this. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Censorship in Debian
Hi, On Fri, 21 Dec 2018, Adam Borowski wrote: > Thank you for illustrating so well why Daniel's words were spot on. Your > response is exactly why censorship must not be tolerated in Debian. Such a message is not constructive and actually hurts any further discussion. First of all, while it may be obvious to you, I don't see in what way Russ's response "illustrates Daniel's word". But I'm not sure that I want to read your justification, you seem to have a very low level of empathy for other persons' feelings. Anyway, nobody has been censored here. It looks like some people including Norbert and Daniel have had inappropriate behavior that have been reported to the anti-harassment team. That team made decisions and acted, even in coordination with the Debian Account Managers. The persons who are the target of those actions have received a detailed explanation of the actions taken and of their justification. AFAIK they are free to publish the details if they wish to. But the policiy of the anti-harassment team is to not publicly shame people so they don't do that themselves. Norbert seems to have stepped back in response: https://lists.debian.org/debian-tex-maint/2018/12/msg00019.html Daniel seems to not follow the same route, instead he seems to engage in some public mud-fight. This has never been successful in the past. It reminds me of the case of Sven Luther. But it's always a painful experience for all parties. So pretty please, to all the followers, think twice before engaging in this discussion and re-read any message twice before sending it. Thank you. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Conflict escalation and discipline
On Wed, 18 Apr 2018, Ian Jackson wrote: > > This implies to me that, at the least, "anti-harassment" is the wrong > > name for a team that deals with this. > > That's certainly true. I thought of these ideas: What about def...@debian.org ? You write to them when you are about to explode and need help to not explode. Or need help because someone else is going to make you explode. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Listing of derivatives on the Debian website?
Hi, On Tue, 05 Sep 2017, Paul Wise wrote: > I discussed this a bit more with Stéphane Blondon offlist and we came > up with this proposal for the criteria and how to list derivatives. > > We would welcome some feedback on these new criteria. I don't have anything to add. It looks good to me (and I believe Kali would fit the requirements too). Altough it's not necessarily trivial to evaluate your criteria: > actively cooperate with Debian Hard to evaluate but can be assumed to be true when the distribution files bugs (and when they user tag the bugs). > are actively maintained - new releases? - people responding to queries/bug reports? > are notable and established distributions Not very specific either: - notable? => how do you know popularity? - established? => how old must the derivative be? Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: https://www.freexian.com/services/debian-lts.html Learn to master Debian: https://debian-handbook.info/get/
Re: Maintainerless Hive-Mind? (was Re: Replace the TC power to depose maintainers)
On Thu, 08 Dec 2016, Guillem Jover wrote: > It is not only not obviously right to me, instead it seems obvious > it carries a set of different problems with it. I feel this carries > so many assumptions of how the proposers feel about how *they* work > or might like to work and ignores how *others* do that. :/ I don't think that entirely abolishing maintainership is a good move. But we should change our process so that by default we have no hard lockin on most packages. For packages where the persons doing the work have special requirements, they should document those requirements in debian/README.maintainers (or README.contributors). In that file they could: - ask to review changes prior to upload (and give some delay in which they usually respond) - define some package-policy to follow (conventions, procedures) - document upstream related things that are good to know - explain their plan for the next upstream release wrt to Debian's release - etc. Team maintained packages could just add a pointer to the team policy. With such a system, it makes sense to drop the Maintainer/Uploaders from the package and have it dynamically generated from persons actually working on the package. We don't need a sole maintainer to make decisions, everyone is entitled to make decisions provided that they follow the rules defined by the active maintainers. And rules can be changed through discussion between active contributors when reaching a consensus... Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Replace the TC power to depose maintainers
On Fri, 02 Dec 2016, Holger Levsen wrote: > I'm not saying people like you dont exist, nor that your reasoning aint > sensible. I've just said some people take motivation from being listed > as maintainer. We could get rid of "Maintainer" in debian/control and still display on tracker.debian.org the name of people who are uploading/committing in a dynamic "Maintainer" section. Actually, this is part of my grand-plan... :-) aka http://dep.debian.net/deps/dep2/ Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: shutting down httpredir.debian.org?
On Thu, 14 Apr 2016, Christian Rohmann wrote: > On 04/13/2016 10:23 AM, Raphael Hertzog wrote: > >> * Intensive checks (even via rsync) regarding mirror consistency > > That's good too but the downside is that the mirrors must > > offer rsync service, either public or at least for the mirror redirector. > > It's not possible to use a mirror that cannot be scanned via rsync. > > Likely wrong: http://mirrorbrain.org/docs/mirrors/#scanning-mirrors > > There is FTP and HTTP fallback. Duh... yes there is, but have you tried scanning a Debian mirror with FTP? It just never finishes. And with HTTP it's even worse, it's not possible to scan unless the mirror has enabled directory listing (or you try one by one all the files of the local mirror). The intent of mirrorbrain is to update the file lists regularly and with rsync I get a 2 minutes update once every hour. That's OK. With FTP I never had the patience to see how long it actually took. So for all practical matters, only rsync is usable. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: shutting down httpredir.debian.org?
Hi, On Tue, 12 Apr 2016, Christian Rohmann wrote: > It does wonderful things (http://mirrorbrain.org/features/): Nice to see some much support but I would like to point out that not everything is perfect either... > * Load-Balance by GeoIP / AS matching (traffic stays very local) That's clearly the main selling point. > * Intensive checks (even via rsync) regarding mirror consistency That's good too but the downside is that the mirrors must offer rsync service, either public or at least for the mirror redirector. It's not possible to use a mirror that cannot be scanned via rsync. > ** It can serve things down to the file level to a mirror that > still/already has a certain file The "still" is wrong. It's actually an annoying bug that needs to be fixed for our usage... Kali wants to sponsor this bugfix but the upstream developer is currently busy with other stuff so it has not happened yet. https://github.com/poeml/mirrorbrain/issues/21 Which also shows another downside: this is really a one-person project currently (not different from httpredir though, and this one has the advantage of being more generic so can and already serves more projects in the free software world). Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: shutting down httpredir.debian.org?
Hi, On Tue, 12 Apr 2016, Peter Palfrader wrote: > So, it appears as if currently nobody has time or the energy to take > care of httpredir.debian.org properly. > > I suggest we shut down the service for now. If, at some future point, > somebody wants to maintain again we can always start it up again. Will you make httpredir point to a normal mirror so as not to break systems relying on it? (Or even to the geolocalized DNS entries if we still have that) If yes, then it's certainly a sensible thing to do. I'd like also to note that once we have proper by-hash package indices in Debian too, it's entirely reasonable to rely on MirrorBrain as HTTP redirector. I use it for Kali for more than 3 years already. http://mirrorbrain.org But I still haven't gotten round to package it properly for Debian... but I will do that at some point. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: Software Freedom Conservancy needs our cash
On Tue, 01 Dec 2015, Ian Jackson wrote: > Could Debian as a project sign up ? Conservancy is a 503(c), like > SPI, so perhaps we in Debian could commit a modest regular funding > stream to Conservancy. +1 We have troubles finding good use of our money. This one should not cause any problem to anyone. Let's give them a part of our money for the service they do us by enforcing the GPL for Debian developers. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/
Re: donations and paypal
On Thu, 11 Dec 2014, Brian Gupta wrote: > As someone who's pretty heavily involved in fundraising for Debian, I'd like > to > express my support for adding Paypal to the list of official methods to donate > to Debian. And if I can add a data point, PayPal is already mentioned on the donation page because Debian France is accepting PayPal. We have been added on this list about two months ago, and we got almost 1400 EUR of donation targeted to Debian via PayPal (coming from 24 different donors). So there is certainly a significant user base willing to support us via PayPal. Cheers, -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20141211153310.gc2...@home.ouaza.com
Bug#772645: lists.debian.org: Please create debian-moderat...@lists.debian.org
Package: lists.debian.org Severity: wishlist Hello, with the adoption of the code of conduct, more and more people started to respond to persons who do not follow its spirit, to let them know that the message was inappropriate in one way or another. Some do it publicly and other do it privately. This is good. Unfortunately, when such a message is sent publicly on the same mailing list, it oftens degenerates in a small sub-thread. This is bad because it generates useless tension and because its brings down the signal/noise ratio on the given list. At the same time, those discussions are also necessary to have some balance and remember collectively that we do not want to over-regulate our mailing lists either. Thus I would like to have a new mailing list called "debian-moderat...@lists.debian.org" that moderators (i.e. contributors who are telling others that their behaviour was inappropriate, or contributors refuting such claims) would use. The complaint would go the interested person and would be carbon copied to this list. This has multiple benefits: - people acting as moderators get a better feel of what can be done and what can't be done (by following what others are doing they auto-regulate themselves) - listmasters can monitor the list to detect regular offenders and take more informed decisions for (temporary) bans - meta-discussions no longer pollute our work mailing lists To not exclude moderators who are unwilling to send complaints publicly, I believe that the mailing list should be private (but archived with archives accessible to DD only) and only open to Debian developers by default. Possibly non-DD could join but they would need the invitation of a DD. A copy of this mail is sent to debian-project, both to have some public discussion of this idea (in that case, please do not keep the bug in copy), and to sollicit a few "ack" from other DD who are already doing that kind of moderation work (or would like to start doing it in a more organized way). Thank you. FTR, this idea was initially submitted in a debian-private thread discussing the code of conduct. -- Raphaël Hertzog ◈ Debian Developer Support Debian LTS: http://www.freexian.com/services/debian-lts.html Learn to master Debian: http://debian-handbook.info/get/ -- 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/20141209143104.ga19...@home.ouaza.com
Re: The Code of Conduct needs specifics
On Mon, 24 Mar 2014, Wouter Verhelst wrote: > The danger of having a list of "do not"s is that people will do > something which is not on the list, and then point to it and say "see, > it's allowed by the code of conduct" when pointed out that they're being > a dick. It's quite common to have an short introductory paragraph saying something along “this list is not exhaustive and is not meant to be, it's just there to avoid any discussion should any of those important misbehaviour arise. For other cases, apply the above guidelines using your best judgment.” Obviously, I would want such a list to be more like an appendix than the main meat of the CoC. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140324085639.gb5...@x230-buxy.home.ouaza.com
Re: The Code of Conduct needs specifics
Hi Solveig, On Mon, 24 Mar 2014, Solveig wrote: > I can write specific amendments, if somebody is willing to sponsor them :) Please do. I tend to agree with what Steve said. It doesn't hurt to have a list of "don't" but this should not replace the "inspirational" part of the CoC. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140324074743.ga5...@x230-buxy.home.ouaza.com
Re: GR proposal: code of conduct
On Wed, 26 Feb 2014, Wouter Verhelst wrote: > > - Wrap your lines at 80 characters or less for ordinary discussion. Lines > > longer than 80 characters are acceptable for computer-generated output > > (e.g., ls -l). > > - Do not send automated out-of-office or vacation messages. > > - Do not send test messages to determine whether your mail client is > > working. > > - Do not send subscription or unsubscription requests to the list > > address itself; use the respective -request address instead. > > - Never send your messages in HTML; use plain text instead. > > - Avoid sending large attachments. > > While I agree that these are useful suggestions (and that therefore they > probably should be retained), these sound more like technical guidelines; I > don't think a code of _conduct_ should contain technical explanations on how > to configure your mail client. > > So I would suggest that for these things, we create something else (not a > code > of conduct) that is maintained by you, our listmasters. The (proposed) code > of > conduct could obviously refer to it from the "further reading" section, if > that seems appropriate. > > Does that make sense? IMO yes. The code of conduct could link to a "Best practices on Debian mailing lists" document that the listmasters would maintain. > > - When replying to messages on the mailing list, do not send a carbon copy > > (CC) to the original poster unless they explicitly request to be copied. > > Well, heh. > > On that one, I think the current code of conduct is a mistake, because most > mail clients make it very hard to do that. +1, I'm also in favor of dropping that requirement. Contributing to Debian lists imply some willingness to interact with people and you should not be much bothered by a CC. If you are, then you can most likely filter out duplicates with procmail. I appreciate getting a CC because I see replies to my mails earlier that way. The downside is that people who can't avoid replying within 5 minutes to every mails they get might quickly generate a noisy thread of 10 mails in a few hours without leaving the time to others to participate in the thread and have a healthier thread. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140227111705.gc23...@x230-buxy.home.ouaza.com
Re: State of the debian keyring
On Mon, 24 Feb 2014, Ian Jackson wrote: > It can increase security because it can make operations more > convenient at the same level of security, and because people trade off > convenience for security. > > For example, it would be possible to have one key for email encryption > and a different (more secure) key for package uploads. This is already possible with subkeys. That said subkeys of a 1024 bits master key can't really be trusted, even if they are bigger. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140224193700.ga15...@x230-buxy.home.ouaza.com
Re: Debian Services Census
On Wed, 19 Feb 2014, Ingo Jürgensmann wrote: > In fact it doesn't duplicate an existing service. Its focus is > different than the buildd.d.o site. The site says “These pages are intended to show additional information to http://buildd.debian.org or more exactly it is basically the same information, but shown in a different, maybe better readable form.” You might want to clarify. > Beside that the name is because it's about build daemons, short: buildd. > It's new to me that "buildd" is a reserved trademark of Debian and I > believe that it's common knowledge for nearly everyone who deals with > buildds that official Debian services will run under a debian.org > domain, which is clearly not the case fuer buildd.net. mentors.debian.net is "official" since it's the only implementation of that service. Yet it's not in debian.org. So IMO the domain name is not really a reliable criteria. buildd.net is neither a debian.net nor a debian.org so its status is not immediately obvious. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140219112428.ga22...@x230-buxy.home.ouaza.com
Re: Debian Services Census
Hi, On Wed, 19 Feb 2014, Ingo Jürgensmann wrote: > Unfortunately I have a problem with the renaming of my pet service > Buildd.Net on https://wiki.debian.org/Services. I added my service as > BuilddNet and it got renamed to "UnofficialBuilddNet". Although it's > true that it's an unofficial service, I feel great discomfort with the > prefix "Unofficial". No other service has this prefix and I sense > disadvantage (not to say: discrimination) about the stigma of being > named the only "Unofficial" service on that page. So I propose either > the removal of "Unofficial" from the title "UnofficialBuilddNet" to > "BuilddNet" or "Buildd.Net" or adding tags "official" and "unofficial" > for each service so that everyone can differentiate between unofficial > and official services by using a filter or such. But I really object > against being the only service named "Unofficial". I don't have a strong opinion about the addition/removal of this prefix but I'd like to point out that contrary to other services, this one reuses the "buildd" keyword which is already associated to buildd.debian.org and it's a service which duplicates features with an already existing service. I guess that's the main reasons why Martin added the prefix to disambiguate its status. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140219091413.gb19...@x230-buxy.home.ouaza.com
Re: Debian services and Debian infrastructure
On Wed, 22 Jan 2014, Tollef Fog Heen wrote: > > 2) the alternative is that they give up on the idea, or host it > >themselves, which makes it harder to work collaboratively on the > >service, and results in services that have a single maintainer (or > >none, in the end). > > How does having a random VM running in a cloud somewhere make that > service easier to integrate into the wider debian.org setup? It means those people who want to experiment get to ask a VM at some predefined places where various parties can monitor who is asking and what their projects are. > think it does; what does is the first point: talk to us so we can figure > out what works for both sides. Especially given you want to give root > to developers on those VMs, there's absolutely nothing that points in a > direction of those VMs being more integrateable than a service developed > on a developer's own laptop (in a VM or in their regular environment). Indeed, but it gives others (including DSA) an opportunity to chime in sooner. > > Another requirement is that the developers should have root access on > > the virtual machine, so that it's easy to try various options without > > DSA intervention (remember: this is about developement/beta testing, > > not about running the service in a super-stable, production mode). > > Who's then to ensure that machine is secured and kept up to date with > security patches and doesn't become a source of spam? Sorry to say, but > most developers are not good sysadmins and they do not have the tools > and infrastructure set up to do systems maintenance well. For this to > be an option at all, we'd want to sandbox the machines heavily enough > that they will be less attractive machines to develop on than a > developer's own laptop. What kind of restrictions do you expect to have to set up? I can imagine some restrictions on outgoing mails (like Amazon VM do by default) but what else could impeded the abilitiy to develop a new service? > It's sgran who's been thinking about how to do this, but afaik he's seen > close to zero interest from developers for it, so it's not happened > yet. I don't think we need anything from the DPL as such, but if people > are actually interested in something like this happening, saying so > would be a good start. I would be interested by it. I would have used it for pts.debian.net (instead of the Amazon VM we have now). And later, I would like us to be able to use a Debian cloud to automatize the rebuild of reverse dependencies with a set of updated packages. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140123082414.gd3...@x230-buxy.home.ouaza.com
Re: bits from the DPL -- December 2013
On Tue, 21 Jan 2014, Lucas Nussbaum wrote: > - [bgupta] work with SPI to enable donations via paypal Note that Debian France has planned to setup that for the Debian project. It would be a small change on this page: https://france.debian.net/galette/plugins/galette-plugin-paypal/paypal_form.php Instead on the current single option we would have two options: * Donation to Debian France * Donation to the Debian project Assuming of course that we are recognized as a trusted organization. > [zack] organize a survey of DDs (N: draft questions) What is this about? Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140122092244.gb27...@x230-buxy.home.ouaza.com
Re: Evaluation criterias for (prospective) Trusted Organizations
Hi, On Fri, 17 Jan 2014, Lucas Nussbaum wrote: > So, first things first, I would welcome your feedback on the TO > criterias[1]. Soft deadline: 2014-02-01. > [1] https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteria I didn't find anything really problematic in the criteria, at least not wrt Debian France. Let me still add some comments. > == The organization should share Debian's general visions == > > The organization's activities and political stance should generally > match Debian's own political and philosophical stances. "activities" might be a bit broad. TO might have (Debian-related) activities that Debian is (purposedly) not doing, and this should not be a blocker IMO. IMO we should simply tell that the TO bylaws, activities and political stance should not be in conflict with Debian's social contract. > == The organization should remain loyal to Debian == > > The organization should be considered fully trustworthy, or provide > guarantees that Debian's assets will be managed according to the Debian > Project's decisions. > > Some examples of possible implementations: > * The organization has a long history of successfully holding a >similar role for other Free Software projects > * The organization is managed by highly respected members of the >Free Software community > * The organization has a leadership structure that ensures a >minimum number and/or a majority of Debian developers > * The organization has decision-making processes that explicitely >delegate decisions on Debian assets to the Debian Project Leader Right, in the case of Debian France we delegate the decisions on Debian assets to the DPL via the "Règlement intérieur" (internal rules) but those rules can be easily modified by the board. That said the board is composed of at least 2/3 of Debian developers (also a requirement imposed by the "internal rules"). > == The organization should provide accountability on assets held in trust == > > Some examples of possible implementations: > * The organization provides, on a regular and frequent basis (e.g. >quarterly), detailed reports of assets tranfers and balance sheets, >in a machine-parsable format. > * The organization provides access to Debian's accounts live data, >in a machine-parsable format. We do use "ledger" to keep our own accounting in a git repository and intend to give access to this repository to the Debian auditors. ledger has some facilities to do some "analytical" accounting and we intend to use that. It would be good to know what exactly are the minimal requirements. Can we have a single "Debian" account with an history of debit/credits or do you want/need a full double accounting output with each operation balanced between the asset account and another expense/income account ? > == The organization should be reliable, sustainable, and reactive == > > Some examples of possible implementations: > * The organization is managed by a large group of active Debian >Developers > * The organization's managers have been involved in Debian or other >Free Software projects for a long time, and have a high reputation >of being reliable. > * The organization has several people sharing the role of treasurer in >order to react quickly to requests in all circumstances In Debian France, Sylvestre Ledru is the treasurer and there's no other treasurer. That said, as the president, I also have the power to do banking operations and I do occasionnaly help Sylvestre to manage the accounting side. The board contains other Debian developers, but none of them would be able to help when it comes to do a wire transfer or something like that. > == The organization should provide a reasonable financial framework == > > For example, it is desirable that: > * Donations and sponsorship are tax-deductible for the donor > * Donations, sponsorship, income from sales and transfers from other >TOs are not subject to income tax > * There are no major restrictions on what kind of expenses can be made, >either due to the organization's bylaws or to the legal framework of >the organization > * There are no major restrictions on how the organization could transfer >assets to another TO > > Some properties are often mutually exclusive (e.g.; ''tax-deductible for > the donor'' and ''no major restrictions''). This is fine -- the goal here > is to understand beforehand what will be possible for a specific TO. We can provide receipts for tax-deductibility, they are valid in France at least. I don't know their status in other countries. The only restriction that we have put is that we want a "supporting statement" (required for proper accounting) for any operation that we are going to handle in behalf of the Debian project. That said if the DPL asks us the reimburse some jewelry, we might require more than an invoice to explain how buying that jewelry serves the purpose of the Debian project and hence of Debian Fr
Re: Updating the Policy Editors delegation
On Mon, 06 Jan 2014, Russ Allbery wrote: > Ian Jackson writes: > > > This is all very well but I think de jure they aren't a delegated team, > > and the distinction is defined in the constitution. This is not > > trivially bypassable, because a delegated team is one who derives their > > powers from the DPL and the constitution limits the powers of the DPL. > > I believe that deciding on the mechanisms and machinery whereby the > project as a whole will work out its technical policy (as opposed to > disputes over the contents of that policy itself) falls nicely under 5.1.4 > and 5.1.9, particularly the latter. Agreed, the role of policy editors is to maintain a document. The fact that it's also uploaded in Debian as a package is just a technicality. Would ftpmasters stop being a delegated team the day where they package dak again ? I don't think so. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20140106180200.ga2...@x230-buxy.home.ouaza.com
Re: Updating the Policy Editors delegation
On Mon, 06 Jan 2014, Ian Jackson wrote:
> Cyril Brulebois writes ("Re: Updating the Policy Editors delegation"):
> > Have you seen some mistakes that would help us (or at least me)
> > understand which problems you're {thinking of,anticipating}?
>
> I think the biggest problem isn't that the policy editors are making
> mistakes, but that they aren't making enough decisions. I'd like them
> to make more mistakes :-).
I would feel more confortable if you made that claim after having tried
to play along the current rules. To me it seems more an issue of having
enough time to animate the discussions and draft the texts than anything
else.
Sure there are exceptions on topics which are highly specialized and where
people don't feel qualified to second (the triggers issue comes to my
mind. BTW why didn't you respond to Charles' query? he explicitly asked
a review from you...) but other than that both Russ and Charles managed to
bring multiple issues to completion without too much fuss, just explicitly
seeking for seconds when they thought that an issue was mostly ready to be
merged.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20140106135344.ga10...@x230-buxy.home.ouaza.com
Re: Debian services and Debian infrastructure
Hi, On Sat, 04 Jan 2014, Lucas Nussbaum wrote: > I've given some thought to this myself, and came up with the following > ideas. Some of them are probably really bad ideas, but let's try to > brainstorm a bit: I don't find them bad. At least from the POV of view of a DD and of a service maintainer, they seem to go in the right direction. > 1. to improve communication between DSA and service maintainers >+ have an archived, public list where (prospective) service maintainers > can engage with DSA about stuff they are planning/thinking about. > (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?) debian-services-admin@l.d.o seems to be rather appropriate for this (it's unlikely that this kind of discussion would generate so much mail that the list could no longer serve its current purpose). >+ have DSA provide collective answers more often, rather than a set of > individual answers. It's often not clear if something is a final > decision, or the opinion of a DSA member. >+ redirect some discussions from IRC to a mailing list, esp. when > things look like policy decisions (on service design, etc) It would also be helpful to have a document explaining their usual requirements. It would pro-actively direct the service maintainers towards choices that are acceptable to DSA. Things like: - use PostgreSQL if you need a DB - keep in mind that DSA likes to ensure high-availability, so make it easy to run a replicate of your service - avoid dependencies not in stable or stable-backports - avoid X, Y, Z for security reasons - etc. > 2. to improve the tracking of services >+ request wiki pages from maintainers that detail who are the contact > points, what the service does, what are its requirements. State a > "service level agreement" (informative of expectations, not punitive, > of course) >+ have service maintainers create similar pages for services in > development, to provide some kind of "incubation process" during which > DSA can provide feedback. This would be good to have but (someone|DSA) would have to prod service maintainers to get this started, otherwise it will never happen. This requirement could also be mentioned in the document I suggested earlier. > 3. to provide a place to experiment with new services >+ create a "Debian cloud" with virtual machines to develop new services > (maybe providing manually-created VMs would be enough -- I'm not sure we > need a complex infra such as OpenStack). I think we're already close to this at least in terms of creating virtual machines for new services. I got one created rather easily and several others were added recently. That said a Debian cloud for short-lived Debian tasks is still an interesting ideas, possibly in relation with PPA and having the possibility to rebuild packages against a PPA. > > Q1. How much should we push for Debian services (services useful to > > Debian) to be hosted on Debian infrastructure? > > Fragmentation in terms of hosting is harmful, and we should all try to > get our services hosted on Debian infrastructure, because that's the > easiest way to ensure that the maintainance of such services can be shared > or transferred between developers. > > Now, for some services, it seems that doing this has become so hard that > it harmed the service itself, and badly demotivated the service > maintainers. I don't think that we should allow that to happen. We should > stay open to other hosting solutions, when this is necessary. Having stuff hosted on DSA-managed hardware seems like something important to me. That said we can't force all services to be ready to meet DSA's requirements from day 1. So my suggestion would be have DSA allocate VMs to host services in incubation and keep those services in the .debian.net umbrella until they are ready. There's always going to be exceptions (stuff needing so much resource that it's unrealistic to allocate them out of the current hardware pool) but that's OK. Those can be dealt on a case by case basis and are likely to benefit from early interaction with DSA. > > Q2. Should we seek other hosting opportunities to ease Debian services > > development and hosting? Should I authorize the use of Debian money to > > fund infrastructure not managed by DSA, in the case of a useful service > > that DSA has been unable to accept in the infrastructure it manages? > > For services development (something for which we don't have a good > answer yet), I think that we should explore getting specific sponsored > hosting. As you know, Amazon provides Debian with free credits on the > AWS Cloud. Those credits are normally used for archive rebuilds, but > have already been used by a GSOC project (PTS rewrite), and more > recently, to start work on an archive-wide autopkgtest setup. A few more > virtual machines could be accomodated, and I will investigate if we > could extend that even
Re: Debian companies group
On Tue, 03 Sep 2013, Michael Meskes wrote: > On Tue, Sep 03, 2013 at 11:12:12AM +0200, Paul Wise wrote: > > I didn't really understand your proposal, it was missing the "What?" > > section. What do you intend to change apart from the description of > > the debian-companies list? > > It is not just the description but the subscription policy that is changed. > But > my goal is to get some feedback about the idea in general as it hasn't got > much > traction so far. If there is no interest from companies we can simply close > the > list. But if there is we should start talking. I fear that a single post on debian-project is unlikely to reach the aforementionned companies. You should see with the Debian Press team if you can send out a news on debian-news@ and maybe relay the information in other places too (blogs, journalists, etc.). Or maybe you can ask the Debconf sponsorship team which probably has a few contacts with companies that would fit. That said I have never been a big fan of the restrictive policy on that list. I'm ok for it to not be public. But I don't understand why interested DD aren't allowed to subscribe to it. I also don't understand what the minimum size requirement brings. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130903133219.gc30...@x230-buxy.home.ouaza.com
Re: LaMont Jones, WTH are you doing?
Hi, On Wed, 06 Feb 2013, LaMont Jones wrote: > On Wed, Feb 06, 2013 at 11:33:39AM -0700, LaMont Jones wrote: > > mergechanges is responsible for the differences you're seeing: > > dpkg-source is run (yes, on an ubuntu system), and then binaries are built > > on a system that is running sid, both amd64 and i386 binaries, since at > > least one of those buildds has bitten me with bad binaries in the past. > > The results are then merged, signed, and uploaded. > > That is, dpkg-buildpackages -uc -us -S is run on the source-holding (ubuntu) > system, You should not trust that. dpkg-dev has multiple parts which are behaving differently depending on the vendor of the host system. It's trivial to keep a sid chroot around which shares /home with your main system (with schroot) and I would advise to build your source packages there too. (Or at least you should override the vendor with "export DEB_VENDOR=debian" in the shell where you build your source package but it's easy to forget it) Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- 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/20130207075551.ga11...@x230-buxy.home.ouaza.com
Re: DEP 12: Per-package machine-readable metadata about Upstream
On Thu, 03 Jan 2013, Paul Wise wrote:
> > The source package control files and some of their derivatives are
> > currently
> > used to document the URL of the home page of the work that is packaged
> > ("upstream"). However, this approach is hard to extend to other
> > information
> > describing upstream, because the size of the control files has to be
> > limited
> > according to the limited power of some systems running Debian.
>
> This DEP-12 seems to exist because of this assumption. Is it true that
> everything from debian/control must end up in the Packages files?
No. Currently all fields ends up somewhere (either in the .dsc and thus in
Sources, or in the .deb and thus in Packages, or in .changes) but this
doesn't have to be that way.
Where fields ends up is controlled by Dpkg/Control/Fields.pm (in
libdpkg-perl), more precisely by the "allowed" key in the huge list of
hash in that file.
It should be possibleto have only CTRL_INFO_(PKG|SRC) in that value and
not have it copied anywhere.
> debian/upstream is to contain a Homepage, should we move the Homepage
> from debian/control to debian/upstream and thus out of Packages?
No, Homepage is an important information that can be used as identifier as
well. I'd like to keep it in .deb files and thus in Packages to be
coherent.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Get the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/
--
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/20130103072801.gc28...@x230-buxy.home.ouaza.com
Re: Diversity statement for the Debian Project
On Fri, 06 Apr 2012, Enrico Zini wrote: > I love how this is increasing in awesomeness as it is decreasing in > size. Indeed. > I feel like suggesting two minor patches, labor limae if anything: > > s/contributions to Debian/contributions/ > s/expertise in other areas/expertise in other areas,/ > s/welcome such contributors in our community/welcome them in our community/ > > which would give: > > > While much of the work for our project is technical in nature, > > we value and encourage contributions from those with > > expertise in other areas, and welcome them in our community. Yes, it looks better with those small fixes. Thank you Francesca! Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20120406060455.ga30...@rivendell.home.ouaza.com
Re: Diversity statement for the Debian Project
On Tue, 27 Mar 2012, Jose Luis Rivas wrote: > If is proposed to GR as it is written now, I will most probably vote > against it too. I thought the diversity statement was to let everybody > know they were welcome to work in the project, not that they have to > think in certain way nor we will have yet another document telling us > how to behave (I have enough of that with my country laws). I fail to see where the diversity statement dictates your behaviour or your thoughts. It just says "we welcome everybody" pointing out some of the differences that by themselves can't be ground to be excluded from this welcoming attitude. Yet at the same time we reaffirm that people who join should be committed to be constructive towards our common project of building the best free OS. Cheers, -- Raphaël Hertzog ◈ Debian Developer Pre-order a copy of the Debian Administrator's Handbook and help liberate it: http://debian-handbook.info/liberation/ -- 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/20120328063124.gc16...@rivendell.home.ouaza.com
Re: Reminder: Debian FTPMaster meeting
Hi, On Wed, 16 Mar 2011, Joerg Jaspert wrote: > multi-arch implementation, see > http://lists.debian.org/debian-devel/2011/02/msg00504.html On Wed, 16 Mar 2011, Steve Langasek wrote: > On Wed, Mar 16, 2011 at 11:44:46PM +0100, Joerg Jaspert wrote: > > Compared to my last post about this meeting, we did rework our agenda a > > little bit, so it currently reads like the stuff I paste below. We > > guarantee nothing from it, but we try to at least have a few short words > > about each. Well, a report after the meeting might tell you more what we > > got from it. :) > > multiarch doesn't seem to be mentioned here, did it not make the cut? You missed it. See above. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110317072039.gi2...@rivendell.home.ouaza.com
Re: Reminder: Debian FTPMaster meeting
Hi Jörg, On Wed, 16 Mar 2011, Joerg Jaspert wrote: > Compared to my last post about this meeting, we did rework our agenda a > little bit, so it currently reads like the stuff I paste below. We > guarantee nothing from it, but we try to at least have a few short words > about each. Well, a report after the meeting might tell you more what we > got from it. :) I saw you included most points raised but nothing about XZ support (even though it's a relatively small item in term of work compared to the rest). I had raised it here: http://lists.debian.org/debian-devel/2011/02/msg00072.html Did you miss it or was this a deliberate omission? There have been quite a bit of discussion after my mail but the discussion showed that there are reasonable defaults compression level with XZ that do not need unreasonable amounts of memory (9Mb only for decompression with level 6). Thus I believe it's perfectly reasonable to go ahead and allow XZ in the archive. I believe it's important so that we can have more useful CD1 or DVD1 by packing in there more software referenced by the tasks. Even DVD1 is no longer enough to have all tasks... Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20110317071918.gh2...@rivendell.home.ouaza.com
Re: What is annoying in the flattr buttons?
Hi, On Fri, 12 Nov 2010, Tshepang Lekhonkhobe wrote: > It's not begging in a sense that someone IS doing some work. It's more > like "use this thing that I produced, and if you want, you can reward > me with a few cents". There simply is nothing distasteful about that. > In fact, I find it courageous, considering the taboo surrounding > money. OTOH, a beggar doesn't provide any service at all. Tshepang, I appreciate that you like my "courage" and my willingness to try new things, but we're speaking of feelings that some people have. You're not going to change those by telling them they are unfounded. It's good that they are expressed (as long as they are not turned as personal attacks) so that we can take them into account and try to avoid bad feelings when possible. There are also topics where we must accept to disagree and be able to move on nevertheless because they are unrelated to our main mission of building a free operating system. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101112155624.gb23...@rivendell.home.ouaza.com
Re: Please draft a policy for planet.debian.org
Hi, (I'm hert...@d.o and not b...@d.o) On Thu, 11 Nov 2010, Joerg Jaspert wrote: > What Can I Post On Planet? [...] > - Be very careful including material from external sites (ie, not your >own blog/domain). The occasional picture from elsewhere is fine, but >anything that can be (or is) used to track reader's behavior >(commonly called webbugs[2]) is considered bad and grounds for >exclusion from Planet. If you regularly need external content, >consider providing that from your own site. This is not in the current policy. I understand and accept that you might decide to not want them on planet.debian.org but then I believe you should filter them on the planet side. I think I have the right to have them in my RSS feed and planet should not be a tool to impose any point of view about the topic of privacy on Debian contributors. We have agreed to build free software together, not to fight against privacy issues in personal blogs of individual developers. They are not too difficult to identify: strip 1x1 images hosted on another domain than the blog article, and images from the major offenders (http://feeds.feedburner.com in my case). Russ said that 4 domains cover 95% of the cases. Note that many blogs hosted on wordpress.com have webbugs as well and I don't know if they can disable them. FYI, I changed my footer to not include the Flattr image and the social button instead I've put a textual link. I will continue to use feedburner however. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/2010224329.gb17...@rivendell.home.ouaza.com
What is annoying in the flattr buttons?
Hi, On Mon, 08 Nov 2010, Holger Levsen wrote: > since a while, we see unsolicted commercial links and images on planet, > mostly > about flattr. So it's now clear that this thread is only about flattr buttons. Quite a few people explained that they are (at varying level) annoyed by them. I would like to know _why_ those buttons annoy them. To get a clear feedback I'd like to setup a poll (with selectricity.org) so that people who have chosen to put those buttons can decide what to do (or not). It's going to be a condorcet-based poll where you have to rank the following statements: I'm annoyed by Flattr buttons because * The picture catches the attention too much in a post which contains only text. * The picture allows Flattr to gather statistics about me. * Debian contributors should not make money from posts syndicated on planet. * I believe Flattr is a bad micro-donation system and it should not be promoted. * The button indirectly promotes a service run by a private company unrelated to Debian. * I don't share the concerns quoted below. (i.e. NOTA) Are those sentences correctly representing your concerns? Are there other concerns to add? Thank you for your help. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101110194522.gb6...@rivendell.home.ouaza.com
Re: commercial spam on planet
Hi, On Wed, 10 Nov 2010, Stefano Zacchiroli wrote: > My next question for you (assuming you accept that a discussion on this > list is enough to decide on this matter---I personally do) is whether > you find that my summary of this thread, given in my former post, is > fair or not. I don't know on what your summary is based. Looking at the replies, we have about 50% persons that wants to filter it and 50% that don't mind keeping them. In this thread, the percentage of people annoyed by the image might be above 50% but some have expressed that it would be less of a problem if it was a picture hosted on the blog (and not on api.flattr.com) or if it was a plain text link. But then I think that this kind of thread mainly gathers interest from annoyed people and that the persons concerned by the complaint prefer to stay away because they have nothing to gain from the discussion. Your summary was: > Moving forward from my personal view and trying to summarize this > thread, I'd say that most of the participants are OK with sporadic usage > of this kind of "spam", but that it is not quite welcome that it becomes > a habit. That's not really a summary, it's a try at a compromise. Let me also remind you that we're speaking of a small footer added automatically to the RSS feed. It's either activated or not. It's not going to appear from times to times only. Your summary is okay if we're considering posts whose sole content is "You know, I'm on Flattr. Please flattr me...". Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101110162440.gb5...@rivendell.home.ouaza.com
Re: commercial spam on planet
Hi, On Wed, 10 Nov 2010, Stefano Zacchiroli wrote: > I'm not particularly happy with the 'flattr this' buttons either. My > main problem is that I find quite difficult to avoid interpreting them > as DMUP violations, specifically about DMUP point "don't use Debian > Facilities for private financial gain". It's a very gray area, so I'm > not saying they are DMUP violations (as it's not up to me to judge > that), but I do think those buttons are quite borderline with respect to > one of the principles that DMUP is trying to defend. From this point of > view, blog posts recommending other things to flattr seems way less > problematic (maybe a bit ironically). Are you going to ask DSA to rule this? AFAIK the DMUP rules were meant to avoid problems that DSA would have to deal with (either legal problems or supplementary useless work). I don't think that the presence or the absence of a flattr button/link is going to make any difference in terms of workload to DSA. It's also clearly not a legal problem. However someone hosting a shop on http://people.debian.org/~foo/ or selling access to a private repository/service that he would setup on a debian.org server is clearly concerned by this rule. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101110152046.ga6...@rivendell.home.ouaza.com
Re: commercial spam on planet
On Tue, 09 Nov 2010, Joerg Jaspert wrote: > > For some value of "any". Planet has a big audience, articles are seen by > > more than 3 persons so it's difficult to speak for them. > > How do you get that number? Feedburner statistics. But I was wrong, it's not that many. That numbers includes also Planet Ubuntu and any RSS reader (it's the number I gave in [1]). I looked it up and my post popular article has been "viewed" 13000 times through http://planet.debian.org or http://planet.debian.net so this is without people following Planet via RSS. But a given article might be viewed multiple times by the same person given that everything is on the same webpage on planet.debian.org and that you load the pages regularly if you follow it from the web. But it's still a number which is largely superior to the number of developers. [1] http://raphaelhertzog.com/2010/10/25/secret-figures-of-a-debian-ubuntu-blogger-what-you-liked-most/ BTW you complain that a flattr image allows flattr to track your browsing habits when there are many other stuff tracking you already and that are not so "visible", like feedburner. > > What do you mean with "other languages"? > > Do the non-English Planet Debian have stricter rules than the English one? > > I didnt wrote about other planets, i wrote other languages. Ok, you meant posts written in other languages are not allowed in the feed. It's not really comparable to a footer, but ok I understand what you meant. On Tue, 09 Nov 2010, Philip Hands wrote: > How about making the planet disarm all links that point elsewhere than > the same domain as the blog post that contains it? Perhaps a little > too draconian? IMO, it's too draconian, indeed. Even if you restrict this to picture. Exactly the same problem exists with HTML mails and many mail-readers don't load pictures by default for this reason. While I can understand the privacy concerns, and while I support that Debian provides software that by default protect the privacy of users, I don't think that Debian needs to have an official policy on this topic as far as Planet Debian is concerned. When you're reading blogs or any web page, you know that you leave many traces and it's a choice of the user about how much to accept, by using or not the extensions that are meant to mitigate this problem. BTW, I would be happy if I could self-host a feedburner like service to gather my stats and avoid leaking that information to third parties. But AFAIK there's no free software doing this currently. And I don't want to write it myself. And I need this because I'm trying to be professional about my blogging activities and I need figures to see how my articles are doing and whether I'm on the right track or not. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101109094140.gb29...@rivendell.home.ouaza.com
Re: commercial spam on planet
Hi, On Mon, 08 Nov 2010, Joerg Jaspert wrote: > You should be. *IMO* your posts are VERY annoying with the "support my > work, give me money money money" below them, sometimes very much looking > to be written just to spread another round of flattr links. > Might not be the intention, but feels like it to me. I am definitely trying to build an audience for my blog. But I try to do it by writing interesting content (both for users and for contributors) and hoping that people share those articles and that people subscribe to one of the ways to stay in touch afterwards (and in particular my own newsletter). While earning some money with Flattr is nice, it's definitely not (yet?) a good way to compensate for the time spent (from Flattr I get around 25 EUR per month for my blog articles, and I spend at least 2 hours per article written). So no, earning money with Flattr is not the main motivation behind my articles. > > I even encourage users to use flattr to support free software with one > > blog post per month. Is this spam according to you? > > Do it once in a while for whatever other project and there is not much reason > to complain. I don't understand. I have recommended 5 projects using Flattr every month and they were all unrelated to me. And even if you don't use Flattr, those posts can be interesting since they introduce you some free software that you might not know and that you might want to try out. > > What I do is to provide a link for people that like my posts to support my > > work. It's not very intrusive IMO. > > Its very much jumping into the view of any planet reader. For some value of "any". Planet has a big audience, articles are seen by more than 3 persons so it's difficult to speak for them. If you look around on the web, you will find that adding a small footer in the RSS feed is a common practice at least to add link to social sharing services. There's a balance to find, I dislike when people put google ads in their feeds, or when they put 5 auto-generated links to "related articles" that usually are not so related anyway. I'm ok when they put social links (including flattr buttons) or a custom text snippet. On Mon, 08 Nov 2010, Joerg Jaspert wrote: > On 12293 March 1977, Holger Levsen wrote: > > > I think we as a project should not tolerate such, agree so, and provide > > simple > > filter mechanisms, so that people can continue to have these links in > > _their_ > > blog posts, while they are filtered out on http://planet.debian.org > > No. I would want it to be the same as with other languages - the feed > owner is responsible to provide a feed that is clean of this. What do you mean with "other languages"? Do the non-English Planet Debian have stricter rules than the English one? I tried to look up but did not find anything on http://wiki.debian.org/PlanetDebian or http://blog.ganneff.de/blog/2008/12/21/planet-i18n.html > > How much spam do you find tolerable? Would it be ok if I sell advertisment > > space on my blog and syndicate this to planet? You know, I need to eat > > too... > > Its on a debian resource, so the DMUP can hold up. Dont make money with > Debian resources. Obviously with flattr you make. It's not obvious, the fact that Planet syndicates content doesn't mean that my articles are a Debian property. I have the right to make money from my freely-available content. Also I am making money by net-installing Debian from Debian-owned servers (for my customers), is this a DMUP violation? I don't think so. In both cases, Debian resources just forward "content". > There is a very big grey area though. What about someone writing a book > about Debian? Someone doing Debian for paid work and blogging about it? > They get money from it -> not on planet? > No. Great to hear that, I'm likely to be concerned by both your examples. :-) > I think it depends on the amount of it. A one time "hey, i wrote this > book" / "hey, im on flattr, in case you care..." and such should be ok. > Regularly having this at every post -> not. If it's the main content of every post, I agree with you. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101109074619.ga22...@rivendell.home.ouaza.com
Re: commercial spam on planet
Hi, On Mon, 08 Nov 2010, Russ Allbery wrote: > Where I personally draw the line is that I'm fairly comfortable with > Debian-involved people advertising their own services on Planet Debian: > their own companies, their own consulting services, their own posts, and > so forth. I would start getting very annoyed if syndicated blogs > contained advertising for third parties. I agree with the general logic but you can't apply this rule blindly. You post book reviews from time to time, so you're advertising products of third parties. I find those OK. And they would still be OK for me even if you provided affiliate links to amazon as part of those articles. Somehow you need to take into account how often this happens, whether the article provide value for a majority of planet readers, etc. It's difficult to set a clear limit. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101108203132.gd26...@rivendell.home.ouaza.com
Re: commercial spam on planet
Hi, On Mon, 08 Nov 2010, Holger Levsen wrote: > since a while, we see unsolicted commercial links and images on planet, > mostly > about flattr. This definition does not make it clear what you're targeting. Can you be more precise? Since I use flattr I wonder if I'm concerned. I even encourage users to use flattr to support free software with one blog post per month. Is this spam according to you? > I think we as a project should not tolerate such, agree so, and provide > simple > filter mechanisms, so that people can continue to have these links in _their_ > blog posts, while they are filtered out on http://planet.debian.org I don't agree in general. I fail to see how this helps towards our goal of creating a free operating system. As far as I am concerned, I like to be reminded that another Debian contributor is using Flattr and that I can use this to support his work. I also like to read about any commercial venture that contributors have started (like branchable.com by Joey Hess and Lars Wirzenius). > How much spam do you find tolerable? Would it be ok if I sell advertisment > space on my blog and syndicate this to planet? You know, I need to eat too... I would object to google adsense inserted into the RSS feed. It's really noise. What I do is to provide a link for people that like my posts to support my work. It's not very intrusive IMO. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20101108201748.gc26...@rivendell.home.ouaza.com
Re: Debian training and code review
Hi, On Tue, 21 Sep 2010, Henri Le Foll wrote: > I have seen that Raphael Hertzog has written a blog entrie about conffile > so I have created http://wiki.debian.org/Training This article is more oriented towards users than towards contributors. But I have other articles that are interesting for contributors: http://raphaelhertzog.com/tag/packaging/ I updated the wiki page. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100930193537.gg18...@rivendell.home.ouaza.com
Re: FTPMaster meeting minutes
Hi Joerg, thanks for those minutes, they were very interesting. I like that you're working on integrating more stuff on the main archive. It's definitely better than to have many separate archives. I do hope backports will be a suite on the main archive at some point. I have one comment and a question. On Thu, 23 Sep 2010, Joerg Jaspert wrote: > 15. control-suite sanity > Right now there is no sane version checking done when we import new > data into a suite using c-s. This means that in theory the release > managers could put packages/versions from any suite into testing > (say, an oldstable version into testing, an experimental version > into testing), completly violating any version constraint the suites > have when processing uploads. > This is currently solved/worked around by having a very big > (virtual) hammer flying above the release/volatile peoples heads - > should they ever make use of this capability and take version from > elsewhere than the allowed source suite the import process would be > stopped by us until we have all code changed to fully check it. I can see the need of those checks as safety guards. They would be set up on request of the people who decides of the policy... but why do you present this as a hammer above their heads? If they're in charge of the policy for a suite, they get to decide what goes in, no? Anyway, I was wondering if there's some documentation about this interface or if there's only the source code. I will have to look into this for the CUT related suites so I might well just ask for a starter. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100924080850.gd5...@rivendell.home.ouaza.com
Re: Heads up for Debian Installer (Re: Debian Project mourns the loss of Frans Pop)
Hi, On Thu, 02 Sep 2010, Andreas Tille wrote: > I admit that I personally can not spend the (spare) time which is needed > to work on or even lead a project like debian-installer but I would like > to raise the awareness of people here by showing the figure above that > especially in freeze time a new leader of the installer team is needed. Otavio Salvador is the current release manager for d-i since quite some time. So we don't need a new leader. That said the team can always benefit from new volunteers. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100902184253.ga7...@rivendell
Re: Debian accepting Social Micropayment?
Hi, On Tue, 17 Aug 2010, Steffen Möller wrote: > there is a new advent on the Internet horizon which is the social > micropayment. Regular web users pay in some money and distribute that > with respect to their clicks in the web. I feel that Debian should > somehow participate with that, i.e. we should have links whenever we > display a package in the bts or in the pts, that allows the user to > "flattr" or otherwise support that package. The amount collected should > then go to upstream. Maybe we should not do this for all packages but > only when upstream asks for it. I don't think we should do that. But Debian might want to use Flattr to collect donations of Flattr users (but those donations would be for Debian itself). See thread on debian-www: http://lists.debian.org/debian-www/2010/07/threads.html#00086 We should not put Flattr buttons everywhere, only in the usual donation page. That said I plan to write a software that scans the installed packages, and propose to flattr the corresponding upstream projects that are using Flattr. This would be a part of the Flattr Foss project (http://raphaelhertzog.com/flattr-foss/). Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- 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/20100817192233.gb24...@rivendell
Re: Problems with NM Front Desk
On Tue, 06 Jul 2010, Felipe Sateler wrote: > On 06/07/10 10:09, Patrick Schoenfeld wrote: > > > AFAICT, none of this justifies silently removing someone from the NM > database. I can't speak for the NM team, but if he was asked to go through DM first (and that's what I understood), I could understand that his NM application got removed for now. Don't attribute it to malice. Cheers, -- Raphaël Hertzog Follow my Debian News on http://RaphaelHertzog.com -- 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/20100706191100.gd12...@rivendell
Re: A team to grant rights on collab-maint?
On Tue, 15 Jun 2010, Enrico Zini wrote: > On Mon, Jun 14, 2010 at 12:45:32PM +0200, Raphael Hertzog wrote: > > > Now I would like to stop dealing with those requests and thus I would like > > a team of people to replace me. > > Do you have a way to know what percentage of non-DDs who can commit to > collab-maint are DMs? In fact I can somewhat estimate it: https://nm.debian.org/dm_list.html gives 118 DM https://alioth.debian.org/project/memberlist.php?group_id=30755 gives 312 members So the % of DM is likely below 40%. But the alioth group contains some DD who are still using their former -guest accounts so the real figure can still vary quite a bit but I expect not by that much. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100624133842.gb18...@rivendell
Re: A team to grant rights on collab-maint?
On Tue, 15 Jun 2010, Christoph Berg wrote: > Why not automatically include all DMs in the collab-maint group? No objection from me. But I don't know how to map DM to alioth accounts. > And to drive the idea further, what about a public-maint group that > everyone with an alioth account can commit to? That sounds like an > interesting experiment to see if random people generate good commits > or tend to screw things up. (There's still someone who need to do the > actual upload. I'd hope they do review changes.) Setting an ACL and/or changing permissions to 666 is easy to try, but: 1/ we don't like world-writable files on Alioth (they are scrutinized by the admins) 2/ in practice collab-maint is not far from that given that I grant access almost automatically if they are already part of another project I'm pretty sure you would have the same result than with collab-maint (no problems in practice). > If there's still too many legitimate (non-DM) requests to join > collab-maint, that sounds rather like a problem with the definition of > access than a executive body deciding on individual requests. It's true that the best solution would be that all DD can add -guest accounts to collab-maint (very much like all DD can sponsor packages for the same set of persons). But adding all DD as admins of collab-maint is not a solution for this (getting every request to join mailed to all DD is clearly counter-productive). Even better would be a dedicated service where all DDs can request a VCS for any package and where they can control the ACL package by package. With most distributed VCS repositories this is already the case but requires setfacl knowledge which really limits the usage of this feature (and it gets complicated when multiple users already own files in the repository). Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100615140510.gd21...@rivendell
Re: A team to grant rights on collab-maint?
On Tue, 15 Jun 2010, Enrico Zini wrote: > On Mon, Jun 14, 2010 at 12:45:32PM +0200, Raphael Hertzog wrote: > > > Now I would like to stop dealing with those requests and thus I would like > > a team of people to replace me. > > Do you have a way to know what percentage of non-DDs who can commit to > collab-maint are DMs? I should be able to extract a list with the associated email (I think the email is not public) and maybe you can then use that to look up the email in the DM keyring, but I don't have any easy solution to generate this statistic, sorry. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100615125244.gc21...@rivendell
Re: A team to grant rights on collab-maint?
Hi, On Mon, 14 Jun 2010, Xavier Oswald wrote: > > Is there an existing team that could take this responsibility? [2] > > Are there volunteers for the task? > > Why a team ? People volunteers registered as Admin could do the needed job > right ? I asked for a team because it would not be unreasonable to have it handled by people dealing with NM or DM. But a distinct set of people is of course a possibility. > I think if we could be 3 or 4 DDs, it could be nice, well handled and will not > take that much time for each DD. Actually the "request to join email" generated by FusionForge is sub-optimal and makes it somewhat painful to coordinate the work, maybe you want to try to get this fixed too... :-) https://alioth.debian.org/tracker/index.php?func=detail&aid=304644&group_id=1&atid=21 https://alioth.debian.org/tracker/index.php?func=detail&aid=311882&group_id=1&atid=21 Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100614143037.gb29...@rivendell
Re: A team to grant rights on collab-maint?
On Mon, 14 Jun 2010, Jeremiah Foster wrote: > > Are there volunteers for the task? > > I would be willing to volunteer as part of a team. I work with the > debian-perl team and find that group maintenance and co-operation makes > things function quite smoothly. I would like to mention I am not a DD > (yet), but have never found this to be a problem when contributing to > Debian. Given that that the task is administrative and consists of a quick "trust check", I'd prefer if it could be handled by Debian Developers since that is the trustable set of people (according to our current structure). Somehow I believe it should fall under the responsibiliy of the NM team since it's a first step where we grant access to resources before even becoming DM. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100614115454.ga27...@rivendell
A team to grant rights on collab-maint?
Hello, ever since I created the Alioth collab-maint project [1], I have been adding non-developers to the project so that they can work together with other DD (sponsors) on a common VCS. 359 requests have been approved since 2005, it currently amounts to 5 to 20 requests every month. The threshold for acceptance is very low: - I verify that they want to join for a valid reason (want to maintain their package there, want to help a maintainer that host packages there) - if they don't give a reason in the request, I verify if they are part of other teams on Alioth, if yes I grant the access because someone else already has had contact with him, otherwise I reply to the mail and ask for more information (and reject if I get no proper answer) And I must always reject a couple of requests by DD that don't know that they already have write access through ACL. This project started for two reasons: - encourage usage of public VCS with broad write permissions (all DD) even for single packages - be able to refuse single-package project request on Alioth that would only clutter the project list when they only need some space to dump their VCS files (see http://wiki.debian.org/Alioth/PackagingProject) Now I would like to stop dealing with those requests and thus I would like a team of people to replace me. Is there an existing team that could take this responsibility? [2] Are there volunteers for the task? One thing that I never did is ping all the maintainers to know whether they are still active and still need access to collab-maint. It was indirectly done once by Tollef Fog Heen who chased -guest accounts that had the same account than a DD (usually a contributor who finished his NM process). It would be nice if the people taking over tried to do this better than me. Cheers, [1] http://alioth.debian.org/projects/collab-maint [2] Currently the Alioth admins have it somewhat. Request that are asked on #alioth are processed (using super powers of Alioth admins) but out of the Alioth admins, I'm the only one receiving the email requests because I'm the only one registered as project admin on collab-maint. -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100614104532.ga26...@rivendell
Re: PTS subscription exposure
On Tue, 02 Mar 2010, Gerfried Fuchs wrote: > This is IMNSHO a serious violation and breach of privacy. It doesn't IMO it's not. The PTS is like launchpad but for Debian and there you can see who is subscribed to each package and to each bug: https://launchpad.net/ubuntu/+source/dpkg https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/262451 See "bug subscriptions" and "subscribers" box on the right. Lucas had my blessing as PTS maintainer to expose hashed versions of the emails. > information", rather the contrary. Such changes to data that are known > and expected to be private have to get discussed *before* making them > public instead of afterwards claiming one can feel free to "raise the > topic on a mailing list". It has been discussed with the PTS maintainers and I decided it was OK for him to do that. My main concern was not exposing email to protect from spam. We're working in an open manner, I fail to see what you fear by letting people know on what you are subscribed or not. Quite on the contrary I find it valuable information for MIA-tracking, for finding possible co-maintainers, etc. Cheers, -- Raphaël Hertzog Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/ My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/ -- 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/20100302102725.ga6...@rivendell
Re: Proposing removal of pump: anyone wants it?
On Tue, 05 Jan 2010, David Paleino wrote: > while hacking on wicd, I looked at the various DHCP clients we have in > Debian. I believe that pump could be removed from our archives, but I'm > sending this mail in case anyone really needs it -- in this case, we keep it > and I'll just remove support for it from wicd. AFAIK it's quite popular in embedded context, at least I have been using it in that context for various customer projects and keeping it available just for this seems worthwhile (but I also used udhcpc in that context when I needed finer control of the resulting configuration). Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Attracting new volunteers to Debian using stackoverflow.com
Hi (quoting almost everything on purpose) On Tue, 22 Dec 2009, Tom Feiner wrote: > stackoverflow.com, which is a website featuring questions and answers on > a wide range of topics in computer programming, has just offered [1] > free advertising for open source projects wanting to advertise > recruiting of new volunteers. > > They get about 1 million page-views per day from developers, so asking > for new volunteers in stackoverflow.com will raise awareness of debian > needing new maintainers. > > What do you think? Should we offer a Debian related ad? Yes. We should also decide on which page people clicking on the ad are redirected! > Does anyone know a graphic designer or someone that can whip up a nice > ad which will attract developers to debian? Maybe pixelgirl (Agnieszka Czajkowska) could do it (ccing her for info). > [1] > http://blog.stackoverflow.com/2009/12/free-vote-based-advertising-for-open-source-projects/ > [2] http://stackoverflow.com/ > [3] http://en.wikipedia.org/wiki/Stackoverflow.com Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: squeeze release cycle?
On Tue, 10 Nov 2009, Stefano Zacchiroli wrote: > Sure, if most DDs have just took that mail as a proposal that they can > safely ignore, the release team should probably be more precise, but I > doubt the substance will be anything else than what we have now. (I also > duly notice that the release team has been heavily flamed just after DC9 > for not having stated explicitly the word "proposal", so they might have > been tempted to write "proposal" now to avoid flaming ... We're all > humans.) Sure, but they could say: “based on the input we got, we propose to freeze in march 2010. If no major complaints come up, we'll confirm this schedule in 2 weeks.” Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: squeeze release cycle?
On Tue, 10 Nov 2009, Martin Wuertele wrote: > If you're talking about the Ubuntu release team that's up to them. If > you talk about the Debian release team then I don't think so. A > proposale is a proposal not a policy. I don't get your point. How do you go from a proposed freeze date to a definitive freeze date if not by letting the RM decide it ? Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: squeeze release cycle?
On Mon, 09 Nov 2009, Manoj Srivastava wrote: > critical" bugs. That gave to nice aphorisms like "release when > ready", but did not really cater to timeliness of the releases. We are speaking of the freeze date, not the release date. > other way: Where timeliness trumps the quality. We also have release > goals; which implies that the release team likely to be looking at > other things than just dates: Release goals are not release blockers, I'm sure you know it. And luk is part of the release team, so he certainly took into account all the elements that he had. While it would be nice to have the number of RC bugs go in the right direction at the time of the freeze, it should not be a pre-requesite. When we're not in freeze, I mainly care of RC bugs on my packages or those that affect me as a user. During a freeze, I try to change my habits. I'm sure the same is true for others. Thus I believe that we should set a target date and respect it. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: squeeze release cycle?
On Mon, 09 Nov 2009, Russ Allbery wrote: > So, there was a long discussion here after Debconf about the merits or > lack thereof of a freeze date at the end of this year for a squeeze > release early next year. My general feeling of the discussion was that > there was a fair bit of opposition to freezing and releasing so quickly > after lenny, but since that's also my personal opinion, I may be > misreading the discussion. Either way, where I think we left that > discussion was with a statement that no decision had been made and the > release team and others were going to think about this and provide more > information later. Indeed, we lack a clear vision again. madduck's email on -release have also been unanswered: http://lists.debian.org/debian-release/2009/10/msg00239.html http://lists.debian.org/debian-release/2009/11/msg00022.html Luk proposed a new freeze date of march 2010: http://lists.debian.org/debian-devel-announce/2009/10/msg2.html But indeed it's only a proposal at this point. The release team needs to set a date in stone now. I'm fine with the freeze in march and it would not be too far from the Ubuntu freeze in february so that it would still make some sense wrt cooperation with Ubuntu. I also agree that we need to confirm the principle of fixed freeze date but I don't mind if we decide to freeze in fall in general and that we do it on march just this time. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
(Put petter on CC, he's probably interested by the patch below)
On Mon, 24 Aug 2009, Alexander Wirt wrote:
> Luk Claes schrieb am Monday, den 24. August 2009:
>
> *snip*
> > Why would file-rc not work properly with dependency based booting?
> you know what file-rc is doing? You have a configfile where you list your
> services and the bootlevels. So we have a configfile here. I would have to
> reorder the whole file for dependency based booting, but how can I do this
> reliable? And even if I would be able to do this, this would mean to change a
> user configuration file which is against policy.
How does file-rc handle the addition of a new init script? Does it modify
that configuration file?
Does it create that file where there is none? If yes, you could at that
point create it so that the initial list at least respects the
dependencies and leave it up to the admin for any future change.
>
> > You might want to look if insserv overrides can help.
> >
> > What is broken with the usage of update-rc.d or the debconf switch?
> a) in my eyes low is the wrong priority as it changes vital system setting
> without further notice. Also a NEWS item would be useful. Another problem is
> that the changes are not revertible.
On the other hand, low prio is the right thing to do if the upgrade just works
for 99% of the users. Ok for a NEWS item, feel free to file a bug for
this if you find it important.
If the non-revertible aspect is problematic for you, maybe you can try to
provide a patch to enhance/fix insserv's removal code?
> Removing sysv-rc ...
> Processing triggers for man-db ...
> Errors were encountered while processing:
> insserv
> E: Sub-process /usr/bin/dpkg returned an error code (1
>
> - ok there we are...
> dpkg-reconfigure insserv
> info: Disabling dependency based boot system
> mv: cannot stat `/usr/sbin/update-rc.d.distrib': No such file or directory
/usr/sbin/update-rc.d.distrib is the (diverted script) provided by sysv-rc and
since you removed it just above, that file doesn't exist anymore. Not
difficult to understand... and given that sysvinit (essential) pre-depends on
sysv-rc|file-rc, it seems natural for any code to assume this file
should be here.
Patching check_divert() in /usr/sbin/update-bootsystem-insserv doesn't
seem complicated...
--- /usr/sbin/update-bootsystem-insserv 2009-07-26 21:17:24.0 +0200
+++ /tmp/update-bootsystem-insserv 2009-08-26 09:33:43.0 +0200
@@ -76,7 +76,9 @@
;;
false)
if [ -n "$div" ] && [ -z "${div%%*by $package}" ]; then
- mv $distrib $2
+if [ -e $distrib ]; then
+mv $distrib $2
+fi
dpkg-divert --remove $2
fi
;;
Or maybe better, let dpkg-divert do the right thing:
--- /usr/sbin/update-bootsystem-insserv 2009-07-26 21:17:24.0 +0200
+++ /tmp/update-bootsystem-insserv 2009-08-26 09:36:59.0 +0200
@@ -76,8 +76,7 @@
;;
false)
if [ -n "$div" ] && [ -z "${div%%*by $package}" ]; then
- mv $distrib $2
- dpkg-divert --remove $2
+ dpkg-divert --rename --remove $2
fi
;;
status) # Return true if the divert is in effect
Both of these took me 5 minutes (they are untested though).
> This is the point where I say its broken. I would have to reinstall sysv-rc.
> Do a
> dpkg-reconfigure insserv and after that try the install of file-rc again. Hey
> this really
> can't be the way.
I think we all agree on that... but complaining is not the way to gets things
going forward.
Cheers,
--
Raphaël Hertzog
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
On Tue, 25 Aug 2009, Marc 'HE' Brockschmidt wrote: > Russ Allbery writes: > > Marc 'HE' Brockschmidt writes: > >> How is calling update-rc.d making our maintainer scripts fragile? > > It's the things that update-rc.d doesn't support directly that are a > > problem, like moving start numbers. > > True, but just using insserv will not fix this problem. As long as we > don't move away from the current update-rc.d API (which we can't in this > cycle [1]), we can also keep providing plain sysv-rc or file-rc. AIUI, the API has not changed but the numbers are no more used since insserv doesn't use the numbers to order the boot sequence... so whatever number you pick, provided that you have put the right dependencies in the init script, it should work (except for file-rc since it doesn't use dependencies) as you expect it. That's why update-rc.d is diverted by insserv, it does something different but does not required updates of all packages providing init script. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Switching the default startup method
On Mon, 24 Aug 2009, Bernd Zeimetz wrote: > No, decimal numbers are the superior design here as they just work without any > magic. One of the reasons I migrated away from SuSE long time ago was the mess > called insserv... There are reports of init script not working because they rely on some other (unexpected) initialization done by other scripts, i.e. numbers were wrong and could not be easily fixed. And there's nothing magic in the dependency based system. On Mon, 24 Aug 2009, Wouter Verhelst wrote: > On Mon, Aug 24, 2009 at 08:54:06AM +0200, Raphael Hertzog wrote: > > On Mon, 24 Aug 2009, Andreas Barth wrote: > > > We should definitly continue to support oldstyle booting, at least for > > > the time being. > > > > Until what? Missing boot-time dependencies were the only problem that had > > to be adressed to fix boot sequence ordering. > > Until we're 100% confident that the new method is working correctly, and > is not causing problems for our users. How do you get that confidence without testing it on a large scale such as unstable? It's not like he did not work on this before-hand. It has been tested but there's no way he could have tested all combinations. Furthermore all reports pointed by Andreas concerns the fact that sysv-rc/insserv can't be easily removed/replaced, all reports about actual boot failures have been worked on (at least I saw some updates made by Petter to fix some of them). > I have no problem with making it the default for new installs -- that > makes sense. However, it should still be possible for people to remove > it if they have problems with it. I don't see the value in being able to disable insserv for those using sysv-rc. I understand that Petter might want to maintain only a single boot system. I agree however that both should be removable together for those who want to use something else. > > They are relying on an inferior system and the fact that they are used to > > it doesn't change anything on its inferior design. > > What makes it an 'inferior design'? I utterly disagree with that statement. Getting the numbers right is a difficult task and as soon as you want to order something between 2 services registered with the same priority you might have to renumber lots of services since you don't know whether one service was started after another on purpose or not. With dependency based ordering, you just state the dependencies and you let it figure out the order. > There are advantages to dependency-based boot systems, sure; but there > are advantages to *not* having that, too (e.g., it is more > deterministic, and therefore easier to debug). Well, both are deterministic but they do not decide of the ordering in the same way and it's just easier for our brains to represent a number-based sequence. > Debian's had multiple choices for init scripts for a long time (file-rc > vs sysv-rc). I don't think there's any good reason to throw that out the > window. I'm not asking for that. Neither does Petter: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=538959#54 (Although that possibility of choice might disappear once we switch to a completely different system like upstart) On Mon, 24 Aug 2009, Andreas Barth wrote: > * Raphael Hertzog (hert...@debian.org) [090824 08:54]: > > On Mon, 24 Aug 2009, Andreas Barth wrote: > > > We should definitly continue to support oldstyle booting, at least for > > > the time being. > > > > Until what? > > Until we know that the new method really works 100% correct, people > enjoy the switch and we noticed that in fact the old packages are > orphaned and not used anymore. In what ways do the bug reports that you pointed out indicate that the new method doesn't work? > This is not the case. I don't know when this will be the case, but > don't expect it to be the case during the squeeze release cycle. > (1-2 stable releases I'd expect if everything works well.) Why do you expect such a long time to be needed? The work has been on-going for a full release cycle already. > > They are relying on an inferior system and the fact that they are used to > > it doesn't change anything on its inferior design. > > This is just your own personal opinion. Please do not try to enforce > your personal opinion on all of us. Thanks. Why do you believe that Petter's work will improve the distribution if you don't consider dependency based boot sequence ordering to be superior? What gains do you expect from his work? > > That's granted but it's easier to say from your place instead of petter's > > place... I for one appreciate the work that he has put in all this and > > I would highly prefer that you hel
Re: Switching the default startup method
On Mon, 24 Aug 2009, Andreas Barth wrote: > We should definitly continue to support oldstyle booting, at least for > the time being. Until what? Missing boot-time dependencies were the only problem that had to be adressed to fix boot sequence ordering. Sure administrators will have to learn tweaking init scripts dependencies instead of tweaking numbers but one always has something to learn when upgrading to a newer version. > > I think the missing point here is that insserv is just one of the ways to > > fix the problem of having to guess a correct start number, among many > > others; and any system that doesn't implement that is actually a > > regression. There are other tools similar to insserv that also do > > dependency-based booting (but AFAIK none of them are in Debian). > > So you are telling us here that anyone who depends on the 20+ years > working method of ordering boot with decimal numbers is using a > regression? They are relying on an inferior system and the fact that they are used to it doesn't change anything on its inferior design. > Please do not break something that works. Please be conservative with > changes to essential stuff. Debian is not a sandbox nor your > playground, but used on many production systems. The trust that we do > mainly sane decisions is one of our most valuable possesions. And we > should make sure we keep that trust. That's granted but it's easier to say from your place instead of petter's place... I for one appreciate the work that he has put in all this and I would highly prefer that you help him instead of complaining about his work. Your mails would have been even better accepted if you said: Petter has been working on doing X, unfortunately some problems have been discovered, it would be nice if some people could jump in and help Petter achieve our goal. Because you're giving away the message that you don't care very much of Petter's work and that you prefer staying with the old system instead of fixing the new system to suit your needs, and that's backwards. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Wed, 19 Aug 2009, Paul Wise wrote: > Also, how about the following addition to the next edition of DeveloperNews? > > === debian-devel and ITPs === > > At DebConf9 there was a discussion about making the debian-devel list > more useful. Towards that end, here is a quick reminder of the > recommendations in the developers reference 5.1[devref51]. Please do > not sent ITPs for multiple packages to debian-devel, instead, please > file the ITPs and send a summary to debian-devel afterwards. This is > especially true for multiple packages that are related in some way. > > [devref51] http://www.debian.org/doc/developers-reference/pkgs.html#newpackage > > -- Paul Wise +1 from me, feel free to open a bug report on dev-ref as well Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Wed, 19 Aug 2009, Ben Finney wrote: > "Bernhard R. Link" writes: > > > * Ben Finney [090818 11:28]: > > > Perhaps you have a better way of succinct terms to use when > > > challenging those logical fallacies? > > > > I think succinct terms help not at all here. Once there is a succinct > > term 90% of their use is name-calling. +1 on the whole message of Bernhard R. Link. You can nitpick details but I agree with the global reasoning. > > If people think something is wrong they should say what is wrong and > > not invoce some name. > > Your distinction is lost on me; pointing out that someone has presented > a logical fallacy *is* saying what is wrong. That we have succinct > labels with well-established meanings serves to more quickly communicate > what is wrong, which I would think is pleasing to you. Pointing out that one is doing a logical fallacy does not help the discussion. We all have our own paradigms to interpret arguments and there's no better common paradigm. Trying to impose one's paradigm to the whole list is what is causing us troubles. You don't have to agree with someone who is doing a logical fallacy. You also don't have to convince him that he's doing it. You can point it once in public and stop responding. If you really want to convince that person, please do so privately. > To point out what is wrong *without* using the well-known terms for > common fallacies surely leads to more volume of discussion devoted to > that, which is what I thought you were trying to avoid. This reasoning is purely theoretical. Using well known terms without explaining why you believe that this is the case here, leads to incomprehension, wich leads to answers, which leads to more mails. We de not care if one mail is 200% bigger than what it could have been if it avoids 5 replies in a sub-thread. > > But I think it would much help if the replies on the lists itself are > > about the topic, and not diverting into what are valid or invalid > > forms to produce arguments. > > As Manoj has pointed out (better than I did earlier), to *name* a > fallacious argument is merely to point out clearly that the discussion > has *already* gone off-topic, and is best interpreted as a request that > the off-topic digression be terminated quickly. It's not necessarily off-topic, it's just an argument that you don't share and that you can't refute because it's based on the personal feeling of someone else. Stating out that it's a logical fallacy will not change the feeling held by that person and will not bring the discussion further. Concentrate on parts that can be discussed and on parts where you can agree and stop obsessing logical fallacies. Manoj has a tendency to impose that all discussions must only be fact-based. While I agree that arguing should be mostly fact-based I don't see a good reason to forbid people to also express their feelings. > > I guess that is a reason why those "succinct" terms are so often used > > to throw them againt people like names-calling. > > I think your guess is wrong. I think your reasoning is wrong. Cheers, -- Raphaël Hertzog -- 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
On Thu, 30 Jul 2009, Frans Pop wrote: > Both the Etch and Lenny releases did clearly show this, and the success of > both releases (Etch more than Lenny IMO) is largely thanks to flexible > starts of the incremental freeze stages. The staged freeze has been a major pain for anyone working on the packages affected by the first stage of the freeze. For dpkg/dpkg-dev we could not go forward for almost 8 months. There's no reason why we can't freeze all at the same time (or really have very short delays between each stage of the freeze). The fixed date makes it much more easy for everybody to remember when the freeze starts and plan accordingly. Cheers, -- Raphaël Hertzog -- 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
On Thu, 30 Jul 2009, Modestas Vainius wrote: > So let's just freeze late in the early/middle spring of 2010 this time and > aim > for Dec 2011 freeze next time. If you disagree with that, please enlighten me > why Debian needs to rush _this time_. If synchronization is so badly wanted > for the next Debian release, why not to synchronize with Ubuntu 10.10 (as an > experiment)? Luk explained in the RM keynote that they do not want the freeze to conflict with debconf so that developers are free to work on new stuff aimed at unstable in this (usually productive) week. That said, I do not think that this concern alone is enough for us to rush a squeeze release and I agree that it would also be reasonable to just target a freeze somewhere in the middle of next year and leave an opportunity to cooperate with Ubuntu for their 10.10 release. It would mean that their next LTS release that would be in sync with Debian 7.0 will be 12.04 which is less than their 2/2.5 years release cycle for LTS. They can probably cope with that though. > By the way, why isn't it obvious that Debian developers _want_ to be informed > about important decisions in advance, not from the press *after* the fact or > any other source outside the project? It really depends on the decision, for example the decision to join opensource for america was taken without prior discussion and it's ok for me. But something that has such a direct impact on the work of DD ought to be discussed a bit and at least announced to DD at the same time that it's announced to the users/press... but with content that is adjusted for them so that we do not have to read between the lines (I knew the context because I was at the keynote where this has been presented but not everybody was there). Cheers, -- Raphaël Hertzog -- 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
On Thu, 30 Jul 2009, Marc Haber wrote: > On Thu, Jul 30, 2009 at 10:37:46AM +0200, Raphael Hertzog wrote: > > What we're speaking of is synergy between both distributions. You know the > > it's the principle behind “the combination of both is worth more that the > > sum of individual parts”. > > What kind of synergy could Debian get from Ubuntu which it couldn't > get in the past? I surely haven't seen any in the past. As you might have noticed, Ubuntu is used by lots of people and they start having some influence on upstream projects. Those projects do some effort to ensure that Ubuntu has a good version of their software (sometimes by using a version that does not come from Debian sid). If Ubuntu and Debian used the same version, the incentive would be even bigger to publish a really good version because it's going to be used very widely in the next 3 years. Also in many cases, Ubuntu and Debian teams can't fully collaborate because they do not target the same upstream version, freezing at the same time should make it possible to achieve this goal. There are certainly challenges to turn this possibility in a reality but if we don't do the efforts to even make it possible, we're sure to get nothing out of what would be possible. We certainly have to see whether Ubuntu is going to do some efforts to go in the same direction, but I certainly hope that they will. > > We'll keep our user base > > That's what I doubt. Ubuntu LTS will be better than Debian stable in > all aspects, why should anybody continue using Debian stable? Why are you using Debian and not Ubuntu? For me: - Debian is where we shape the future - Debian's goals/principles are in sync with my own values - Debian can be used on embedded targets - Debian is stable and more tested (even if we freeze at the same time, we're likely to release after Ubuntu with way more fixes than Ubuntu) This is not going to change and as long as that's true, Debian won't die as we will keep an active development community. I'm also quite convinced that by doing better communication/marketing that explains what we are, we can continue to attract new users and new developers. World domination does not start with "competing with Ubuntu" but with competing with all the proprietary systems out there and for this we would certain benefit from more cooperation with Ubuntu. Cheers, -- Raphaël Hertzog -- 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
On Thu, 30 Jul 2009, Marc Haber wrote: > In fact, I would prefer if Ubuntu had to change _their_ scheduled to > accomodate us, if they want to have the advantage of being in sync > with us. It's _their_ advantage after all, not ours. I don't mind who changes the date for the other but I really don't agree that doing it is only for Ubuntu's advantage. Nobody in Debian would have taken such a decision, we are Debian developers and have no interest in helping only Ubuntu. What we're speaking of is synergy between both distributions. You know the it's the principle behind “the combination of both is worth more that the sum of individual parts”. > We are not only major supplier to Ubuntu, we have our end customers > ourselves. I'd prefer that it stayed that way. The synchronization with Ubuntu is not going to remove our identity. We'll keep our user base and the possible improvements in both distributions will help us do better in the competition with other operating systems (proprietary or not). Cheers, -- Raphaël Hertzog -- 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
On Wed, 29 Jul 2009, Sandro Tosi wrote:
> bullshit! we are trading quality for what?
Please don't be so aggressive and leave some time to RM to respond to your
comments before posting more mails
> Or there's something else behind the curtains that it's not being said
> (consciously), like ubuntu LTS?
Yes, it was said in the RM keynote at debconf.
Note that the announce is meant mainly for the users/press, not for
developers.
But the idea of a press release came from the press team and not
necessarily from the RM. It would have been nice to have a simultaneous
announce for DD on d-d-a with more developer-oriented content.
> > accommodate the needs of larger organisations and other users with a long
> > upgrade process, the Debian project commits to provide the possibility to
> > skip the upcoming release and do a skip-upgrade straight from Debian
> > GNU/Linux 5.0 ("Lenny") to Debian GNU/Linux 7.0 (not yet codenamed).
>
> so, what's the point in preparing squeeze? let's just skip it then
We are not only targetting big corporations. Either we do a full release
or we extend lenny to 3 years with lenny and a half. The release team
decided for the former.
It will be difficult but I think it's worth trying. As Colin commented in
the RM keynote, a one year release requires some discipline onto us, it's
not necessarily a bad idea to force ourselves into this.
> Not to mention how many angry replies are coming, I feel the community
> of debian developers is not accepting this decision silently.
I have almost never seen a decision that was not commented... that does
not mean that it won't last. The RM are entitled to take the decision and
while I was also surprised by it, I don't intend to work against it.
And there are many other people here at debconf that feel the same. You'll
see it in the video of the RM keynote.
Cheers,
--
Raphaël Hertzog
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [OT] aggressiveness on our mailing lists.
On Fri, 24 Jul 2009, Ben Finney wrote: > Manoj seems to be emitting a great deal more typos to Debian forums in > recent years. Perhaps we should pool together donations for a better > keyboard for him? Or he should post less and take the time to review what he writes... (including the pass where he's supposed to remove the unneeded agressivity) Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Maintaining packages properly
[ Moving to -project ] Hi, context: someone proposed a scoring system like this: > x (= 10?) Important bugs are RC critical > y (= 25?) Normal bugs are RC critical On Fri, 20 Mar 2009, Patrick Schoenfeld wrote: > On Thu, Mar 19, 2009 at 02:41:46PM +0100, Vincent Fourmond wrote: > > > > Hmmm... I find that this is a good idea, but, just as you say, there > > are rather painful side effects if we apply blindly this rule. > > I think that the original idea is better. Some automatic approach sureley > works better instead of requiring someone to act on some problem that exists, > because someone obviously is unable to act properly. > Additional the so-called "side effects" are probably wanted. For several > reasons: > > 1) The maintainer(s) should really be urged to act on the bugs. Its obvious [...] > 2) If basic tools (!) have a great number of valid important bugs that > would be *very* bad. Just because tools are used more often does not > mean that a higher quantity of bugs is to be ignored. > > The maintenance of standard, important and essential packages is btw. a > topic on its own. I find it for example highly undesirable to have a > package which is basically installed on *every* Debian system to have > about 180 outstanding bugs, with 5-10 (or sometimes more) beeing > priority important or higher. Its also undesirable to never care about > wishlist bugs (which basically is what a lot of maintainers do). Creating such rules serves no purpose. Instead you should work to recruit volunteers to resolve those problems when they come up. Take the dpkg package, it currently has 396 bugs open and 13 marked important among them (and 176 normal). We had more than 500 bugs 2 years ago and it has been a _lot_ of work to get to this state. http://people.debian.org/~glandium/bts/d/dpkg.png We welcome volunteers to fix more bugs but right now only 2 persons are actively working on the code. At the current rate, all bugs will be dealt with in 6-8 years. What would your rules change to the situation ? There's a lot of work to do to help responsabilize maintainers concerning their duties but those rules would not help. I would rather that we try the "self-assessment" idea that I presented on -qa a few months ago. http://lists.debian.org/debian-qa/2008/12/msg00046.html Would you be interested to work on that ? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Creating a public list for wanna-build team? Input needed.
On Wed, 18 Feb 2009, Adeodato Simó wrote: > In #512780 (http://bugs.debian.org/512780), we've requested the creation > of a debian-wbadm list to serve as a role address and discussion umbrella > for the wanna-build team. The full rationale is in the bug report, but > the bottom line is that we've realized a public role address is better > from our past experiences with debian-release. > > Listmaster has asked us that we follow the standard procedure of getting > people to express their interest on the requested list in the bug report. > So, if you'd welcome the wanna-build maintenance team move to a public > list as their role address, we would appreciate if you could send a > quick mail to the bug report. I agree it would be useful, debian-rele...@l.d.o already started to collect binnmus request in the past and it would seem natural to me that such request (now properly directed at the wbadm team) get archived/discussed in the same spirit on a dedicated list hosted at lists.debian.org. I don't care for the precise name, -wbadm or -wb-admin both seem fine. > Additionally, listmaster has also suggested that we use a teams.debian.net > list for this purpose. I don't agree with this for the reasons stated in > the bug report. Feel free to comment on this issue as well. I agree with your reasons (it's a core d.o infrastructure) and the same reasons led me to remember you that you should really create a wiki page on http://wiki.debian.org/Teams :) Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Mon, 12 Jan 2009, Robert Millan wrote: > > This is one of the reasons why the vote was flawed; > > Again, if the vote was flawed (I don't think it was, but if the Secretary > considers it flawed), the right thing would be to cancel it. The constitution doesn't explicitely allow a vote to be cancelled. So Bdale has let it run knowing that the conclusions that could be drawn would be limited anyway. Now please stop flooding the list and get back to something more productive. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: > > Anyway 2Q is too much in my opinion. Q would be much more reasonable. > > See my reply to Bernd why I think its not. It seems like most people who responded preferred Q up to now. It might end up as an amendment otherwise. :) > > It would be also be good to add a sentence inviting the seconders to > > explain why they second the proposal. At least it would make the many > > formal mails to second proposals somewhat interesting to read > > (they could even be linked from the vote web page so that voters who have > > not taken part in the discussion can refer to the reasoning of those who > > have brought the option to the vote). > > As a must or as a should? A should would probably work. A should. There's no point forcing anyone to justify his acts, but it's better if he does IMO. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, 30 Dec 2008, Joerg Jaspert wrote: > Hi, > > I have felt for some time that the low requirement for seconds on General > Resolutions is something that should be fixed. We are over 1000 > Developers, if you can't find more than 5 people supporting your idea, > its most probably not worth it taking time of everyone. Various IRC Why are you saying 5 ? Your proposal requires 30. Recent votes have shown that some options tended to have more seconds than the others but we never reached 30. We had 17 for "Exclude source requirements for firmware" and 21 for "Invite the DAM to further discuss until vote or consensus, leading to a new proposal.". Note that with those new requirements some interesting amendments/alternate choices would not have made it in several of the votes (although different rules would have probably lead more people to second). Anyway 2Q is too much in my opinion. Q would be much more reasonable. It would be also be good to add a sentence inviting the seconders to explain why they second the proposal. At least it would make the many formal mails to second proposals somewhat interesting to read (they could even be linked from the vote web page so that voters who have not taken part in the discussion can refer to the reasoning of those who have brought the option to the vote). > only. I'm *not* calling for seconders with this mail. Thats also the > reason for the reply-to/mail-followup-to header going to -project, > please respect them. List-reply ended on both lists, I had to hand-edit the result. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
On Sun, 21 Dec 2008, Anthony Towns wrote:
> On Sat, Dec 20, 2008 at 10:35:14AM +, Jurij Smakov wrote:
> > * "Vocal minority" dominates "silent majority" by contributing a
> > disproportionate amount of list traffic, [...]
>
> Note that voting can have a similar drawback -- in that if you've got
> enough like-minded people voting for a particular viewpoint (eg, "Joe
> Random sucks, give him what for!") people with a different viewpoint
> (eg, "stop berating people, argh") aren't going to bother voting ("the
> score's already +50, why bother with a -1?"). This seems to happen on
> digg a fair bit. Probably someting to be aware of.
Contrary to digg, a discussion offers multiple opportunities to vote
because there are several messages and each one defends a particular
viewpoint.
Would it make sense to use positive rating for the content
of messages ("me too") and negative rating to tag messages which have been
too rude/impolite or even off-topic ?
That way there's no “battle” between +1 and -1 raters.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
On Sat, 20 Dec 2008, Stefano Zacchiroli wrote: > [ re-ordering the quoted text, anticipating your reply to my post ] > > On Sat, Dec 20, 2008 at 04:35:43PM +0100, Raphael Hertzog wrote: > > The goal is not (necessarily to) filter the messages that we want to > > see or not, the goal is to give feedback to contributors so that > > they know if their messages were in line or not with what people > > expect on the list. The hope is that contributors will try to avoid > > doing the same mistake once that many people pointed it out > > explicitely. > > Well, I think both are reasonable goals, aren't they? Yup. > > - having such a mechanism not only helps posters to be aware that their > > messages are causing troubles, it also helps newcomers to better > > identify the problematic contributors and they might avoid starting an > > argument with them. > > m, this is risky and an important point: do we want the > information to be publicly available or not? The initial proposal The initial mail said that clearly at least: “which simply collects the data and makes it publicly available in some way” > seemed to be more oriented to scoring single posts, while here you are > kind of inheriting a score on the poster from his posts. They are two > quite different approaches. They are different but if the data is available, it's also relatively easy to imagine ways to do that. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Voting on messages: a way to resolve the mailing list problems
Hello, On Sat, 20 Dec 2008, Jurij Smakov wrote: > and so on. The way I would like to see this idea developing is that it > starts as an unofficial project, with very simple rules (like, "you > can vote once for each message ID"), which simply collects the data > and makes it publicly available in some way. Interested parties and > individuals can then use the data to provide their own metrics (and > try to convince others that their way of calculating the mailing list > "karma" is the right one). Eventually, we should be able to settle on > one authoritative way of calculating it, which can become "official", > and used to develop procedures for warning the offensive posters that > their behaviour is considered disruptive, for example. > > I believe that at this point Nick Rusnov, John Goerzen and myself have > expressed interest in working on the first stage of the project. If > you have any ideas or comments - please share, we would also welcome > your contribution if you decide to help out with it. I agree it's worth trying (I also came to a similar proposal several times when I tried to imagine how to give feedback to people who are starting to cause troubles with their behaviour on lists). I'm not at all convinced that it will work or be useful, but I really don't have a better idea. Depending on your implementation choices, I might be able to help a bit. Keep me in the loop. Various remarks: - making data available doesn't mean that people will regularly follow them, there must be a mechanism to inform the contributor when a threshold has been reached so that they are informed that many people found their messages objectionable - classifying in good/bad is not enough, we need to be able to express what we find incorrect (personal attacks, too many replies that repeat the same thing, improper vocabulary, …) - having such a mechanism not only helps posters to be aware that their messages are causing troubles, it also helps newcomers to better identify the problematic contributors and they might avoid starting an argument with them. - later on, depending on how it works, the listmasters might want to hook up some filters on this data so that someome who repeats himself too much is blocked during 24h to post in the same list (for example) - mutt macros can be written to make it handy for us to quickly give feedback On Sat, 20 Dec 2008, Stefano Zacchiroli wrote: > Now, I like your mechanism way more than moderation, because yours is > self-regulating. Still, a problem I spotted with the shadow list also > affects your mechanism, namely: context loss. What if a very > bad/unpolite/rude/useless message gets scored down (which is quite > probable) whether a nice/constructive/ polite response to it gets > scored up (which is as probable)? People only following the "good" > messages will experience context loss receiving a reply to a message > they are missing. The goal is not (necessarily to) filter the messages that we want to see or not, the goal is to give feedback to contributors so that they know if their messages were in line or not with what people expect on the list. The hope is that contributors will try to avoid doing the same mistake once that many people pointed it out explicitely. > In a sense, it seems to me that the mechanism work properly only if we > switch in mass to it. Not sure, but it's surely more representative if many people use it. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: motivation (Re: It's all about trust)
On Mon, 27 Oct 2008, Matthew Johnson wrote: > On Mon Oct 27 20:28, Holger Levsen wrote: > > Her basic idea is, that in addictive games the first levels of success are > > easy to achieve and then it gets harder, but only so slowly so that people > > dont loose motivation. She also manages very well to carry this over to > > free > > software development and I suggest you watch it (its 45min), as she can > > really connect this much better than I can do here.) > > > > Currently, in Debian it is (still) really hard to get involved and part of > > the > > project (though to be fair, it's perceived even harder than it is). DM was > > a > > good step in the right direction and we should keep that direction, not add > > too many levels of access, priviledges and buerocrazy. > > Surely the multiple levels are the point she is making? By having > multiple levels of access and/or privileges you can slowly give them out > and make the early ones easier to attain. The reason for creating > posts/roles/statuses which are more restricted than full access is that > you can make it correspondingly easier to be granted them and therefore > they can be used to help people not lose motivation before they manage > to get the full access. In case it's not clear, I agree with Matthew and it's the underlying logic of my proposal. I don't know what is bureaucracy in the eyes of Holger but at this point most of the "conditions associated to privileges" are not set in stone and everyone can suggest what would be reasonable without falling in the trap of the bureaucracy. For now, I have suggested something similar to DM where the decisions are taken only based on advocations and peer-review and I don't know how to make it more light-weight while still getting the required confidence in the contributor's skills. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On Mon, 27 Oct 2008, Lucas Nussbaum wrote: > On 27/10/08 at 16:40 +0100, Raphael Hertzog wrote: > > On Mon, 27 Oct 2008, Lucas Nussbaum wrote: > > > > - this process might be too heavy with fine-grained privileges as it > > > > would > > > > require the intervention of many DD each time we have to grant a > > > > right > > > > (when trusting the decision of 2 members with special rights would be > > > > enough). > > > > > > That's why I don't think that it's a good idea to play with a lot of > > > different privileges. Privileges should be granted when they are > > > necessary to do something, and if you are a DD, you should be able to > > > easily get any privilege you need to do your work. You are already > > > trustworthy, so there's no need to double-check everything you do. > > > > If I advocate someone based on some perl modules, I trust him to handle > > any perl modules reasonnably well but I certainly don't trust him to > > package a new library. I do trust some people to refrain from doing stupid > > things with their DD powers but that kind of trust comes with much more > > time and interaction. It's not the kind of trust that I would give to > > anyone that has only proven that he's able to package perl modules. And > > yet we want to give that contributor some immediate reward for his work. > > If someone is only trustable to package perl modules, shouldn't he be a DM > instead of a DD? We might want him to be able to package new perl modules on his own? Where do you draw the line? If you maintain 20 or 50 perl modules? Note that my proposal doesn't change much to that problem except that when one gets granted the extended rights for this specific reason, that pseudo-contract between the community managers and the contributor would/could be more explicit and the contributor would be informed that we expect him to go through sponsors when he decides to package something else than perl modules. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
On Mon, 27 Oct 2008, Lucas Nussbaum wrote: > > - this process might be too heavy with fine-grained privileges as it would > > require the intervention of many DD each time we have to grant a right > > (when trusting the decision of 2 members with special rights would be > > enough). > > That's why I don't think that it's a good idea to play with a lot of > different privileges. Privileges should be granted when they are > necessary to do something, and if you are a DD, you should be able to > easily get any privilege you need to do your work. You are already > trustworthy, so there's no need to double-check everything you do. If I advocate someone based on some perl modules, I trust him to handle any perl modules reasonnably well but I certainly don't trust him to package a new library. I do trust some people to refrain from doing stupid things with their DD powers but that kind of trust comes with much more time and interaction. It's not the kind of trust that I would give to anyone that has only proven that he's able to package perl modules. And yet we want to give that contributor some immediate reward for his work. Am I missing something here ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: It's all about trust
Hi, thanks for your comment. For reference, people might not have noticed but my initial mail was not only a reply to liw's mail but a real alternative proposal. BTW, I added some further explanations on my blog: http://www.ouaza.com/wp/2008/10/27/debian-membership-reform/ On Mon, 27 Oct 2008, Lucas Nussbaum wrote: > What you want to do is to create a small group of DDs, called "Debian > Community Managers", that would have super-powers and be able to manage > the rights of other DDs. It will start small but it might get rather large if we have a real set of developers that trust each other enough to be able to follow the (predefined) rules to distribute the rights. And I believe that we have such a set of developers. > Something I really like in Debian is that it tries to keep everybody at > the same level. Sure, some people have special privileges, but they are > usually necessary to accomplish special tasks, and those tasks are often > not very fun ones. Well, it's true that the "same level" that is shared would be somewhat lowered but as this level includes the right to vote and to propose GR I don't think that it's a real problem in term of fairness as people could always get the rule changed or have their say in the orientation of the project. > Your proposal changes that, by creating a group of super-DDs who > wouldn't have any special task to do, except exercise their super-DD > powers. That sounds like a perfect role to have for power-hungry people, > but also like something that could create huge feelings of unfairness, > jealousy, etc. They have a task: ensure we don't loose confidence in the quality of the work done by our volunteers. They are not alone working on this but the fact that they would control privileges distribution would give them a special role on this. Power-hungry might well be interested by this role but when 20 other people have the same power, you really don't gain much with your power. Unfairness is difficult to avoid as all human judgment have a subjective part… but I don't see why this would be exacerbated with this proposial compared to the status-quo or to the N-advocations model. > Since apparently, the NM process doesn't allow people to trust new DDs > anymore, I would prefer to move to a system where trust comes from the > fact that a large number of normal DDs advocated someone (like what Lars > proposed). Several (possible) problems with this approach: - increasing the number of advocations by DD to increase the trust has a real cost. A contributor will usually have interacted with very few sponsors that can advocate him at little cost since they already reviewed his work. The other advocates will then have to review the work by themselves to gain the required confidence. Chances are rather large that we will have DD who won't do that job and advocates people just to reduce the backlog of applicants that look motivated. - finding many advocations to grant a right might be doable, but removing a right is much less fun and will never happen in practice if it follows the same rule of a "large numbers of DD" - this process might be too heavy with fine-grained privileges as it would require the intervention of many DD each time we have to grant a right (when trusting the decision of 2 members with special rights would be enough). In general, I find it more productive to have a few trustable individuals doing a serious review than to have many doing a not so serious review and trusting the advocation already done by other DD. It also cristallize better the responsibility to decide what one is allowed to do. With the current NM process it's spread over many individuals and at the end nobody is responsible if someone has gone through when he really shouldn't. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
It's all about trust
On Fri, 24 Oct 2008, Lars Wirzenius wrote: > I think we should go in the opposite direction: massively simplify > the whole membership thing. I tend to agree on the description of the situation but I would also add that we effectively have a trust problem within the project and that any reform to the membership management must solve that problem. We do have DD that are okayish at packaging what they package but that I wouldn't trust to advocate new DM/DD or that are not good enough in sponsorship or that I wouldn't trust to maintain any complex software (think library or essential packages). As such I really don't buy that all DD should be equal when it comes to technical work however I do think we have to move in the direction where we broaden our membership to new kind of contributors and that all contributors should have the possibility to request all kinds of privileges (mainly vote right, limited upload right, full upload right, right to grant privileges to others). The set of contributors with the right to grant privileges to others could be called "Debian Community Managers" and would only comprise very skilled and dedicated members. This group would replace the NM team and would grant/retire privileges according to their own judgment and a set of reasonable rules to define. The initial set of community managers would be designated by a vote. Ideally the group of community managers would evolve to cover all the main teams of Debian so that for any privilege request we have one or more members that are well placed to evaluate the work of others. All the rules would have a single purpose: keep the initial trust placed in people intact and make sure we remain the quality distribution that we are supposed to be. I'm afraid we lost that trust a few years ago while the NM process was more an academic study than an apprenticeship. Now, let me illustrate the above explanation with some examples of how all this could work in practice: - any new contributor would register in nm.debian.org and have to go through the initial set of hops to upload a gpg key and sign an agreement that she will pursue the goals of Debian and that she agrees with all the foundation documents. - she contributes in the way that is of interest for her - if she has worked on a particular package she can request upload access for this package like we do for DM currently: she needs a sponsor first (someone with full upload rights) and two advocates (they should have uploads rights to the package that she request access to), and of course she needs her key to be signed by a Debian Developer. - if she needs a shell account on specific machines that can be granted provided that she follows the requirements defined by the DSA team. - if she's already a skilled hacker and interested in generic bugfixing she could in theory immediately request full upload rights but that would be the exception at this point I guess. - when she has contributed for more than 6 months (those 6 months need not happen after the registration on nm.debian.org) she can request the privilege to be a Debian Developer. This privilege entails the right to vote and to have the @debian.org email. The community managers just make sure that the contribution is real and that she understands how to handle her GPG keys and under what conditions she can sign someone else's GPG key. - if she decides to do more transversal work on the distribution she can request "full upload rights" for this but the community managers will have to gain confidence in her ability to not screw up by reviewing several uploads that she prepared/already got sponsored. They might attach some remarks like “limited to l10n/i18n work” or “limited to perl related packages” if the access has been requested for specific tasks instead of generic (bugsquashing) work. This remark is informational only but can be taken into account if someome later complains about a bad NMU or any other problem with her work. The community managers really try to ensure hard that all people with full upload rights are aware of their responsibility when they sponsor people and when they advocate other people for a grant of some upload privilege. They also ensures that the people are either very skilled, or aware of their own limits so that they avoid touching things where they are not skilled enough. In practice, we replace DAM + Front Desk + AM by a single team where each member can do all the steps to grant privileges to any contributor provided that he can justify/document that the contributor matches the criteria defined. I wouldn't replace the keyring team because I believe that it's best managed by a limited team but its role is only administrative since the decisions are taken by the community managers anyway. The community managers would also have to deal with complaints about contributors making bad use of their privileges. Th
Re: Release notes
On Tue, 07 Oct 2008, Peter Palfrader wrote: > I need information where > debbugs Don responded, it moved to bzr: http://bugs.debian.org/debbugs-source/ http://wiki.debian.org/Teams/Debbugs > debian-openoffice $ apt-cache showsrc openoffice.org | grep Vcs Vcs-Bzr: http://bzr.debian.org/pkg-openoffice/packages/openofficeorg/2.4.1/unstable Vcs-Svn: svn://svn.gnome.org/svn/ooo-build/branches/debian-2-4-1 > debian-doc Badly named webpage (http://www.debian.org/doc/cvs) is up-to-date and gives: svn://svn.debian.org/ddp/manuals/trunk http://svn.debian.org/viewsvn/ddp/ > deity, $ apt-cache showsrc apt | grep Vcs Vcs-Bzr: http://bzr.debian.org/apt/debian-sid/ > and tetex tetex is gone replaced by texlive: http://wiki.debian.org/Teams/TeXTaskForce They don't use Vcs-* fields apparently but they use svn: http://svn.debian.org/viewsvn/debian-tex/ svn://svn.debian.org/debian-tex/ > moved to, similar to what is available from the READMEs in > /srv/cvs.debian.org/cvs/qa. Can you provide that? HTH. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release notes
On Mon, 06 Oct 2008, Peter Palfrader wrote: > On Sun, 05 Oct 2008, Cyril Brulebois wrote: > > > Raphael Hertzog <[EMAIL PROTECTED]> (05/10/2008): > > > > http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc > > > > > > This link is wrong. DDP uses SVN nowadays. > > > > Question is: why is that still available? > > Probably because nobody bothers to tell DSA when services are no longer > required. There are still 2 users of cvs.debian.org (webwml, dak/srcdep), otherwise I would have requested it to go away. https://rt.debian.org/Ticket/Display.html?id=146 But you can disable all the other modules in the web interface at least and remove write rights in all other repositories. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Release notes
On Sun, 05 Oct 2008, Charles Plessy wrote: > http://cvs.debian.org/ddp/manuals.sgml/release-notes/?root=debian-doc This link is wrong. DDP uses SVN nowadays. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fw: Debian and non-free
I was frightened by your message until I realized that it was not your message but one of Sven… please don't forward messages that you don't endorse (in particular when it contains wrong claims). > debian-multimedia.org is not maintained by debian, it is for patent > encumbered stuff, liable of a lawsuite or something such. It was done by > an ex-DD who left debian in discontent. That's simply wrong. Christian Marillat is still DD: $ finger [EMAIL PROTECTED] [db.debian.org] uid=marillat,ou=users,dc=debian,dc=org First name: Christian Last name: Marillat Email: Christian Marillat <[EMAIL PROTECTED]> URL: http://www.debian-multimedia.org/ Fingerprint: 1D7F C53F 80F8 52C1 88F4 ED0B 07DC 563D 1F41 B907 Key block: finger marillat/[EMAIL PROTECTED] Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
