Re: Questions around Justice and Our Current CoC procedures
On Mon, Feb 21, 2022 at 08:51:51AM -0800, Felix Lechner wrote: > On Mon, Feb 21, 2022 at 8:29 AM Steve McIntyre wrote: > > > > This is getting worrying. Russ expressed sympathy about the bad > > effects that warnings could have on people, and you've somehow > > misinterpreted that as a direct attack on you. > > Thank you, but despite your condescending tone I retain the right to > interpret who expresses sympathy for me, and who does not. Then you need to start taking responsibility for creating conflict when there was none, which is sadly something I see as a recurring pattern in the way you participate in Debian interactions. Is this something you'd acknowledge and would be willing to work on? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Keysigning in times of COVID-19
Hello, we have people approaching Debian with a lack of GPG signatures, and we generally cannot ask them to travel and meet other developers in person to get their key signed. Technically, we are not requiring that people meet a DD in person, only that people have their key signed by a DD. Technically, every DD has their own policies for signing keys, which could go from not requiring meeting in person at all, to requiring to meet in person multiple times. It might require to check a government issued photo ID, or it might not. Practically, I feel like most of the time people's policies match what are the perceived expectations of the rest of the project. Meeting in person has always been a good safe bet, if only for the reson that it's been accepted without question for many years. It's time to review those expectations. For example, speaking of myself only, if my goal is to raise the cost of impersonation or sock puppet identities, then probably signing someone's key after having worked with them online for a significant time, would require a much higher cost than showing up at a keysigning party with a fake ID good enough to fool me. Others may have other policies, and are likely to be acceptable. As DAM, I would have a problem if someone automatically signed the keys of every stanger who asked them nicely in an email. At the same time, I am open to the idea of policies that do not require meeting people in person. I think the world has changed enough in the last months that currently perceived project expectations about key signing are getting out of alignment with practical realities, and it might be time to explore other options. I do not intend to ask people to break their sensible signing policies so that people can get into Debian. I'm interested instead in exploring what signing policies people may have, or may be considering, that have been staying out of our narrative because we've always been having a specific standard one that worked. What do you think could be alternative key signing policies, that would be acceptable to you, that would not require traveling and meeting face to face? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Debian infra services and tools looking for programming contributions
On Thu, May 21, 2020 at 03:36:15PM -0300, Antonio Terceiro wrote: > Not the part where I need your help. I'm looking for people who maintain > or contribute to a Debian infrastructure service or tool that could use > some help with programming, have the availability to provide some > mentoring for someone who is already a programmer but not necessarily > already involved with Debian, and would like your project to be > highlighted in such a talk. nm.debian.org: - code is at https://salsa.debian.org/nm-team/nm.debian.org and it has a README explaining how to deploy a local development version - Python, Django, or JavaScript[1] front-end help is always welcome - Plenty of issues to pick from https://salsa.debian.org/nm-team/nm.debian.org/-/issues and https://bugs.debian.org/nm.debian.org - People with experience with the code hang out in #debian-newmaint on OFTC contributors.debian.org: - code is at https://salsa.debian.org/nm-team/contributors.debian.org and it has a README explaining how to deploy a local development version - Python, Django, or JavaScript[1] front-end help is always welcome - Plenty of issues to pick from https://salsa.debian.org/nm-team/contributors.debian.org/-/issues and https://bugs.debian.org/nm.debian.org - People with experience with the code hang out in #debian-newmaint on OFTC debtags.debian.org - code is at https://salsa.debian.org/debtags-team/debtagsd - some issues at https://bugs.debian.org/debtags.debian.org - I'm barely managing to look after the site these days because all the others have more pressing issues for me to deal with - it has great fun potential if someone wanted to take it over up and play with things like gamification of tagging contributions, or playing package search front-ends - contact point: sadly, only me sso.debian.org: - code is at https://salsa.debian.org/debsso-team/debsso - it's hard to deploy a local development version - it's mostly there as legacy, now that we can use Salsa as OIDC provider. To do a nice thing, it needs to be made to support Salsa OIDC, too, so that services that still only authenticate with client certs don't need to depend on the crumbling former-alioth setup. - contact point: mostly me Enrico [1] the UI is a Bootstrap4 layout keep as uncomplicated as possible -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Sat, Apr 11, 2020 at 03:05:12PM -0700, Sean Whitton wrote: > Right now I can rely on my notmuch database to pull basically any Debian > discussion, because it includes the BTS, lists, and mail which I was > CCed on or received through an alias like ftpmaster@. And one can > easily incorporate mboxes from master.d.o or bugs.d.o to get any missing > context.[1] I think archival's a very good point, especially for a DEP-like discussion. You also implicitly propose an archiveal format that I like, namely some kind of email mailbox. I'd say that having a mailbox for archival would not be necessarily needed during a discussion, and would make sense once the discussion is declared closed. Discourse has some email gatewaying, which as far as I understand loses some metainformation like reactions or polls. It would be something I thing should be preserved from an archival point of view. Does Discourse have some kind of export feature, that one could postprocess to get for example a mailbox of annotated emails? > Could you say more about how you think Discourse would have changed how > the discussion went? Things that the current list discussion doesn't easily give: - +1 kind of feedback, or simple agreement, tends to unexpressed: people only reply if they have a problem with things, and shut up otherwise. For example, the recent Salsa as OIDC provider discussion had a relatively small amount of people contributing: does it mean that a lot of people just agree, or does it mean that only few people care? Silent assent and only negative feedback is a very demotivating process to go through putting a proposal up for discussion. - Some kind of weighting of posts. Sometimes I wonder: "is it just me, or this objection is not that relevant?", and I have no real way to know, besides maybe polling my social bubble, which could be biased. Ranking of perceived importants of topics or aspects discussed might have helped me manage the energy I put into the whole discussion, going into more detail where I could see there was more interest or concern. > I am concerned that the problem is basically a social one, and so cannot > be solved just by using a different software stack to host discussions. Ish. I think there are may social aspects involved, and the same time the process that we currently use has technical or traditional limits which filter against various kinds of feedback which people would socially be happy to give. I follow list discussions and some messages make me go "yay! Standing ovation!" and some messages I skip after reading part of the first line, and some messages make me furious. Socially we might able to express that in a way that feeds into the quality and direction of discussions, but technically, we currently cannot. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
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. > 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. 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. I want to be very clear on this: I have no intention of keeping the status quo as it is now: either it becomes something that I can manage, or I'll stop managing it. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Fri, Apr 10, 2020 at 07:59:59PM +0100, Neil McGovern wrote: > For a little while, I've been keen to see how we can improve our > communication methods, both to make it more accessible to newcomers and to > take advantage of more featureful tooling than has been traditionally > possible with email lists. > > As such, I set up an instance of Discourse[0] at > https://discourse.debian.net, and am now asking for a wider input on if > this is something the project wishes to use and if I should spend my > time pursuing. The recent difficult discussion on SSO here on -project made me think of a use case for which Discourse might be just the thing: Debian Enhancement Proposals[0]. I get the impression that having proposals discussed/peer reviewed on Discourse might be easier and more pleasant than on lists. For example, it would give a way to express agreement with something more visible than silence, it would give a way to get visible feedback other than negative, and give some measure of perceived relevance to the various contributions made to the discussion. I'm not sure if I would be motivated right now, or ever, to have another round of "peer review" like the one I just had, on a list. Discourse seems like it might be a venue for peer review that wouldn't make me feel like leaving the project after a couple of days of interaction. Enrico [0] https://dep-team.pages.debian.net/deps/dep0/ -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Wrapping up the Salsa as OIDC provider proposal
0407182106.t772yp2ry3tl5...@shell.thinkmo.de * Non-DDs will eat up names in a namespace so far reserved for DDs I think it's not a problem if Debian contributors get to choose a username and keep it. I would argue it's an improvement to have usernames that don't have to change as one's membership status is gained or lost. See: https://lists.debian.org/20200408130828.izn7jdyufch7k...@enricozini.org and: https://lists.debian.org/20200408131839.ispzcuzwwof2k...@enricozini.org * If we drop the requirement of having "-guest" for non-DD users on Salsa, how can one tell if a user is a DD? Waldi has a prototype ready for showing official membership status prominently and directly on a user's page, with information synced from nm.debian.org. Making sure that only current DDs have access to certain repositories is a problem that can be solved independently from account naming policies. * Will nm.d.o have a field which reflects the username on salsa? Yes, finally! It's been really painful not to have that so far. * How do we avoid namespace clashes between LDAP and Salsa? The two namespaces start in sync for non-guest accounts. nm.debian.org will forward the Salsa username to LDAP when new LDAP accounts are created, and will ask people who don't have an LDAP account, to choose a Salsa account name that is free in LDAP. This means that LDAP remains independent from Salsa and DSA remains fully in control over the user account namespace. It is the Salsa namespace that will have to adapt to what is free on LDAP's side, the moment someone with a Salsa account requests an account in LDAP. For people who get an account in LDAP and later want to rename their Salsa account, the option remains to register a new account to keep the old name locked. See: https://lists.debian.org/20200409072447.ci2xnvtnwv5as...@enricozini.org and: https://lists.debian.org/20200409181701.3qqsn5sqq3xbu...@enricozini.org * Currently client certificates can be used to connect outside of browsers OIDC is a common standard, and there are standard ways to address this kind of use cases. Some services outside browsers (like dovecot) support OIDC. Services providing APIs normally offer API keys for interacting with the APIs. See: http://lists.debian.org/20200407182106.t772yp2ry3tl5...@shell.thinkmo.de * Proposed conclusion I could not see any reason why this proposal would make the situation *worse* than the status quo, or any reason this proposal would block further migration to something else in the future. I therefore consider it a useful iterative improvement over what we have, and see no reason to block it. I will start working with Waldi on getting it implemented, tracking progress at https://salsa.debian.org/debsso-team/oidc Anyone who would like to help, please get in touch! Enrico [1] https://salsa.debian.org/bisco-guest/nacho -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 02:23:47PM +0200, Ole Streicher wrote: > I don't know the exact proposed rules here, but I could imagine that > without these rules anyone cann fill the namespace of nice Debian user > names. If you're talking spam account flooding the namespaces, they can be cleaned up from time to time. If you're talking about legitimate Debian contributors not yet interested in becoming DDs, using up names that people interested now in becoming DDs would like to have, I think it's not a problem if the people who registered the name first gets to keep it. > And there is the danger that someone hijacks the user name of a > Debian user who is still not on Salsa. Or an emeritus name or so. The proposed workflow is that: - you register a name on Salsa - after you go through nm.d.o, it becomes your name on LDAP By default, when you become a DD you have the same username on Salsa, and so it's taken by you and nobody can register it, even if you become emeritus. If you decide to rename your Salsa account, then yes somebody else can take it, and it's fair enough. If somebody takes it over maliciously, the account can be locked. If you decide to rename your account but don't want somebody else to register your old name, you can register it yourself after the rename, to keep control of it. > I would also like to have a visible distinction between "trusted" names > (where the owner is verified via key) and random names, in one way or > the other. The official membership status synced from nm.debian.org can, with some work, be made visible in the user's page. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Fri, Apr 10, 2020 at 09:40:45AM +0200, Enrico Zini wrote: > If you or someone else eventually will manage to introduce a Single Sign > On system that would take us to a next step of being able to advocate > developers, take packaging actions, update the ssh key you use to access > debian.org machines, all via a web interface, I really look forward to > that! Incidentally, if you could eventually manage to make a viable proposal for a SSO system that DSA and ftp-master considered secure enough to enable building web UIs that could do things like, for example, but not limited to: - advocate people on nm.d.o without needing to paste a GPG-inline-signed statement into a web form - move a package from experimental to unstable with one click - trigger a binNMU - vote for a GR by ranking options in a web form Then I think that it would be a compelling enough innovation that you won't have to be afraid of any amount of "good enough" for whatever other system will be in place by then. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 02:34:03PM -0500, Michael Lustfield wrote: > I was previously involved with a company that audited various git-hosting > services. I'm stuck behind a very strict (saw it brutally enforced) NDA, so > please forgive the lack of specifics. Gitlab is a tool that gets many things > right, and many things wrong. Access control is an area where I have seen some > critical bugs. Some of those bugs lead me to not trust it as a non-internal > authentication source. I normally assume anything with a huge codebase to be full of holes, so I'd say you haven't told me anything surprising. The current sso.debian.org codebase has been written by one person (me), deployed by one person (me), audited by nobody, and as far as I'm aware, nobody besides me has ever read the code. I think that's a scarier picture than Gitlab: at least Gitlab is somehow widely deployed, has regular updates, and has people maintaining it in production and sending patches, which gives it a limited amount of scrutiny. I still claim introducing gitlab as OIDC provider is not going to make matters /worse/, and, I repeat, that's the only claim I've been trying to get validated here. If you are concerned that Debian critical operations could be depending on a single signon platform which does not have the track record of security that we would like, then we're already dealing with that: the whole world controlled by sso.debian.org is designed under the assumption of not being secure enough. You can't get sso.debian.org access with your Debian master password: you need a web password instead, which does not give you access to the rest of db.debian.org. With a sso certificate, for example, you can't change your status in Debian, you can't advocate a person, you can't AM approve, you can't DAM approve, you can't upload packages, you can't vote, you can't read debian-private, you can't gain shell access to debian.org machines: we require a GPG signature from a key in the Debian keyring for all those operations. That is not going to change. If you or someone else eventually will manage to introduce a Single Sign On system that would take us to a next step of being able to advocate developers, take packaging actions, update the ssh key you use to access debian.org machines, all via a web interface, I really look forward to that! That's not what we're trying to do here. We're not there now, and it's not going to change with introducing Salsa as an OIDC provider. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Thu, Apr 09, 2020 at 05:09:19AM -0500, Michael Lustfield wrote: > It also appears that there is an intent to drop -guest naming. I haven't seen > any technical discussion about this beyond learning about the current > structure. I am very concerned that this will have significant consequences in > regard to DSA-managed LDAP. Are you concerned or do you have specific issues in mind? Do you have actual issues that have not been addressed in 20200409072447.ci2xnvtnwv5as...@enricozini.org and 20200409181701.3qqsn5sqq3xbu...@enricozini.org ? > Meanwhile, there are now five people with an interest in doing what we can to > rectify the situation. It's unfortunate that we weren't aware of the stall a > year ago, but we're here now, and I don't intend to work slowly. I'm confident > you're aware of my "requirements gathering" phase. Design has been roughly > discussed and I'm now taking a day to bury myself in documentation. Since I'm > still playing the social distancing game, you can probably guess where my > weekend priorities will be. :) I don't know how many times I repeated that I have no intention of standing in your way, I wish you great success, I look forward to having a healthy and long-lived team that takes care of a great and official Signle Sign On system in Debian. I *want* to be able to stop worrying about this and focus on maintaining the services I need to maintain. Could you please meanwhile not stand in the way of trying to fix the status quo enough that I feel safe in keeping the services I maintain online? I've been in a horrible situation for more than a year waiting helplessly for this to happen, and I have a chance to get out of that pit while not getting in your way. Can you give me a good, practical reason why you seem want me to stop with that? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Thu, Apr 09, 2020 at 07:46:21PM +0200, Tollef Fog Heen wrote: > > 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.) You don't have to, and I wouldn't consider LDAP subservient to anything: if you create an account in LDAP that exists on Salsa, when the Salsa user wants a guest account or to become DD, we'll ask them to rename their Salsa account because the LDAP one is already taken. The idea is to leave DSA free to implement whatever policy they want and manage their LDAP namespaces as they see fit. When people want to create accounts in them, they adapt according to the rules DSA sets. nm.debian.org tries to validate as much as possible according to those rules, to make thinks smoother. What we can't validate, we deal with it on a case by case basis. This is pretty much what what happens today: DSA gets to refuse (and does refuse) account names arbitrarily without providing explanations even when we ask, and we suck it up and deal with it. This is not something we outside DSA can change, and it's not something I expect will change. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 04:06:25PM +, Luca Filipozzi wrote: > Another view point: I don't think that one's username should change as > one's role(s) with the organization changes. If we could avoid that... Agreed! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 03:48:43PM +, Luca Filipozzi wrote: > > If you're instead generally expressing a fear that once we migrate to > > Salsa, we'll be in a local optimum that is going to be considered good > > enough to be worth bothering migrating to anything else, then I would > > argue that the problem wouldn't be having moved to Salsa as an OIDC > > provider, and rather that the next step that is proposed wouldn't be > > bringing enough compelling advantages to the problem at hand. > > Indeed, a local optimum is worrisome. If you mean that we should block a workable proposal for incremental improvement in case it turns out to be good enough, I think I don't want that. What we have /now/ is unsustainable, to the point that I'm afraid and ashamed of keeping some of the services I'm responsible for online. We have come up a proposal that could be deployed in a couple of weeks of off-working-hours straightforward work, with no need to deploy any new infrastructural component. It can solve the urgent issues. Then we can talk about a better, long-term, technically excellent, actively supported and sustainable solution, and by all means, I'd like to see that. We could also do a post-mortem of why we have had what sounded like a good solution for more than one year and never managed to get it deployed. Not for pointing fingers: for avoiding getting in such a stalled situation in the future. I am not at all in the mood for any of that, though, while I find myself starting responding to users' requests for help by apologising for the state things are. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:50:00PM +0200, Tollef Fog Heen wrote: > > 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? For guest accounts opened on request via nm.debian.org, the idea is requesting an account name that is the same as the Salsa account name. Any requirement mismatches can be fixed by renaming the Salsa account name prior to LDAP account creation. 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. In case later a person decides to rename their Salsa account after having a corresponding one in LDAP, see 20200408130828.izn7jdyufch7k...@enricozini.org Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 03:00:31PM +, Luca Filipozzi wrote: > > Question: is there something in the proposed Salsa plan that somehow > > blocks experimenting with, introducing, or migrating to Keycloak in the > > future? > > The further we go down one path, the harder, in my opinion, to change > later. I think we're not really going "down one path": we're trying to dig ourselves "out of one pit". I'll have to repeat the question: is there something specific in the proposed Salsa plan, that somehow blocks experimenting with, introducing, or migrating to Keycloak or some other solution in the future? From what I can see so far, we're starting a migration to OIDC, removing one of 3 user databases, adopting more standards, and doing some general cleanup along the way, which makes me think Salsa could be considered an iterative step towards a migration to anything else. If you're instead generally expressing a fear that once we migrate to Salsa, we'll be in a local optimum that is going to be considered good enough to be worth bothering migrating to anything else, then I would argue that the problem wouldn't be having moved to Salsa as an OIDC provider, and rather that the next step that is proposed wouldn't be bringing enough compelling advantages to the problem at hand. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 10:05:19AM -0400, Sam Hartman wrote: > I don't think it blocks your proposal, but I do think that having > something to audit repos and make sure only current dds have access to > certain repos is a valuable user no]eed. > And I think the current-status-permission check need is also valid and > probably more critical. Sure. I seriously think we don't have enough audit tools in Debian, and I'm strongly in favour of having more. With regards of current-status-permission, I checked with waldi, and with some extra work it is possible to add some visible information to the user's page, synced from nm.debian.org, about their official membership status: we can totally have that. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:25:06PM +0800, Shengjing Zhu wrote: > > I understand you want to recognize DDs from other contributors, but why? > > Does it help you with permissions, does it help understand who someone > > is, or is it a habit that has been there since Alioth? > > For me, it's easier to trust a DD than a non-DD, so I'll grant a role > with higher permission if they request to join a team/project. I think this has ups and downs. Currently, if someone doesn't have -guest on Salsa, they are either active DDs or locked accounts. The moment a non-"-guest" person loses their DD status, their account gets locked. This is currently causing trouble: when one loses DD status, suddenly they lose access to all their repositories until they get readded to everything with a new -guest account. For repositories that only they controlled, this requires admin intervention and headaches. This has happened, and it's serious enough to make Salsa not suitable for hosting long-term projects at the moment: I don't want to build my projects' ecosystem on something which locks me out the moment I decide to go emeritus, or the moment I get my Debian membership temporarily suspended for whatever reason. I would argue that it would make more sense to grant roles and permissions to people based on their past contributions and reputation, rather than based on current status. I agree that with the current proposal, the use case of "grant a person permission based on their status, which is somehow revoked or blocked if the status goes away" becomes something we might not be able to do. In my opinion this change, rather than opening a new problem, fixes an old, nasty one instead. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:45:32PM +0800, Shengjing Zhu wrote: > Sigh, but it makes sense too. Will nm.d.o have a field which reflects > the username on salsa? It finally will, yes! \o/ It's been quite painful not having that mapping so far. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 08:04:59PM +0800, Shengjing Zhu wrote: > > 1. Can you still keep the "-guest" enforcement, so it's still easy to > > recognize who is DD or not on salsa? > > The reason why I ask for this is because > 1. If a -guest account is added to a project in salsa Debian group, > the group name is also shown on the personal profile. > 2. Users can make their profile private, so you don't know what group > they belong to. > 3. To search in the Debian group member page takes too many steps. > > If there's an easy way I'm not aware of, then I'm fine with it. I checked with waldi, and with some extra work it is possible to add some visible information to the user's page, synced from nm.debian.org, about their official membership status. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 07:50:22PM +0800, Shengjing Zhu wrote: > 1. Can you still keep the "-guest" enforcement, so it's still easy to > recognize who is DD or not on salsa? I'll leave answering these questions to Waldi / Salsa admins. I would like to stick to investing energy in solving problems that we really have, though, so I'm curious: do you have specific reasons in mind for asking to preserve the "-guest" enforcement on Salsa? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Wed, Apr 08, 2020 at 04:51:49AM +, Paul Wise wrote: > Is there any documentation and diagrams on the typical request flows > between the browser the servers involved that happens with OIDC? > Is there an OIDC demo site somewhere so that I can see the requests > between the browser and the servers involved and see which browser > features OIDC uses and requires in practice? My goal in this discussion is to see if there are blockers for moving in the direction that me and Waldi proposed, or to discover unexpected ways in which what we propose would make the situation worse than it is now. I would like to keep this discussion focused on ACK/NACK, so that me and waldi and whoever may want to join the work, can go ahead and start putting together implementation schedule and get things moving. Are your questions an expression of curiosity about the OIDC protocol, or about hinting that there is something there that you consider a blocker to be discussed before we start working? > > However, I don't know how a moderation workflow should work. > > I'd like to see this happen via a "welcome" team. You register an > account with a paragraph about why you're signing up, your account > gets moderated and you receive a welcome email from the team with tips > related to your signup paragraph and to the service where you started > the registration flow, for eg people starting their registration on > the wiki might get a link to the wiki editor guide. > > https://wiki.debian.org/Welcome I would definitely like to see the Welcome Team take off, and I would prefer not to derail what seems like a workable plan about improving the broken Single Sign-On situation, into a discussion about a Debian Welcome Team. I'd love to have a healty, active, and pervasive Welcome Team, and maybe Salsa's an excellent opportunity for Welcome Team contributions. Unless you think having a functional Welcome Team onboard should be considered a blocker for moving on with SSO improvements, could we postpone this to a later point? I'd like to keep this round of discussion focused on two points: - is the current situation broken? - with this proposal, does it become less broken? That the current situation is broken seems to be generally agreed. I haven't yet seen anything that convinced me that what we are proposing would make it more broken, or would prevent further opportunities for moving on. If no serious blockers show up, in a few days I would start to go ahead. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 03:20:52PM +, Paul Wise wrote: > I'd like to learn a bit about what the effects for Debian account > holders and service admins will be. Thanks, I'll answer where I can. I understand that you're exploring all possible corner cases that might change and we might have to document or generally be aware of, and are not implying that any change in the areas you explore should be considered blockers for migrations away from the status quo. > > - Salsa becomes primary source of user info and authentication for secondary > > services via OpenID Connect (OAuth2), for both DDs and non-DDs, replacing > > sso.debian.org. > > It sounds like the answer is no, but does Salsa, Keycloak or > LemonLDAP::NG support TLS client certs? At least as a transition period, I intend to add OIDC authentication to sso.debian.org via libapache2-mod-auth-openidc or something equivalent, so that services that haven't migrated to OIDC can keep working. I guess the same can be done authenticating against Keycloak, LLNG, or most other things we might end up using, although I hope that if sso.debian.org ends up not being needed, we can turn it off after transitions have transitioned: I'm a big fan of reducing the amount of custom code that I have to maintain. > So it sounds like Debian would be switching our SSO authentication > protocol from TLS client certs directly supported by TLS clients to > something based on HTTP redirects, referrers and cookies and that > requires a browser in order to login? Technically yes. Practically, things like OIDC are standard setups, and there are standard ways to deal with non-browser access, like API keys. nm.debian.org for example already supports API keys without the need of a client certificate. > Is it intended that service maintainers each implement OpenID Connect > etc within their service code using existing libraries, or should we > use something like the mod_auth_openidc Apache module to pass > authentication details to service code. > > https://github.com/zmartzone/mod_auth_openidc I suppose each service can choose as they see fit. The apache module would provide a handy migration strategy from the current sso, keeping things handled at the web server level. Each service can decide what to do according to what options are provided by their underlying frameworks: OIDC is a widely supported and adopted standard, and it could be that using the corresponding functionality of Django or whatever framework one has, turns out to be easier for development and maintenance than the web server module. Both options would be available, anyway. If we really find out that we need a CA issuing client certs for some kinds of services, we can still keep maintaining sso.debian.org: it's a simple enough codebase and I think most people would be able to pick it up and maintain it as a CA service for our SSO federation. Note that I'm not aware of anything using sso.debian.org certificates outside a browser. I wrote and published example code to do that years ago, and haven't seen any adoption or even feedback. > Can services using non-HTTP protocols be authenticated with OpenID Connect > etc? > > Is it intended that there be moderation at account creation time? In > our experience with the Debian wiki, a large amount of spammers > attempt to sign up. I hear that Salsa gets a lot of spammers signing > up too and those are manually cleaned up if they do something spammy. > For the wiki we found the best way to prevent spammers from signing up > is human moderation. Even that doesn't always help as I've let > spammers sign up before based on the content of their signup emails, > but it is a good start. One very nice aspect of the wiki signup > moderation is that the team can respond to aspects of the signup > email, welcoming the applicant with pointers to documentation, > suggestions of ideas on how to help, mailing lists to join and so on. I defer to Salsa people for this part. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 09:14:11AM -0500, Michael Lustfield wrote: > I can very much appreciate a desire to get a replacement rolled out as quickly > as possible. The more I learn about the current situation [1], the more > alarming > it is. However, please don't consider the work Lucas and I are doing as > stalling. I was unaware that the whole effort stalled. I'm currently between > contracts and have plenty of free time to make something happen. > > I also like to think of a myself as a good masochist. You can expect me to > stick around for the long term. :) That's great, and I also don't want the Salsa improvement we proposed to be a blocker for further developments. As far as I'm concerned, we could get started with migrating services to OIDC consumers[1], unblocking new non-DD access to services, and cleaning up the status quo a bit. Sooner or later, your and Luca's work (or somebody else's, or all of them) can get validated, and can pick it the situation from where we left it and keep improving. [1] or even simply libapache2-mod-auth-openidc, since the current cert system is handled by apache anyway > Aside from the security concern I raised earlier, it's largely a "gut feeling" > that comes from seeing how quickly legacy quirks develop in any new > deployment. > If Salsa needs to make any assumption or enforcements that Alioth did not, > those will need to be accounted for in the new solution. Additionally, we > already have a clean path I don't understand what you mean with "any assumption of enforcements". > Something that comes to mind is what it would take to migrate accounts from > Salsa to somewhere else. Does gitlab provide user exports? As unfortunate as > it > is that alioth's DB is now a flat-file managed by hand, it provides a very > simple and easy way to import all of that data. Gitlab does indeed provide user exports: some more details are in the "Exit strategy" part of the proposal Waldi posted. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 03:28:07PM +0200, Xavier wrote: > With a SSO, I don't think it's a good thing to have a protected app as > user database (even if it's possible). Then migration consists to > extract gitlab accounts and push them in LDAP (2 branches, one for DD, > one for guests) Ok, please help me to see where that would be an issue. The current status of accounts, is that: - There is only one LDAP server, DSA-managed, on db.debian.org, which has accounts that do not end in "-guest". They may be DD or ex-DD accounts, or "guest accounts" created for non-DDs who need to have temporary access to porterboxes - There are accounts ending in "-guest" (that are not "guest accounts"), that are not managed by DSA, and used to be on Alioth's separate LDAP when alioth existed. - "-guest" accounts for purposes on sso.debian.org authentication are now stored on a hand-maintained text file that is exported somehow to serve as an apache authentication source for sso.debian.org - "-guest" accounts on Salsa are stored on Salsa's user database We currently have all sorts of overlaps and corner cases: - "guest accounts" in LDAP that do not end in "-guest" and are for non-DDs - "-guest" accounts in Salsa for DDs and ex-DDs, with the part before "-guest" not matching the LDAP account name. I wonder if we have the same "-guest" accounts in Salsa and in the sso.debian.org text file, that are controlled by different people? With the Salsa proposal: - the text file disappears, reducing the count of user databases from 3 to 2 - LDAP remains as it is, and Salsa remains as it is - DD accounts remain on LDAP - We gain an explicit mapping between LDAP accounts and Salsa accounts, via nm.debian.org, that we currently do not have - People who gain or lose DD status can keep using their Salsa account without needing to migrate from "something-guest" to "something", or from "something" to "something-guest" With the Salsa proposal the only change from here that I can see is that we would start to have non-DD accounts on Salsa that do not end with "-guest", like we already have non-DD accounts on LDAP now that do not end with "-guest". I still don't see how the Salsa proposal makes adoption of a new system harder than what we have now: removing one user database and introducing a mapping between the remaining two, seem to me to make further adoptions actually easier. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 02:31:31PM +0200, Xavier wrote: > > I'll ask you the same question I asked Luca: is there something in the > > Salsa proposal that would prevent further experimentation with LLNG and > > eventually possibly integrating it into the ecosystem, or migrating to > > it? > > No, just to migrate accounts Could you give some more detail of what you mean? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Tue, Apr 07, 2020 at 12:20:40PM +0200, Xavier wrote: > Resume of proposition: > * all users managed by SSO; self-registration authorized with "-guest" >in a distinct LDAP branch > * GitLab becomes a slave of SSO using SAML (or OIDC) > * other applications are protected by handlers/GateKeepers. If LLNG is >chosen, just to add few lines in Nginx configuration > * new applications can be protected using handlers, SAML, CAS, OIDC,... > > I greatly appreciate yours and Luca's and Michael's proposals, and offers of help. I would like to avoid stalling progress on sso on things like analysis paralysis, or like sorting out deployment details, as happened in the last years. I'll ask you the same question I asked Luca: is there something in the Salsa proposal that would prevent further experimentation with LLNG and eventually possibly integrating it into the ecosystem, or migrating to it? If not, then we could start with that, which requires no deployment of new software, and on which we can make progress immediately, and buy time for everyone to work out the perfect solution, meanwhile moving on from an unsustainable status quo. As a side effect of an interim on Salsa, services can begin to migrate from client certificates to OIDC, switching to a mode widely used, usable, and flexible standard, which I wouldn't be surprised if it would make things easier when moving to something else later on. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 07:07:26PM +, Luca Filipozzi wrote: > > I don't know keycloak: what are the maintenance costs, and what would be > > the benefits over time? > > > > Right now, with the proposal waldi just posted, we have very little to > > no added maintenance cost, possibly negative maintenance cost once we > > take sso.debian.org and the current handcrafted salsa subscription thing > > offline. The amount of code deployed compared to the status quo would go > > *down*. The user interface and user experience for the lot would be good > > and well known. Gitlab's codebase, while large and complex, is widely > > deployed, and we already have know-how about it in Debian. > > Having just joined this conversation, the above is an argument that is > difficult to refute: one can always argue that 'one in the hand is > better than one in the bush'. Yes :/ I think that's more or less where we are now, unfortunately, after a year or more failing to find people to deploy and maintain alternatives. On one hand, client certificate handling in browsers gets worse over time, and the current sso solution is effectively running on people collecting all sorts of workaround instructions in the excellent wiki page at https://wiki.debian.org/DebianSingleSignOn On the other hand, signing in for non-DDs is a major hurdle that takes literally weeks, when one can find out how to do it at all. We DDs care little about that, it's Not Our Problem. That barrier makes joining nm.debian.org to become a DD a challenge in itself. Other things like managing one's own information on contributors.debian.org are just not worth the challenge, and I'm planning to take contributors.d.o offline soon, because I/we can't, ethically and legally, publish people's information without giving those people a reasonable chance to control it. > My DSA colleagues asked for demo and I'm building that up, currently. I > view this as a positive but not definitive step in the maintenance > questions. > > I appreciate that the idea of using keycloak as an IdB requires everyone > to shift perspective. > > Let me know if you have appetite (or not*) to discuss the above. Personally I'm interested in anything that works and that I can have a very good confidence that somebody will maintain over time. I care about maintenance and sustainability more than about anything else, because I'm the one who's been forced to set up and maintain SSO in Debian mostly alone for 8 years, because everybody else walked away from it and I could not. OIDC supports various authentication sources, and the Salsa plan decouples OIDC from LDAP allowing them to evolve independently, removes custom nonstandard components, and includes the option of migrating away to something else in the future. In my understanding it enables experimentation with other systems rather than blocking it. Question: is there something in the proposed Salsa plan that somehow blocks experimenting with, introducing, or migrating to Keycloak in the future? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Salsa as authentication provider for Debian
On Mon, Apr 06, 2020 at 04:09:38PM +, Luca Filipozzi wrote: > That said, please consider an approach that would see keycloak used as > an idenitity broker, allowing external users to create accounts using > social identities that are then promoted to full Debian identities (in > LDAP) if they complete the onboarding process. Could be used as > replacement for debsso, could be used for wiki, could be used for > debconf, could be used for salsa. I don't know keycloak: what are the maintenance costs, and what would be the benefits over time? Right now, with the proposal waldi just posted, we have very little to no added maintenance cost, possibly negative maintenance cost once we take sso.debian.org and the current handcrafted salsa subscription thing offline. The amount of code deployed compared to the status quo would go *down*. The user interface and user experience for the lot would be good and well known. Gitlab's codebase, while large and complex, is widely deployed, and we already have know-how about it in Debian. I would not want to see a workable proposal that we could implement over the next two weeks and that we have the resources to maintain long-term, blocked by something that risks getting us stuck with sso.d.o for another bunch of years until we get it right, and possibly ending up being maintained long term by a team with a dwindling bandwidth and bus factor. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
On Sat, Mar 14, 2020 at 05:41:38PM -0400, Roberto C. Sánchez wrote: > The fact is that given the length of time packages can wait for NEW > processing and the amount of effort package maintainers put into > packaging, it is understandable that they would be frustrated at the > rejection of a package. That said, it does not make flaming the FTP an > acceptable response and is certainly not going to produce any positive > result. But it is not clear that it would be possible to prevent such a > thing. I would like to change the strategy we currently use in Debian to deal with structural issues, from what seems like "people yell abuse out of frustration and teams survive by bearing with it", to something else. I would ideally like to cut on the abuse, and invest in help (both asking for, offering, and accepting help) in dealing with both routine and structural issues. I mean, *abuse in the project cannot possinly be part of routine work*. Please let the Community Team know of instances so they can talk to people, and please let DAM know of particularly bad instances, like personal threats, if they happen. However, if we have a structural issue that causes frustration, having the community team helping people in keeping their cool and DAM taking action on people with a tendency to losing it bad, does not make the structural issue sustainable. For this reason, thank you for asking for help! I hope people who volunteer can expect better working conditions than what was offered in the call, and I hople that one can have a path of growth in the team from something that looks like grunts who do the routine work under enemy fire, to someone who can get appreciation for their work, over time develop understanding and agency in the team, and eventually can help to shape it. I don't mean for this to be specific to the FTP team. I guess this thread gave me an opportunity to voice my more general thoughts. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Lenovo X395 Support Latest Debian Version
On Tue, Feb 11, 2020 at 10:07:58PM +0100, Christian Kastner wrote: > I am very positively surprised by this effort. It's rare (to me) for a > vendor claiming Linux support to show even a modicum of interest beyond > a very specific configuration. Quite. Same here. Just today the maker of my fancy business laptop[1], that is not Lenovo, told me that to replace a swollen battery under warranty I have to either ship it off-site and spend at least 10 working days without it, or give them 375€+VAT for someone to come change it on-site, because they consider the battery on this one as non-user-replaceable. My first thought after reading their mail and Mark's post here, was that I could keep the swollen battery, and put that money, or the money I would lose in a 10 working days downtime, into the piggy bank for a new Lenovo laptop... Enrico [1] who does kindly sponsor DebConf, for which I'm grateful, but still fails to officially support Debian on it :-/ -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Sun, Dec 29, 2019 at 03:15:07PM +0600, Judit Foglszinger wrote: > Maybe instead of saying "you shouldn't have done that", > rather explain which parts of questions asked in one specific process > one found sufficient to approve the NM as a DAM and why, > so there is some more orientation and more insight, > what exactly DAM finds important to ask. > > On the other hand given that quite some people find their process > a valuable experience, it would be sad to reduce it to the bare minimum, > as long an AM takes the effort to ensure, that > the NM is not forced to do unnecessary things they rather wouldn't want to do. > (if some stuff is more clearly optional, it might also easier for DAM to skip > it) Thanks! I like the angle of documenting what was found sufficient, rather than what was not needed. Probably the documentation shouldn't be public, to avoid applicants to build an expectations of a bare minimum work required and then get angry at the AM if the AM feels like asking more than that, but it could be, for example, a monthly post to the am@ alias. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: possibly exhausted ftp-masters (Re: Do we still value contributions?
On Sat, Dec 28, 2019 at 02:35:50PM +, Sean Whitton wrote: > On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote: > > > Oh, wow. I've been doing this wrong all along. I am not sure how I > > developed the impression that it was necessary to distinguish different > > copyright holders (even same copyright holders with different copyright > > years), but your approach is most certainly simpler and more compact. > > Right. This is the sort of overdocumentation that I worry our > machine-readable copyright format implicitly encourages us to do. I see similar things on nm.debian.org, which I ended up calling in my head something like "the law of inflation of bureaucracy". That is, I see that when people are asked to do some work, that later will be checked by someone else, over time there is a tendency for the perceived amount of work to inflate. I guess the incentives are such that doing one bit less feels like making it more likely that review will fail, and doing one bit more feels like making it more likely that review will pass. The result over time is an increase in the amount effort that both people who are doing the work and people who are doing the checking end up putting into the system. For example, an Application Manager in the NM process will tend to err for asking a question more, that DAM will have to read. I haven't yet seen easy ways of introducing a feedback mechanism to counter this: saying "you didn't need to do this" feels to me like arbitrarily undervaluing someone's work, and maybe the person really found it important to do it. I would be very much interested in reasoning about this. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Sat, Dec 21, 2019 at 02:44:41PM -0600, Gunnar Wolf wrote: > I am always sad and disheartened when this kind of threads erupt. And > I can only imagine how this hurts people that cannot just sympathize > with you, but suffer instead in their own bodies and lifes the > discrimination. I am a believer of social change towards inclusiveness > and acceptance, but it's a long and very gradual process. I agree that inclusiveness and gradual growth and patience are really important, and are the main way in which a project as wide as Debian can mature. However. We are talking about being on the receiving end of a steady stream of "you don't belong here", "your identity is not valid", "you don't have a right to exist", Gradual growth and patience work in a community, if the people being invalidated can rely on getting support, protection, and an affirmation of their validity. If we do *not* offer this, we *cannot* ask people for patience. Otherwise, it would be (and it is) asking disempowered people to perform on par with everybody else, while bearing the punches from the trolls, while being patient with the confusion of the innocent, and while being expected to politely and patiently educate the privileged ones. It would be like, in a school, expecting that the kid who most gets beaten up, be responsible for solving the bullying problem for everybody else. The responsibility for a healty community, where everyone can feel included and accepted, is nominally the responsibility of everyone in the community. In practice, however, it is *primarily* the responsibility of the people who are *in a position of privilege and power* within that community. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Mon, Dec 16, 2019 at 06:28:41PM -0800, Russ Allbery wrote: > (I realize that this can be kind of frustrating for people who aren't > native English speakers, because those rules can provide the structure > that they rely on to express themselves in English.) In my experience, this mostly becomes frustrating in bullyish environments, where people are putting more effort in debating me and competing on who is more "right". There, an apparent language mistake means that people will be delighted to disregard everything I was trying to say, and instead point a finger and laungh at me having been WRONG. "You make a good point but your grammar is WRONG, and now I'll divert the conversation into patronisingly explaining it to you" is a great classic when speaking to people with a confrontational attitude and a fragile ego, who can't just say "I like your point" and build on it. I've seen it work also the other way round, where in bullyish environments people intentionally make "innocent" mistakes if they help "take the other person down a notch". In an environemnt where people are putting more effort in cooperating, and working together towards a common goal, even a language mistake that would render an entire point incomprehensible or absurd, would end up into not much more than "wait, I don't get it, you mean to say $THIS?" "uh, ah, lol, no, sorry, I meant $THAT", and work and life go on without even a significant break of the flow. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Some thoughts about Diversity and the CoC
On Fri, Dec 13, 2019 at 10:49:12AM +0100, Bernd Zeimetz wrote: > No, either we have a CoC or not. > If it goes so much against your believes, humanity or whatever else, > that you can't answer in a sane language, ask somebody else to answer > in your name. Especially when you are in a team that wants to keep > the CoC upright. If one focuses on Tina instead of looking at Gerardo's history of behaviour on Debian list, and is actually in common faith trying to make sense of an extreme reaction, I suggest these links for a bit of context: * https://en.wikipedia.org/wiki/Sealioning * https://en.wikipedia.org/wiki/Tone_policing * https://blog.valerieaurora.org/2019/01/09/repost-how-calls-for-civility-are-harming-tech-companies/ TL;DR: there is a widespread form of oppression which consists in politely but relentlessly asking minorities to justify themselves. As long as we allow it to happen in Debian list, as I observe that we do, I do expect that somebody loses it at some point. I believe that the person who engages in sealioning, and those who enable them to continue doing so, should at least get to share in the blame. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Mon, Oct 21, 2019 at 07:37:16AM -0400, Sam Hartman wrote: > > * In extreme incidents or after repeated harmful behaviour or Code of > > Conduct violations, writing reports for relevant teams (e.g. Planet > > admins, listmasters, DAM), to summarise relevant incidents along > > with analysis and suggested possible courses of action; and > > my understanding from cambridge is that DAM would prefer not to get > recommendations on what to do in such cases. > Is DAM happy with the suggested possible courses of action language? > Even if not, it's fine to keep if other teams would appreciate that > feedback. Thanks, good catch! I would prefer to receive on the DAM side a collection or list of pointers to relevant things, and anything I could use to decide what to do, and I fear that receiving suggestions on what to do would make things more complicated. This is because if feel that if we receive a suggestion, not only we still need to figure out a course of action independently of what the reporter(s) suggests, but then we also need to deal with a conflict with the reporter(s) if the course of action that we choose is different from what was suggested. We might of course find it helpful or important, depending on cases, to reach out to the reporter(s) or other people involved to discuss possible course of actions. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Mon, Oct 14, 2019 at 01:40:34PM +0200, Enrico Zini wrote: > Posting draft team missions where one has to read between the lines > about possible institutional conflicts and other unsaid issues, is > emphatically /NOT/ a way to build trust within the project. To make it clear: I think the draft team mission that was posted is a great start for a discussion, and I think we need teams to support people in Debian, and I think we need a good way to escalate different interpretation of the CoC. What I think is not a way to build trust, is what Guillerme's reading of Tina's message was implying. I think those things hurt everyone and destroy good efforts, and I strongly wanted to push the discussion back to the idea of constucting something together. I see how my message could be read as implying that the whole draft Steve posted is not a good way to build trust. To the contrary, I consider it a good way to put cards on the table, and to start to work out together how they should be arranged. I was afraid I was hearing that some cards might not be kept on the table, and I wanted to strongly object to that. If all the cards are on the table, by all means, let's all find a good way to put them together! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Sat, Oct 12, 2019 at 04:04:49AM +0200, Guillem Jover wrote: > > Once you do that I'll be happy to work with you just as I would any > > other group approaching changing/renewing/creating a delegation. [...] > But then I see no reason at all why they need to do that now. Even though > they have already stated so, and the mail you reply to went as far as > mentioning a timetable of around 12 months, which TBH I pretty much > interpreted as a tactful way to say “once the current DPL term is over”. If one wants a delegation from a DPL, I'd expect them to work *with* the DPL, as the DPL is the person responsible for delegations. If a team has an issue with a DPL, I expect them to acknowledge the issue, state their long term plans and why they wouldn't work with the current DPL, state what they'd like to do in an interim situation, propose a GR. Posting draft team missions where one has to read between the lines about possible institutional conflicts and other unsaid issues, is emphatically /NOT/ a way to build trust within the project. I think the responsibility of interpreting the CoC should go to people who we can trust not to wield it like a club, who are clearly named, and so on. A delegation provides this. Currently, as I understand it, interpretation of the CoC is the responsibility of the DPL, overridable by GR. Needing to read between the lines of a proposal like this, instantly makes me think of attempts to grab that power away from the DPL. Of trying to force a self-written delegation on the first DPL who gets distracted for a moment. This is most emphatically /NOT/ a way to build trust within the project. I have seen, in other communities, successful power grabbing attempts done by emptional blackmail, refusals to take no for an answer, and similar kinds of social pressure. I don't at all mean to imply that it is what is happening here, and I trust at least some of the member of the (AH|Community) team enough to believe it is actually not the case. Still, I most emphatically do not want to have to read things between the lines in a discussion like this one. Not when power is involved. Not when trust is involved. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Community Team - where we want to go
On Wed, Oct 09, 2019 at 10:26:39PM +0100, Steve McIntyre wrote: I join other respondents, with a risk of redundancy, with a few notes due to the decision of not having delegated powers and being an undelegated advisory group. > The (CT) is the team responsible for interpreting the Code of Conduct > (CoC) when necessary. I feel strongly against this: "The team" hints at being the only team, and "Responsible" hints at having power. I believe strongly that anyone who is /the/ person/team responsible for interpreting the Code of Conduct needs to gain that responsibility from an official delegation, and absent a delegation, I believe that the only person ultimately responsible for interpreting the CoC when necessary is the DPL, overridable by a GR. However, I also believe that any member of the Debian community is responsible for upholding the Code of Conduct, and I'm fine with the idea that one or more people or groups could make themselves available to help with CoC interpretation or supporting people if things get heated. At that point, however, the CoC interpretation is not a responsibility but an offer of help, whose value can maybe come from experience and reputation of a person or team members inside the project. > Finally, the CT will also work in combination with event organisers to > deploy incident response teams on the ground and ensure that the CoC > is observed for Debian events. In the same light as above, I suggest s/work/make itself available/, as any other group could make themselves available to event organisers to help with Debian or event-specific CoC. > Responsibilities include > I agree with what Mathias Behrle wrote about this session. > Examples of things the team does *not* do > = > > * Remove blogs from community forums like Planet Debian This I think is something the team could actually do, just as any Debian Developer could do it, having commit access to the planet config. > * Take punitive measures or actions against members of the Community. I find this point a bit tricky, because I think that what is "punitive" is up for subjective interpretation. For example, feeling forced to engage with individuals wearing a Community Team badge could already be seen by some as a punitive measure. You may want to remove this point entirely, as it's mostly covered by the other examples of what the team does not do. - - - Some more general feedback points. I suggest to review your notes with the idea that there could be two or more such teams in Debian posting the same set of notes, and they shouldn't conflict. Also, given the idea that there can be multiple groups doing this, the name "Community Team" sounds possibly problematic name to me, as it hints indeed at being /the/ team for Debian Community issues, which could potentially be setting the wrong kinds of expectations. Although I would prefer a name that would make it explicit that we're talking about /a/ /self-appointed/ group, I wouldn't consider the naming a blocker: I know names are hard, and I don't want you all to spend your energy picking names. Still, I'd acknowledge and keep in mind that the name does sound ambitious, and as a consequence I'd expect you all to be extremely careful in all team descriptions and team actions to make it clear that you are /a/ community team, not /the/ community team. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: GR proposal: mandating VcsGit and VcsBrowser for all packages, using the "gbp patches unapplied" layout, and maybe also mandating hosted on Salsa
On Tue, Sep 24, 2019 at 08:27:15PM -0400, Sam Hartman wrote: > But I think having recommendations available when people are new, when > they are looking for what to do when writing new tools, when the trade > offs don't matter, is really important. I think it's important enough > that it's worth time for a quick vote (and I do believe we can > efficiently handle GRs). I agree with your message, and I'd like to expand on "when people are new". I probably don't qualify as new in Debian, and I maintain some package outside of teams. For those packages, I suffer from the lack of a team policy that gives me a default way of doing things unless I have better ideas. Also, as over time my packaging practices have become outdated, I have found it both difficult and frustrating to engage on a quest for figuring out "how does one do this thing nowadays?"[1], and if there were default recommendations available, I would have considered them a boon[2]. When the upstream is straightforward and I'm not engaging in innovating packaging practices, I'm significantly happier having a default script that I can follow, instead of reinventing or refiguring out the wheel every time I have an upload to make[3]. So, maybe I'm not new in Debian, but Debian is often new to me, When there's no team to provide me with some well thought defaults, I could use a well documented set of well thought defaults to work with. Enrico [1] if one finds themselves in a similar position, a good way of staying up to date is to become Application Manager. AMs routinely learn a lot from applicants [2] maybe with some policy-style upgrading checklists [3] the things I maintain don't need frequent uploads, and it's become sort of my expectation that for each upload that I make I need to plan some nontrivial yak shaving time to figure out which of my assumptions have become invalid since the last one -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: debian-private leaked on pastebin, worried
On Mon, Aug 05, 2019 at 12:50:27PM +0200, Geert Stappers wrote: > And I think he worries more about Debian then the majority of us. > That is something that does worry me. I this this is more obsession[1] than worry: when one worries about someone or something, one doesn't go on stalking and harassing them. Enrico [1] https://www.quora.com/Whats-the-difference-between-being-obsessed-with-someone-and-being-in-love-with-them -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Results of the Antiharassment Team Survey
eople who we expect to moderate it, and generally those people are
too busy keeping the service running to also deal with the moderation.
Or possibly, the expertise needing to keep a service running is not the
same expertise needed in being an effective moderator for the service.
Also, moderation isn't the same thing as antiharassment, and is
something that possibly has more to do with editioral choices than with
personal conduct. For example, I haven't met a single person who doesn't
regularly skip the frequent CRAN posts on planet, and I think planet
would be destroyed if every single person who syndicates their blog on
it started to post montly summaries of their work, but I certainly
wouldn't call those posts inappropriate content.
Still, the confusion with moderation as editorial choices to keep the
signal-to-noise ration of a given medium optimal and moderation as
stopping inappropriate behaviour, and the confusion between who is
running a service and who is moderating it, means that it's just easier
at the moment to do no moderation at all, and I think we're missing out.
Then I'd like people who can do early intervention with short temporary
bans from lists or the bts when people get heated. I'd like it to be ok
to be kicked out from lists for a few days, and since everyone might
have a bad day every once in a while, It might even get to a point when
most people who have been in Debian for more than a decade could count
one or two short bans from a list in their history. It'd be better than
being able to count having flooded one or two threads in an extremely
embarassing way and having everything archived everywhere across the
internet for everyone to see.
It'd be more akin to asking a person to take a step back and count to
ten, than to tell a person that they are a harasser who is abusing
people. I'd see value in having this teams also being a team able
to add "and are you ok? Wanna talk?", now that they have someone's
attention, but I'd rather have one or the other, than try to have both
and end up with none.
I think this role would also need some delegation, to allow people who
run the services to act on their requests without the need to double
check them every time.
I would guess that all these needs of mine are needs that are more or
less shared by many in Debian, like a static charge building in the air,
and now that we are waving a lightning rod in that general direction, we
get a request for *everything* coming through: mediation, early
intervention, moderation, safety net, confidentiality, interpreting the
CoC, being reactive, being proactive, be nonjudgemental, pronounce
judgements.
I'm super happy that we are having this discussion, and that we are
starting to deconstruct and map the gaps that we want to fill. I don't
think we'll be able to fill them all, and least to fill them all with
one team, and incremental improvement is better than no improvement.
If we can get someone who interprets the CoC, but doesn't do mediation
or moderation, I think that's better than the status quo.
If we can't have a mediation team, we can start a collection of links
for conflict resolution that anyone in Debian can read, and add to
Developers' Reference a section on how to help when people seem to be in
trouble, and how to ask for help. I think that'd be better than the
status quo.
And so on. Debian is going to be around for a long long time: we'll have
the solutions to all our problems when they're ready. In the meantime,
I'm super excited that we're working on them!
Enrico
[1] I make no assumptions on directionality of help in a conflict: I
think there is a stage at the beginning when everyone could use
help. Even if one party turns aggressive, it may happen out of
frustration from not being heard, for example.
See https://en.wikipedia.org/wiki/Tone_policing
[2] Or maybe that it's good to expect that if I don't postpone sending
my emails when I have a bad day, I'll get 20 mails from random
people telling me to take some long breath before posting next time.
That sounds healthy actually. I'd like to expect that those 20
emails are not harsh, though, because harsh replies don't generally
help with recovering from a bad day.
[3] https://en.wikipedia.org/wiki/Bystander_effect
[4] I'd like to document an invitation never to be alone in Debian, and
always have a few friends/teammates at hand you're comfortable with,
who can help you weather a bad day, or support you and help you to
respond if you find yourself on the receiving end of something
unpleasant.
[5] There would be the team mailing list or IRC channel, but sometimes
one could use some confidentiality.
[6] *sends a mail*
"Failure to assume good faith!"
*takes one penalty card*
[7] https://joeyh.name/blog/entry/thread_patterns/
--
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini
signature.asc
Description: PGP signature
Debian Easter shake down
Joerg, Jonny, Christmas was so much fun, lets do it all again Hang some developers over the side of the ship for a good shakedown and make them give us all their Easter eggs Enrico -- ,''`. : :' : Enrico Zini `. `'` Debian Account Manager `- --- Take your mailboxes with you. Free, fast and secure Mail Cloud: https://www.eclipso.eu - Time to change!
Re: Appeal procedure for DAM actions
On Tue, Jan 08, 2019 at 01:21:20PM +0200, Jonathan Carter wrote: > If I read the original text correctly in item 1 above, it seems that > only the person who's rights got revoked can appeal? Yes, correct. > If that's the case, are you talking about multiple appeals from people > who have had their membership revoked, or is it that I interpreted it > wrong and that anyone can appeal? I'm clarifying the corner case in which two people have had their membership revoked, and are in a position to appeal in overlapping time frames. This should almost never happen, but given that we have waived the time limit for the cases in the last 6 months, we have potentially overlapping time frames now. Enrico who unfortunately cannot run this kind of procedure through valgrind --tool=helgrind -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Appeal procedure for DAM actions
On Mon, Jan 07, 2019 at 11:27:35PM +0100, Joerg Jaspert wrote: > 1. Appealing DAM decisions > -- > Any person who had their Debian membership suspended or revoked by DAM may > appeal the decision. They must request the appeal within 30 days, stating > why they disagree with the decision in a mail to DAM. DAM will notify the > New Members Committee (NMC)[1][2] and Front Desk. In case two people appeal at the same time, the NMC should not have to discuss multiple issues in parallel. if an appeal is requested while another appeal is already ongoing, starting the later appeal is delayed until after the committee has finished voting on the previous ones. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Planet Debian revisions
On Wed, Jan 02, 2019 at 05:39:58PM +0200, Jonathan Carter wrote: > 4. Avoid posting personal fights or insults. Planet Debian is not an > appropriate medium for this. If I'm still on time, I'd suggest: "personal fights, insults, or slurs", as I'm not sure how much we can give for granted that everyone understands that using slurs counts as insulting. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Censorship in Debian
Hi, On Wed, Dec 26, 2018 at 01:13:53AM +0900, Norbert Preining wrote: > For those not aware of the issue, here is *my* view onto the events. > AH and DAM can answer and provide their own interpretation. I will try > to stay as objective as it is possible for me. As written in the message we sent you, none of the issues linked, taken singularly, would be worth of taking action, but taken all together they represent a long recurring trend. The reason we took action is because: > our impression is that you seem to ignore the issues raised > while attacking the people who raise them. That is not an acceptable behaviour in a community that is built by the cooperation of a diverse range of skills and people. Also, we could see, while considering the situation, that this kind of trend is not just a thing of the past. As we wrote here: > On nov 27, the antiharassment team removed your blog post from Planet > again, because of yet another reiteration of these problems. Your > response, even though it was framed like asking questions, again it read > as an accusation to the people, a delegated team in this case, who, once > again, called you out. > > On dec 4, you have unilaterally readded yourself to Planet Debian. This was another, recent repetition of the trend of attacking the people who raised issues instead of listening to them. In particular, this part of your reply to the antiharassment team, that you chose to leave out when reposting it here on -project: > Question 4: several people feel uncomfortable > - > If you consider the harassment team different from a hidden military > court or a gulag general, I expect that those who have deposed complains > do not remain anonymous. Please let me know who initiated this > procedure. I hope this helps make sense of our decision. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Automatic downloading of non-free software by stuff in main
On Fri, Dec 01, 2017 at 08:22:58PM +0500, Andrey Rahmatullin wrote: > > Debian ought to be a good upstream for everyone, not just "me" > > (whoever me is). > Our users are declared our priority, our downstreams aren't. It never occurred to me that our downstreams could be considered as not being a part of our users. Is that a common understanding? Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Emeritus status, and email forwarding
On Wed, Nov 15, 2017 at 01:45:52PM +0100, Mattia Rizzolo wrote: > In many cases (such this particular one) people don't have a viable gpg > key anymore in the keyring: that means they can't email > chan...@db.debian.org to update their LDAP details (theoretically, they > might still know the LDAP password and do it from there, but in practice > all the people who reach that point already forgot it). > So there is really a very technical issue to overcome for your proposal. I would be ok with saying that emeritus people who have a valid gpg key can still have email forwarding, exporting the emeritus keyring alongside the other keyrings, and handling email forwarding configuration changes via chan...@db.debian.org, and key replacements as usual. It would exclude people who don't have a viable gpg key anymore in the keyring, or who are not interested in maintaining one, but that is already the case mostly anywhere in Debian, and I don't see it as a blocker for keeping forwarding working as long as someone is emeritus and has a key in the emeritus keyring. I would also be ok saying that people whose keys in the emeritus keyring become invalid over time, because they expire or because they are not replaced when needed, move to "removed" status after a while. Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC
hurt again. Also, almost any post can be NSFW for some values of Work. For example, I know there are workplaces where talking about Free Software would not be safe. So there needs to be some kind of political judgement made about when to say "if Planet is usafe for your workplace, it's our problem" and when to say "if Planet is usafe for your workplace, it's your problem", and I don't think a policy could cover enough corner cases to be the place where such choices are made. Rather than have policies, I'd like to have guidelines, and an editorial team who's trusted and empowered to make calls on a case by case basis. Who can say "we temporarily removed your feed because post X caused Y, can you remove the post from the feed, or change it so that it doesn't cause Y?" or "no, your feed can't be on Planet Debian, full stop". And if the team at some point loses the trust of the project, we look for a new team. Enrico [1]: I don't really care about each and every single release of GNU R libraries or of Gammu, or about the lists of last month's Free Software activities of a self-selected group of people. But then I avidly read nageru's news and intricate development details even though I know I'll never use it myself. Le cœur a ses raisons que la raison ne connaît point. -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: Formal declaration of weak package ownership in source packages (was: Replace the TC power to depose maintainers)
On Tue, Dec 06, 2016 at 03:42:57PM +, Ian Jackson wrote: > > It's a lot simpler to keep this metadata outside source package. > I endorse this product and/or service. Here's one way to quickly build a service like this: - Configure the web server to accept Debian's SSO credentials: https://wiki.debian.org/DebianSingleSignOn#Documentation_for_web_application_owners - Set up a Django site using RemoteUserMiddleware, but trusting SSL_CLIENT_S_DN_CN instead of REMOTE_USER: https://docs.djangoproject.com/en/1.10/howto/auth-remote-user/ (see the CustomHeaderMiddleware example) - Create the model and CRUD pages for the extra info you want to maintain about developers, with ForeignKey to django.contrib.auth.get_user_model() - Export your data with django-rest-framework Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org> signature.asc Description: PGP signature
Re: moving to usergroups
On Fri, Oct 16, 2015 at 11:09:34AM +0200, Peter Palfrader wrote: > Therefore I propose to: > - create, for each user in the Debian LDAP, a group named like the >user. > - Make the primary group for each user their corresponding group. > - Make their former primary group (Debian, guest) a supplementary >group. > > This would require adapting all scripts that currently rely on the gid > field to tell if somebody is a DD. They would have to change their > filter/condition from e.g. gidNumber=800 to supplementaryGid=Debian. > (Note that supplementaryGid is a multi-value field.) > > Comments/suggestions/concerns? As far as I'm concerned, go for it. I do check gidNumber on nm.debian.org in a couple of places, and I'll happily fix it. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini <enr...@enricozini.org>
Re: Debian Project Leader Election 2015 Results
On Thu, Apr 16, 2015 at 10:41:52PM +0100, Jonathan McDowell wrote: I get the numbers from nm.debian.org, both at https://nm.debian.org/api and https://nm.debian.org/public/findperson/ Sadly this list is trivially proved inaccurate; the list for Debian Developer, Uploading includes stew who was moved to emeritus back in January: https://anonscm.debian.org/cgit/keyring/keyring.git/commit/?id=b768c0a3506631ddeacf4c80ba8f3be6995e8a8f and finger s...@db.debian.org correctly returns no active fingerprint for the user. Copying Enrico who can no doubt comment more about the expected accuracy of nm.debian.org; AIUI it's still a work in progress in terms of being entirely up to date all the time. nm.debian.org is supposed to be the authoritative source, but Debian did not grow with having a single membership database, so in practice it needs to be kept manually in sync with changes coming from LDAP and the keyrings. Examples of membership related changes that can happen without nm.debian.org knowing are DSA adding a guest account, keyring-maint creating a DM (the current workflow skips FD entirely), keyring-maint replacing a key, keyring-maint removing a compromised key. Keeping it in sync manually is work, and I'm the only one who has been doing it. I've recently fallen behind, because syncing DMs from keyring changes is nontrivial[1] work and a lot new DMs piled up, and there is a large amount of 1024-4096 key changes pending, too. Now that keyring-maint has introduced machine-parsable and signed git logs, the sync with keyring can be automated somehow. It's a Simple Matter Of Programming, I already got started, but I'm the only one writing code. After that is done, we're left with the problem of DMs: the current workflow skips nm.debian.org entirely, so the data sources for new DMs are the keyring and RT, and none of them has information about alioth account names, which would be needed for sso.debian.org to work, so new DMs currently require extra manual intervention to be able to log into sites like nm.d.o and contributors.d.o, or DebConf. Also, if we want to be strict and have DAM really responsible and authoritative for new accounts, some of the syncing from DSA and keyrings need manual approval anyway, otherwise keyring-maint and DSA people will be able to create/remove developers without DAM knowing. I do not think that is a risk that we have at the moment, though, but it's a thought. There are ideas flying around. One is that DMs have a name in LDAP, or that the workflow for DM starts by filling in a form on nm.debian.org, which would simplify *a lot* of things, since most of the procedure for becoming DMs is made of mechanical steps. If we're not in a super hurry, we can make this all happen during Debconf at the latest. Or during a DebCamp sprint: we can organise a sprint about that, if there are other people interested in working on it. [1] nm.debian.org needs to have the first/middle/last name split that LDAP has, so I need to work out that split from full names in key UIDs, among other things, which is nontrivial: http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian Project Leader Election 2015 Results
On Fri, Apr 17, 2015 at 10:00:56AM +0100, Jonathan McDowell wrote: As far as I know relying on the keyring and ldap has always been incorrect. The number was always off by a few. I've never quite understood why LDAP isn't accurate, but I couldn't figure out a simple query and even '((gidNumber=800)(!(shadowExpire=1))(objeass=debianDeveloper))' gives 988 entries of which some are incorrect. [...] The astute will notice that this leaves 981 keys, whereas I counted 983 keys in the keyrings. It turns out there are 2 DDs who have removed 1024 bit keys but who have locked LDAP accounts (issue with SSH key on one, DSA locked on the other as comments). Anyway. The 2 things to take away are a) yes, it's depressingly hard to work out how many voting members Debian has and b) the answer is 986 at present. Indeed. We have multiple user databases, each with its own sets of corner cases. We cannot currently univocally identify a person by account name (DMs and Debian Contributors do not have one), by alioth account name (a person can have many), by GPG key (a DD can have none, in case they just revoked a stolen one), by full name (hi Brian Nelson(s) and Luca Bruno(s)), by email (it changes). LDAP login can be disabled when one becomes emeritus or temporarily after a case of abuse. DSA can create guest accounts. In nm.debian.org's nightly maintenance I run a lot of code that computes differences between these data sources, so we have the capability of tracking things, and the possibility of manually tweaking nm.debian.org to really fit the bill. But since we have also a need for manual tweaks, it gets out of date. It's was my understanding that DAM says that nm.debian.org is authoritative. That is the eventual goal but at present various pieces of information are manually updated. Enrico and keyring-maint have been working on making it easier for nm.d.o to track keyring changes but there's still more to be done before this is complete. There's a vague plan to get this done during DebConf if not before. And indeed that'd be the way forward as I see it: reduce the need for manual intervention as much as possible, so that routine takes care of itself, and manual intervention is only needed for corner cases, which are hopefully few and far apart in time. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: About the recent DD retirements
On Wed, Jan 21, 2015 at 06:46:16PM -0800, Russ Allbery wrote: about it). But there are still a lot of hard and interesting problems, which are worth working on. So, one, we need to figure out how to make those problems apparent and provide people leverage to work on them. But we should also consider that the project has a lot of appeal for people I volunteer one such problems: packaging collections of packages. simple-cdd is a tool that tries to make it easy to create subsets of Debian: you give it a debian version to build from (wheezy, jessie..), a list of packages, some debconf preseedings, and you get an ISO image. To do that it coordinates reprepro, debian-cd and a bunch of other utilities. I've recently been porting simple-cdd to python, and in the process I refactored it so that it contains more internal documentation. The list of relevant environment variables to control the process is quite daunting: http://anonscm.debian.org/cgit/collab-maint/simple-cdd.git/tree/build-simple-cdd?h=topython#n277 There's nontrivial work to be done there, and the result means making it easy to build package collections to support all sorts of interesting deployment and distribution workflows, with d-i images, live images, preinstalled tarballs, docker contains or what have you. And then it gets deployed and it's a standard Debian, well known, with clean upgrade paths and security support. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Reminder: Removing 2048 bit keys from the Debian keyrings
On Sat, Nov 08, 2014 at 10:19:02PM +0100, Richard Hartmann wrote: That seems to have happened in similar form a few times already; given the context, it's reasonable to expect them to poke -project, -private, or just anyone on their own. I know at least one of the people listed who is already taking action, currently managed to get one DD signature (me) and several other paths to the strongly connected set, and will probably wait until closer to the deadline to do the key update, hoping for opportunities for more DD sigs. Therefore I would not claim that all of the people listed there are sitting there doing nothing. I like that Jonathan's mail was worded as an invitation to offer help. Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Update to reimbursement procedure (now: max 3 months after expense)
On Tue, Oct 07, 2014 at 08:12:49AM +0200, Lucas Nussbaum wrote: Providing a rough estimate should not be a problem, given it is already required to get pre-approval. If it's already required to get pre-approval, why ask to send it again? Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org -- 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/20141007071834.ga18...@enricozini.org
Re: Reverting to GNOME for jessie's default desktop
On Thu, Aug 07, 2014 at 03:29:26PM -0700, Don Armstrong wrote: Specifically: 1) Would you want the default CD/DVD image to use a GNOME even if GNOME was unable to fit on a single image? 2) Would the GNOME team consider a less-complete DE for cases where image size is a restriction? How hard/sane would it be to have XFCE as default on installation CDs and Gnome3 as default on installation DVDs or netinst CDs? That way, people with disconnected, old computer get XFCE which has a higher chance of working there. People with computers that either have a DVD or a fast network connection, would instead default to the heavier/more-feature-complete desktop. Enrico either way, I use lxde :P -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: keybase.io
On Fri, Apr 04, 2014 at 07:27:36PM -0400, Paul R. Tagliamonte wrote: +1 russ. This is true of the dropbox daemon too. Are we to throw out DDs with dropboxd installed? Wine? ...skype, steam, flashplugin-nonfree[1]. Code git-cloned without checking signatures on tags[2] or doing some auditing[3]. Random cool vim plugins git pulled from random people on github with fancy selfies[4]. ssh -X or -Y to a remote host, then run X apps. I've recently got worried about common practices I see around me, and started considering running a Hardening Debian Development BOF at the next Debian event I'm going to participate. The intention would be to see how to address those issues, but with a strong awareness on usability[5]. Ciao, Enrico [1] for example, https://lists.debian.org/debian-vote/2014/03/msg00246.html skype and adobe can be trusted or course, it's not as if some random government wouldn't have motivation and means to tweak with their code. [2] As if people nowadays signed their tags. Or tagged releases. Or released at all. Who needs QA? Code review? The coolest features are in master, implemented an hour ago. [3] http://underhanded.xcott.com/ [4] luckily, this is disabled by default, but hell if I found a warning about it: https://github.com/scrooloose/syntastic/blob/master/syntax_checkers/html/w3.vim (also found in /usr/share/vim/addons/syntax_checkers/html/w3.vim) [5] https://www.schneier.com/blog/archives/2009/08/security_vs_usa.html -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: keybase.io
On Sat, Apr 05, 2014 at 12:45:53PM -0700, Russ Allbery wrote: If someone would write up a good step-by-step guide for how to isolate one's web browser in a VM running on the same host, so that you can still get reasonable display performance but have a real separation boundary between the web browser and the rest of the system, I for one would be extremely grateful. The same technique would work for things like Skype. I'm sure it's possible, but I don't know enough about the various virtualization systems to be able to figure it out quickly, and I've yet to get interested enough to spend several days figuring out a method. By all means, I'd love that. This is where I got to. Keith Packard assured me that running software in a nested X server like Xephyr is a way to prevent them from accessing the outside X session, and I considered it an interesting way of running skype, as a dedicated user, after checking that my home dir permissions are sound. Still, skype also wants access to hardware like a webcam, and I haven't yet felt like putting in effort to audit udev rules, and figuring out what having access to webcam hardware really allows one to do[1]. [1] Instinctively, that should only be get images out of the webcam; that wasn't the case for firewire[2]. Also, how is the LED light next to my webcam wired? Can the webcam be turned on leaving the LED switched off? [3] [2] And I grew up thinking that video hardware would just drive some video output, while nowadays on a Raspberry PI it'll read FAT filesystems on an SD card, parse config files and boot the system. [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? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: State of the debian keyring
On Fri, Feb 28, 2014 at 01:59:23PM +0100, Yves-Alexis Perez wrote:
It doesn't really change anything, does it? Sure, uploads are not the
only way to check someone is active, but still, people with no upload
since 2012 and a 1024{D,R} key is likely a candidate for direct contact.
It would probably be expected of me to point out that there is more to
contributing to Debian than just package uploads[1].
On the other hand, in my opinion even active people should be candidates
for direct contact[2], when they look like they're lagging behind what's
expected and announced to debian-devel-announce.
Ciao,
Enrico
[1] https://contributors.debian.org/sources/
[2] Especially helpful and polite direct contact, rather than direct
contact to the head with a knobby stick :)
--
GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org
signature.asc
Description: Digital signature
Re: State of the debian keyring
On Mon, Feb 24, 2014 at 06:51:37PM -0800, Russ Allbery wrote: Brute-forcing the key just requires compute cycles. There is essentially no chance of discovery and no risky activity at all until you start actually using the key. ...which reminds me of http://www.enricozini.org/2008/tips/audit-uploads/ which was a prototype of creating an audit log of key usage in debian. However, for the audit log to be usable as an audit log without giving a false sense of security, it should be complete, and really cover all instances of key usage in Debian. This means hooking into any place where a signature verification or a decryption actually happens in Debian: I can think of uploads, db.debian.org, voting, keyring requests, RT tickets filed, emails received by lists or the BTS: are there more? I see the job as not so much technically complex[1] as socially complex: since I would not trust auditing an incomplete audit log, I fear that a missing or badly implemented data source could invalidate all the system. So I can't just open vim and write the code: auditing key usage in package uploads requires someone who knows dak inside out, and can commit to maintaining notification triggers in all obscure corners where keys are used, now and in future updates of the ftp-master toolchain. Same goes for any other bit of Debian. The starting point for this work is probably this, then: is it just me, feeling that we have a problem here, or am I actually in the good company of people who can do their bit? Ciao, Enrico [1] For realtime auditing, we now have a rabbitmq server. Or collection could be decoupled in one audit log per team, which are then aggregated by a separate project. Or they can be submitted to a central collection point, like a new ad-hoc bit of contributors.debian.org. I don't see anything technically difficult here. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: State of the debian keyring
On Sun, Feb 23, 2014 at 05:46:53PM +0300, Cyril Brulebois wrote: (It took me like 4 years to switch to my current 4k key, partly because I didn't feel the urge to switch, and partly because I would have hated wasting your time with a malformed request.) It also took me a long while to switch because I didn't understand that it was already this urgent, so my mode of operation was let's collect sigs for the time being, and switch when I hear another call. I think it would be useful to see an update to debian-devel-announce, explaining what's the current vulnerability status of 1024bit keys, and asking to please switch NOW. As a potential follow-up plan, I propose this one: After a month or two, we can start mailing people directly, starting from the most active, asking why they haven't migrated yet, and asking them to please tell others to migrate if they see a 1024 key around. After another month or two, we can start taking keys off the keyring, starting from the less active people, and announcing each batch of removed keys to d-d-a. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Disabled authenticated access to nm.d.o and contributors.d.o late tomorrow
On Mon, Feb 17, 2014 at 11:20:02AM +0100, Enrico Zini wrote: Some more changes are needed for sso.debian.org; as a consequence we expect logged-in access not to work from sometimes tonight (UTC) until late afternoon tomorrow (UTC). Today things did not happen as we planned yesterday. I have now disabled authenticated access to nm.d.o and contributors.d.o until I we can fix the outstanding issues that we have. Work on the fix does not fully depend on me, so I cannot estimate how long it is going to take to bring that functionality back online. I hope it is going to be just a matter of a couple of days. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: mailing list auto subscriptions
On Wed, Feb 05, 2014 at 09:43:12PM +, Lars Wirzenius wrote: I don't have an opinion on whether having DAM send a mail to $list-subscr...@lists.debian.org (for some set of lists) instead of just one mail with a pointer to the lists.debian.org subscription page, except for this: I would expect someone who's just been through the process to become a DM or a DD to already be subscribed to those lists, if they're interested. And so it should be. In the default NM conversations[1] we have this: debian-announce: Major public announcements debian-devel-announce: Major announcements to the developer community These two lists are must-subscribes. Everything else is optional. So if one hasn't already subscribed before then, there's another chance to do it. If anyone knows of people being DM or DD who have't heard of those two announce lists, or aren't subscribed to them, I'd like to figure out why, just in case we need to improve our templates. In my experience, ignorance tends not to be considered an excuse for something that was posted to debian-devel-announce, so I consider it something to care about. My current understanding, though, at least looking at the people I know, is that contributors tend to be already subscribed without needing to be explicitly told. Ciao, Enrico [1] http://anonscm.debian.org/viewvc/nm/trunk/nm-templates/nm_pp2.txt?view=markup -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Sun, Jan 19, 2014 at 12:04:17PM +, Ian Jackson wrote: My reasons are quite different to yours: to summarise, it seems to me that the init system decision involves political questions as well as technical ones. I would gladly vote an option that says: technically, we trust what the TC says; politically, we are concerned about some of our upstreams' choices. A technical endorsement need not also be a political one. I would like to keep the technical and political issues as distinct as possible, though. I am not interested in spending time evaluating each option to form a technical opinion on what the best choice would be, and I'm extremely happy that the TC are doing that for me. I do have personal opinions on some of the upstreams' choices, but I believe that they should not get in the way of a technical decision. A constructive thing that we may do as a project to address the political side of the matter, is to add to our technical decision a list of things that we wish our upstreams would do to make all our lives easier in the future. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On Tue, Jan 07, 2014 at 08:32:23AM -0500, Brian Gupta wrote: Well the toolset that people in the fast moving startup world are using to provide devs with a local dev environment that very much approximates their multinode prod envs is a combination of vagrant, virtualbox, and the puppet/ chef code used to provision those environments. (Basically a toolset to automate the provisioning of local VMs that are configured like their production machines). I don't know enough about DSA infrastructure or the issues to say whether or not this would work for us, but it may be worth investigating. Our production environments are debian stable+backports, and all web application dependencies should be debian packages from stable+backports. I don't think we need any fast moving startup infrastructure: just debootstrap, puppet to configure the VM (or a copy of the server's apache configuration), and apt-get. We are a distribution, and already we do very good integration work. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian services and Debian infrastructure
On Sun, Jan 05, 2014 at 12:05:18PM +0100, Raphael Hertzog wrote: 1. to improve communication between DSA and service maintainers + have an archived, public list where (prospective) service maintainers can engage with DSA about stuff they are planning/thinking about. (Maybe recycle debian-admin@l.d.o, or use debian-services-admin@l.d.o?) debian-services-admin@l.d.o seems to be rather appropriate for this (it's unlikely that this kind of discussion would generate so much mail that the list could no longer serve its current purpose). debian-services-admin@l.d.o seems to me, too, to be the perfect place for it. It would also be helpful to have a document explaining their usual requirements. It would pro-actively direct the service maintainers towards choices that are acceptable to DSA. Things like: - use PostgreSQL if you need a DB - keep in mind that DSA likes to ensure high-availability, so make it easy to run a replicate of your service - avoid dependencies not in stable or stable-backports - avoid X, Y, Z for security reasons - etc. Also agreed. It sounds to me like a specifications of the production environment where things will be deployed, and it's something that as a developer I should see sooner rather than later. 2. to improve the tracking of services + request wiki pages from maintainers that detail who are the contact points, what the service does, what are its requirements. State a service level agreement (informative of expectations, not punitive, of course) + have service maintainers create similar pages for services in development, to provide some kind of incubation process during which DSA can provide feedback. This would be good to have but (someone|DSA) would have to prod service maintainers to get this started, otherwise it will never happen. This requirement could also be mentioned in the document I suggested earlier. I think we already have something very close to this description here: https://wiki.debian.org/Services Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Google contacting (harassing?) new DDs
Hello, it looks like as soon as one becomes DD, an email arrives from Google recruiters. I understand that some people may find it interesting, and some people find it annoying. My experience with just ignoring their email was that I was contacted again. I am toying with the idea of contacting companies with aggressive recruiting policies like Google asking them to please leave us in peace, and offering instead to maintain a wiki page of recruiting contacts for companies that like the taste of DD blood. Something like: These companies consider Debian Developers as especially interesting people to recruit. If you are a Debian Developer and looking for a job, you can reach them using the contacts below: Google: f...@google.com Facebook: b...@facebook.com Amazon: b...@amazon.com Canonical: g...@canonical.com ... and so on. Comments? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Google contacting (harassing?) new DDs
On Tue, Dec 10, 2013 at 06:14:51PM +0100, Daniel Pocock wrote: Even if one major employer politely agreed not to do this, it is worth remembering that there are gazillions of tiny little agencies out there. Most operate at arm's length from the big employers, giving themselves more latitude in their choice of tactics, to put it politely. We would probably never be able to stop all of them trawling through Debian membership/contact data. I'm not much interested in stopping spam, but in just making it better for everyone involved. People may not want to be contacted now, but at the same time may not want to train their spamfilter to delete job offers. On the recruiter's side, they would only get offers from people actually motivated to take up a job with them. On our side, we hopefully lighten the burden somewhat[1], and we get to know that the people not playing by the book are probably also not playing by a whole lot of other books, which may be another source of interesting information regarding a potential employer. Ciao, Enrico [1] from my personal experience, negotiating an alternative solution with Google alone would get rid of a significant percentage of potential harassment here. I would assume that Google is an entity we can talk with, with a reasonable hope of success. -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: The tell me if I'm being stupid statement
On Thu, Dec 05, 2013 at 01:30:17PM +0800, Paul Wise wrote: Do we need explicit statements like this? I always had the impression that everyone feels free to ask people to improve their behaviour (at least in recent years) and that most people don't have a problem being asked to improve their behaviour. Agreed. It really should be expected to be the default, with no need of stating explicit consent to it. In part, because no smoking signs just make smokers want to smoke more[1]. In part because it sort of implies that the default is that you can't tell a friend if they're being stupid unless they have an explicit statement in the signature saying that you can. It would make logical sense, in this respect to have a signature saying Please don't tell me if I'm being stupid: I know I am[2] but I don't see this being usefully picked up anytime soon. Ciao, Enrico [1] http://blogs.villagevoice.com/runninscared/2011/05/no_smoking_sign.php [2] and a procmail filter handling mail with such a signature appropriately -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Code of Conduct: picking up
On Thu, Nov 28, 2013 at 12:19:57PM +0100, Thorsten Glaser wrote: Following the Code of Conduct I will probably be punished for making jokes about the different gender, different religion, different political opinion, and maybe even different OS. Where is the border, where is the limit. 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”). As was pointed out at the time, that was not a violation of some code of conduct, but a violation of the DMUP[1], which you were supposed to have read, understood and signed the moment you became a Debian Developer. The DMUP is not a ritual about politeness, but a prerequisite that makes it possible for Debian to run its infrastructure. I invite you to please take a moment to read it again. Further mistakes of that kind from you will not be tolerated, as far as I am concerned. [1] http://www.debian.org/devel/dmup Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Debian tech tree
Hello, this should look familiar to many people: http://www.civfanatics.com/images/civ2/poster/civ2chart.jpg I had the odd idea that we could have a similar thing for Debian: Packaging unlocks Sponsored NMUs unlocks DD, uploading (link to below) Sponsored uploads unlocks DM unlocks DD, uploading unlocks Sponsoring uploads unlocks Debian Mentors Unsupervised NMUs Application Manager Voting Delegations [...] Making cool infographics unlocks Web team unlocks DD, non uploading [...] I don't know if a work like this can ever be finished, since Debian is continuously changing, so I don't know how feasible it is to have a cool artsy layout, but then that isn't my field of expertise. I'd love to see this tried. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Result of the Code of Conduct BOF at Debconf
On Tue, Aug 13, 2013 at 08:20:28PM +0200, Wouter Verhelst wrote: slap others with the code of conduct. Enrico also raised a number of other points, but I'm afraid I'll have to say that I forgot much of it; I'll have to ask him to raise them again on the list. Sure. I thought discussing this CoC was difficult because I feel that its design goal hasn't been defined very clearly, and so everyone tries to stretch it in different directions depending on their personal feelings and priorities. I think that a work like this needs to start with an analysis of who the users of such a document are, what are their goals, how the document could help them. Once it is clear what problem we're trying to solve, whom we're talking to and what is in it for them, then it gets remarkably easier to write good stuff. If we are trying to create a document that people can be pointed at when they're having a bad day, then we should keep in mind that the document will be read by someone who, well, is having a bad day. It should treat the reader with the utmost respect, be extremely coincise, and offer useful reminders. Whoops, I screwed up, what can I do to limit the damage? -- I'd be curious to see what a document like that would look like. If we are trying to document the bits of the status quo that work, so that they are proposed as a baseline standard, then we're addressing newcomers and people who have just been on the wrong side of someone's bad day. People could use it to realise when someone is deviating from some standard, and decide whether the deviation is creative or destructive. I don't think that a document could be written that fits both goals, so I would pick one goal at a time and focus on creating something that does the job for that, and that thing only. If I were to try and reverse-engineer the users and goals of the CoC that was proposed, I'd get the feeling of something written by old-timers to express their frustration about what it is that makes discussion difficult. I think that's also a worthwhile document to write, but it shouldn't be called a CoC. It would rather be the description of a problem that we're trying to solve. If it were a piece of software, I'd say that we've jumped straight into writing code, without spending enough time understanding the requirements, and agreeing on them. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Revising the Code of Conduct
On Tue, May 21, 2013 at 10:32:09AM +0200, Wouter Verhelst wrote: So, without further ado, here's my draft: [...] As a general principle, I object to any attempt to codify good behaviour. The DCG, which I thank Lars for mentioning, was attempting to give clues and reasonable expectations to people looking for them, not to give rules for people to enforce. It is hard to define what is good behaviour in our environment. I'd even think that being unable to define and enforce good behaviour is a prerequisite where creativity is sought. Please note that a society where every single citizen is well behaved, and every single deviant is promptly corrected, is a police state. Bruce Schneier's Liars and outliers has some very interesting thoughts on this. I tend to work well in communities that are generally made of adults endowed with reasonable judgement and common sense, rather than communities of misbehaved kids in need of supervision. Adding rules tends to nudge things towards the latter. People who don't act like adults should just be treated as such and be politely asked to grow up, keeping in mind that all of us may occasionally slip into a childish behaviour on the occasional bad day, and often all that is required to recover is a friend who kindly gives the right feedback. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
I caught up with debtags patch reviews
Hello, the previous patch review interface for debtags.debian.net was rather cumbersome to use and I fell behind approving patches to go in the Packages file. In the last 3 days I've created a new interface, which is much swifter to use. In less than an hour, I managed to catch up with all the backlog, and I've just uploaded the reviewed tag data, well in time for Wheezy. I know some people were frustrated by the lack of migration of tags from debtags.debian.net to the archive. The situation has now greatly improved \o/ Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: DEP 12: Per-package machine-readable metadata about Upstream
On Thu, Jan 03, 2013 at 04:51:02PM -0800, Russ Allbery wrote: My point, rather, is that a bunch of the stuff that's being discussed as relevant to debian/upstream can change independent of any functional change in the package, and therefore the proposal raises the question of whether we want to put even more non-functional metadata directly into the source package instead of somewhere with lighter-weight update processes. I think this is particularly relevant to any information that isn't specific to a particular upstream version of the package. This currently happens with Debtags, since tags are changed at debtags.debian.net and not in package source files: Tag fields are injected by dak directly into Packages through an override file. It's a bit of a hack and we already discussed some ways of improving it; afaik it's the only existing example of a field that can change independently of functional changes in the packages. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: DEP 12: Per-package machine-readable metadata about Upstream
On Thu, Jan 03, 2013 at 04:57:56PM +0100, Guillem Jover wrote: option. The first fields that come to mind could be Homepage, Maintainer and Description (and for the latter this has already happened somewhat). But then this does not require a split in the source format, but only in the archive indices, and possibly in the package managers frontends. I'll throw in a few more data points. Other such existing fields that come to mind are Tags, and Vcs-* Possible new fields that haven't been introduced so far are: Popcon, Rating, upstream BTS type and URL, extra keywords for full text search indexing, date+time the package has first entered the archive, and/or the release; datetime that version of the package has been built/uploaded. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
On Mon, Aug 20, 2012 at 10:37:57AM +0800, Paul Wise wrote: Added info about wiki.d.o/forums.d.n user information access policies. Thanks. How much detail do you want on the data available? The use cases I can see for the page are: 1. someone trying to manage their own identity online (say, changing name after a wedding, adopting a pseudonym, tidying things up with middle names or transliterations...) 2. someone working in infrastructure, trying to link things together somehow. So I'd say, what is stored where? who can see the data? how do I get the data? how do I change the data? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Feedback on your Whois system proposal - Was: Re: Review of personal information sources in Debian
On Fri, Aug 17, 2012 at 05:13:10PM -0400, Michael Gilbert wrote: On Thu, Aug 16, 2012 at 8:52 AM, Enrico Zini wrote: Recklessly exposing too much information outside the context in which it was published can in some cases turn people away from contributing. If [...] Couldn't most of these problems be solved by making the system opt-in (i.e. requiring the user to do some manual configuration under his alioth home with the ability to enable only the appropriate bits that he/she wants)? I don't like you opted in so now I do whatever I want with your data, either. opt-in could be useful for some odd features, but I think it's more useful to allow people (within reason) to manage their information (both in terms of being informed, and in terms of being able to change it), and to be careful when playing with things that are visible by search engine robots. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
On Thu, Aug 16, 2012 at 02:33:55PM +0200, Enrico Zini wrote: In terms of implementation, I see an overlap with nm.debian.org, portfolio.debian.net and db.debian.org. ...and the Debian Maintainer Dashboard (http://udd.debian.org/dmd.cgi), thanks today's Misc Developer News. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
On Fri, Aug 17, 2012 at 11:22:55AM +0200, Olivier Berger wrote: Here you go : http://wiki.debian.org/ContributorsInformationSources Others, I haven't re-read the thread, to add other contributions to the discussion to the wiki page. Feel free to edit it at will. I've added MIA and Carnivore, mostly as stubs, which were mentioned to me in a private email. UDD was also mentioned to me, but I don't know if it should be added to that list. It probably shouldn't if it's just an alternative interface to existing data sources. However, it probably should if it is storing unique information, or if it is distributing information to a larger audience than the original data sources. For example, UDD exports carnivore data to anyone who has an alioth account, but can carnivore itself be accessed by people who just have an alioth account? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
On Tue, Jul 31, 2012 at 12:57:29PM -0600, Paul Wise wrote: wiki.d.o: email/jabber address, name, page subscriptions, timezone, other settings. forums.d.n: email, various contact addresses/URLs. carnivore: stores other email addresses that might be unknown to the keyring LDAP. Added to http://wiki.debian.org/ContributorsInformationSources mostly as stubs. Could you please have a go at the details? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
already thinking of adding alternate emails from MIA to nm.d.o, which would improve the portfolio and DDPO links and the default minechangelogs search. The only information we would then miss would be badges and stats. I guess that, for those, what we most need is a way of collecting them: a standard REST API that various pieces of Debian infrastructure can implement, perhaps? Once the data is collected, where it is displayed becomes a detail: it could be a stand-alone site linked by nm.d.o and portfolio.d.o, it could be nm.d.o itself, or both. I guess that boils down to what technologies whomever is doing the work is comfortable working with. Regardless of the final implementation, I think network APIs are a must, so that even if you make your own website, I can still easily show badges on nm.d.o pages if I feel like, and you can get personal info from nm.d.o without needing to keep your own database in sync. P.P.S. Have you seen https://wiki.mozilla.org/Badges ? Hah, no. I didn't know about that! It looks very nice, and it's a very similar concept. Although it probably doesn't make much sense in trying to integrate with them. I was looking at it mainly as a standard protocol to handle badge information. Even if we don't care about integrating with them, what would you think of just reusing their technology? Also, it's not like this is a great idea that came to me overnight. We have something very similar in spirit at work, and that's where my idea came from. Sure, and no matter where it comes from, I think it's a good idea, it's great that you're working on taking it to Debian. Ciao, Enrico [1] http://www.enricozini.org/2012/debian/more-diversity-in-skills/ -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Feedback on your Whois system proposal - Was: Re: Review of personal information sources in Debian
On Thu, Aug 16, 2012 at 10:38:10AM +0200, Olivier Berger wrote: I think Ohloh.net provides, for instance an interesting comparison to your proposal (see my profile for instance [0]). In case you didn't know it, I suggest to check its features for inspiration. While I agree with most of what you said, I feel the need of a warning before taking ohloh too seriously as an inspiration. In my experience, ohlog has severe privacy issues: I once wrote them saying that they were misrepresenting my work skills and politely asking to please not show any information about my online persona, and they basically replied telling me to fuck off. They didn't use the f word, but they have been just as offensive. We must not assume that, since there are public logs of VCSes or uploads available for one's Debian work, then the person contributing to Debian cannot have some reasonable objections on how that data is processed and displayed, especially when processing changes the meaning of the data somehow. For example, if I uploaded a package at 9pm yesterday, we can safely assume I'm happy that the world knows that I uploaded a package at 9pm yesterday. But we cannot, for example, assume that I also meant to publish information about when I usually do Debian work, or when I'm usually at home, or whether I like to do work or have fun during Italian national holidays. Similarly, if me and you commit patches to the same project, we don't necessarily mean to tell the world that we are friends, or coworkers. Suppose we had jobs at competing companies, and there were a nice page, easy to find in Google, that said enr...@magnets4u.com and oliv...@allaboutmagnets.com are friendly working together! just because we both commit to a software that's used by both our companies: first thing, we'd be expecting a call from our bosses, which might or might not be able to understand the logic of what's really going on. Recklessly exposing too much information outside the context in which it was published can in some cases turn people away from contributing. If ohloh were actually being taken seriously by people in my professional circle, I would probably have to consider going through the extra trouble of not using my real identity while contributing to Free Software. We do not want that. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Review of personal information sources in Debian
On Mon, Aug 13, 2012 at 03:22:02PM +0100, Martín Ferrari wrote: Sounds like you may be working on something like that, and in that case I'd be interested in being involved. I think a service that provides a centralised database of identities, which allows each person to tailor how their identity is exposed, would be very helpful, and would allow to improve many other services that currently rely on incomplete identity information, specially for non-D[DM]s. Indeed: nm.debian.org is currently the authoritative database for the status of people contributing to Debian, and it already tracks, for example, DMs and people with guest account. It kind of lends itself to be such a centralised place. I've already been giving some thinking at allowing people to tailor how their identity is exposed, and that was one of the reasons for doing this review. Code is at http://anonscm.debian.org/gitweb/?p=nm/nm2.git;a=summary What did you have in mind? Ciao, Enrico P.S. I did see your blog entry and wanted to get in touch, then I got sidetracked by other things. It's great you got in touch! P.P.S. Have you seen https://wiki.mozilla.org/Badges ? -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Review of personal information sources in Debian
Hello, I've recently done a review of personal information sources in Debian, which I'd like to share here both because I don't think this has been done before, and to check if I missed anything. These are all the places I can think of, where we store personal information: - LDAP - nm.debian.org - the Debian keyring - alioth.debian.org (for -guest accounts) - debian/ directory in packages (control and changelog) - mailing list archives Let's go into details. * Mailing lists, packages, alioth One has total control over the email address used to post to mailing lists, over their alioth -guest account information, and over what information is used in debian/control and debian/changelog. Everything goes as long as uploads are signed with the GPG key of a DD (or DM), who takes responsibility for what goes in. * The OpenPGP key in the Debian keyring Not much to say here: your key goes in the keyring with whatever information you put into it, and is publicly exported. For the key to enter the keyring in the first place, some ID check is required, generally in the form of having other DDs sign some identities on your key. http://keyring.debian.org/ has details on managing it. * LDAP LDAP is the place where we turn to for real life needs, and where we would like to have real personal information. A subset of LDAP contents (first/middle/last names, key fingerprint, irc/jabber/icq contact info if provided) are publicly exported via db.debian.org, both on the web and over finger. The real name from LDAP is also exported via the GForge interface in Alioth: https://alioth.debian.org/users/enrico and via nm.debian.org: https://nm.debian.org/public/person/enrico * nm.debian.org nm.debian.org is only storing NM related information, and piggybacks on LDAP for personal information. The idea is that we want to reduce maintenance costs, so we try to reuse existing information sources. The site is most notably the authoritative place to know the status of a person in Debian (DD, DM, ...). It also stores all information related to changes of status, like advocates, process history and AM history, which is publicly exported only partially, so that the process log can be updated freely without worrying of it showing up in internet search results. It's partial (DM processes aren't yet tracked, for example) but getting better. Given that it acknowledges someone's status in the project, it lends itself to be used to credit someone's contributions and reputation. For example, I find myself using the People search function a lot, combined with the DDPO and Portfolio links, as well as the changelogs link once you're logged in. It has been pointed out, and I agree, that we should not publish real names unless where necessary, so that one can associate their Debian-related reputation with the online persona they prefer: for example, one may be known in the general developer community mostly via a nickname, and would prefer Debian-related search results to also show up under that nickname. Did I miss anything in this review? Is everything represented correctly? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Fwd: Today the public review period for ADMS.F/OSS v0.3 began
On Fri, May 11, 2012 at 02:25:13PM +0200, Olivier Berger wrote: You may be interested in knowing that a draft of a vocabulary intended to be used for describing software developped in forges, or listed in catalogues has been published by a working group attached to the European Commission (ISA programme), for review by the public. I imagine it could well be used some day to publish metadata about Debian distributions and or software packaged in Debian on the Semantic Web (for instance to interlink records of an upstream software, some user reviews, its debian packages, and other distributions', etc.). I'm sorry I don't have the time to participate personally, but should you need something to complement Trove categories, there are several facets in Debtags that are pretty well defined and useful. These are general purpose facets that are imo ready for prime time, and very useful: role, implemented-in, interface, system, uitoolkit, works-with, works-with-format, hardware. These are domain-specific facets that support important use cases: accessibility, admin, devel, field, game, iso15924, mail, network, protocol, office, science, security, sound, web. The use facet is one with a lot of potential, but which requires more thinking: it could be a good starting point for an interesting discussion. If you need anything debtags-related, you know where to find me: I hope I'll be able to respond in a timely manner. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Diversity statement for the Debian Project
On Thu, Apr 05, 2012 at 10:32:21PM +0200, Francesca Ciceri wrote: It doesn't matter how you define yourself or how others define you: we welcome you. We welcome contributions from everyone Moar nitpicking: s/define/perceive/g That gives: It doesn't matter how you perceive yourself or how others perceive you: we welcome you. This is after feedback from a respected friend on a private IRC channel, who pointed out that the concept of definitions has unwelcome connotations. Ciao, Enrico trying to prove that the draft is perfect by constantly trying to suggest improvements: http://en.wikipedia.org/wiki/Perfection#Paradoxes -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Diversity statement for the Debian Project
On Thu, Apr 05, 2012 at 10:32:21PM +0200, Francesca Ciceri wrote: The Debian Project welcomes and encourages participation by everyone. It doesn't matter how you define yourself or how others define you: we welcome you. We welcome contributions from everyone as long as they interact constructively with our community. While much of the work for our project is technical in nature, we value and encourage contributions to Debian from those with expertise in other areas and welcome such contributors in our community. I love how this is increasing in awesomeness as it is decreasing in size. I feel like suggesting two minor patches, labor limae if anything: s/contributions to Debian/contributions/ s/expertise in other areas/expertise in other areas,/ s/welcome such contributors in our community/welcome them in our community/ which would give: While much of the work for our project is technical in nature, we value and encourage contributions from those with expertise in other areas, and welcome them in our community. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Diversity statement for the Debian Project
On Fri, Mar 23, 2012 at 02:28:58PM +0100, Francesca Ciceri wrote: But I'd also like to have some inputs from you all, on it. Since one of my responsibilities in Debian is to actually discriminate people, I feel like I should contribute :) I like your idea. Such a statement is IMO a direct consequence of defining ourselves a universal operating system, and of having DFSG5 and DFSG6 in our Social Contract; but it's good that we spell it out. I also like the draft, and I'd happily accept it as it is. This is the extra input I can give: The Debian Project welcomes and encourages participation by everyone. We are committed to being a community that everyone feels good about joining. Although we may not be able to satisty everyone, we will always work to treat everyone well. Whenever any participant has made a mistake, we expect them to take responsibility for it. If someone has been harmed or offended, it is our responsibility to listen carefully and respectfully, and do our best to right the wrong. I can think of another thing that we care about, which I don't see mentioned here: We expect people to be constructive members of the community. That is something that we have learnt to pay attention to, over the years. Although this list cannot be exhaustive, we explicitly honour diversity in age, culture, ethnicity, genotype, gender identity or expression, language, national origin, neurotype, phenotype, political beliefs, profession, race, religion, sexual orientation, socio-economic status, subculture and technical ability. I could see elsewhere in this thread how detailed lists are a fantastic bikeshedding magnet; I wish I had an idea on how to get away with a list and just say what part of universal do you not get?. But I don't have any good idea to offer, and that list does the job. I fully agree with Russ at http://lists.debian.org/debian-project/2012/03/msg00054.html and I wonder if it's just enough to replace technical ability with skillset, and field of expertise. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: New DDs introductions ?
On Wed, May 25, 2011 at 03:40:34PM +0200, Stefano Zacchiroli wrote: On Wed, May 25, 2011 at 02:23:51PM +0200, Olivier Berger wrote: Is there any tradition to self introductions to the project, for instance via -project list ? Not to my recalling, but it'd be a nice tradition to establish indeed. I personally see no drawbacks in posting introduction on this list: 1) it has low traffic, 2) introducing new project members to the project discussion list seems (at least borderline) on topic, and 3) the flow of new DDs is not high enough to risk spam-ing anyone (IMHO at least). One of the reasons a shortened AM report, with bio, is posted to d-newmaint is to serve as a bit of an introduction (other reasons are to allow people to say yeah or oh noes!!. Of course that happens at AM approval time, not at account creation time, so I understand if that isn't enough. But it'd be sort of nice to merge the two things. Could it be something we can automate once we work on the new nm website at debconf? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Better visibility of what can you do with Debian on the?Debian main page
On Fri, Apr 15, 2011 at 08:56:46AM +0200, Andreas Tille wrote: was intended (and even if I do not like it personally - it is real). So why not using the name app store for a large set of applications where you can cherry pick from? I tried to post about it yesterday, but it doesn't seem to have been noticed: http://lists.debian.org/debian-project/2011/04/msg00054.html There is already a name: AppStream. It comes with code and standards: http://distributions.freedesktop.org/wiki/AppStream It's as good as any other, and I don't see the need to invent another one. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Better visibility of what can you do with Debian on the?Debian main page
On Fri, Apr 15, 2011 at 12:02:17PM +0200, Andreas Tille wrote: There is already a name: AppStream. It comes with code and standards: http://distributions.freedesktop.org/wiki/AppStream It's as good as any other, and I don't see the need to invent another one. I did not understand your mail in a way to use the term AppStream in front of non-geeks to explain what Debian means. My intend was to use a commonly used word to explain what Debian is. I know that the meaning of this word is stretched a bit - but that's the fate of words sometimes ... Sorry, I think I misunderstood the thread, I thought you wanted to redesign the current web views of Debian packages so that it is somehow more trendy/modern, but I now realised you only want to find it a trendier/more modern name. I stand corrected. However, if after finding it a new name you'd like to keep going and add things like ratings, comments, tag clouds and whatnot, you can go back to my messages in this thread and know where to start :) Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Better visibility of what can you do with Debian on the Debian main page
On Tue, Apr 12, 2011 at 05:47:18PM +0200, Adrian von Bidder wrote: My proposal (which is orthogonal) is linking to applications, just to show that Debian is not just an operating system as defined on our title page (set of basic programs and utilities that make your computer run.) It seems odd not to see the AppStream project mentioned here: I think that is the direction in which to focus these kinds of efforts: http://www.enricozini.org/2011/debian/appinstaller2011/ I'm chiming in with a few links and comments, and I urge you to have a good look because most of what you are talking about has been prototyped, or at least standardised in a cross-distro way: http://distributions.freedesktop.org/wiki/AppStream/Implementation Although in AppStream you will see that the main point is to build an application installer, as a precondition for that there is a need to build standard ways of accessing extra useful information like screenshots, various kinds of ratings, tags and user comments. Those standards could and should be used to build all sorts of other things, including fancy web-based application browsers: http://www.enricozini.org/2011/debian/pkgshelf/ In fact, you can take the graph at http://distributions.freedesktop.org/wiki/AppStream/Implementation and replace 'Software Center' and 'PackageKit' with 'Website': this gives you pretty much the architecture you need. I suggest you do exactly that: you'll find code and people to talk to, and it's a development effort that is likely to be shared with other groups and built upon. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: non-uploading Debian New Maintainer process
On Mon, Nov 08, 2010 at 01:01:38PM +0100, Gerfried Fuchs wrote: 4. Is it correct that now, the DNM process takes one year ? (See Applicants in Process on https://nm.debian.org/) It always did depend and always will depend on the individual applying, what they have done and how well they are prepared for the process. Also it is a sign of still too less AMs. I should also add that the Applicants in Process page does not show all those applicants that got through in a month or less: by its very nature (it shows applicants in process, not applicants processed) if one looks at that page one would mainly see those applications that get stuck on something for a reason or another. That is to say, that page is in no way representative of the average experience with the NM process. And they will advocate others to become non-uploading DD's :) How would a non-uploading DD advocate someone for getting uploading rights? This is the only part of your mail that actually stirred some thoughts in me. Advocacies are now reviewed by Front Desk before being accepted. If a non-uploading DD advocates somebody for having upload rights we'll just, as usual, read it and see if we should ask for more information or more advocates before assigning to an AM. Likely it will be the case, but the world being crazy and unpredictable, I wouldn't be surprised if some rare case happened when it will be perfectly clear that that won't be needed. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian training and code review
On Thu, Sep 16, 2010 at 01:13:45PM -0500, Raphael Geissert wrote: Am 16.09.2010 09:40, schrieb Enrico Zini: I'd love it to see it eventually go a step up, like having some review process by people with especially strong experience, and having them published by an own blog (à-la debian-administration) where they can be archived and searched. But that's just one of the many improvements the idea can start to collect once it starts happening. I though about having a specialised blog too, before suggesting the wiki page. The advantage of the wiki page is that the documents can be collectively pre-screened and evolved. Nothing prevents to have both: start on the wiki, when the content is judged to be good enough the wiki page is blogged, then let it stay as a wiki page to be improved further. Attach more bits of workflow to make it eventually end up on flossmanuals, developers' reference complements and so on. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: Debian training and code review
On Wed, Sep 15, 2010 at 08:47:33PM -0500, Raphael Geissert wrote: Random though: we could encourage people to write about different topics, post them to a wiki page (wiki.d.o/education/topic/sub-topic if necessary) and then post it on a blog that is syndicated by planet (a personal blog should be enough, a persistent copy would be at the wiki anyway.) A series of posts on -planet about best practices would be a very welcome thing indeed, and a quick way to get this started right now by everybody who'd like to do it. I'd love it to see it eventually go a step up, like having some review process by people with especially strong experience, and having them published by an own blog (à-la debian-administration) where they can be archived and searched. But that's just one of the many improvements the idea can start to collect once it starts happening. Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
Re: A team to grant rights on collab-maint?
On Mon, Jun 14, 2010 at 12:45:32PM +0200, Raphael Hertzog wrote: Now I would like to stop dealing with those requests and thus I would like a team of people to replace me. Do you have a way to know what percentage of non-DDs who can commit to collab-maint are DMs? Ciao, Enrico -- GPG key: 4096R/E7AD5568 2009-05-08 Enrico Zini enr...@enricozini.org signature.asc Description: Digital signature
