Re: Polling informally Debian Contributors
On Thu, Feb 17, 2022 at 9:26 AM Andrey Rahmatullin wrote: > > On Thu, Feb 17, 2022 at 10:02:13AM +0100, Philip Hands wrote: > [..] > You described Reddit, just with some very complicated integration with > your mail client. Apologies for jumping into this, despite not having time to participate properly in theconversation. I would urge folks driving this effort to have a look at Audrey Tang's description of the platform they've been using for country-wide consensus building in Taiwan. They have a reddit-like system but _without_ a reply button (nor IIRC a downvote button). That tiny ux change means that: - agreeing is effortless (just press upvote button) - disagreeing requires _constructive_ work (one has to make a new post, that actually proposes something, rather than merely criticise somebody else's) - a controversial post can be ignored, and only if it gathers a non-trivial number of upvotes one feels the need to do something about (aka xkcd.com/386) Their implementation is open-source but I doubt that it'd work for Debian. We'd need something that integrates with email and gpg signatures. It could be email in, web out (much like our BTS), although technically one could also have web in, to accommodate folks that are more keen on a forum like interface. Needless to say that this'd take a significant amount of work to design and develop. Somebody would need to figure out the relation between email threads and polls (and counter positions in the same topic). I don't have time to participate in centi-threads, let alone work on this, but I'd be happy to review any relevant docs in this direction.
Bug#703050: www.debian.org: Please document the criteria for debian.net services to be integrated into debian.org
Package: www.debian.org Severity: normal Hi, Some debian.net services would serve their purpose better if they were integrated into the www.d.o namespace, but the criteria for deciding which services would qualify is not documented. Here's some suggestions that could be a useful start: - there is consensus and/or evidence that the service is useful enough to warrant attention from d.o visitors - the developer of the service is willing to stay around to maintain the service, and/or produce sufficient documentation for its maintenance - the service's web site uses d.o's stylesheets and navigation, and meets the web team's accessibility requirements - the web team feels comfortable to support the service from a security perspective (eg. because the site is a bunch of static HTML files, or if it's dynamic, it uses a stack that's considered acceptable) - the original developer is willing to address any other concerns the web team might have cheers, sez ps. my personal motivation for this bug report is wnpp-by-tags.d.n which I think would serve its purpose better by relocating to eg. www.d.o/devel/wnpp/by_tags and linked to from www.d.o/devel/wnpp -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130314160829.5683.40807.reportbug@mobee
Re: Report from the debconf11 sponsoring/mentors BoF.
David, thanks for the report. Another issue that was mentioned during the QA is that debian-mentors is a misnomer and should ideally be called smth like debian-packaging. debian-mentors should become a discussion list for people that care about mentoring in Debian. Nitpicking aside, I care about mentoring but I don't have time for RFS calls (other then the people I already sponsor) so it'd be wasteful to subscribe to -mentors and I would rather have this discussion in -project instead. I suspect I'm not the only one like that. On Sun, Sep 11, 2011 at 08:44:23AM -0300, David Bremner wrote [edited]: Sponsor guidelines and tracking --- Up to now, sponsor metrics do not exist yet. For now we rely on static lists, giving people hints whom they shall ask for sponsoring if the general RFS procedure on debian-mentors did not yield any success (or, also along the usual RFS procedure). I (Arno) am currently staging a patch to Debexpo introducing limited support for sponsor metrics. It does not (and will not) feature the whole idea, but will allow developers, who are sponsoring packages to publish their personal sponsor guidelines in a more or less structured way. This will allow sponsored maintainers to learn about potentially interested developers more reasily, as the information is being coll- ected on a central, common place. Please stay tuned, I will announce this feature on behalf of the Debexpo team when it is deployed. Mean- while you are invited to test it and give feedback on it. Please contact Arno [6] if you want to have an exclusive look. Please note, no further matching is effectuated, in particular we are not trying to guess the right sponsor for a package. A sponsored main- tainer is on its own to find the best sponsor for his package. Nonethe- less it is hopefully still an improvement and can be used as starting point for further work. Arno, Janos (Cc'ed) expressed interest during DebConf in helping out as well, but I haven't had the time to ping him about it. I understand that there's two sides in this effort: debexpo plugins that produce additional info about certain package features, and a repository of sponsors' interests/preferences/requirements. Do I understand correctly that you implement both things within debexpo? Are DDs expected to enter their preferences via the debexpo web ui? My idea instead was to maintain DDs' preferences via an ikiwiki instance (using something structured like yaml), and make the wiki data accessible to debexpo via a REST interface. At the end of the day, it's up to whoever will do the work, but it's wise to remember that geeks prefer their favourite text editor than a web browser. Anyhow, thanks for stepping up, and whatever your approach, please share any code you have with Janos and see whether/how you could work together. cheers, sez -- Every great idea is worthless without someone to do the work. --Neil Williams -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110911215606.GD3458@mobee
[DEP9] inet-superserver configuration by maintainer scripts
[M-F-T set to -devel and my email] Hi, I claim DEP-9 for a proposal on inetd.conf updates by maintainer scripts. This proposal is the evolution of one I've made over a year ago, and takes into account the criticism and suggestions made at the time. FWIW I've contacted privately those that were against the old proposal, a while ago, to give them the opportunity to voice their opinion on this new version, and the only reply I've received was rather positive, so here it is for further discussion. Appended below the DEP itself -- please follow up to -devel. Cheers, Serafeim Title: inet-superserver configuration by maintainer scripts DEP: 9 State: DRAFT Date: 2011-02-28 Drivers: Serafeim Zanikolas s...@debian.org URL: http://dep.debian.net/deps/dep8 License: http://www.jclark.com/xml/copying.txt Abstract: Motivation, requirements and functional overview of a successor configuration tool for inetd superservers. [[!toc ]] # Introduction The inet-superserver facility (typically provided by the openbsd-inetd package) listens to certain sockets and invokes the right server upon the arrival of an incoming request. Servers that are meant to be invoked by inetd must add a service entry to /etc/inetd.conf upon package installation (and remove the entry upon package purge). Maintainer scripts that modify inetd.conf must currently do so using a utility called update-inetd, as per Policy 11.2. However, update-inetd has a problematic interface that leads to several kinds of bugs, including cross-package ones. Fixing update-inetd is largely a matter of fixing its interface, which would break backwards-compatibility. With that cost as a given (ie. the cost of revising all maintainer scripts of update-inetd's reverse-depends), one might as well create a successor tool with a cleaner interface. This DEP proposes such a successor inetd configuration tool, hereafter called reconf-inetd. reconf-inetd, in addition to providing the existing functionality, must meet the following requirements: * the standard configuration files of inetd and xinetd must remain the authoritative files; * the solution must not change the way system administrators configure inetd, and must have no impact on maintainers of Provides: inet-superserver packages; * reconf-inetd must be capable of co-existing with update-inetd, so as to allow a gradual transition. Note that the first requirement above implies that inetd.conf entries that have been (i) added by reconf-inetd and (ii) were subsequently modified by the user, shall not be removed even on package purge. # Motivation The main problem of update-inetd is that the service entry to be enabled, disabled or removed, is selected in terms of a service name, such as ftp. This limitation typically leads to cross-package bugs because of the difficulty to distinguish between independent implementations (eg. ftpd-ssl versus proftpd), or an ipv4 versus an ipv6 implementation of the same kind of service. As an example, in #168847, ftpd-ssl's invocation of update-inetd enables the service entry of (the previously uninstalled) proftpd because both packages' entries have an ftp service name. As of now, one can try to avoid the above problem as follows. A maintainer script may (i) further specify the acted-upon service entry in terms of a regular expression (which is matched against the whole service entry, instead of just the service name); (ii) override the default comment-prefix (#lt;offgt;# ), to distinguish service entries of different packages that provide the same kind of service (eg. #lt;off-ftpd-ssl-ipv4gt;# vs #lt;off-proftpd-ipv4gt;# ). These features work when used correctly, but at the cost of fragile logic in maintainer scripts. To summarise, the interface of update-inetd is inadequate in that it does not require that the following three elements are specified to select an entry: service name, protocol type, and path to server program. A secondary issue, but nevertheless one that would be nice to solve, is support for configuration updates of xinetd (#8927). xinetd has a relatively low popcon but one could argue that that may be the case because it is not well integrated in Debian. # Outline of reconf-inetd operation reconf-inetd will operate similarly to update-inetd, ie. add, remove, enable and disable service entries in /etc/inetd.conf. The main difference is that where update-inetd uses command-line arguments, reconf-inetd will use xinetd.conf(5) configuration fragments under /usr/share/reconf-inetd (hereafter called reconf-inetd fragments, for brevity). Moreover, reconf-inetd will be invoked via a dpkg trigger, as opposed to from maintainer scripts. With reconf-inetd, inet-superserver configuration will occur as follows: * reconf-inetd will provide the directory /usr/share/reconf-inetd, and declare a dpkg trigger for that directory * server packages that can use inetd, will depend on reconf-inetd and install a reconf
Re: d-d-a (and/or d-announce) on planet.debian.org
On Fri, Nov 05, 2010 at 01:57:55PM +0100, Mehdi Dogguy wrote [edited]: Nowadays, It seems that planet.debian.org became an important news media and has a fairly large number of readers. I think that a large number of mails sent to d-d-a (or debian-announce) may take advantage of this media to gain more visibility (e.g. various RFH sent to d-d-a by various teams). Makes sense. Or better even, publish d-d-a and d-a in news.d.n, and sindicate the latter in planet.d.o -S -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101105183612.ga6...@mobee
Re: debian-private declassification team (looking for one)
On Sat, Jun 26, 2010 at 11:34:36AM +0200, Ralf Treinen wrote [edited]: On Fri, Jun 25, 2010 at 02:46:02PM +0200, Frans Pop wrote: I would welcome a new GR to rescind the previous one and revert d-private to what it's always been: private. I would second a proposal for such a GR. If even those who argued in favour of the declassification process at that time are not sufficiently motivated to invest now some work in this then this proves to me that the whole thing is nonsense, and that we should get rid of it. There's a compromise: revise the declassification rules to help automation. Writing a perl script to filter msgs based on threading and well-defined declassification headers shouldn't be that much of work. -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100627211151.ga2...@mobee
Re: debian-private declassification team (looking for one)
On Fri, Jun 25, 2010 at 03:20:14PM -0700, Don Armstrong wrote [edited]: My own opinion is that we've done this backwards, and that everything on -private modulo vacation messages and posts explicitely marked with a header indicating that they shouldn't be declassified should be declassified automatically after three years. +1 When I first read the resolution, it really surprised me as to how bureaucratic the defined process is, as opposed to something amenable to automation. -S -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625224649.ga7...@mobee
Re: copyright
On Sat, May 22, 2010 at 12:54:18PM -0700, peter chan wrote: Hi, Is debian a free software for anyone to download use? can i download it and install on my own computer to practice how to use linux? Yes, it is free, and you are encouraged to do so. Details at: http://www.debian.org/intro/free -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100522210154.ge2...@mobee
The Softer the Topic, the Longer the Debate (was: d-devel b...@debconf9)
On Tue, Aug 18, 2009 at 10:57:24PM +0200, Josselin Mouette wrote [edited]: No, one of the biggest issues currently on the list is that some people are engaging into rhetorical wars and bikeshedding, instead of the technical discussions we expect. +1 Perhaps we should add pop-up (anti)features in all email clients as described in: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers (search for pop-up in the page) :-) (subject stolen from http://producingoss.com/en/common-pitfalls.html#bikeshed) -- debtags-organised WNPP bugs: http://members.hellug.gr/serzan/wnpp -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debian redesign
On Wed, Jul 29, 2009 at 04:51:22PM +0200, Ana Guerrero wrote [edited]: You can take a look at her presentation at: https://penta.debconf.org/dc9_schedule/attachments/112_debian_redesign.tar.gz What do you think? :D WRT the pics of the campaign, I find the ensuing discussion rather unproductive without an agreed upon set of objectives and the tradeoffs involved, eg. - What's the relative priority of the different groups of people we're aiming at? DDs and potential new contributors? corporate users? individual users? In other words, should the campaign focus in say attracting more corporate users, or more hackers applying for membership? (pixegirl says people outside the organisation, some debian folks disagree) - Do we want the campaign to be contentious (I'd think not) or as far as possibly inoffensive (and again, these perceptions vary among different kinds of groups)? Seems like many debian folks find pixelgirl's work of high quality but not meeting the desirable tradeoffs. Has there been an agreement or even a discussion about these tradeoffs in any debian list? -S -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: FOSDEM videos released
On Sun, Feb 15, 2009 at 06:09:11PM +0100, Holger Levsen wrote [edited]: blogging (1-203) life; title=FOSDEM videos released [..] And second, I have no real clue how useful our streaming efforts are, I believe the recordings are useful, but in both cases feedback from people who find them useful is appreciated! Covering FOSDEM is certainly a lot of fun, but it's also a lot of work and leaves not much room for seeing other parts of the conference. So a short reply (I'll post this to d-d-a with reply-to set to -project) will be very much appreciated! :) Yes, streaming is most definitely appreciated by those of us that weren't lucky enough to be around! Many thanks, Serafeim -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
