Re: Salsa as authentication provider for Debian
]] Enrico Zini > On Sat, Apr 11, 2020 at 09:47:39PM +0200, Tollef Fog Heen wrote: > > > We quite regularly have upstreams getting access for weird architecture > > failures. There's no particular reason for those people to have salsa > > accounts. > > I understand those are temporary accounts. Do those cases need an > arbitrary name from the LDAP namespace? > > Several places I worked with use a pool of time-limited accounts from a > guestNNN namespace, for example: that could address your use case > without overlapping with anything else. We have guest accounts that have been in use longer than the lifecycle of some DD accounts, so while it would technically work, it wouldn't be a particularly nice solution. (You can of course say that requiring non-DDs registering on salsa to have a -guest suffix isn't nice either, something I can agree with.) > > It does to me, since suddenly we have to care about what's on salsa, > > something we've never had to care about before. > > As I said in 20200409181701.3qqsn5sqq3xbu...@enricozini.org, no, you > don't need to care about anything: you keep doing what you want, and we > deal with it. I think we in practice will want to do that in order to avoid triggering bugs in software that assumes that user names are consistent. > So far, I only received requests to keep the status quo as it is > indefinitely, and very little in terms of counterprosals actionable now, > besides theoretical new software solutions to be explored, that would > address the problems I am having. In case that was directed at me, rather than the wider world: I'm not requesting you do one thing or another, I'm pointing out some possible ramifications. It's not clear to me why removing the -guest restriction has to happen for sso.d.o to be using Salsa as an IdP, which seems to be your primary goal? That's my most immediate concern. Switching to oauth2/OIDC seems like a good idea, and assuming we can move to another broker somewhere down the line, I have no problems with that happening. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Salsa as authentication provider for Debian
]] Sam Hartman > >>>>> "Tollef" == Tollef Fog Heen writes: > > Tollef> ]] Enrico Zini > >> For guest accounts opened by DSA directly, it can be pretty much > > First, at this point in time I would be very skepticle of someone > contributing to Debian enough to need porter box access but not having a > salsa account. > It's possible, but that would be a yellow flag for me in evaluating > such a request. We quite regularly have upstreams getting access for weird architecture failures. There's no particular reason for those people to have salsa accounts. > However, as I read the guest account process, it has a number of manual > steps where people are processing tickets. > I suspect that DSA actually has a script or set of scripts that go > create the guest account. That varies. It's LDAP, people sometimes use the ud-* suite of tools, sometimes ldapvi. Is salsa also going to check for debian.org accounts when creating and renaming accounts on its side? > Having these scripts check to see if the name is registered at salsa and > requiring manual override to create an account if it conflicts with > salsa and appears to belong to a different user is not, in my mind, > making DSA's ldap subservient to the salsa LDAP. (Salsa doesn't use LDAP, afaik) It does to me, since suddenly we have to care about what's on salsa, something we've never had to care about before. It also breaks the invariant people have been able to trust so far, that foo@salsa.d.o is also foo@d.o (assuming both exist). This will no longer hold true, and I think we'll run into security problems down the line because of it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Salsa as authentication provider for Debian
]] Enrico Zini > For guest accounts opened by DSA directly, it can be pretty much the > same: you can use the current Salsa account name of the person as the > username for the guest account. I don't think we want to make the Debian LDAP service subservient to salsa's, which this effectively would. (People requesting guest accounts might also not have salsa accounts.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Salsa as authentication provider for Debian
]] Sam Hartman > There's another flow. Contributors interact with DSA in some process I > do not fully understand to get guest accounts on porter boxes etc. https://dsa.debian.org/doc/guest-account/ I'd like to see a proposal on how to avoid namespace clashes between guest and non-DD salsa accounts? (There's also the wiki account lifecycle, but that's completely separate and doesn't interact with any of the others, so we might want to keep that outside the discussion for now.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Using Debian funds to support a gcc development task
]] Ian Jackson > Such a small, essentially honorary, contribution wouldn't distort our > volunteer setup, and don't need the levels of serious review and > engagement that a larger amount does. But it would act as a tangible > way to express that we would like to see something done and might > encourage others. For me, it's not about the amount at all, but rather that we don't spend Debian money on directly paying people or use Debian money as carrots for directing effort. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Using Debian funds to support a gcc development task
]] John Paul Adrian Glaubitz > I don’t know what “m-f-t” stands for in this context, sorry. I’m on > mobile at the moment though so my phone might be messing up > things. Sorry for that. Mail-Followup-To. Don't Cc people unless explicitly requested. [...] > But that’s just your personal opinion on what the focus should be on > when supporting a good cause. Someone else could argue about more > diversity in software. We have something as the “Debian init > diversity” project after all which is also a non-commercial but a > community effort. I don't get your focus on commercial vs non-commercial here, I think you're the only person in the thread talking about commercial concerns as something that even enters the picture. > I think it’s up to every free software developer which cause they > would like to support. After all, free software also means we work on > the projects we are passionate about and not what’s commercially > viable. Sure; feel free to support the m68k porting effort as much as you want and in any reasonable fashion you want. Nobody is going to stop you. I'm arguing against spending Debian money on toolchain maintenance (for a port that's no longer part of Debian proper even!). Not what you or GCC upstream or anybody else does with their own time and money. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Using Debian funds to support a gcc development task
Please respect m-f-t, as is the custom on Debian lists? ]] John Paul Adrian Glaubitz > As I explained in my previous mail: The development task here is > something that goes a little beyond normal maintenance work and hence > requires someone to work with a longer dedication on the task. The required level of maintenance varies over time, that's completely normal, and I don't see how this changes anything. > While gcc is free software, it doesn’t mean the work on it is free. I > think we all know that without commercial support, free software > wouldn’t be able to survive these days. Of course not; everybody needs to put food on the table, one way or the other. Some of us are paid to work on Debian and free software and do it that way. Some do it during our free time, either because they earn enough that they can do it as a hobby or because they are a student with free time on their hands, or some other reason that makes it possible for them to contribute without getting paid for it. This hasn't really changed in a very long time. > > Keeping the toolchain working is a pretty essential requirement for > > keeping a port alive, and I don't think it's viable to base the ongoing > > toolchain maintenance for a port on fundraising. > > Maintenance isn’t the same as a one-time porting effort. Normal target > maintenance work is usually a matter of discovering bugs and fixing > them unless you are a port with commercial support where paid > developers are working on supporting new features and hardware on a > regular basis. Maintenance effort over time by far exceed the initial porting cost, so if the port isn't even able to surmount that, I don't think it's long-term viable. [...] > > As a general rule, I don't think Debian should pay developers to write > > software. (There are some exceptions such as outreachy, but they are > > few.) > > Does that mean you would agree to supporting the effort if the > developer came from a minority group? (It might actually be the case > here.) No, it means that there are situations where I think giving people from less-privileged backgrounds a leg up so they can start contributing might be appropriate. The suggested project does not sound like a project for somebody who is not already contributing to GCC. I guess you could try to do it as a GSoC project if it's in that ballpark. (I don't think «minority group» is a useful classifier; depending on how you slice it, we're all from some sort of minority group or another.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Using Debian funds to support a gcc development task
]] John Paul Adrian Glaubitz > Hello! > > On 9/28/19 3:26 PM, Tollef Fog Heen wrote: > >> Since the lack of modernization would eventually mean that m68k support > >> would > >> get removed from gcc, I'm currently running a campaign to prevent that. I > >> have already opened a tracker bug upstream in gcc's bugzilla [2] as well as > >> linked the issue to BountySource [3]. > > > > Doesn't this just mean there's not enough manpower to keep the port > > alive? > > No, it just means that the current gcc maintainer [1] for m68k backend hasn't > worked on this particular task yet because his employer wouldn't pay for > this particular work. Unlike the other ports like amd64, ppc64el, arm* > and s390x, we don't have large companies supporting us as the commercial > potential is low although there is still a small Amiga, Atari and Mac68k > market with new hardware and software being made. > > gcc is just one part of the port, others parts like the Linux kernel or > the Debian ports are actively maintained as I mentioned in my initial mail. To me your «no» actually means «yes». When we're talking manpower, it's about the right people with available time and ability. It's not about the number of warm bodies, so if there's just a single person who is able to do this work and they don't have the time, the port is missing absolutely critical manpower. Keeping the toolchain working is a pretty essential requirement for keeping a port alive, and I don't think it's viable to base the ongoing toolchain maintenance for a port on fundraising. > > I don't think spending $1-5k would be the best use of Debian > > funds. > > Is that really that amount of money? Paying a developer is normally > a lot more expensive. You were the one who suggested that sum, not me. As a general rule, I don't think Debian should pay developers to write software. (There are some exceptions such as outreachy, but they are few.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Using Debian funds to support a gcc development task
]] John Paul Adrian Glaubitz > Since the lack of modernization would eventually mean that m68k support would > get removed from gcc, I'm currently running a campaign to prevent that. I > have already opened a tracker bug upstream in gcc's bugzilla [2] as well as > linked the issue to BountySource [3]. Doesn't this just mean there's not enough manpower to keep the port alive? I don't think spending $1-5k would be the best use of Debian funds. As you point out, it's one of the oldest ports, but ports go through a natural life cycle where they eventually pass away, and that's ok. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
]] Thomas Goirand > 1- Mandating VcsGit and VcsBrowser, meaning we do mandate using Git for > packaging. Like Steve said, there are cases where git is not the right tool. Recommending, fine. Mandating? No, I think that would be a bad idea. > 2- Mandating using the "gbp patches unapplied" layout for Git, as this > seems to be the most popular layout, and that we need some kind of > consistency. It seems to be self-evident to you that we need consistency. It's not at all clear to me that having a single layout to rule them all is the right path forward. Why do you think we should just have a single layout? Beyond that, I think we should move away from patches-unapplied rather than towards it. If you look at how normal software development is done today, it's done with a git repo and not shuffling patches-as-files back and forth. I also think that having a single way of solving a problem will keep us back from further evolution. Freedom to experiment is useful, and by having this as a GR, the only way forward from this would be to have another GR to change to something else. Binding ourselves that way doesn't seem wise. As for what you wrote downthread about possible to use 1.0 native packages: yes, > 3- Mandating using Salsa as a Git repository. Again I think this proposal fails to account for corner cases, as an example on top of what other have talked about: this could end up affecting what can go into non-free. This would also increase coupling, something we already have a problem with, and which is considered a bad idea in software development. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Realizing Good Ideas with Debian Money
]] Steve McIntyre > On Sat, Jun 01, 2019 at 12:29:04PM +0200, Tollef Fog Heen wrote: > > >This is a hugely important point: we're already seeing conflicts where > >people conflate the paid-for LTS effort with other team's priorities. > >If we move that funding closer to Debian, we're effectively saying that > >«this funded effort is important and all relevant teams, volunteer or > >not should support it», rather than trusting teams to act in the > >currently more creative anarchic way. Adding more tension internally in > >the project, which I think spending money in this way will do, is a bad > >idea. > > That's definitely my concern, too. I don't want to have to consider > funding when working on stuff for fun, and I also don't really want to > reorganise how things are done to accommodate others who do. At the same time as what's written above, I think we have to realise we are in an incredibly privileged position to be able to contribute to Debian because it's fun. I'd like that to be the case for more people, and funding will be a part of that, as it is with Outreachy and to some extent GSoC. However, what we're looking at here is not expanding our outreach, it's almost the opposite: people have suggested improving core services and improve underfunded, but important areas like bookeeping. In addition, it's not clear that the funding and political work has to come from Debian. I think it's a lot wider and hooks into the debate about socioeconomic inequalities and universal basic income, areas which I don't think we'll agree on at all inside of Debian. > Having said both of these, I think there *are* reasonable places to > spend money that shouldn't affect us so much. The areas in question > are those where we struggle to find any/sufficient volunteer effort to > do what we need - bureaucracy etc. Volunteer book-keepers are few and > far between, IME. We do have a treasurer team, I would be interested in hearing what their feelings on this would be if we decided to bring in paid labour to help them out. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Realizing Good Ideas with Debian Money
]] Russ Allbery > These dynamics change a *lot* when the money is coming from > the project itself. That money is special; it's not just one more company > or foundation or whatnot that is providing resources to aid in a general > volunteer project. It becomes a loaded statement about what work the > project considers the most important and, worse, *who* the project > considers important to do that work. This is a hugely important point: we're already seeing conflicts where people conflate the paid-for LTS effort with other team's priorities. If we move that funding closer to Debian, we're effectively saying that «this funded effort is important and all relevant teams, volunteer or not should support it», rather than trusting teams to act in the currently more creative anarchic way. Adding more tension internally in the project, which I think spending money in this way will do, is a bad idea. > Particularly now that my free time is rarer and more precious to me, > doing unpaid work for an organization that also has paid staff is > hugely demotivating. It's entirely plausible that paying for > resources would mean that Debian would end up with *less* resources > than we have now, if other volunteers feel the same way. Well said, and I feel the same way. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Censorship in Debian
]] Miles Fidelman > Well, first off, the process led to the resignation of the chair of > the Technical Committee - out of a feeling that the process had become > too "personalized." JFTR (since this keeps being brought up, otherwise I'd much rather we just let this lie): Ian was not chair of the TC at the time. Bdale was (and he did not resign, his term expired on December 31st 2015). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: hacking a home with free technology and Debian
]] Daniel Pocock > Can anybody comment if they give a genuinely plug-and-play experience, > without needing firmware blobs or proprietary tools to get up and > running? Or are there even better alternatives for the > freedom-conscious Debian user? No experience with the Zigate, but I have the aotec z-wave stick and it works fine with other zigwave equipment. (I'm using home-assistant to drive everything, I don't think that's particularly important, it just uses the python libs.) Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: UEFI Secure Boot sprint report
]] Hideki Yamane > Hi, > > > In the end, we decided to have a signing service which will construct > > a source package based on a "template" package and a list of files to > > sign and upload this to be processed by the normal buildd and dak > > processes. The signing service will also have an audit log which makes > > it public what was signed and when. > > I'm curious how this works. > > * source package was modified to generate -$ARCH-signed-template >binary package > * dput it to repo and dak would pass to code sign service? > * sign binary package?? The signing service is a source package builder. I'll use linux as an example package. It's uploaded to experimental and builds the normal set of linux-image-* packages. In addition, it builds a package named linux-image-amd64-signed-template. This matches a filter on the dak side, so it is exposed in https://incoming.debian.org/debian-buildd/project/external-signatures/requests.json (+ .gpg for the signature) as «this needs to be signed». The signing service polls that URL regularly, and when there is a new package available, it is downloaded and unpacked into a temporary directory. It includes a manifest of what files from what packages need to be signed. Those packages are downloaded, the files in the manifest are signed and the source package is built, signed and uploaded, to be built by the regular buildds. This allows us to both keep the key in a central place, having reproducible builds, having an automated process and not having to execute any code from the template package as part of the build. I hope this explains it well enough, let me know if there's anything unclear, I'm happy to explain further. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: UEFI Secure Boot sprint report
]] Ian Jackson > > Once this was agreed and various corner cases ironed out, we started > > implementing the signing service, and the necessary changes in the > > Linux kernel package, dak, fwupdate, shim and grub. The source for the > > signing service can be found at > > https://salsa.debian.org/ftp-team/code-signing. > > One small point: Do you think tht the source for the signing service > is part of the source for the signed output ? If so it probably needs > to be in the Debian archive, not just on salsa. Sorry if this is > inconvenient. Not any more than sbuild, buildd and wanna-build is part of the source for buildd-signed packages in the archive, so my initial answer is no. That said, it would be trivial to package, so somebody could easily upload it to the archive. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
UEFI Secure Boot sprint report
People from the FTP team, kernel team and DSA, as well as other interested individuals met in Fulda, Germany for a sprint with the goal of deciding and implementing the workflow for Secure Boot. Participants * Ansgar Burchardt * Joerg Jaspert * Luke W. Faraone * Ben Hutchings * Tollef Fog Heen * Helen Koike * Philipp Hahn * Julien Cristau [remote] * Steve McIntyre [remote] We had a long discussion about what requirements we had for the signing process, whether that could happen inline in the regular build process, if a human needed to be involved in the signing and how to best handle embargoed builds. In the end, we decided to have a signing service which will construct a source package based on a "template" package and a list of files to sign and upload this to be processed by the normal buildd and dak processes. The signing service will also have an audit log which makes it public what was signed and when. Once this was agreed and various corner cases ironed out, we started implementing the signing service, and the necessary changes in the Linux kernel package, dak, fwupdate, shim and grub. The source for the signing service can be found at https://salsa.debian.org/ftp-team/code-signing. By the end of the sprint, we were able to: - generate a signing template for Linux kernel modules - generate a signing template for shim - generate a signing template for fwupdate - have DAK detect such signing template packages automatically and generate a request for signing - run the code of the signing box by hand to generate the source code packages containing the generated signatures We're still missing (partially or completely): - generate a signing template for GRUB2 - have DAK accept those generated source-only uploads Acknowledgements - the sprint has been possible thanks to: - the Office Factory for hosting us, - donations to the Debian project for covering travel and accommodation costs for the sprint, - Dropbox for sponsoring Luke's travel and accomodations, - Technische Universität Dresden for sponsoring Ansgar's travel and accomodations, and - Univention GmbH for sponsoring Philipp's travel and accomodations, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Debian System Administration team sprint report
]] Martín Ferrari > Having said that, I was just talking with one of the upstream developers > and he told me that since 2.0, remote LTS is not really that important > anymore, as the new storage engine can handle well label/timeseries > churn, can do reliable backups, and it can grow as much as needed. My slight concern there is if we'll see a database bump sometime in the future, when a hypothetical new storage engine comes out and becomes the default, and there's no way to migrate data from the current version to the future version like there was between v1 and v2. We currently have multiple years of data in munin and it could be useful to keep data for longer periods of time, either through federation or just downsampling with a remote storage. > > The Prometheus UI is fine for debugging queries and such, but it's far > > away from Grafana when used interactively. I'd be very happy if we > > managed to get a newer version into Debian. > > Yeah, me too. I hope to be able to start working on it soon, but it is > not going to be trivial with the heaps of javascript dependencies it has. I know. :-( -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Debian System Administration team sprint report
]] Martín Ferrari > Like I had offered soon after I got Prometheus into Debian, I would be > happy to help DSA in adopting Prometheus. I can also offer assistance to > assess if it is a good fit for DSA. Thanks for the offer. (I already use Prometheus heavily at work, but other DSA members have less or no experience with it.) > Right now, support in Debian is pretty strong, with the newest releases > being present in testing and stable-backports. Yes, this is great to see, especially with the v2 support out. Do you have any plans for packaging something like Weave Cortex which offers a more long-term storage than Prometheus itself? > Grafana is a problem, I know, but I hope that as the interest in > prometheus grows, I will get some help in getting Grafana back in shape. > In any case, Grafana is not needed at all to use Prometheus, it is just > a shiny front-end. The Prometheus UI is fine for debugging queries and such, but it's far away from Grafana when used interactively. I'd be very happy if we managed to get a newer version into Debian. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
]] Martin Steigerwald > Regarding Systemd/SysVInit/OpenRC this approach comes with a considerable > cost > tough as it is such a core part of the system. One cost is that a lot of > packages link against Systemd library which is part of the reason why Devuan > exists. Or that GNOME and to some degree other DEs without Systemd is > somewhat > challenging. Devuan developers gave up on the GNOME without Systemd topic for > now as far as I understood. systemd-shim seems to still exist in testing, so presumably it works well enough that it's not accumulating RC bugs. As for why you want to avoid linking to particular libraries, that's simply not how Debian works. We generally enable all options and link to every library possible (as long as they don't interact badly). Personally, I don't particularly favour mysql, but I don't go out of my way to ensure I don't have libmysqlclient (or nowadays, libmariadbclient) installed. It's just pointless, the cost in terms of disk space is tiny. […] > Within the Debian project a first good step would be to accept the fork, > instead of just tolerating (and probably suffering from) it (what else could > Debian people anyway than at least to tolerate it? it is free software after > all). Accepting the fork basically is just accepting that the past is they > way > it is. Could I let go of wanting to change the past? Especially when all my > wanting to change the past still was not able to change it? I don't know what you mean by accepting the fork. It's a fork. Forking is fine and those folks interested in doing something that doesn't fit in Debian proper (whether that's removing specific bits they object to or something else) are free to do so. […] > Also are either not all CTTE´s are announced on debian-devel-announce or is > [CTTE #741573] Debian Menu System from September 2015 really the last > technical decision of the CTTE? https://lists.debian.org/debian-devel-announce/2017/07/msg00006.html is an example of one from this summer. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Automatic downloading of non-free software by stuff in main
]] "G. Branden Robinson" > At 2017-12-01T18:11:34+0100, Adam Borowski wrote: > > Microcode itself has data loss and local exploits (such > > as an unprivileged user of an unprivileged VM taking over the host machine), > > then often comes in one bunch with IME updates that close remote holes. > > And how do we know they aren't opening new ones due to the same factors > (bad design or bad intent) that led to the originals? This argument can be applied to any bug fix we or an upstream does, but that doesn't mean we avoid shipping updated software. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Emeritus status, and email forwarding
]] Ondřej Surý > On Fri, Nov 17, 2017, at 23:01, Tollef Fog Heen wrote: > > ]] Ian Jackson > > > > > I think that, with some safeguards[1], this would be a good thing to > > > offer people. If nothing else people have often used @d.o addresses > > > in Debian work, where the addresses live on after they move on, and we > > > should definitely encourage even an emeritus member to be reachable > > > for answering questions or whatever, as their time and interest > > > permits. > > > > I don't think we should do that. Once they've left the project, they > > don't and shouldn't have the ability to answer for Debian in any way. > > +1 to that. Either you are with the project, or you are not. If somebody > hasn't been active in years, and intend to possibly return, we can > recycle the account name, but he should be probably subject to the > regular NM procedure. Yes, people who come back after having retired (or having gone MIA) can of course have their user name back (subject to them becoming DDs, through the processes for that). Nobody else can get that account name, though, since that could cause problems. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Emeritus status, and email forwarding
]] Ian Jackson > I think that, with some safeguards[1], this would be a good thing to > offer people. If nothing else people have often used @d.o addresses > in Debian work, where the addresses live on after they move on, and we > should definitely encourage even an emeritus member to be reachable > for answering questions or whatever, as their time and interest > permits. I don't think we should do that. Once they've left the project, they don't and shouldn't have the ability to answer for Debian in any way. > Unfortunately it would mean that such people would still need some > kind of login on Debian systems, so that they could update the email > forwarding. But it wouldn't have to have the wide powers of an active > DD/DM account. > > What do people think ? How hard would this be ? It would make our already too complex setups even more complex, but that's not the reason why I think it's a bad idea. > The emeritus member should refrain from advertising the @debian.org > email address, so outgoing emails, web pages, etc., should be updated > to show a different address. Obviously the point of retaining the old > address is to avoid having to deal with a massive array of existing > places where the address is published, but there should be no active > uses, and any particular instances should be changed on requests by > Debian. The forwarding would have to be withdrawn if the emeritus > member continued to advertise their @d.o address, or if they did > something sufficiently bad that we would want to disassociate > ourselves from them more completely. I don't think we're in a position where we would be able to effectively police this, and so I don't think we should try either. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee
]] Russ Allbery > There are two primary reasons why we're continuing to discuss this. One > is that the decision went a direction that a lot of people didn't, and > don't, like, and they're still unhappy about it. There's really nothing > that can be done about this; any other decision would have had exactly the > same consequence, just with a different set of people. We could fix the culture. We can choose to change our culture into one where once we decide on something, that's decided at least until new facts emerge. Instead, we have chosen to have a culture where everything can be discussed again and again, until not only is the horse dead, but its skin is tatters and its bones meal too. Some people in Debian who were unhappy about the decision initially did choose to stop beating on it and instead unite and move forward. I wish we, collectively, agreed more that's what we'd do after such a divisive process. > The other point I want to make here is that the systemd discussion was > one of the most exhausting and time-consuming things that I've ever > been involved in. Ditto, and even just reading those few last mails triggers something not entirely unlike PTSD for me. > This is some of the "being human" part that I was talking about in my > other message. Making people heard can be incredibly time-consuming > and can require a ton of emotional energy, and TC members, like all > project members, are volunteers. Often with very limited quantities > of time they can spend on Debian. The TC members at least have signed up for it, having some idea of what the work entails. Random maintainers who are suddenly thrust into the spotlight are much less so, and it's their emotional well-being I want to protect at the same time as making good technical decisions. It's really, really hard, for many of the reasons listed in this thread. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Are online services also software for Debian's rules?
]] Christian Seiler > Hi, > > I don't have anything useful to add to your other comments, but: > > On 08/12/2017 02:11 PM, Tollef Fog Heen wrote: > > ]] Christian Seiler > >>> [free CPU designs] > >>> (although I'm sure there are...) > >> > >> There are, take a look at RISC-V, for example. [1] And for the > >> requirement about not requiring non-free software, you don't need > >> to have a fully free CPU design, just one where the microcode is > >> free. And I believe that current POWER CPUs fall under that > >> category. (I may be wrong though.) > > > > Doesn't help if it's not packaged in Debian, though. > > Well, if I'm not wrong about POWER, that's supported in Debian > as a release arch (ppc64el). I was talking about the microcode for said arch (which doesn't seem to be packaged, or at least not in main, from a quick apt-cache search). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Are online services also software for Debian's rules?
]] Christian Seiler > > So that means I don't think all of Debian should be in non-free because > > there > > are no free cpu designs > > Ahem, nobody said anything about non-free here, we're talking about > contrib. That said: for all release archs of Debian there are > actually free implementations of the CPU architecture, in the form > of Qemu. So I don't think this applies here. Taking this to its absurd extreme gets you, unsurprisingly, absurd results: Sure, qemu itself is free, but it'll have to run on an OS which is either not Debian (in which case, according to some of the arguments in this thread, it should go to contrib), or Debian. Eventually, you end up on the silicon. However, modern silicon is largely defined by software, and has supporting software on many chips (all of which is not in Debian), so effectively requires software outside of Debian to function (and so should go to contrib). I don't think our distro would be improved by arguing that all packages should move to contrib. Having to structure your code or packaging in a specific way to ensure you can actually put it in main rather than contrib also does not seem like something we should encourage; it should be done according to what makes technical sense. > > [free CPU designs] > > (although I'm sure there are...) > > There are, take a look at RISC-V, for example. [1] And for the > requirement about not requiring non-free software, you don't need > to have a fully free CPU design, just one where the microcode is > free. And I believe that current POWER CPUs fall under that > category. (I may be wrong though.) Doesn't help if it's not packaged in Debian, though. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Debian contributor Register of Interests
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Debian contributor Register of Interests"):
> > Indeed. I also think there's a hang-up about financial conflicts of
> > interest in the discussion, but for at least me (and I suspect others),
> > money is a pretty weak motivator. I generally have enough that it's
> > something I don't need to spend much mental energy on.
>
> That makes sense.
>
> But these things can change. If you don't have enough money then it
> can be a very powerful motivator. Worry about (say) losing one's job
> can be pretty significant. For me, being employed to work on free
> software means an inevitable tension between the interests of my
> employer, and my own views. Indeed such difficulties contributed to
> my need to depart from Canonical.
Absolutely, I'm not saying they can't be, just that they're not that
powerful motivators for everyone (and while I don't have data about it,
I know that IT generally pays ok to well, and the importance of money
goes down as you get more, so it's a reasonable conclusion).
> From Debian's point of view: I think that anyone who takes prolonged
> employment with an organisation which takes an active interest in
> their Debian work, to the extent of taking an interest in what they
> say about Debian and Free Software, ought to declare that.
My employer pays for me to go speak at Debconf. I'm not sure if that
passes that bar or not. (I've declared who they are in the context of
the CTTE, which I think is in a somewhat special situation when it comes
to being very clear about conflicts of interest.)
> > An example of what I do think could cause conflicts of interest is
> > where I'm part of some community (free software or not) and my
> > interest is in ensuring I have a good standing or status in that
> > community and this colours judgements I make in Debian.
>
> Most of the communities like that I am part of, are either
> sufficiently remote from software that they wouldn't care, or are
> themselves technology projects.
>
> In the latter case, most of the information is already public. It
> would be impractical and pointless to ask everyone to collate it.
Isn't that what the wiki page is about? Else, you're saying I should
put nothing on there, since it's all public already.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Debian contributor Register of Interests
]] Didier 'OdyX' Raboud > Assuming a hypothetical Debian contributor with financial interests in > a hotel business, part-time software engineer and affiliated to a > political party: not all three connections matter in all Debian work, > or discussions. The first might matter though iff people start > considering paying for accomodation in hir hotel; the second might > matter in a discussion about a piece of software they are paid to work > on, and the latter might matter when discussing the Debian project's > eventual reaction to a complicate situation somewhere in the > world. But these only matter in specific discussions, not constantly. Indeed. I also think there's a hang-up about financial conflicts of interest in the discussion, but for at least me (and I suspect others), money is a pretty weak motivator. I generally have enough that it's something I don't need to spend much mental energy on. An example of what I do think could cause conflicts of interest is where I'm part of some community (free software or not) and my interest is in ensuring I have a good standing or status in that community and this colours judgements I make in Debian. I object to collecting all that information, though. It would feel entirely too intrusive. There's a question of what is a legitimate interest and what is not, and this might be worth exploring, but I suspect it all comes down to «it depends» and reasonableness tests. > Where I'm going to is that I feel we're much better in a situation > where we don't load all our conversations with references to _all_ our > "real-life" interests. It opens the floodgates to interpret any > position under the light of these interests, neglecting the mere idea > that for plenty (if not all) of Debian interactions, we are genuinely > acting as independent individuals. I think «geniunely acting as independent individuals» is a meaningless concept, since everything we do is coloured by the context we're in and that includes social relations. > That said, I still think that there are situations in which declaring > one's conflicts of interest _does_ matter, but I do expect the > affected individual to either explcitly retract (or stay away) from > the discussion, or declare the conflict of interest at that point. I agree with this, if you do see a possible and reasonable conflict of interest, declare it and discuss it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: If Debian support OS certification?
]] Thomas Goirand > I do believe it'd be a fair way to get free (as in free beer) hardware > for the DSA team. It's up to us to define the terms. It would mean we'd end up with a hodgepodge of different servers from different vendors with no coherent OOB access methods, we'd need to track a lot of different firmware versions and so on. It's not something we want. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson
> Philip Hands writes ("Re: Replace the TC power to depose maintainers"):
> > Ian Jackson <ijack...@chiark.greenend.org.uk> writes:
> > > I still don't understand why the TC is so crushingly slow to conter
> > > maintainer power in Debian. As I say in my other emails, a result of
> > > the TC's inaction, maintainer power in Debian is nearly unassailable.
> >
> > I wonder which column on your tally sheet you will put this outcome.
>
> I think the maintainer saw the writing on the wall, so I count this as
> a successful intervention by the TC. (I hope the new maintainers will
> prove me right.) That there wasn't a formal vote is beside the point.
I don't consider this case particularly successful. Regardless of what
one thinks of the outcome, the process was subpar and had people sniping
at each other. I don't think that's how the process ought to look.
> I still (perhaps, even more so) believe we need to have a better way
> of dealing with these kind of disputes.
That I agree with.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson
There's no need to Cc me on replies, I'm subscribed already.
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers"):
> > Because I generally find it's generally the wrong tool for the job. If
> > I can come up with a good explanation for why somebody should take a
> > particular course of action (which I need before I'm willing to override
> > anybody), and I take the time to explain it to them and discuss with
> > them, I find we usually end up agreeing.
>
> That is of course mostly true of disagreements.
>
> But it is not mostly true of problems which come to the TC.
>
> Of course sometimes the TC will find that getting people to explain
> themselves clearly will cause the dispute to evaporate. I remember
> that happening about twice during my term. But it's easy to tell
> when this happens because both parties go away happy and say they
> don't need the TC's help any more.
That's not my experience. They'll go away grumbling because they both
had to make some sort of concession(s). The goal of the current dispute
isn't to get global a new maintainer. It's to ensure the package is of
as good quality in Stretch and beyond. This is balanced by the goal of
not making too many people too sad or annoyed, not taking on lots of
technical debt or crazy design decision and so on.
> > The goal is not to end up with a new maintainer. Deposing a maintainer
> > or overriding them is sometimes a necessary evil, but it's never my
> > first option.
>
> Surely the goal should be to make Debian as good a social and
> technical space as possible.
I didn't say what the goal was, I pointed out what it was not.
> If the maintainer is exercising poor leadership - poor enough that
> someone has risked coming to the TC with it - then that goal is best
> served by replacing them.
Based on that argument, the TC should just rubberstamp all appeals and
always grant them, which is surely not what you mean. Also what ScottK
writes about being «on trial» (which is what it feels like) as quite
uncomfortable for the maintainer.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Ian Jackson
> Tollef Fog Heen writes ("Re: Replace the TC power to depose maintainers [and
> 1 more messages]"):
> Lars Wirzenius
> > > I suggest a lighter approach than a GR for eroding the strong package
> > > ownership further is to start another page, "LowThresholdHijack" or
> > > something, listing maintainers who are OK if someone hijacks their
> > > package if the maintainer isn't taking good care of it. Would anyone
> > > else than I put themselves on that new page? (If you would, start the
> > > page on the wiki and announce it on this thread, and I'll add myself.)
> >
> > A similar proposal: Have a way of declaring the package to be under
> > collective maintenance (put it under collab-maint on alioth +
> > Maintainer: collect...@debian.org or somesuch?) That'd move closer to a
> > model where individuals don't own that particular package.
>
> This is all very well and good, but frankly, Lars (and the others in
> this conversation) are not the problem. The problem maintainers won't
> put themselves on a LowThresholdAdoption list either.
>
> We already have ways of dealing with maintainers who are simply
> absent or busy, and not actively resisting. Our processes for that
> are rather cumbersome but it is possible to use them effectively.
>
> What we lack is a way of dealing with maintainers who are determined
> not to lose control of their packages. (And I do mean "control".)
I believe that cultural change can happen through collective action on
an individual level, rather than sweeping regulation and legislation.
The culture around NMUs has changed _immensely_ in the years I've been
involved in the project. Nowadays, they're a pretty routine matter (as
an example, look at the conflict over global where the petitioners have
NMUed a newer version into experimental where this isn't really that big
a deal).
I believe our view of maintainership can change similarly if enough
people say «here are the keys to the kingd^Wpackage, please be
considerate», even for the packages which are not collectivised.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Philip Hands > Tollef Fog Heen <tfh...@err.no> writes: > > > ]] Ian Jackson > > > >> That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > >> weeks during which members of the TC have been prevaricating. > > > > What are you accusing the TC of lying about? > > I think that British English has drifted into using that as a synonym > for procrastinate while American English seems to have stuck to its > earlier meaning (judging by the online dictionary entries I see). That doesn't match the reading of the Cambridge dictionary: http://dictionary.cambridge.org/dictionary/english/prevaricate prevaricate verb [ I ] UK /prɪˈvær.ɪ.keɪt/ US /prɪˈver.ə.keɪt/ formal to avoid telling the truth or saying exactly what you think: Or the Oxford dictionary, https://en.oxforddictionaries.com/definition/prevaricate: prevaricate VERB [NO OBJECT] Speak or act in an evasive way: > I certainly didn't (and still wouldn't) assume that Ian was accusing > anyone of lying here. Given his later apology, I'd assume so as well, but as a native speaker of English, Ian should really know better than using the term in the first place. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson
> Didier 'OdyX' Raboud writes ("Re: Replace the TC power to depose
> maintainers"):
> > Le lundi, 5 décembre 2016, 14.41:01 h CET Ian Jackson a écrit :
> > > 6+ weeks during which members of the TC have been prevaricating.
> >
> > I had to lookup prevaricate in a dictionary:
> > > to speak falsely or misleadingly; deliberately misstate or create an
> > > incorrect impression
> > > to deviate from the truth
> >
> > This is not helping, really. Please tone down.
>
> That's not what meant by "prevaricate". I asked #chiark about the
> meaning of the word and they said:
They might want to consult a dictionary then,
http://www.dictionary.com/browse/prevaricate:
verb (used without object), prevaricated, prevaricating.
1. to speak falsely or misleadingly; deliberately misstate or create
an incorrect impression; lie.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > That is 6+ weeks' more stop-energy. 6+ weeks' more inaction. 6+ > weeks during which members of the TC have been prevaricating. What are you accusing the TC of lying about? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers
]] Ian Jackson > Imagine the roles were replaced. Imagine the actual petitioners (P > and W, for the same of argument) were the current maintainers, and the > actual current maintainer (R) were a petitioner saying "please make me > the maintainer". Would the TC would spend months debating before > dismissing such a manifestly unfounded petition ? That's a very hypothetical question which is hard to answer without more context of what P and W had done lately in terms of maintaining the package. > Can you explain why the TC is so reluctant to depose or overrule > maintainers ? Because I generally find it's generally the wrong tool for the job. If I can come up with a good explanation for why somebody should take a particular course of action (which I need before I'm willing to override anybody), and I take the time to explain it to them and discuss with them, I find we usually end up agreeing. The goal is not to end up with a new maintainer. Deposing a maintainer or overriding them is sometimes a necessary evil, but it's never my first option. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Replace the TC power to depose maintainers [and 1 more messages]
]] Lars Wirzenius > I suggest a lighter approach than a GR for eroding the strong package > ownership further is to start another page, "LowThresholdHijack" or > something, listing maintainers who are OK if someone hijacks their > package if the maintainer isn't taking good care of it. Would anyone > else than I put themselves on that new page? (If you would, start the > page on the wiki and announce it on this thread, and I'll add myself.) A similar proposal: Have a way of declaring the package to be under collective maintenance (put it under collab-maint on alioth + Maintainer: collect...@debian.org or somesuch?) That'd move closer to a model where individuals don't own that particular package. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: third-party packages adding apt sources
]] Bas Wijnen
> Debian stable is for users who want a rock solid system. It is out of date by
> the nature of how it is built. Users who want to get the newest versions of
> their software should not be running stable; testing is probably better for
> them.
This often isn't what users want, though. They want the newer versions
of some packages: On my server, I want a new weechat (since it has
bugfixes and features I use), I want a newer grafana (ditto). I don't
care about having a newer version of emacs, the version in stable is
fine. Ditto for, say, postgres.
Other users are going to care about different sets of packages, but we
all have the same «I want stable, but for $list_of_packages».
Maybe backports is what we decide is the best solution for those cases,
but maybe we can do better than that.
> > We have zero procedure in place for the following:
> >
> > - Totally unsupported very old version of ${FOO} in stable, maintainer
> > isn't patching bugs, bugs are going to upstream, and upstream is
> > annoyed Debian has out of date, perhaps insecure thing X.
>
> Yes, this is a different problem. We may want to shield upstream from
> bugreports for those packages somehow.
I'm not at all convinced we can shield upstreams, since users will show
up on mailing lists and IRC upstream and go «I'm trying to do $X, but it
doesn't work, and according to the online docs, it should» and after a
bit of a back and forth, it's discovered that they're running an old
version which either lacks the feature or where it's broken.
> IMO it would be good to recommend our users to file all bugs with us,
> and leave it to the maintainer to pass them to upstream. I have
> upstreams that follow our bug tracker, which is great. But if they
> don't, it should be up to me to decide whether the report is worth
> their time.
A lot of user interaction isn't bug reports, but rather closer to user
support. I don't think it's reasonable for maintainers to be asked to
do all the user support that upstream does. Even just handling bugs
well (triaging and in some cases fixing and sending patches upstream) is
a lot of work.
> > Hell, teams packaging Mozilla-soft and PostgreSQL are DDs maintaining
> > *external archives* because it's easier.
>
> This indicates that our procedures are too hard. That needs to be fixed.
> Maybe people from those teams are reading this and can comment on it?
No, it doesn't merely indicate that our procedures are «too hard». I
think apt.postgresql.org exists because PostgreSQL.org themselves want
to provide a service to our common users. We don't want to have all the
supported postgresql versions in our distro, but it's super useful for
users who need a particular version.
> > Making it hard to install a new archive will only lead to more
> > workarounds, more FAQs telling users to dismiss warnings, and more
> > upstreams hell-bent on working against us, because we keep making their
> > lives harder.
>
> Yes. But I'm reluctant to throw away our stable release process. If it's not
> for everyone (and it isn't), we should be more clear about that.
I haven't seen anybody advocating throwing away our stable release
process. So far it's mostly pointing out problems, not yet trying to
come up with solutions. (Which is fine, we need to find out what the
problems and the pain points are before it's useful to come up with
solutions.)
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Re: shutting down httpredir.debian.org?
]] Ondřej Surý Hi, > since you work at Fastly, could you make the deb.debian.org to have IP > address? :) Currently it's accessible only via Legacy IP although > static.debian.org has records, it get's redirected to > global-nossl.fastly.net that's accessible only via Legacy IP which makes > me very sad. deb.d.o has a lower-priority ipv6 fallback, so you should file a bug on apt asking it to use the lower-priority alternative that has the protocol you need, since apparently that doesn't work today. Until that gets fixed, you can use cdn-fastly-v6.deb.d.o for v6 support. It's not the default since too many users ended up in suboptimal places. Once that's fixed, I'm going to flip the switch back again. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: shutting down httpredir.debian.org?
]] anarcat (In the interest of full disclosure: I work for Fastly.) > On 2016-04-14 05:02:18, Peter Palfrader wrote: > > If we want to maintain some form of geographic closeness for it, then > > pointing it to deb.debian.org seems like something we could try. > > Note sure what that is. http://deb.debian.org/ seems to say it uses the > Fastly CDN, at least from here. That is correct. > A fundamental issue of all this is who we give our users to. Sending > Debian users to a commercial CDN is a political decision with huge > privacy implications for our users. I do not think we should redirect > httpredir like this without at least first informing our users, in > advance, so they can make an informed decision on which mirror they > trust with their metadata. They're already being redirected to random mirrors by using httpredir, where we have absolutely no control over their logging policy and practices. With Fastly, we control the logging policy and can stream logs if we want to (or we can decide not to, which is the current setup). Fastly's own policy is documented on https://docs.fastly.com/guides/compliance/security-and-technology-compliance#cache-data-and-end-user-information-management -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: shutting down httpredir.debian.org?
]] Bastian Blank > On Thu, Apr 14, 2016 at 09:02:18AM +, Peter Palfrader wrote: > > If we want to maintain some form of geographic closeness for it, then > > pointing it to deb.debian.org seems like something we could try. > > What kind of setup is deb.debian.org? It's ftp.debian.org fronted by (currently at least), Fastly. (Not sure if that answers your question? Happy to elaborate if you explain what you're after.) > And maybe we can fit the possibility to force some ip blocks to given > mirrors. Currently we hard-code the Azure supplied mirrors into the > images[3]. However I would like to move this decision into more global > infrastructure, without paying the overhead of httpredir in the current > form. (Taking a slight guess at what you actually mean here.) Anycast for HTTP directly is somewhat icky, when done over the global internet, since you often (relatively) end up with BGP reconvergences leading you to hit a different server, which causes the current problems. For this, just doing anycast for the DNS servers is better (since it's mostly UDP (and the rest is short-lived TCP) and therefore not subject to the same problems. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Namespace question - data.debian.org
]] "Iain R. Learmonth" > Semantic URIs represent not just documents but also abstract concepts > and may be referenced by other datasets. I'm not sure what this actually means. What kind of abstract concepts? The idea of there existing a relationship between packages called «Depends»? > It's important that these allocations are permanent as far as > possible, so it's important to get this right. Assuming we use HTTP for this, HTTP redirects are a thing, so we can always move stuff around if we need to. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Announcing GNU ethical criteria for code repositories
]] Ian Jackson > No reporting of site visitors to third parties, so no third-party > tracking tags or images. [B1] It's interesting to see that FSF fails this test themselves. They're using a third party DNS service for one of their DNS servers (FSF France, which is a sister organisation of the FSF, hence a third party.) I think such a requirement, when treated as written is entirely too strict. It disallows the use of best-practices technologies like CDNs. (They also fail the second part of B1, since they're using tracking tags in pages by way of using piwik, as well as using ETags, whose principal usage today is tracking.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are
Re: Support YUBICO
]] Здравствуйте, Debian-project. Support for Debian Yubico key ? Yes, a bunch of the Yubikey software is packaged in Debian. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/877fuxi80o@aexonyam.err.no
Re: About the recent DD retirements
]] Anthony Towns On Fri, Jan 23, 2015 at 11:29:19AM -0600, Gunnar Wolf wrote: Anthony Towns dijo [Fri, Jan 23, 2015 at 10:57:55AM +]: (Yes, I really think Debian should have 300k+ packages, including everything in all the language archives, no matter how special purposes (compare against the chiark* packages eg). My answer to this is that... A distribution should mostly cater to users. That means, we should target applications, not libraries. So I'm going to disagree with that in two ways. First, and more trivially, is that there are plenty of applications people want to run, that depend on unpackaged libraries that are a PITA to package. Etherpad is the example I already gave. Openrocket is another -- it's packaged as an installer that downloads the pre-build OpenRocket .jar file from the upstream site and instals it; because openrocket upstream likes using cool new java libraries for features and java libraries are a pain to package. This also points at something not explicitly mentioned: Our support for multiple versions of the same package is pretty much non-existent. (You can hard-code the version into the package name. This causes NEW pain, this kinda breaks dependencies and doesn't map well to how at least some languages like Ruby handles dependencies.) This means that if you use system packages and want to have two applications that both want foo.jar installed, but different versions (since they need different APIs or different bug compatibility), we don't support that well. For C libraries, there are sonames and all, but those largely doesn't exist for other languages and fixing that would be a huge undertaking with, IMO, pretty poor prospects for success. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d264um6d@aexonyam.err.no
Re: About the recent DD retirements
]] Keith Packard Tollef Fog Heen tfh...@err.no writes: This means that if you use system packages and want to have two applications that both want foo.jar installed, but different versions (since they need different APIs or different bug compatibility), we don't support that well. For C libraries, there are sonames and all, but those largely doesn't exist for other languages and fixing that would be a huge undertaking with, IMO, pretty poor prospects for success. For Java, I'm afraid I've taken to embedding the ABI version in the filename. The alternative is to completely disallow simultaneous installs of different versions, which seems worse. That requires tracking ABI versions. People often don't do that. They (effectively) statically link and then just test the resulting binary and distribute that, including all dependencies. There are certainly downsides to this approach, but it's what lots of the world seems to have fallen down on. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/8761bvvrxx@aexonyam.err.no
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
]] Stefano Zacchiroli I'm hereby formally submitting the GR proposal included below between dashed double lines, and calling for seconds. With respect to past discussions on the -vote mailing list, this is the proposal code-named 2-S; see [1,2] for (the last known versions of) alternative proposals. I like the term limit concept. I'm wondering if we should have a wider proposal in which we just make the CTTE an elected body. I'm not sure it's a good idea, but I'm also not sure if it's been discussed at all (only having followed some of the -vote discussions around this from the web archives). -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87fvcyh2tr@aexonyam.err.no
Re: GR proposal, Call for Seconds - term limit for the tech-ctte
]] Philip Hands Tollef Fog Heen tfh...@err.no writes: ]] Stefano Zacchiroli I'm hereby formally submitting the GR proposal included below between dashed double lines, and calling for seconds. With respect to past discussions on the -vote mailing list, this is the proposal code-named 2-S; see [1,2] for (the last known versions of) alternative proposals. I like the term limit concept. I'm wondering if we should have a wider proposal in which we just make the CTTE an elected body. I'm not sure it's a good idea, but I'm also not sure if it's been discussed at all (only having followed some of the -vote discussions around this from the web archives). Wouldn't it have been great if the various factions around the systemd issue had got the idea early on to try to stuff the committee with their respective friends before the decision. If we assume four-year terms, that'd have been, at max, two members out of the eight. Personally I think there's more than enough voting going on as it is, and adding reasons to have more regular votes will just promote the idea (that is already rather hard to dissuade people of) that all one needs to do is vote for a thing, and somehow it will magically do itself. I'm not seeing people having that idea. It does not strike me as obvious that popularity correlates to competence. Also, it would not be helpful if members of the committee were tempted to take the popular side of an argument, against their better judgement, because they were coming to the end of their term, and they would like to be reelected. If that's the only reason, make it so people can sit for a maximum of one term before being off the committee for a full term and that effect more or less vanishes. I'm not saying «We should absolutely have an elected TC», I'm saying that I think it's something that's worth discussing. As for Zack's point about this process being underway already: yes, that's the point. If we want to change things about the TC, let's put out a comprehensive proposal instead of changing one thing now and another thing in six or twelve months. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d28168qi@xoog.err.no
Re: Interpreting the init system GR results
]] Matthias Urlichs Russ Allbery: A lot of that analysis concludes that the pro-systemd side in Debian won some sort of conclusive victory. I have a different perspective. Too true. This GR does not have winners. We all lost. Not as a result of this vote, bus because of the incessant arguing, trolling, and mixing up of personal preferences and angsts with technical merits and bugs which preceded and accompanied it. (It also caused a couple of people to quit who shouldn't have had to.) No, we all won. We won because we said that «we have processes for this». We won because we as a project said «we are responsible and trust each other to be excellent and work together for the best solutions for everybody». We won because we rejected making technical policy through political processes. There were sacrifices along the way. This isn't an easy won victory, and we'll all be sore and tender for a while while we regain our balance and find out how to best move forward together. Are we up to the challenge? Personally I doubt we are, and I'm not necessarily excepting myself from that judgement. But we should strive to be. I sure hope we are. It won't be easy, but I think we are. If I didn't, I'd not have been here still. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87egsyc5iq@xoog.err.no
Re: Interpreting the init system GR results
]] Matthias Urlichs Hi, Tollef Fog Heen: Matthias Urlichs Too true. This GR does not have winners. We all lost. No, we all won. We won because we said that «we have processes for this». We do have processes for this, but the interaction of reasonable people and working processes with not-so-reasonable people (note that I'm not blaming a specific side here) definitely resulted in misguided (ab?)use of our processes (in the opinion of a large majority of developers) -- altogether an experience I wouldn't want to repeat any time soon. If ever. :-/ Yes, in this case it was one of those cases where one group wanted to (and my apologies for the war-like metaphor here) call in the heavy artillery. The project said «no, we have better mechanisms for this». That's certainly a course correction, but that's fine. So, yes we «won» in the sense that the mandate to get over our mutual pigheadedness and start to bloody *talk* to each other was sent loud and clear (let's hope it'll be received), but along the way we lost a heap of trust in each other which will have to be regained. It's not only a mandate, it's a directive. It's the metaphorical parent going «why are you running to me to solve this problem? You know how to fix this already!». I sure hope we are. It won't be easy, but I think we are. If I didn't, I'd not have been here still. Same here. Well. Enough of that. Back to getting actual work done! ;-) Yupyup. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87sihd8rsq@xoog.err.no
Re: Update to reimbursement procedure (now: max 3 months after expense)
]] Lucas Nussbaum As a general rule, no reimbursement requests will be processed if requested more than 1 year after the corresponding event (sprint, purchase, etc). I received a reimbursement request today for expenses made in 2008 and 2011. I don't think that we (esp. auditor@) have the energy to track reimbursement requests made so long ago, so I decided to stick to the above policy, and to reject this request. I also used that opportunity to update the wiki page so that it reads: As a general rule, '''no reimbursement requests will be processed if requested more than three months after the corresponding event''' (sprint, purchase, etc). (diff: 1 year - three months) Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. Has the auditors requested this change? There's nothing in the DPL log about it. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/871tqlldew@aexonyam.err.no
Re: Update to reimbursement procedure (now: max 3 months after expense)
]] Lucas Nussbaum On 06/10/14 at 13:33 +0200, Holger Levsen wrote: Hi, On Montag, 6. Oktober 2014, Lucas Nussbaum wrote: Both 2008 and 2011 are more than a year ago, so I don't see any justification for making this change and would like to see it reverted. /me too Also, I don't think that 3 months is unreasonable. My employer applies a two-week soft deadline, and a one month hard deadline for travel reimbursements. or have it raised to 6 months. 3 month is really not that long, esp for those who are too being busy due to jobs or whatever. (While within a job one can do these request on job-time, so a shorter interval is more reasonable here.) Also we don't want to punish those we want to support :) Sure. But should we punish our Trusted Organizations with reimbursement requests that take several months? Somewhat of a separate problem, but it seems we're currently punishing our volunteers with delays of many months. AIUI, people are still waiting for reimbursements for the release sprint nine months ago. It takes 15 to 30 minutes to gather receipts, scan/snail-mail them, and request reimbursement via email. If for good reasons, you are temporarily so busy that it's not possible for you to find those 30 minutes in 3 months, I can accept that, and will not blindly reject reimbursement requests (especially if you send an email to inform that you will be late before the 3 months deadline). But on the other hand, I would like to set the expectation that reimbursement requests should generally be sent in less than 3 months, which seems to me like a totally reasonable deadline in the general case. It takes 30 to a minute to process a payment through online banking, so if we're applying the same scale for reimbursements, those should never take more than three days, then? (It also takes way more than 30 minutes for me at least to mail anything using snail mail, since that means a trip to the post office.) I think you're addressing the wrong problem here. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87k34dj9r4@aexonyam.err.no
Re: keybase.io
]] Enrico Zini [3] Anyway, there is no activity LED for the microphone. Can I have a panel applet thingie which shows if some process is reading from a microphone or webcam device? Use a physically separate microphone, either a headset or something like http://www.yamaha.com/products/en/communication/usb_conference_speakerphones/pjp-10ur/?mode=model (The latter is an absolutely excellent little conference mike: shows up as an USB audio device, does in-firmware echo cancellation, only downside is its price tag of ~220 USD.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87k3b1edn5@xoog.err.no
Re: Proposal - preserve freedom of choice of init systems
]] Russ Allbery (Dropped DAM and personal Ccs) Second, Matthew's proposal explicitly doesn't change the TC decision, so I'm not even sure what you think would be aborted here. It wouldn't have any effect on the choice of default. It dictates in a top-down manner to individual developers how to do their work and undermines the flexibility of Debian contributors in ways that I think are unnecessary and a little condescending, and requires work be done without identifying anyone who is going to do the work, which is why I voted against it. But it's not some sort of end-run around the previous decision. The previous decision does say that it is replaced completely by the text of such a position statement and I do note that the proposed GR does, very carefully, not refer to systemd as the default. It makes for a clumsier construction, which when combined with the level of legal-ish arguments being made here, makes me suspicious. It feels like we're way past rough consensus and working code and running at full speed into a courtroom. Third, even if it were, as Andreas points out, we put that clause in there intentionally. If the project wants to change the decision about the default init system, it can do so with a 1:1 majority. I don't think anybody has a problem with the non-cornercase interpretations of the GR. I think the way this GR is phrased is odd, and I agree with Bdale that I see no reason why it couldn't just be a straight statement on issues of the day without being attached to a TC decision. Currently, it's attached to a decision about the default init system while not actually saying anything about the default init system, which I think is strange. I concur with Kurt that while procedurally this may be allowed, I don't think it's a particularly good idea. I think it's a terrible idea. Ian writes that he specificially made it as broad as he did in order to create this situation so that anything could be included. Also, separately, please don't attack Ian for things that Matthew proposed, or for clauses in previous decision that Bdale drafted in conjunction with the project secretary. This is not a situation of Ian's creation. https://lists.debian.org/debian-vote/2014/03/msg00020.html, by Ian: That GR override clause was written by me. I specifically drew it widely precisely so that, amongst other things, a GR could answer questions that the TC has failed to answer. I don't think pointing at Ian for the clause is particularly unfair. Ian's also seconded the proposed GR, which generally means you agree with whatever you're seconding. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87lhws1kp7@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] Lucas Nussbaum Thanks a lot for this status update. I'm very much in favor of exploring ways to make the Debian infrastructure easier to manage, and using a CDN sounds like a great way to do so. It's great that things worked out with Fastly (any plans for a more public announcement?). I'd like to move some other bits over and get some of the technical hurdles worked out first. Amongst those are the problems of ensuring that downstream caches see a consistent view, whether we're talking about sites such as planet (where the plan is to pull in images to be served from the planet.d.o domain rather than from the blog posters domain) or backports. The considerations that apply to backports would also apply if/when we want to push the main archive through. In short, the problem is as follows: We have a static-master with the master copy of the web site. This tree gets synced to a bunch of mirrors (currently three). In some cases, a mirror might be unreachable, be down or otherwise not be updateable. If it's not updated, we want to ensure that mirror is not used until it's up-to-date. How we solve this problem is going to differ by CDN, but common to all of them is we need tight control over timing to ensure users never encounter out-of-sync mirrors. I have some ideas how to do this for Varnish-based CDNs, but I'm not sure how to solve it for some of the other CDNs, so we'll need to talk to them. However, in [1], I raised one main non-technical concern that is not mentioned in your mail: I fear that, by moving to CDNs without ensuring that there are a sufficient number of CDN providers willing and able to support Debian, we could end up in a lock-in situation with a specific CDN provider (after all, there are not so many of them, and even a smaller number could be able to deal with our technical requirements). [1] https://lists.debian.org/debian-project/2013/10/msg00074.html You're just mirroring what we talked about in https://lists.debian.org/debian-project/2013/10/msg00029.html there. We're so far just reducing latency for users, those sites were served purely by the static mirror hosts up until recently and we had no load problems there, so if we want to, we could easily pull back to using our own infrastructure again. Of course, as long as we have the infrastructure to go back to the old way of doing things, it is not a big problem. So I'm not worried at the moment. But one of the end goals of using CDN is to reduce the number of Debian PoP (have Debian machines in a fewer number of datacenters, to make them easier to manage). Once we do that, it will be very hard to go back. We're not going to reduce the number of POPs significantly by using a CDN, and it's not the goal either. https://lists.debian.org/debian-project/2013/06/msg00164.html talks more about the initial motivations for using a CDN. Have you been trying to reach out to other CDN providers about supporting Debian? I know of discussions with Amazon CloudFront, but I remember some technical blockers? I'd like to get the services working well with one CDN before I start engaging others. Could the DPL be of some help to you in that process? I talked with James Bromberger at LCA, so contact is already established there. We're also talking with at least one other CDN, so I don't think we need any help in that area right now. We'll let you know. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2fvnt2go1@rahvafeir.err.no
Re: mailing list auto subscriptions
]] Holger Levsen Those 3-4 lists should be read by anyone (as in DD/DM) anyway. This way, we'd gently push new contributors to lists we'd expect them to read anyway... I think they should be reading those lists (well, those appropriate for them) before they become DDs, so I'm not sure how useful auto-subscribing people is. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/877g98spdp@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] Florian Weimer * Tollef Fog Heen: There's not really anything to be fixed, since you shouldn't be using HTTPS for that host yet. Can't they serve it off an IP address that doesn't answer on 443/TCP, to avoid confusion? It would be technically possible to do so, but the network's not set up that way and I see little point in spending effort on changing that. (If we do change it, we should change it to be served using HTTPS and with a local copy of resources, else you'll just end up with warnings about mixed-content pages.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/878utrulwg@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] Tollef Fog Heen Hi all, - the various bits and bobs that are currently hosted on static.debian.org I thought it's time for a small update about this. As of about an hour ago, planet and metadata.ftp-master are now served from the Fastly CDN, and it all seems to be working quite smoothly. We've uncovered some bits we want to make work better, such as adding and removing backend servers automatically when they become unavailable or are added to the static DNS RR, purging content from the caches when it's updated and possibly some other minor bits. This does sadly mean we don't currently have IPv6 for those two services, something that's being worked on by Fastly. As for the privacy concerns raised in the thread, I've had quite a lot of discussions with Fastly about how they operate wrt privacy. They don't store request-related logs (only billing information), so there are no URLs, cookie, client IPs or similar being stored. Varnish has an ephemeral log which they go through a couple of times a minute where some of that information is present, but it never leaves the host (unless we enable logging to an endpoint we control). I'm quite content with how they're handling the privacy concerns. In the interest of full disclosure I should also mention that I'm starting to work for Fastly in a few days time. I don't believe that has influenced my views or judgements here. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/877g9h1vh8@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] Craig Small On Thu, Jan 30, 2014 at 01:53:55PM +0100, Tollef Fog Heen wrote: I thought it's time for a small update about this. As of about an hour ago, planet and metadata.ftp-master are now served from the Fastly CDN, and it all seems to be working quite smoothly. https://planet.debian.org/ gives a big scary certificate warning. Well, yes. We didn't have HTTPS before and we don't have it now either. One reason to not have it is that you'd have a ton of «insecure third party resource» warnings. Ganneff said he'd take a look at having Planet download those resources locally when he has some free time. Until then, planet is HTTP-only as before. (We want to do this anyway to avoid leaking information about people who read planet to those running the hosting for various blogs.) Interesting way they've stapled all the names together on the certificate too. I didn't know you could do that, but, you might like to tell them to fix that certificate. There's not really anything to be fixed, since you shouldn't be using HTTPS for that host yet. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/878utw8zks@xoog.err.no
Re: Debian services and Debian infrastructure
]] Stefano Zacchiroli So, in the end, this sounds like a good match-making situation. If you're worried about demand how about mentioning this in a future DSA mail to d-d-a? (No, I don't think this thread is enough visibility, especially considering the conflictual parts it went through.) Just ask people that would potentially use this service to let you know. It was mentioned in our sprint report from last June and has been in the minutes posted later. I don't recall anybody (apart from Lucas) saying at anything at all about it, on the list or in other forums such as IRC. Yes, we could have mentioned it on d-d-a too, but given it's posted both here and mentioned in a Debian news mailing, I think I think it's indicative that there's no great demand based on us not seeing any responses. If people don't express enthusiasm for a service, it's quite likely it might not get worked on. I, for one thing, would be interested in something like this. To be clear, I don't have anything which is currently *waiting* for this. Your interest is noted, thanks! -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r47zhwrg@qurzaw.varnish-software.com
Re: Debian services and Debian infrastructure
solution. However, it seems that it requires manpower and resources that DSA does not really have for now (I would happy to help if possible with the 'resources' side -- I can't do much about the 'manpower' side). That's something we should work on so that ultimately, e.g. 1 or 2 years from now, we reach that point. We have a rolling five-year plan for our hardware replacement schedule which I'm sure you're familiar with. As long as we keep up with that, I don't foresee any particular problems. If somebody shows up with a huge service that might change, but as it is now, we're quite ok, resource-wise. But I don't think that we should wait 1 or 2 years to solve that general problem. That's why I'm exploring a compromise and temporary solution, which is using resources from public clouds. I will be very happy to drop that solution as soon as we have a DSA-provided one. There's no solution as permanent as a temporary solution. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2k3drvfey@rahvafeir.err.no
Re: Debian services and Debian infrastructure
]] Charles Plessy Personally, I am totally confused by what I read, and do not understand what is even the basic stand point of each participant. May I suggest that you talk directly face to face or by videoconference ? You're of course free to suggest that, but if you read the initial mail in the thread you'll see that this is an attempt at bringing this discussion into the open, where it belongs. Taking it off to some other medium will work directly against that. For me, the take home message is: - Do not develop services that need you to have administrator access, because this is hard to transpose on DSA-hosted machines. No, because it's a terrible idea in general. If your service requires you to have root on the system, it's probably misdesigned. - Sevices on debian.net should be hosted by Debian as much as possible. Rather, Debian should self-host our own services. What their domain name is is less important. After many years as a DD, I became better at using a machine via root privileges than via collective hosting. For instance, I completely forgot how to use CPAN, and I am much more comfortable configuring apache via /etc/apache2/sites-available than via .htaccess files. Also, by my activity of a DD, I am more familiar with Testing-Unstable mixtures than with Stable. For example again, I did the apache 2.4 transition, where the Debian Apache team made a great work, and I would prefer to forget how the 2.2 systems work. If you look at the various setups, you'll see that it's not uncommon for us to give service admins write access to their vhost setup, so there's hardly any conflict between that and not having root. As for mixing testing and unstable in production, I hope you see why that is not a great idea on a production system. I think that if I enjoyed collective hosting, I would have used it through numerus commercial providers, and would not have become a DD. At work, I would happily install software in my home directory on our CentOS servers, and would not mumble regularly that we need access to a cloud system instead. Installing random software in your ~ instead of from packages is a really bad idea since there's then no central record of what's installed, there's no uniform way to upgrade the packages, etc. All the usual reasons for why we use packages rather than building stuff from source. But now I have the impression that self-hosting it is very unwelcome, and that the bar for setting up a .debian.net service is very high. If you're hosting it yourself, ask two questions: Does this (or will it, in the future) provide a valuable service to Debian? What happens when you lose interest or get run over by a bus? If the answer to the first question is yes (which I hope it is, since else why are you spending your time on it?) you should have a good answer to the second question. My answer is «it runs on Debian infrastructure, so the underlying OS is maintained, the hardware is maintained and we're able to grant other interested DDs access to the service». I think any reasonable answer that satisfies the same conditions basically means you're duplicating the work DSA are already doing, which is inefficient. If you do have a good answer that doesn't imply a waste of resources, where the OS and hardware is maintained and where we, as a project, can have some reasonable level of service contigency expectation even in the case of catastrophic failure of the service owner then I'd like to hear it. I am not asking for an answer now since you need to clarify a lot of points together. I understand the need for transparency, but on the other hand, posting your discussion on -project gives the implicit message that the other subscribers should read it. No, it means we think that other people should be able to read it, which is not the same thing. I have no opinion on how the subscribers of our mailing lists spend their time. Please take your time and consider using parallel and more casual discussion channels, to focus the postings on -project to the points of agreement that you reached, rather than the points of disagreement, which we all hope are just transient. I'm not going to do this for the reasons outlined at the top of this email. If this thread bothers you, just ignore it. Heck, it's not as if -project generally has that much traffic, so just skimming it shouldn't take that many minutes out of your day. I find it really disappointing to hear that you would rather have discussions with project-wide ramifications to be held in secret, rather than out in the open. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m238kfuq17@rahvafeir.err.no
Re: Debian services and Debian infrastructure
]] Lucas Nussbaum On 21/01/14 at 15:07 +, Stephen Gran wrote: I think there's quite a range of options between DSA can't host everything under the sun and I'll go set up a private parallel development environment out of project funds without any further discussion. I don't know who you are quoting here, but I never said that I would go set up a private parallel development environment out of project funds. If you think that's what sgran wrote, you might want to read again. [...] I have some operational questions about this cloud setup, since it seems you've delegated running Debian owned machines to us and then gone and got some that you don't want us to run. I'm not sure what to do with that disjuncture. I don't know what you are talking about. Where did I got some Debian owned machines that I don't want DSA to run? Those VMs are machines. They're not owned by the individual developers (quite obviously), so they're owned by Debian. The DSA delegation you sent less than two weeks ago include: - Setting up and administering Debian-owned machines, ensuring that they are kept secure, operational, and running. so it's quite clear to me at least than any VMs owned by Debian falls under that umbrella. Separately, given how upset you got after having a request to add a member to the DSA team Cc-ed to debian-project, I think you're completely out of bounds when you're informing DSA (and others) that you're working on setting up parallel infrastructure by mailing debian-devel-announce. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87k3dte21y@xoog.err.no
Re: Debian services and Debian infrastructure
on such cloud infrastructures? That would ease the monitoring of which services are being developed, and help with getting involved early in the design process. Given we don't lack for computing resources, I think the answer to that question is «mu», and I don't think we should be looking at this. Q3. What should be our definition of official services? [ The debian.org DNS domain name is often associated with official services, whereas the debian.net DNS domain name is often associated with unofficial services. Besides the d.o/d.n distinction, I'm not aware of another definition of official services in Debian ] Even if this is highly preferable, I don't think that official services (.d.o services) should necessarily be running on Debian hardware managed by DSA, provided that: - the service is clearly useful and used - the service has a sustainable maintainance model (active team + instructions on how to contribute, run a local copy, etc. + DFSG-free) - the service's design does not raise security or scalability concerns Unless the service maintainer takes full-stack responsibility for this (in which case, they're basically replicating DSA's job, which means extra coordination costs), there will be security concerns. In fact, I think any non-readonly service running on non-DSA-managed hardware, is a security concern. Openssl.org is the most recent example of why. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2wqhtujnx@rahvafeir.err.no
Re: GR: Selecting the default init system for Debian
]] Daniel Pocock E.g. if we choose systemd, who will implement all the things that need to be changed outside the Gnome related packages? What will immediately fail if not adapted to systemd? In general, nothing should fail. sysvinit scripts are first class citizens in the systemd world and you can have native → sysv → native dependencies. There are some bugs, both in systemd and in init script (such as cycles), but in general this hasn't been a big problem so far. I believe that the ease of maintenance and the ability to do more with native systemd units (private /tmp, network namespacing, etc) will make it interesting for maintainers to move towards native units by themselves, but there's no flag day involved for a switch-over. So, I'm not sure what you mean by «all the things that need to be changed outside the GNOME related packages». If you have any particular things in mind, please feel to enumerate them and I'll answer to the best of my ability. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/877g9ws2q0@xoog.err.no
Re: Please update the DSA delegation
]] Martin Zobel-Helas Welcome to the team, Héctor! - Maintaining the central user (LDAP) database listing all the Debian developers. This includes: I don't think the delegation should specify the technology for handling user accounts. If we want to switch to another technology, that shouldn't require any changes in the delegation. [...] - Setting up and administering Debian-owned machines, ensuring that they are kept secure, operational, and running. Technically, Debian doesn't own anything, yadayada. Not sure what a better phrasing might be. [...] - complete install requests for porter chroots This isn't really done by us any longer, since it's self-service so should probably be dropped. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87fvq8z43t@xoog.err.no
Re: Please update the DSA delegation
]] Charles Plessy Le Thu, Dec 05, 2013 at 01:35:38AM +, Ian Jackson a écrit : But the main point here is that the team should normally be able to manage its membership directly. That's how these things have often been done (sometimes with no explicit DPL rubber stamp, even). I think that we need both. While the DPL is not the best person to bring new members to the team, it is the best person to ensure that the team does not accumulate too many inactive or barely active members. No, the DPL is not in a good place to do that. How is the DPL to know which of the DSA members who are active and not? If membership is fluid, there is no need to keep a title just in case, and I would prefer the DPL to be actively questionning memberships each time the delegation is renewed. I would prefer if we could just self-manage and not have even more process around routine changes. Debian generally has more than its share of process already and we should not actively work towards adding more formalism and red tape. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87bo0vzszw@xoog.err.no
Re: Code of Conduct: picking up
]] Thorsten Glaser «Malware, short for malicious software, is software used to disrupt See. This isn’t software. It is a perfectly valid string of Unicode characters. You might want to read http://ansuz.sooke.bc.ca/entry/23 . Intent and context matter. I find your continued lack of understanding that what you did was wrong worrisome and fear that it shows a lack of good judgement in other areas too. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87li03z2ec@xoog.err.no
Re: Code of Conduct: picking up
]] Thorsten Glaser On Thu, 28 Nov 2013, Tollef Fog Heen wrote: You mean you were using Debian resources to spread malware, and it seems You’re ridiculous. That’s not malware and cannot spread either «Malware, short for malicious software, is software used to disrupt computer operation, gather sensitive information, or gain access to private computer systems.» There's a reason why I wrote malware rather than virus. Malware doesn't have to have any way of spreading by itself. Let me make you a simile. Back in the 1990s, we had the ping of death which for a while reliably crashed Windows machines that were exposed to it. Do you think www.debian.org should have sent out such packets to any hosts that accessed the web site? It's basically the same thing you're doing: you're using Debian infrastructure to perform a denial of service attack on people who use other platforms. you're not even apologising for it. I think that's pretty sad. You and me come from different cultures¹ then. I see nothing to apologise for. In my culture, what you're doing is on the same level as moving chairs around when you're with blind people and laugh when they fall over because they're sitting down on a chair that is no longer there. In my culture, that is called being a dick. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/874n6vpldi@qurzaw.varnish-software.com
Re: Code of Conduct: picking up
]] Thorsten Glaser This is true. While many of such jokes are probably something undesirable, some people go actively against any and all jokes of that matter (I’ve had that Arabic script crashing Apple’s text thingy in my .sig for a while, and got told off for it very brusquely, so I had to remember to actively switch .sig for when writing to Debian lists; and there are other cases that aren’t even that “offensive”). You mean you were using Debian resources to spread malware, and it seems you're not even apologising for it. I think that's pretty sad. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87iovcps79@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] anarcat I would also point out that none of the CDNs *publish* the software they develop as free software. They may *use* free software, but they built their business on proprietary software on top of our hard work. Maybe not all of their software, but a blanket statement like that is simply wrong, take a look at https://github.com/fastly for some of what fastly's done at least. I'm not sure if Amazon has done something similar, but it wouldn't surprise me if they're pushing fixes for components upstream. Why wouldn't they? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zjoxbg0p@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] anarcat On 2013-11-20 16:43:35, Tollef Fog Heen wrote: ]] anarcat On 2013-11-14 10:37:21, Tollef Fog Heen wrote: Yes. If you're just anycasting an IP, you'll get pretty poor performance. Can you expand on that? BGP anycast will just get you the closest one in term of metrics. This is probably the fewest number of cheapest hops. There's no guarantee those hops are going to be the shortest or fastest. It doesn't mean you will necessarily get poor performance, you may, but then it's part of the idea of running BGP: you choose the paths.. Not really. You choose some. There are other players that will manipulate paths to save themselves money or bandwidth too, so it's all a bit like a real-time strategy game. I guess I am worried about forcing CDNs down the users' throats. I'd like us to keep a decentralised infrastructure that doesn't depend on those CDNs and allow people to run their own mirrors. Hopefully that will still be possible. Nobody has talked about taking away rsync which you can use to run your own mirror. debmirror and others also support mirroring over HTTP so you'll always be able to able to mirror if you want to. Whether that's possible has little or no bearing on if ftp.$cc.d.o is the default apt download location or if it's some other CDN-ed name. (Which isn't what we're talking about initially, but a point we might eventually get to, some years down the line.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87y54hbg0l@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] anarcat On 2013-11-14 10:37:21, Tollef Fog Heen wrote: Yes. If you're just anycasting an IP, you'll get pretty poor performance. Can you expand on that? BGP anycast will just get you the closest one in term of metrics. This is probably the fewest number of cheapest hops. There's no guarantee those hops are going to be the shortest or fastest. You need monitoring to make sure the mirror is up to date and something that automatically updates DNS when it isn't, and puts it back in when it is. That is a problem we're having already, and that we'll probably have with commercial CDNs, or at least that we'll have to resolve so get a consistent state across the mirrors. Yes, and we're doing a terrible job at it. It's a manual job right now, and there's essentially a single person doing that job. I'm not trying to pick on him, since he's doing as well as he can, but it's the wrong way to go about solving the problem. CDNs have infrastructure for distributing purges, so we'd just go «nuke all your Release and Packages files» and assuming the CDN isn't too bad, they'd be gone a few hundred milliseconds later. If you're going to do anycast, you'll need to have BGP announcements sent from a diverse set of places. This seems like something we have, with the variety of mirrors out there. :) We don't. Debian doesn't run its own AS, we don't have peering agreements and we don't announce anything anywhere. We don't have any interest in doing so either. It's not what we think is fun, nor what we're good at. I guess what I am saying is that doing incremental improvements over the mirror infrastructure should be considered. I am worried that migrating to a commercial CDN will be detrimental to the current infrastructure, which are based on a spirit of free access and open knowledge, something commercial CDNs seem to be alien to... We've waited for somebody to step up and actually do that. Nobody is doing it. Lots of proof-of-concept services out there, but nothing that's solid, tested and production ready. How long would you like us to keep the current state before we actually do something about it? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87mwkyda0o@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] anarcat All the tools currently running the Debian mirror architecture. Some mirrors may run an FTP mirror on a non-free software, but they don't *have* to, and we unfortunately can't control that. No, they can't. You can't route a packet through the public internet without it hitting non-free software. Heck, you can't get a normal server that will run without non-free software. (If nothing else, firmware for the ethernet controller or the firmware for the EC or disks.) This is not a two-tone discussion and trying to make it one will not lead to a useful outcome. Yes, it's extra work, but it's feasible. The question is: do we want to keep on running our own CDN, or do we want to give up? I say we should keep doing it. Autonomy is important for our community. And a commercial CDN will come with strings attached - Gimp just moved off Sourceforge for that reason... It's not a vote, and it's easy for the people who do not have to do anything but send mails to a mailing list to say «we should spend more effort». -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87fvqz8eub@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] anarcat On 2013-11-14 05:20:12, Tollef Fog Heen wrote: ]] anarcat All the tools currently running the Debian mirror architecture. Some mirrors may run an FTP mirror on a non-free software, but they don't *have* to, and we unfortunately can't control that. No, they can't. You can't route a packet through the public internet without it hitting non-free software. You can't *right now*. I assume you are talking in part of those cisco switches that litter the network, and I can tell you a lot of people are tired of those - for example Facebook (of all places...) is building an open alternative for those. I'm not aware of any open source 40GE PHYs for instance? Most of what I've seen done is around SDN, which is all nice and good, but doesn't actually make the PHY and MAC firmware free. I haven't been trawling around, so maybe it's further ahead than I thought. Heck, you can't get a normal server that will run without non-free software. (If nothing else, firmware for the ethernet controller or the firmware for the EC or disks.) Sure, but we at least try. A lot of great people are working on coreboot and such initiatives that go a long way, probably farther that we've ever been, in making sure that the stack is as open as we can. Even if you restrict yourself to the main UEFI implementation, can you even get anything free for a modern server there? With warranties? Having to void your warranty to run a free UEFI implementation is not something we'd like to do. This is not a two-tone discussion and trying to make it one will not lead to a useful outcome. And saying that because there's proprietary firmware in your BIOS it's okay to offload all of Debian's infrastructure to a non-free CDN is okay seems to me to be a slippery slope. Nobody has talked about moving all of Debian's infrastructure. It's not a vote, and it's easy for the people who do not have to do anything but send mails to a mailing list to say «we should spend more effort». Well, if it's not a vote, and if my opinion doesn't actually matter, why are we discussing this on -project in the first place? We were hoping to get some useful feedback. [...] And the improvements necessary to get this to a commercial-grade CDN doesn't seem to me like much more: some IP alias on the mirror machine, and BGP announcements. Am I missing something? Yes. If you're just anycasting an IP, you'll get pretty poor performance. You need monitoring to make sure the mirror is up to date and something that automatically updates DNS when it isn't, and puts it back in when it is. You need to herd the mirror operators, keep them happy, make sure they're using the right tools so you don't get transient breakages in the middle of a mirror run. If you're going to do anycast, you'll need to have BGP announcements sent from a diverse set of places. You need to monitor your BGP stuff, trace down why you get suboptimal routing for a given user and get that fixed. You'll need to run GeoDNS and correlate that with routing so hopefully, the user hits the best server. And that's just a few items off the top of my head. Running a CDN is not hard. Running a CDN well, over time, is hard. It's something that DSA would not add value by doing ourselves, just like we would not add value by creating our own OOB solutions or soldering together our own UPSes. It's not that we can't, it's that it's cheaper and more reliable to buy a ready-made solution and most important of all: it's not part of our core mission. It's a means to an end, not an end goal in itself. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2iovv6lla@rahvafeir.err.no
Re: Should mailing list bans be published?
]] Stefano Zacchiroli On Mon, Nov 04, 2013 at 02:51:52PM +0100, Tollef Fog Heen wrote: So, what would be the beneficial social effects of publishing the ban *duration*? The ban duration is an indication of how severe we think the violation is. You don't get a lifetime ban for a minor transgression and you don't get a one-day ban for serious harassments. Of course. The question is: do you think disclosing ban duration will discourage bad behavior on our mailing lists more than just disclosing the bans currently in effect? (I don't.) To the extent that publishing the bans in the first place is going to help: yes, I think so. Another important point is it will enable more oversight so you can see that a ban was instated at $time and is due to be removed at $time+$x, but now $time+$x and it's still not removed and it's the possible to poke the relevant people to get it fixed. If the expiry is unknown, you have no idea if the ban is still there on purpose or not. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ppqfqktr@qurzaw.varnish-software.com
Re: Should mailing list bans be published?
]] Stefano Zacchiroli So, what would be the beneficial social effects of publishing the ban *duration*? The ban duration is an indication of how severe we think the violation is. You don't get a lifetime ban for a minor transgression and you don't get a one-day ban for serious harassments. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/877gcos29z@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] Stefano Zacchiroli For the specific case of CDN offerings to the Debian Project, the point---well, my point, I respect the fact that others disagree it's a problem---is whether we're going to force our user to receive the Free Software we're distributing via infrastructures built using non-free software. That problem would exist even if the companies behind those services were big Free Software advocates, which just happen to have a single service (the CDN) built using non-free software. You seem to be under the impression that CDN implies non-free software. Fastly uses Varnish (which is free software). Cloudfront uses Apache (which is free software). I'm sure there are CDNs using non-free software too, but that doesn't seem particularly relevant. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zjpsv0pp@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] Stefano Zacchiroli On Tue, Oct 29, 2013 at 11:19:14AM +0100, Tollef Fog Heen wrote: You seem to be under the impression that CDN implies non-free software. Oh, no, not at all. I'm just saying that we should judge CDN offerings on the basis of the kind of software they're build upon, and not on the basis of how much the companies offering them advocate Free Software. I don't believe we ask mirror operators what OS their mirror runs on or whether it's free software today. While I'd like both them and a CDN to use free software, this doesn't look like it'll change anything from current practice. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/871u34us83@qurzaw.varnish-software.com
Re: Possibly moving Debian services to a CDN
]] Nikolaus Rath - You can use an IP anonymizing service such as Tor. Are you suggesting to download debian packages over tor? Last time I used it, I got about 25 kB/s of bandwidth. But even if that has changed, I'm pretty sure the tor network isn't intended for bulk transfer of the debian archive... «such as». They're not the only one, and I wasn't suggesting running a full mirror over it. Downloading your daily package updates over it is likely to be slower than your regular network connection, but when I just tested it was at the level of some megabits. If you're actually seriously concerned about privacy and worried about government-level organisations using package download data for tracking you, you should use something like tor, yes. I personally think that's overly paranoid, but I'm not going to tell people they're not allowed to turn their paranoia dial all the way up. (Using paranoia here for lack of a better word; no disrespect meant.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87wqle7ito@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] Ingo Jürgensmann Am 14.10.2013 um 07:29 schrieb Tollef Fog Heen tfh...@err.no: - I would like us to have agreements with any donors that they're not allowed to use the information for anything but operational issues. We can't tell them not to log (because that's really hard on a technical level), but we can restrict what they can do with the logs. True. You can request agreements, but as the whole NSA affair is showing: it doesn't matter when it comes down to NSA Co. There are secret courts with secret decisions and National Security Letters for silencing the providers, although internal agreements like Safe Harbor do exist. So, whereas agreements can be made, there will be no way for Debian to control whether they are being held or not. I'm fundamentally of the opinion that if the NSA or a similar organisation wants to track you and is willing to expend that effort on tracking you in particular, there is just about nothing you can do about it. As you note, we can't actually control it, just like we can't do it today, so the difference becomes «lots of mirrors, vulnerable to smaller attackers, but hard to coordinate MITM-ing» vs «fewer mirrors/CDN nodes, requires more effort from attackers, easier to MITM». I don't think it makes that much of a difference in terms of cost if the attacker has that many resources and is willing to expend the effort. It seems you disagree, and I don't really see us agreeing here, as it's a question of tradeoffs and you weigh your tradeoffs differently than I do. 2) Integrity concerns: although Debian uses signed package lists and hashed packages, using a CDN would raise the chances that there might be attack vectors by manipulating the traffic. Maybe not be the will of the running company, but there are other groups that might have interest and the power to intercept traffic and manipulating it. This is, of course, also true to current mirror sites, but a centralized CDN will be more convenient to such kind of attackers. Given we don't use HTTPs and such today, you don't know if the traffic is actually going to the mirror you think it's going to, so this isn't really different from today. With a CDN we could actually push more of the traffic to HTTPS if we wanted. This isn't feasible with today's mirror network. That's a valid point of you, thanks! The use of HTTPS should be encouraged, of course. How would HTTPS with a CDN work? I would believe that the CDN provider will use some kind of SSL proxy or SSL interception techniques. Otherwise you would have the same problems with managing HTTPS with the current mirror network. There are probably these possible ways: a) CDN provides an HTTPS entry point, but connects to the underlying mirror by plain HTTP. b) CDN uses DPI and SSL interception to break end-to-end encryption You upload your cert and key to the CDN, which then does HTTPS to the client. Whether they do HTTPS to the backend or not depends on the CDN. I know at least some do. [...] Anyway, I think the discussion about using a CDN is not about technical aspects, but it's a political debate that needs to b held and finally a political decision have to made whether Debian as a Free/Libre Software project/distribution wants to use a CDN and accept the risks that come with that or not. Right, there are technical hurdles we need to overcome. If we can't overcome those in a reasonable fashion, the whole exercise becomes pointless. Personally I believe, that using a CDN would make live of DSA more easier (you wrote something in a different mail today that current CDN breaks on a weekly basis. Can you elaborate this, maybe on wiki.d.o?) and it might be easier for users. The breakage I'm seeing is from apt-get update failing on various hosts around the world. It's usually fine if it's retried 5s later. And yes, the goal here is to free up volunteer time as well as get a better experience for the end user. OTOH I have great privacy concerns of using a CDN. And when the current mirror network will still be maintained, where's the benefit for DSA and the users then at all? Having freedom of choice is always good, so I'd be fine with keeping current mirror network, but having a cdn.debian.org in parallel. When doing fresh installations people should be made aware of privacy concerns when using the CDN (like: Using a CDN might be easier and faster for you, but Debian doesn't control the CDN and cannot guarantee privacy and data protection). That implies we can guarantee privacy and data protection for other mirrors, which we can't. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87siw27ibt@xoog.err.no
Re: Possibly moving Debian services to a CDN
]] Philip Hands Tollef Fog Heen tfh...@err.no writes: ... Nobody has suggested removing the mirror network. What's being discussed is using a CDN for some .d.o services. That was certainly not clear from your original post. I certainly read you as suggesting that some services could be moved to third-party CDN(s), with an eye to moving ftp.debian.org there to, with the implication that the mirror network would then become mostly redundant. «Become redundant» is not the same as being removed, though. It would initially be something we ran alongside the regular mirror network (anything else would be crazy for what I think are obvious reasons). If our experiences are then positive, we might want to stop relying on the mirror network in say, d-i, but there's not central planning committee shutting down any mirrors. Local mirrors choose whether they want to carry Debian or not, and I suspect many of them will want to use the resources for other things if the usage falls below a threshold. Whether that actually happens or not amounts to predicting the future, something I'm not going to try to do. Does that make it clearer, or is it still confusing? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87txgk5839@qurzaw.varnish-software.com
Possibly moving Debian services to a CDN
Dear Project, The System Administration Team (DSA) are considering moving some of the static hosting that Debian currently provides from our infrastructure to one or more CDNs. We have received feedback indicating that a broader discussion is desired. Debian has, for over a decade, operated its own form of a content delivery network (multiple variants, actually) by leveraging our own infrastructure as master sources and community-provided infrastructure (primarily from universities and regional network providers) for local distribution. This «proto-CDN» has required users to select the mirror 'closest' to them. Recent efforts (http.debian.net, cdn.debian.net) have attempted to alleviate the configuration challenge of pre-selecting a mirror node. In the commercial world, this challenge has been addressed through a mix of anycast DNS redirection and geo/BGP-based DNS views to local distribution nodes hosted at ISPs. Akamai is the best known CDN but other significant players include Amazon and Fastly and a host of other more specialised CDNs for example for video. In the DSA team's view, CDNs have become sufficiently mature for Debian to consider leveraging external service providers for our CDN needs. We have approached several providers and they have agreed, in principle, to sponsor bandwidth and storage for Debian's CDN needs. This allows us to consider combining the efforts of http.debian.net, cdn.debian.net, static.debian.org and the mirror network under a single effort to provide our users with the most transparent access to Debian public resources as possible. We appreciate that there are some sensitivities regarding the use of commercial service providers and/or our reliance upon them. Our mitigation strategy is to utilize multiple CDN service providers so that we can survive the loss of any single one (with quick change-over via DNS record modification). The concern regarding commercial entities support Debian activity is somewhat misdirected given our reliance on sponsors (often commercial) to support Debian and DebConf. For many years, Debian survived on the good graces of HP, for example, who provided cash and in-kind donations. Ultimately, we are of the opinion that the content delivery problem is a solved one and it behooves us to investigate whether CDNs can benefit Debian. There are several technical challenges that we must overcome. In particular, CDN offerings are very focussed on HTTP/HTTPS while Debian has a strong reliance (and strong desire to continue to use) other protocols such as rsync. Also, since CDNs primarily utilize CNAME records, they are incompatible with email service for that particular domain name. The address t...@security.debian.org is a good example here. In addition, using a CNAME means all services are redirected to the CDN, not just HTTP, which is incompatible with rsync. We are working with CDN service providers to find a resolution to these technical challenges and we hope to be able to report successful resolution in the near future. The services that we consider would benefit from a move to a CDN are: - ftp.debian.org - www.debian.org - security.debian.org - the various bits and bobs that are currently hosted on static.debian.org There has been concerns that switching to a CDN would harm our existing relationships with mirror operators and make it impossible to go back if we later wanted to do so. The ftp mirror network is one of the most important mirror networks, so we wouldn't have to start with that. We could start with (for instance) www.debian.org and only later move the actual package mirrors over once we are confident CDNs are not a passing fad. It will also take time to coordinate switching to a CDN with all the country operators, we do not wish to undermine the existing relationships or upset anybody needlessly. Assuming that our experiences are positive, we don't believe it will be interesting to go back, and even if one CDN folds, they are fast becoming a commodity so we think switching to another will be fairly easy. We appreciate feedback while we continue our investigation of CDNs. Thanks for your interest, -- Tollef Fog Heen for the Debian System Administration team -- 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/m24n8lacuv@rahvafeir.err.no
Re: Possibly moving Debian services to a CDN
]] Russ Allbery Joey Hess jo...@debian.org writes: Ultimately, we are of the opinion that the content delivery problem is a solved one But apparently not one solved by free software included in Debian. Perhaps it's worth avoiding using it if that will help encourage the development of libre alternatives. Quite a few of the CDNs use free software. Both Varnish and squid are used, for instance. CDNs aren't really software problems. They're infrastructure and network peering problems. I think all the software required is in Debian, but the data centers, peering arragements, route advertisements, and so forth are things that only make sense to do at a larger scale than a single project. This is the main reason. The commercial CDNs are in a position where they have more manpower and can scale better than we can because of volume. We can do a home-brewed CDN -- that, after all, is what the various services referenced in the original message are. But one of the commercial CDNs will have better performance and better load distribution than one can do with software-only solutions without the peering setup and data center distribution. We are already running CDNs, multiple of them: The mirror network, the security archive network, the web pages and a few more. What we don't have is the manpower and the infrastructure to run and maintain this as well as a CDN that does this as its primary business. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2txgk8mrl@rahvafeir.err.no
Re: Possibly moving Debian services to a CDN
]] Ingo Jürgensmann 1) Privacy concerns: Debian would deliver much more data to business companies than necessary. Keep in mind that personalized data is one of the most valuable things to data miners. Currently I choose one mirror site to pull my packages from. I can freely choose that mirror on basis of location, bandwidth, personal likes or, let's say, privacy reasons because I know that this specific mirror doesn't log my IPs. When using a CDN, at least in that way I understood your proposal, I'm not free to choose anymore. The company running that CDN will obtain all of data like how many machines are behind a subnet or IP, what kind of machines (intel, sparc, powerpc, m68k, ...) and might know if I forget to update a machine (security). This is absolutely a valid concern. I have a few mitigation strategies and one observation: - You can still run your own mirror. We need that ourselves and like I wrote in the initial email, we need to find a way that keeps rsync working. - You can use an IP anonymizing service such as Tor. - You can use a local proxy that hides the details of how many nodes, etc. you have. - I would like us to have agreements with any donors that they're not allowed to use the information for anything but operational issues. We can't tell them not to log (because that's really hard on a technical level), but we can restrict what they can do with the logs. The observation is that we currently don't have any such control over mirror operators. They are, AFAIK, free to use whatever information they collect for whatever purpose they would like. 2) Integrity concerns: although Debian uses signed package lists and hashed packages, using a CDN would raise the chances that there might be attack vectors by manipulating the traffic. Maybe not be the will of the running company, but there are other groups that might have interest and the power to intercept traffic and manipulating it. This is, of course, also true to current mirror sites, but a centralized CDN will be more convenient to such kind of attackers. Given we don't use HTTPs and such today, you don't know if the traffic is actually going to the mirror you think it's going to, so this isn't really different from today. With a CDN we could actually push more of the traffic to HTTPS if we wanted. This isn't feasible with today's mirror network. 3) Surveillance concerns: together with 1) and 2) goes this one... Using a CDN would make it easier to secret services to collect data, because they have a single point where they can get all wanted data from instead of monitoring several providers and connections. CDNs generally don't have central logging at the request level. There's just no way for them to do that with the data rates you're looking at. Also, can be mitigated with chucking HTTPS at the problem. 4) Dependency concerns: as a project Debian should be as independent as possible. Using a CDN provider will create a big dependency to a specific company, although we might be able to shift companies from time to time. Using multiple CDN providers will mitigate that concern a little bit, but only to a certain degree. Having too many CDN providers will be as difficult to handle as now the many FTP mirror donators. So, there's some trade-off anyway. As I wrote in the initial email: CDNs are becoming a commodity. Switching from one provider to another isn't hard, and we already have offers from multiple CDNs, so I'm not particularly worried about this. Were it harder to switch, it would be different, but luckily, it's fairly easy. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2ppr88lp0@rahvafeir.err.no
Re: Possibly moving Debian services to a CDN
]] Paul Wise About the archive mirrors, some reworded thoughts from the DPL IRC channel when this came up a few days ago: pabs [...] I think the current state of affairs is fine; I don't believe you're one of the person who is doing the legwork in maintaining any of the CDNs we're currently running, so how would you know that? Because it's not visibly broken (most of the time)? I see it breaking on a weekly basis, if not more often. [...] Removing the mirror network won't be possible anyway, people are still going to create mirrors, especially ISPs will for their customers; due to quotas and distant mirrors being much slower. Nobody has suggested removing the mirror network. What's being discussed is using a CDN for some .d.o services. If somebody wants to continue running their mirror they will of course be free to do so. bguptaNot all CDNs support IPv6. We will want to use CDNs that do support IPv6. It's one of the technical bits that need to fall into place before we will want to switch. I would rather expand the mirror network. Does that mean you're volunteering for the task of doing this and maintaining the various existing CDNs? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2li1w8ldp@rahvafeir.err.no
Re: Possibly moving Debian services to a CDN
]] Andrew M.A. Cater On Sun, Oct 13, 2013 at 08:44:56AM +0200, Tollef Fog Heen wrote: Dear Project, The System Administration Team (DSA) are considering moving some of the static hosting that Debian currently provides from our infrastructure to one or more CDNs. We have received feedback indicating that a broader discussion is desired. Debian has, for over a decade, operated its own form of a content delivery network (multiple variants, actually) by leveraging our own infrastructure as master sources and community-provided infrastructure (primarily from universities and regional network providers) for local distribution. It works - tell anyone to use ftp.[country name].debian.org and it just works. If ftp.[mycountry].debian.org is down, use ftp.[neighbour country] .debian.org - and, crucially, it's all under one debian.org domain. Whether we use a CDN or not does not change that at all. (We might want to move everything towards using ftp.debian.org and just geolocate/anycast the CDN nodes and long-term deprecate the country based domains.) If managers/software licensing mavens/project funding authorities etc. question where your software is actualy from - it's from Debian themselves. To the same degree that it will be in the future. We don't run most of the mirrors ourselves, they're run by a bunch of third parties. Some of those are doing an excellent job, some are not. This is (potentially) good news for laptop/desktop users: instant access from closest mirrors. This is also an increasing trend: Firefox, Raspbian, Archlinux (I think) are all CDN served. One of the CDN offers we have are from the people that run the CDN for the pypi (Python packages) network. If you run behind restrictive firewall policies / in corporate land, it's not nearly so hot. Static long lasting mirrors are really useful here when you have to ask your network admin. to unblock firewalls for each IP address. That's not really that different from today. We move security mirrors every so often and they're geolocated so the ones you get in Europe and the US are not necessarily the same. If you want to configure 10 servers, say, or to build repeated groups of servers over a long time, it's good to have consistency and the existing network provides this. If the trend globally is to CDNs, however, it will be hard to buck the trend for the long term. If you want to, you can always run a local mirror. We are not trying to change that. There is nothing in the current setup that inherently give you any such guarantees. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/m2k3hg8lbn@rahvafeir.err.no
Re: Can CC BY 2.0 be upgraded to 3.0 ?
]] Bas Wijnen Sure, but if you have a program, then that is an original work. No. #! /bin/sh echo hello world is not a work. It is not copyrightable. It does not bring anything new and original into the world. Norwegian copyright law talks about «work threshold» as in a bar you need to clear for something to be copyrightable. I believe this is what Russ is talking about. (Russ, please correct me if I'm wrong here.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87li2y9uju@xoog.err.no
Re: Authorizing minor expenses by DSA without prior DPL approval
]] Lucas Nussbaum I like this idea of max outstanding of $300 instead of an explicit time limit. But I think that your proposal makes it possible for DSA to not get reimbursed if the DPL is grumpy and decides not to approve the expense. I would rather use DPL acknowledgement than DPL approval. First, thanks for pushing this forward, much appreciated. So, new proposal: DSA is allowed to make expenses and get reimbursed by Trusted Organizations for up to US$300 to support the operation of Debian infrastructure (pay shipping costs, purchase of cheap hardware such as cables, replacement disk, etc.). Given we're not buying the cheapest disks we can find (since they have worse warranties, etc), replacement disks quite often ends up at approximately the $300 mark, maybe make the limit $400 or $500? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87ioypiykr@xoog.err.no
Re: PaySwarm-based Debian donations
]] Manu Sporny On 06/16/2013 06:26 AM, Stefano Zacchiroli wrote: OTOH, I think it would be fine to have something at the package level to pass on donations to our upstreams, as well as to ease donating to the Debian project as a whole. See [1,2], already mentioned by Paul Wise in his initial followup to this thread. Ok, so what if this system does not allow Debian package maintainers to specify where the money should go at all? There are only two options: 1. The upstream author includes a file called DONATE that specifies where donations should go. 2. If that file isn't specified, the money goes to the Debian Project. If so, I'd like a third option: I don't want donations for a given package at all. The only resource I'm interested in people donating (as a thanks for my work on my packages) is their time, not their money. Money is a very undemocratic resource, and I believe that tipping (which is what I consider small donations based on work done by an individual to a single package is) is denigrating and a blight upon the world. If they want to donate to the project because they're happy with Debian, that's great and something I think we should make easier and more visible. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87wqpr26jx@qurzaw.varnish-software.com
Re: [all candidates] Removing or limiting DD rights?
]] Russ Allbery (Cc to owner@bugs, M-F-T to -project.) Note that we already did do something about it by deprecating close in the BTS in favor of sending a real email message to -done that is copied to the submitter. The Debian BTS now nags the maintainer about telling the submitter something if they use the close command. We did this ages ago. Perhaps it's time to retire the close command entirely? -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87sj38p1tc@qurzaw.varnish-software.com
Re: license of http://udd.debian.org/ data collection?
]] Stefano Zacchiroli If I understand correctly what Jonas is aiming at, that's not (yet) a satisfactory answer. The license of a collection of a data might very well be different than the license of the individual pieces of data itself. I'm not expert on database licensing, but the underlying intuition here is that there might be a creative effort in assemblying the data, and that _that_ creative act might be copyrightable and hence have a license in itself. It's probably less about copyright and more about database rights. Facts aren't copyrightable. Database rights exist to grant some of the same protections that copyright grant, to database producers. There is no requirement for creative input, only that «there has been a substantial investment in obtaining, verifying or presenting the contents of the database.», which I think is the case for the UDD data. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87txrl9n3a@xoog.err.no
Re: Temporarily disabled Jonas's feed
]] Jonas Smedegaard Please pretty please someone either purge the Planet cache or tell me what embarrassing detail I am missing here. I have done it now. At least I think I have. ;-) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87zk3b85in@xoog.err.no
Re: DebConf travel sponsorship
]] Bernd Zeimetz That pretty much depends on your credit card company. My VISA card is from my normal bank and there is no delay at all, the money is just gone from my bank account as soon as I pay with it. That's a debit card, not a credit card, then. If invoices are required, then Debian should book flights for people or find some other solution to receive those documents, without asking people to book there flights in the hope that they will be reimbursed later - the result is probably that those people who are not able to attend without being sponsored are not able to come at all because they can't pay that sum in advance. I'd happily use my credit card to book tickets if I had an up-front commitment from Debian I'd be reimbursed, whether I needed to provide an invoice or not. (Heck, I (personally) would be ok with doing it off my debit card too, since I can afford the liquidity without wanting to bear the cost myself.) And of course, others might have tighter liquidity and so what you say applies. I just don't think it'll apply for everybody. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87r4sqpimq@qurzaw.varnish-software.com
Re: Claiming the debian account on GitHub ? [and 1 more messages]
]] Joey Hess Alessandro Ghedini wrote: If anything it may be nice to mirror some important Debian software (say dpkg, debhelper, lintian, ...) on GitHub like the Apache Foundation does [0] (also see [1]). AFAIK those mirrors are completely automated and would allow GitHub users to follow the development of a few interesting Debian projects. In my experience this leads to a raft of badly formed pull requests that I cannot triage while offline (see Linus's rant about no diffs) and that I have to pull up a bloated web app over https over a modem to look at; The pull requests show up as branches in your remote repository, so you can pull them using the normal git tools. No diffs in the pull request email itself though. I guess that's something github might be convinced to add if somebody asks. as well as random forks, none of which are communicated to me, and within some of which there might be value, but hunting it out is unlikely to be a good use of my time; as well as a crappy BTS (that can at least be disabled). Yeah, the random forks is quite annoying. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87d34yn8hr@xoog.err.no
Re: Claiming the debian account on GitHub ? [and 1 more messages]
]] Yaroslav Halchenko * If we start using this organization as intended (i.e. placing our clones for maintained software), since the listing of the repositories get sorted by recency, README.Debian will sink to the bottom thus killing its visibility and thus its intended purpose I'd recommend avoiding this, as people are likely to see pull requests for software and that'll break any naive mirroring of git repositories at least, since those branches show up as undeletable remotes. (As for having anything official of Debian on github, I don't think we should have it, since I think it's pointless, but I can't say it bothers me particularly much in one direction or the other.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87mx44w598@xoog.err.no
Re: Planned changes to Debian Maintainer uploads
]] Ansgar Burchardt We plan to instead implement an interface where developers upload a signed command file to ftp-master to grant upload permissions instead, similar to dcut. This could end up looking similar to this: Could we have an expiration date associated with the grants? I might grant somebody rights to a package, but want it to expire within $period (or at least be subject to more aggressive QA/MIA checks than a normal DD), since I'll be tied to them in a way. Cheers, -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87obopykrz@xoog.err.no
Re: Planned changes to Debian Maintainer uploads
]] Stefano Zacchiroli On Mon, Jun 11, 2012 at 04:48:17PM +0100, Jon Dowland wrote: That seems like a good idea, if we're in agreement that the point of DM is to be a bridge status whilst someone works through NM. I think that was the intention and presume it still is. I disagree that it is always the case. It might be a popular option (due to the fact that we highly encourage NMs to go through DM first). BUt there are many cases, at least according to my anecdotal evidence, of people who are more than happy remaining DM. I don't think we should make their life more miserable by ensuring they have to periodically re-ask for the permission to upload. Then make it contigent on the person having made an upload in the last three months or something sensible. Also, I don't think asking a DM to be reapproved yearly or every other year would be that onerous. (It's also the direction we're moving in for shell accounts on d.o as you know; people who don't use them will have to go through changes@db to reactivate their shell access.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87k3zdy74l@xoog.err.no
Re: General Resolution: Diversity statement results
]] Kurt Roeckx It's about to move to a new host, and I'm not sure if DSA is still going to give everybody access to that host. I imagine that depends on what the secretary asks us to, with us having a slight-to-medium preference for making it restricted. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87aa0e46ca@qurzaw.varnish-software.com
Re: Long-term hardware replacement planning (Re: (deferred) bits from the DPL: March 2012)
]] Filipus Klutiero Great. Is this plan written? If so, it would be a good idea to make it available. I'll see what we can get done. There's a bit of cleanup to be done, since we don't want to publish all the information from our spreadsheet of doom. It contains quotes and numbers from vendors which they've asked not to be made public. Ditto, I don't think there's much point in publishing the serial numbers of our various servers. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- 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/87vckxy2iv@qurzaw.varnish-software.com
