Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 03:40:40PM +0200, Ansgar wrote: > On Wed, 2020-04-15 at 08:56 +0100, Neil McGovern wrote: > > The point of the trust levels is to distribute the moderation. Whatever > > metric we come up with, it will involve a certain amount of actually > > using the site, and engaging with the community. > > Looking at some topics on meta.discourse.org, people explicitly use > trust levels as a "reward" tool to increase "user participation" in > some metric. [1] mentions this for example, but it's not the only topic > talking about reward systems or gamification in Discourse. > I think to be accurate, this should be rephrased as "some people, who are not discourse developers explicitly use..." - I know this may seem pedantic, but posting an example of where someone's priorities are doesn't mean that Debian would have the same priorities. > Badges and other systems serve the same purpose. I conceed that it certainly can, but I would ask you to consider that there are also other uses. As the discourse developers themselves have stated, a number of the badges are there to help guide new users on how to use Discourse features, and the badge notifications quickly drop off. Additionally, each badge can be customised and individually enabled/disabled. Note: I am not making a judgement here on the suitability of any particular badge or trying to balance if the badge award system is good or bad. In fact, the *whole thing* can be disabled, or a custom one addeed to encourage people to log in once an hour, or to like every post, should we wish to do so. I simply ask that motivations are not ascribed to what is going on when other possibilities exist. > (I can do those tricks too ;-) SCNR this one time...) > *grins* Neil -- signature.asc Description: PGP signature
Re: [Summary] Discourse for Debian
Hi Brian, On Wed, Apr 15, 2020 at 10:12:21AM -0400, Brian Gupta wrote: > Do we have to start by making it a mandatory switch? I don't feel consensus to > move to discourse will be impossible in the long term but it's normal for > human > beings to resist change, especially during a time of otherwise great stress. > I think we're miles away from making it a mandatory switch! In fact, I explictly stated this in my initial email: > What about the mailing lists? > This may or may not be a replacement for any particular list. I suspect > there are some thet would benefit greatly from having Discourse be the > primary interaction, and other places where this would be less suitable. > > Be specific! > Ok... I think debian-user, debian-vote and possibly debian-project would > be better off in Discourse. I think debian-devel-announce should stay as > an email list (for now). However, I am not suddenly proposing that we shut > those lists down. The aim of this exercise is to see if Discourse would > work well for us. The whole point of this is to evaluate if Discourse would work for Debian at all, rather than if it should be the primary communication platform. I think that discussion is very different. > How do you feel about making discourse.debian.org, and making it a fully > supported tool, that's fully backed up, and available as an alternative for > new > lists? He can have another discussion later about migrating existing lists. > Personally, I think that would be fantastic, and the idea behind this initial call for testing is to determine if I should be spending my time, and aiming for a discourse.debian.org instance, or if there is no appetite for that. Neil -- signature.asc Description: PGP signature
Re: [Summary] Discourse for Debian
On Wed, Apr 15, 2020 at 07:22:53AM -0400, The Wanderer wrote: > Would you be willing to list out which points it is from the given > "cons" category which you see as positives? > I'd really rather not at this stage, as I'm already seemingly having to spend time talking about how Discourse is set up, rather than what I was trying to do. I don't want to end up in a big debate on where "requires account" or "distributed moderation based on trust levels" sits. The point of this Discourse instance is to try and see if there is interest in moving to it rather than smartlists for community discussions. If there is sufficient interest, we can then find a group of people who want to consider these tradeoffs and who are willing to help with the way categories are organised, for example. If there is sufficient pushback, I'll delete the instance, move on with my life, and conclude that no one in Debian can possibly try and innovate or do new things unless it is either: * 100% optional for people, or * made completely compatable with the old way of doing things Apologies if the frustration is showing, but hopefully you can see where this is coming from. Neil signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 12:47:06PM +0200, Ansgar wrote: > I'm not concerned about marking messages read after some time and > keeping the view time in ephermal storage for that. But that's not > what Discourse does: as described elsewhere it stores all read times > persistently on the server; that would not be neccessary for marking > posts as read even on a web application. No, but it is required for things like knowing which posts in a topic is popular, so should be used for auto-summary. It also is used to reduce abuse, as a normal new user would spend time reading topics before posting for the first time. > Evolution also keep track of the mouse cursor, but that is something > different from recording clickstreams and evaluating them to increase > user participation as some people do. Your reply seems to put both on > the same level. My point is that it's unhelpful to automatically equate "user tracking" to something undesireable. > > Interestingly, I've generally mixed replying via email with visiting > > the > > site. I would agree that it's not en par with the web UI, but I don't > > think it ever can be, due to email being designed rather differently. > > >From my tries with Discourse, it just silently stripped all quotes out > from the reply. > Perhaps this is: https://meta.discourse.org/t/single-quote-block-dropped-in-email-reply/144802 > Is this documented in some discoverable place or hidden? I've still not > managed to discover any documentation for Discourse targeting the user > (compared to admin or API documentation). > https://discourse.mozilla.org/c/meta/faq/244 Generally, there isn't a central user documentation, because each discourse instacne can be configured quite heavily, depending on each community need. Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
On Wed, Apr 15, 2020 at 11:08:45AM +0200, Martin wrote:
> On 2020-04-15 08:56, Neil McGovern wrote:
> > Could I point out that the email program you wrote this message in is
> > doing the same?
>
> Could you elaborate on that? Ansgar seems to use
> "User-Agent: Evolution 3.36.1-1"
> (While I'm using mutt.) How do such UAs track reading behaviour?
>
Evolution tracks how long you've looked at a message in order to mark it
read. This is configurable in Preferences -> Mail Preferences -> Mark
messages read after X seconds. My point is that one cannot simply say
"user tracking is bad", as it may be required for actual functionality.
User tracking is also known as "saving state" :)
> > Quoting does work in most circumstances. Could you explain what
> > additional funtionality is missing?
>
> Speeking for myself, I find the email support in Discourse poor,
> to the point, that I would not advertise it. It is useful for
> notifications, but by far not en par with the web UI.
Interestingly, I've generally mixed replying via email with visiting the
site. I would agree that it's not en par with the web UI, but I don't
think it ever can be, due to email being designed rather differently.
> After reading more about Discourses many features ("likes"...),
> this is completely understandable that one cannot mimic one
> medium via the other. Trying so, will lead only to frustration.
Just on this one, you can a little. Replying with a +1 will turn your
email into a "like". Currently supported actions are:
* +1 or like: likes the post
* watch: watches the topic
* track: tracks the topic
* mute: mutes the topic
> Btw. do you know by accident, how I can "lurk" in Discourse via
> email? E.g. Let's say, I'm subscribed to debian-project, but
> only to know what is going on. Can I subscribe to a "category"?
Yes. You can subscribe to categories, topics and tags (or combinations
of them). For example, if you only ever care about m68k, you could watch
#m68k and get a notification email for that across all categories.
Neil
--
signature.asc
Description: PGP signature
Re: Testing Discourse for Debian - Moderation concepts
Hi Ansgar, To start with, I want to say that I found your mail to be quite frustrating. I feel it may have been more constructive to phrase concerns as questions, rather than stating them as facts, and ascribing motivations or inferances which simply aren't correct. That said, I'll try and reply to the factual bits. On Tue, Apr 14, 2020 at 02:30:52PM +0200, Ansgar wrote: > The "trust levels" though are one of the features that I don't like: in > particular "Trust Level 3 - Regular" mostly requires to constantly > visit the site every day (or every other day), read x% of all posts and > topics (even though they might not be relevant to your interest or in a > foreign language you don't speak), ... to not get demoted again. This is the default configuration. It can be changed to pretty much any limit we want, including zero. However, I should point out that the additional important abilities gained at this level are that the user can: * Recategorize and rename topics * TL3 spam flags cast on TL0 user posts immediately hide the post * TL3 flags cast on TL0 user posts in sufficient diversity will auto-silence the user and hide all their posts The point of the trust levels is to distribute the moderation. Whatever metric we come up with, it will involve a certain amount of actually using the site, and engaging with the community. > The system also requires tracking active read time and such; I don't > really like a system doing that... Could I point out that the email program you wrote this message in is doing the same? Exactly how this work and the reason for it being required is explained here: https://meta.discourse.org/t/how-does-post-tracking-work-in-discourse/115790 > The notifications to welcome new people or that the system hasn't seem > someone for some time[1] also seem designed to manipulate people into > spending more time on the system. Could you explain this please? I feel that having a notification (which only appears for people who regularly interact with the site) that someone is new to the community to be useful. > The claim of Discourse having an excellent email interface also feels > exagerrated: unless I missed something[2] it seems very basic. One can > send and receive messages, but quoting in replies already doesn't work > as usual and any additional functionality isn't exposed at all as far > as I can tell. Quoting does work in most circumstances. Could you explain what additional funtionality is missing? > > Instead, it encourages community members to flag posts. If a post receives > > sufficient flags, it is then automatically hidden. Users may chose to > > "unhide" the post for themseleves if they wish to view it. > > > > These are then sent to the moderating team to agree, disagree or > > ignore the flag. > > What decides who is in the moderation team? That seems to be something > different from the trust levels? Yes. At the moment those in the moderation team is... well, me. I would expect to follow something similar to Mozilla: https://discourse.mozilla.org/t/updates-to-moderation-guidelines/2 > I would also expect Discourse to have some way to entirely remove > messages, or at least remove the original content fully and replace it > with a notice that the message was removed; who can do that? Also the > moderation team? Yes, that is correct. Neil -- signature.asc Description: PGP signature
Re: [Summary] Discourse for Debian
I'm just going to correct things that are factually incorrect here, rather than label them as pros/cons. I feel a number of things you have put in the cons column are advantages. On Tue, Apr 14, 2020 at 01:31:56PM -0700, Ihor Antonov wrote: > - Not 100% GPL - some javascript scripts loaded into users browser are not > free Could you please let me know which scripts these are? > - makes it harder to use for people with limited abilities An example here would be useful. > - requires login This is incorrect. Anonymous reading and posting is possible. > - achievements/badges/other gamification of the process > - trust levels are revoked if you don't use web interface often enough to > maintain current trust level These are based on the default configuration and can be changed to suit Debian's needs > - currently no way to request removal of collected user's data This is incorrect. Neil
Re: Testing Discourse for Debian
On Tue, Apr 14, 2020 at 03:57:08PM +0200, Martin wrote: > Is the API stable in general, or only this particular function? If you're using the stable branch of Discourse, then the API is stable :) > I ask in the context of #956705: "ITP: python-pydiscourse -- > Python library for working with Discourse". Upstream says: > > > * Provide functional parity with the Discourse API, for the > > currently supported version of Discourse (something of a > > moving target) > > > > The order here is important. The Discourse API is itself > > poorly documented > The head version is indeed in flux somewhat, although I'm personally running the "tests-passed" branch in production with API integrations, and I've not had any incompatability problems. The documentation is at docs.discourse.org. I woudn't say it's poorly documented, but possibly incomplete. Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Mon, Apr 13, 2020 at 02:16:48PM -0700, Sean Whitton wrote: > Do you think that would end up capturing all discussions, with possibly > a few weeks delay? Is it typical in Discourse use to lock/close threads > after a certain point? And do you think the API is stable enough for us > to start doing something like this? > That's entirely dependant on the configuration :) For example, on GNOME's Discourse instance, I have a few categories where it is set to close 14 days after the last reply. Then again, people can also request that they're reopened... I suspect the API should be stable enough for this, if people wanted to store discussions in a form that isn't discourse itself. Neil signature.asc Description: PGP signature
Re: Testing Discourse for Debian
On Sun, Apr 12, 2020 at 07:39:34PM +0200, Enrico Zini wrote: > Does Discourse have some kind of export feature, that one could > postprocess to get for example a mailbox of annotated emails? > Yes, though I think there's just automated ways of doing this for the entire database, or for your *own* data at the moment. It would be fairly trivial to do this yourself though, as Discoruse is primarily two things: 1) An API 2) A webpage that consumes that API. If you can do it via the web, you can do it via the API. Neil -- signature.asc Description: PGP signature
Re: Testing Discourse for Debian - Alternate interactions
I am going to try and split this out into two replies, so those following along can see the different issues. The irony of the difficulty on doing this within email may or may not be lost for others. On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote: > - There are only 2 browsers out there in existence (Firefox and Chrome > variants) and duopoly in browser market is already alarming enough. > There are much more email clients available. > I have tried Epiphany, which works fine for reading and replying. I have tried with dillo and lynx, which work fine without Javascript enabled at all for reading. You can also interact with Discourse via email. > 2. I can't now use email the way I did. Discord's email interface is > subpar in spite of what sales people tell you. So If I want "a > first-class citizen" experience I am stuck with option 1 > This is correct. Discourse interaction by email can never be as good as interacting with it via a fully featured web browser. This is because, well, email isn't a fully featured web browser. There is a commitment to improve the email integration from at least one Discourse employee, who also happens to be a Debian Developer. I but do want to emphasise the point I made in my original mail: > It should be noted however, that there is not 1:1 feature partiy with > email and the web interface, as Discorse does things that can't easily > be done with email. For the majority of users though, email > interaction should be "good enough". Neil
Re: Testing Discourse for Debian - Moderation concepts
I am going to try and split this out into two replies, so those following along can see the different issues. The irony of the difficulty on doing this within email may or may not be lost for others. On Sun, Apr 12, 2020 at 02:43:31PM -0700, Ihor Antonov wrote: > > You have to trust the moderators, > > So far I am not convinced that I can trust you to moderate. > > > and you have to have some mechanism to > > evaluate that trust and to discuss it and possibly revoke it if something > > goes horribly awry. > > Prevention should always be the first step. Something WILL go wrong but you > are > too blinded by the immediate sugar candy in front of you. > I just want to state, I won't debate any issues around freedom of speech. I believe that these do not apply in this context - especially with Debian being a private entity. Now, I do believe you have a comment on moderation, and how this is done. This requires me to explain two concepts in Discourse - trust levels and flags. Firstly, trust levels. These are the levels of "trust" that the platform has in any particular user. Instead of explaining it here, please have a read of the following: https://blog.discourse.org/2018/06/understanding-discourse-trust-levels/ The short version is that the more a particular account interacts with the community in a positive way, the more trust the system has about them, and the more privileges they are afforded to assist in moderation. Secondly, flags. Discourse has the opinion that moderation cannot be proactive with a small group of users - this doesn't scale. Instead, it encourages community members to flag posts. If a post receives sufficient flags, it is then automatically hidden. Users may chose to "unhide" the post for themseleves if they wish to view it. These are then sent to the moderating team to agree, disagree or ignore the flag. This will unhide the post, or keep it hidden and offer an opportunity for the moderator to suggest the original author edits their post in light of the number of flags they got. If an author does so, the post automatically unhides. All these actions are logged, and affects the trust levels above. In fact, every time an admin performs any action on a user, this is logged. I hope this explains how I believe that moderation is more powerful on Discourse, but also more practical, transparent and accountable. Neil
Re: Testing Discourse for Debian
On Mon, Apr 13, 2020 at 04:54:28AM +0900, Charles Plessy wrote: > In that sense, I would expect structured discussion systems such as > Discourse to be a potential time saver, and therefore lower the barrier > for contribution to everybody: those who contribute their point of view, > and those who summarise them. > Just on this point, Discourse has an auto-summarise feature. This isn't meant to replace a human summary creator, but should help with megathreads and save people time. For example: https://meta.discourse.org/t/feedback-on-new-hamburger-and-user-menus/32519 has 231 posts, and an estimated read time of 29 minutes. If you click on "Summarize this Topic", it drops that down to less than 50 posts. Neil -- signature.asc Description: PGP signature
Testing Discourse for Debian
Hi folks, 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. FAQ === Is it Free Software? Yes. It's GPLv2+. Who else uses it? Lots of people. GNOME, Mozilla, Ubuntu, Fedora to name a few What about the mailing lists? This may or may not be a replacement for any particular list. I suspect there are some thet would benefit greatly from having Discourse be the primary interaction, and other places where this would be less suitable. Be specific! Ok... I think debian-user, debian-vote and possibly debian-project would be better off in Discourse. I think debian-devel-announce should stay as an email list (for now). However, I am not suddenly proposing that we shut those lists down. The aim of this exercise is to see if Discourse would work well for us. Email is still important to me! Fine, you can interact with Discorse by email rather than the web interface. It should be noted however, that there is not 1:1 feature partiy with email and the web interface, as Discorse does things that can't easily be done with email. For the majority of users though, email interaction should be "good enough". Why are you doing this? I have two motivations. First, is moderation. Discourse has built in tools to allow community moderation on a much better scale than our email lists. Secondly, I genuinely believe that ease of access to new contributors is of paramount importance to the project. What about X software instead? Feel free to explore other solutions. I've already done evaluations, and I'm pretty much set on this as the correct way forward. If there is insufficient interest in moving forward with Discourse, I'll leave it to others to invest time. What about forums.debian.net? I have no interest in interacting with a community of users and moderators who allow blatent Code of Conduct violations to go unchecked. What's next? I'd appreciate people testing Discourse. If you have any questions, then I'm happy to answer them. Thanks, Neil [0] https://www.discourse.org/ signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
Hi Scott, On Sat, Mar 14, 2020 at 10:43:33PM +, Scott Kitterman wrote: > As long as there are people involved, a certain amount of it is > inevitable. Putting it in the requirements is bowing to reality. The > FTP Team sometimes has to make unpopular decisions and it's inevitable > that people won't always react well. > > If Sean hadn't mentioned it, I think it would have been a disservice > to potential volunteers. People should know what they are signing up > for. Honestly it's not a lot of the feedback, most of what we get > back is positive, but it's enough that it's worth mentioning. > I think that mentioning it is absolutely the right thing to do, and I'm certainly aware (having been release manager for *mumble* years) that unpopular decisions can lead to unpleasant reactions. I think my point is that we should strive to reach the point where it's not inevitable, and that our reality can change. It should never be the case that making a hard decision leads to abusive messages, and I believe as a project we must act to try and achieve this goal. For leadership roles, such as release manager, or ftp master, I think it's doubly important. Putting aside the issue of current volunteers, and the project's duty to ensure a safe and welcoming environment, this affects the overall ability for the project to attract new volunteers at all. These key posts can be aspirational for new contributors - the concept that one day you could be an ftp-master is attractive. However, if we accept that in order to reach one of these key roles you have to be willing to accept a certain level of abuse, then we have failed to produce that welcoming community, and will fail to attract and retain a diverse and thriving team. This is obviously not something that ftp-masters can solve, but I think it is useful to highlight this issue for the wider project. Thanks, Neil -- signature.asc Description: PGP signature
Re: FTP Team -- call for volunteers
Hi debian-project and ftpmaster folks, On Sat, Mar 14, 2020 at 01:37:59PM -0700, Sean Whitton wrote: > - cope well with flames in response to your decisions > - after training, comfortable with being on the other end of the > ftpmaster@ alias, which receives a huge volume of > not-always-pleasant messages daily. I hope I am not the only one to be deeply concerned that this should be a requirement on volunteers. For me, it is absolutely unacceptable that people should put up with unplesentness or flames that come from doing a difficult job. Putting this in the requirements is, for me, a failure of the project. Sean: do you have any ideas on how we can reduce this aspect of the valuable work that ftpmasters do? Do you have some (anonymised) examples of the areas of abuse that you receive perhaps? Thanks, Neil -- signature.asc Description: PGP signature
Re: Standing behind GNOME Foundation against Rothschild Patent Imaging LLC?
On Mon, Sep 30, 2019 at 02:29:38PM +0100, Neil McGovern wrote: > On Sun, Sep 29, 2019 at 12:25:53AM +0100, Andy Simpkins wrote: > > Where can I contribute to the war chest in order to help fund fighting this? > On Sat, Sep 28, 2019 at 09:03:37PM -0400, Paul Tagliamonte wrote: > > Aye aye! We should distribute a fundraising site more widely among Debian > > for anyone in our community who is willing to donate to the collective > > defense of our tools. > > At the point when we require significant funds to fight this, I'll > address it. At the moment, we're very much in the preliminary stages of > this legal case. More generally, I'm talking to other folk around how to > make sure that GNOME and free software isn't attacked in future. > > Apologies for not being able to provide more clarity at this stage, I'm > sure you'll understand why! > For those not following closely, we've now filed our motion to dismiss, response and counterclaim: https://www.gnome.org/news/2019/10/gnome-files-defense-against-patent-troll/ Our strategy is to not only get the case dropped or dismissed, but to take out the patent as well. We do need funds to do this, and for those who are kind enough to donate, please do so at https://secure.givelively.org/donate/gnome-foundation-inc/gnome-patent-troll-defense-fund If you can't, please help spread the word. Neil -- signature.asc Description: PGP signature
Re: Standing behind GNOME Foundation against Rothschild Patent Imaging LLC?
Thanks Chris and all for the support that's been shown in this thread, it really does mean a lot while we're going through this complex period. On Sun, Sep 29, 2019 at 12:25:53AM +0100, Andy Simpkins wrote: > Having read the 'claim' being made, I for one, can not see there being > a case to answer, however my experience does not cover the American > patant/legal systems. To me this looks like a classic case of patent > tolling. Any and all instaces of which SHOULD be taken into court to > be struck down and the patent invalidated. On no account should these > trolls be allowed to walk away without a legal rulling against them. > At the moment, I'm not going to publicly state our strategy or position on the patent in question, as anything I do say wouldn't be legally privileged. However, I think I can say that my concern isn't just about GNOME and this case, but how free software projects are affected by this sort of patent activity more widely. On Sun, Sep 29, 2019 at 12:25:53AM +0100, Andy Simpkins wrote: > Where can I contribute to the war chest in order to help fund fighting this? On Sat, Sep 28, 2019 at 09:03:37PM -0400, Paul Tagliamonte wrote: > Aye aye! We should distribute a fundraising site more widely among Debian > for anyone in our community who is willing to donate to the collective > defense of our tools. At the point when we require significant funds to fight this, I'll address it. At the moment, we're very much in the preliminary stages of this legal case. More generally, I'm talking to other folk around how to make sure that GNOME and free software isn't attacked in future. Apologies for not being able to provide more clarity at this stage, I'm sure you'll understand why! Neil -- signature.asc Description: PGP signature
Re: Any plans to add Pale Moon browser to the repository?
On Thu, Mar 12, 2015 at 09:05:18PM -0700, Russ Allbery wrote: > (Please note: this response is based mostly on the information included in > your message. I only looked cursorily at the actual license of Pale Moon > to confirm that it looks very non-free by our definitions.) > I /believe/ that the redistribution licence is only applicable to the binaries produced by Pale Moon themselves. However, they do have a restriction on the trademark, which would make things somewhat more complicated. Neil -- signature.asc Description: Digital signature
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Fri, Oct 17, 2014 at 03:46:57PM +0100, Jonathan Dowland wrote: > On Fri, Oct 17, 2014 at 03:30:54PM +0100, Neil McGovern wrote: > > This isn't something that's happened in the past, what's announced is a) > > that a GR process has started, b) the various CfVs, and c) the results. > > > > I'd be wary about spamming d-d-a every time there's a new > > amendment/adjustment to an amendment etc > > Sorry for not being clear. I wasn't advocating for that; I want what you > describe as a) above. > Ok, cool, that's what happens now[0]. What /doesn't/ happen is that a d-d-a post is sent out when an initial proposal is sent, but hasn't had sufficient seconds to be accepted as a valid GR. > > What's the actual issue that we're trying to solve here? eg: why aren't > > people subscribing to -vote? Would a -vote-discuss or -vote-announce > > make more sense? > > DDs missing a GR by not reading -vote. Since we mandate subscription to > d-d-a, I felt that a "GR process has started" announcement to that list > was the cleanest solution. > Sure - that makes sense when we're got a vote coming up. That doesn't solve the problem of people being unable to get enough seconds, but I'm also not sure if it's the secretary's job to help with that. :) Neil [0] And since 2009. It didn't happen for one in 2008, because I forgot to do it as there was 7 amendments and I was also trying to get a release out. -- signature.asc Description: Digital signature
Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))
On Fri, Oct 17, 2014 at 03:12:35PM +0100, Jonathan Dowland wrote: > Dear Kurt, > > On Tue, Oct 14, 2014 at 09:17:27AM +0200, Kurt Roeckx wrote: > > If on -vote the required amount of seconds have been reached, I > > will announce that the GR process has been sarted on > > debian-devel-announce. > > This is now the case for one GR and one GR amendement. There may > be further amendments. Would you be prepared to post an announcement > to d-d-a? > This isn't something that's happened in the past, what's announced is a) that a GR process has started, b) the various CfVs, and c) the results. I'd be wary about spamming d-d-a every time there's a new amendment/adjustment to an amendment etc, they can get quite... commplex. See https://lists.debian.org/debian-vote/2014/03/msg00159.html for example. Additionally, it's considerable work to set up a vote page on www.d.o - the current one took me about two hours. It would be good if there was a way of avoiding having to do that just to announce something to d-d-a. What's the actual issue that we're trying to solve here? eg: why aren't people subscribing to -vote? Would a -vote-discuss or -vote-announce make more sense? Neil -- signature.asc Description: Digital signature
Re: Code of Conduct violations handling process
I have tried not to reply to this, but there's some bits in here I don't think should go unchallenged, but I'll stick to the major points rather than replying to each comment. On Thu, Sep 04, 2014 at 09:15:33AM +1000, Zenaan Harkness wrote: > On 9/4/14, Scott Kitterman wrote: > > I'm offended at the use of the CoC as a political hammer. > As are many. Emailing lists off of debian infrastructure have been > created and those who enjoy certain ... freedoms of expression ... > have migrated, at least partly. That's fine. Those who do not share the project's values about what is or is not acceptable behaviour are free to set up their own lists, just as Debian is free to withdraw a platform to host their views. > On 9/4/14, Scott Kitterman wrote: > > On September 3, 2014 12:52:44 PM EDT, Manoj Srivastava > > wrote: > >>On Wed, Sep 03 2014, Scott Kitterman wrote: > >>> As far as I can tell, he spoke the truth as he knows it. I have no > >>> idea if he's right or wrong, but he was stating his perspective and > >>we > >>> ought to be open to that. > >> > >>> While he could have phrased it better, I don't think the CoC protects > >>> people from having to hear opinions relevant to the project that they > >>> disagree with or make then feel bad because they are being accused of > >>> bad behavior. > > One woman's opinion is another mans offensive speech. I'm sorry, but why did you have to bring gender into this? That's not relevant to the discussion. > This is the fundamental problem, not with the COC per se, but with the > doors it opens up, and why I believe so many spoke and voted against > it. By a vote of 228 against 53, this passed. I believe that to be a strong endorsement of the CoC. > > No matter how well or poorly he put his opinion, some people were > > going to have a case of butt hurt over it. > > > > Avoiding offence is a great goal, but sometimes (and I think this is one of > > those times), it isn't possible to avoid it without overly restraining free > > expression. In cases where free expression and avoiding offence are > > conflicting, free expression has to win out. > > Sad! Now you're already talking about valid restraining > of free expression. No, it's absolutely not. It's a fallacy that one forum's rules on what is acceptable is in any way a restriction of free expression. Free expression does /not/ mean you have a right to express any view in our forum. You are completely at liberty to do so in your own space, and I beleive that the conflation of these two concepts does a great deal of harm to the efforts to produce a civil discussion. Neil -- signature.asc Description: Digital signature
Re: Bug#747290: Please display the new Code of Conduct
Tags: +patch
Thanks
On Wed, May 07, 2014 at 11:36:54AM +0300, Andrei POPESCU wrote:
> On Ma, 06 mai 14, 13:45:11, Brian Gupta wrote:
> > All kidding aside, is there a plan to post the CoC, and make it easy
> > to find from www.d.o? (Perhaps either in the "About" section, or on
> > the "about Debian" page?)
> >
> > Perhaps I should just file a bug and let web team figure out best placement?
>
> Done... ahem, filed :)
WML attached for webwml/english/code_of_conduct.wml -
comments/corrections welcome.
Neil
--
#use wml::debian::template title="Debian Code of Conduct" BARETITLE=true
{#meta#:
:#meta#}
Version 1.0 ratified on April 28th, 2014.
Debian, the producers of the Debian system, have adopted a code of conduct for paticipants to its mailinglists, IRC channels and other modes of communication within the project.
Debian Code of Conduct
Be respectful
In a project the size of Debian, inevitably there will be people with
whom you may disagree, or find it difficult to cooperate. Accept that,
but even so, remain respectful. Disagreement is no excuse for poor
behaviour or personal attacks, and a community in which people feel
threatened is not a healthy community.
Assume good faith
Debian Contributors have many ways of reaching our common goal of a
https://www.debian.org/intro/free";>free operating system which
may differ from your ways. Assume that other people are working towards
this goal.
Note that many of our Contributors are not native English speakers or
may have different cultural backgrounds
Be collaborative
Debian is a large and complex project; there is always more to learn
within Debian. It's good to ask for help when you need it. Similarly,
offers for help should be seen in the context of our shared goal of
improving Debian.
When you make something for the benefit of the project, be willing to
explain to others how it works, so that they can build on your work to
make it even better.
Keep in mind that what you write once will be read by hundreds of
persons. Writing a short email means people can understand the
conversation as efficiently as possible. When a long explanation is
necessary, consider adding a summary.
Try to bring new arguments to a conversation so that each mail adds
something unique to the thread, keeping in mind that the rest of the
thread still contains the other messages with arguments that have
already been made.
Try to stay on topic, especially in discussions that are already fairly
large.
Be open
Most ways of communication used within Debian allow for public and
private communication. As per paragraph three of the https://www.debian.org/social_contract";>social contract, you
should preferably use public methods of communication for Debian-related
messages, unless posting something sensitive.
This applies to messages for help or Debian-related support, too; not
only is a public support request much more likely to result in an answer
to your question, it also makes sure that any inadvertent mistakes made
by people answering your question will be more easily detected and
corrected.
In case of problems
While this code of conduct should be adhered to by participants, we
recognize that sometimes people may have a bad day, or be unaware of
some of the guidelines in this code of conduct. When that happens, you may
reply to them and point out this code of conduct. Such messages may be
in public or in private, whatever is most appropriate. However,
regardless of whether the message is public or not, it should still
adhere to the relevant parts of this code of conduct; in particular, it
should not be abusive or disrespectful. Assume good faith; it is more
likely that participants are unaware of their bad behaviour than that
they intentionally try to degrade the quality of the discussion.
Serious or persistent offenders will be temporarily or permanently banned
from communicating through Debian's systems. Complaints should be made
(in private) to the administrators of the Debian communication forum in
question. To find contact information for these administrators, please
see https://www.debian.org/intro/organization";>the page on
Debian's organizational structure.
Further reading
Some of the links in this section do not refer to documents that are
part of this code of conduct, nor are they authoritative within Debian.
However, they all do contain useful information on how to conduct
oneself on our communication channels.
Debian has a https://www.debian.org/intro/diversity";>diversity
statement.
The http://people.debian.org/~enrico/dcg/";>Debian
Re: clarify FTP master delegation?
On 11 Mar 2014, at 18:20, Daniel Pocock wrote: > There is some ongoing discussion (on debian-legal) about whether the FTP > masters will accept a particular package For those who weren’t around 10 years ago, I would suggest[0] reading up on #283578, and associated mails to the lists, LWN articles etc around the time. Neil [0] Or don’t. It’s probably better to do something more useful with your time. -- 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/07980463-b56d-4a40-9443-9c6b04c3b...@halon.org.uk
Re: Spam fighting in -ctte mailing list....
Hi Jakub, On 4 Mar 2014, at 17:40, Jakub Wilk wrote: >> On Mon, Mar 03, 2014 at 09:13:06AM +, Jonathan Dowland wrote: >>> Thanks for the suggestion. I hate to be *that guy*, but, these messages are >>> not spam. They are damaging, time wasting and clutter our views of our >>> mailing lists, this is true. Perhaps it is appropriate to use the spam >>> architecture to clean them out. > > The review interface offers more than binary spam/ham classification. These > are the choices you have: > Out of interest, is the interface available to general DDs? Would that indeed be something useful for people who have a spare 30 mins or so to spend their time on? Neil -- 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/f77ba03e-29aa-40ef-9ec1-f927a728e...@halon.org.uk
Re: Restrictions for TOR connections on Debian IRC channels
On Fri, Feb 28, 2014 at 03:25:28PM +, Neil McGovern wrote: > Each channel that has the group @debian-ops in it's access list receives > a "/mode +b *!*@*.tor-irc.oftc.net". Those who are registered can ask > nickserv to provide them with a unique cloak tied to their account, with > "/msg nickserv set cloak on". Channels who do not have the @debian-ops > in the access list (/msg chanserv access #debian-foo list) would be > unaffected. > All, I've now implemented this as follows: Channels with @debian-chanop - ban applied --- #debian-qa #debian-devel #debian-offtopic #debian-derivatives #debian-newmaint #debian-mentors #debian-it #debconf-video #debian-meeting #debian-ctte #debian-mysql #debian-gr #debian-dpl #debian-soc #debian-fedmsg #debian-3dprinting #debian-security #debian-next #debian-paultag-fanclub #debian-ftp #debian-perl #debian-multimedia #debian-l10n-fr #debian-mirrors Channels with @debian-chanop - ban not applied --- #dw-question - I don't know what this is #kgb-devel - not in the #debian-* namespace #pet-devel - not in the #debian-* namespace #debian-private - Protected by a key #debian-bots - Only contains bots #debian-ops - We need to keep this open #debian-mia - Protected by a key #debian-soc-mentors - Protected by a key I've also tried to check on each channel if there was anyone who would be affected by the ban who had already joined, and sent a message to them on how to cloak themselves. Please note that there are 382 channels total in the #debian-* namespace, I've only done ones which have @debian-chanop in the access list. If any channel owners wish to add the above, feel free, but if you wanti me to take any actions, please let me know as I probably won't notice. Neil signature.asc Description: Digital signature
Restrictions for TOR connections on Debian IRC channels
Hi all, Over the past few weeks, we've seen a number of issues with certain people connecting over TOR, and repeatedly sending various inappropriate comments to a number of IRC channels in the #debian* namespace, including #debian-ctte and #debian-women. Unfortunately, from a OFTC network point of view, there's very little that can be done, short of taking the action of turning off TOR all together. However, I'd like to propose that: Each channel that has the group @debian-ops in it's access list receives a "/mode +b *!*@*.tor-irc.oftc.net". Those who are registered can ask nickserv to provide them with a unique cloak tied to their account, with "/msg nickserv set cloak on". Channels who do not have the @debian-ops in the access list (/msg chanserv access #debian-foo list) would be unaffected. In summary, this would mean that those who connect over TOR, and are not registered with nickserv would be unable to connect to those IRC channels. I believe this allows legitimate tor users to still access our channels, but would restrict the 'drive by' nature of some of the unpleasentness we've seen recently. As this potentially affects a large number of channels, I'd appreciate any constructive feedback from the project before implementing. Thanks, Neil -- signature.asc Description: Digital signature
Re: GR proposal: code of conduct
On Wed, Feb 12, 2014 at 10:48:04PM +0100, Stefano Zacchiroli wrote: > For IRC it's a bit more difficult, because we do not long our IRC > channels by default (or at least I'm not aware we do), with the > exception of meetings run with the help of meetbot. That means that it > would be rather difficult for the moderators to point out to the > evidence on the basis of which they've banned someone. I can't help > wondering if the solution to this shouldn't just be radical, > i.e. publicly log our IRC channels. A less invasive solution is to just > ask moderators to publish log excerpts that they think justify the ban. > Indeed, that's an issue - but I always have logs anyway. Proactively publishing bans on IRC may produce quite a bit of mail, as these tend to be more frequent than mailing list bans. Neil -- signature.asc Description: Digital signature
Re: systemd bad press? score card?
On Mon, Feb 10, 2014 at 10:42:14AM -0800, Russ Allbery wrote: > I personally would defer to the Debian press team to decide whether they > feel we should make a public statement at this time. I think we're still > in the middle of our process, which I understand that a lot of people > outside the project find baffling and protracted. I'm not sure whether > it's a good idea to comment on that or not. > Not really a press issue yet. Sam Varghese unfortunately didn't contact the press team over this opinion piece, and hasn't corrected factual errors in the article which have been pointed out in the comments below it. This does seem to be a pattern of his opinion pieces, but falls short of complaining to the editor. > My personal professional experience is that ignoring the press unless you > have something specific you want to say is a good default, but this is > *far* from my area of expertise. > Indeed, I'm not entirely sure what you'd like us to say - "the process is ongoing, this isn't the end of it", or "we finally have a decision". The truth is more complex than that, but doesn't make for a good press line. At the moment, I'd suggest just leaving it. Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 09:21:41AM -0800, Russ Allbery wrote: > "Didier 'OdyX' Raboud" writes: > > Le dimanche, 19 janvier 2014, 12.39:01 Ian Jackson a écrit : > > >> I agree. I think that would be quite bad. We could explicitly state > >> in our TC resolution that the TC decision can be vacated by General > >> Resolution on a simple majority. > > > I don't think our constitution allows a resolution of the TC to change > > how §4.1.4 has to be interpreted for a GR overriding it[0]. It would > > certainly need to be checked with the secretary (CC'ed, just in case). > > Personally, I think we should amend the constitution to remove this > requirement, but in the meantime, it's obviously possible for the TC to > change its own decision. So, failing any other approach, the TC can > simply vote to adopt the GR decision as its own decision, which only > requires a simple majority in the TC (assuming this isn't a matter that > involves a maintainer override). > Indeed, or at least to allow this to happen if tech-ctte wishes it. > I'll defer to the secretary on whether it makes sense for the TC to do > this in advance, or whether to be formally correct we would have to do so > after the GR had passed. > So will I, but I believe it should be sufficiently clear at the moment to the developer body at large where the -ctte's view on this matter is. Neil -- signature.asc Description: Digital signature
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 05:11:17PM +, Ian Jackson wrote: > > Ian - any thoughts on if your tech-ctte constitution GR could address > > this? > > You mean my TC resolution draft. Nope, I meant your supermajorty etc draft. Snipping the rest, as that seems to be something for tech-ctte, rather than me :) Neil -- 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/20140127172208.gm8...@halon.org.uk
Re: GR: Selecting the default init system for Debian
On Mon, Jan 27, 2014 at 03:56:29PM +0100, Didier 'OdyX' Raboud wrote: > I don't think our constitution allows a resolution of the TC to change > how §4.1.4 has to be interpreted for a GR overriding it[0]. It would > certainly need to be checked with the secretary (CC'ed, just in case). > That would certainly seem to be the case, but it would be illogical for a group who is happy to be overridden with a lower requirement to be prevented from doing so! In practical terms, if the tech-ctte was so minded, they could use some of the proceedures in 4.2.2 to essentially achieve this outcome. Ian - any thoughts on if your tech-ctte constitution GR could address this? Neil -- signature.asc Description: Digital signature
Re: Updating the Policy Editors delegation
On Mon, Jan 06, 2014 at 07:39:55PM +, Neil McGovern wrote:
> On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote:
> > Doing that now. :-) Also, I'm more worried with the interactions with
> > Constitution 6.1.1. It seems to me that a Policy Editors delegation
> > should have come from the TC, not the DPL.
> > Dear Secretary, what do you think?
> >
>
> Thanks for doing it officially :) Me and Kurt are looking at it now.
> There's two conflated issues, but we hope to get a full view out in a
> day or two.
>
All,
I think me and Kurt have now reached consensus about the issue - and as
such we'd welcome any comments on the draft, available below!
Neil
-- draft below --
It seems that two separate questions are being asked. Firstly, what is
the ability of the DPL to create a delegation, and how pescriptive can
this be on the day to day working of a delegate.
Secondly, on the status of the Debian Policy Editors, and if they can be
delegates.
I will deal with both in turn.
In writing this, general commentary appears { in curly brackets } -
these bit aren't official interpretations of the constitution, but a
commentay of my own :)
1) Ability of DPL to make pescriptive delegations
The Debian Constitution is quite clear:
"The Leader may define an area of ongoing responsibility or a specific
decision and hand it over to another Developer [...].
Once a particular decision has been delegated and made the Project
Leader may not withdraw that delegation; however, they may withdraw an
ongoing delegation of particular area of responsibility." (5.1.1)
"The Delegates are appointed by the Project Leader and may be replaced
by the Leader at the Leader's discretion. The Project Leader may not
make the position as a Delegate conditional on particular decisions by
the Delegate, nor may they override a decision made by a Delegate once
made." (8.2)
"Delegates may make decisions as they see fit, but should attempt to
implement good technical decisions and/or follow consensus opinion."
(8.3)
This means that delegations should take care not to perscribe any
particular process, or method for working that a delegate should adhere
to. It is up to the delegate(s) to form a team and to produce a process
themselves. It is, of course required as above that delegates should
attempt to implement good technical decisions and/or follow consensus
opinion.
As a guide - it is the wording that "ongoing responsibility or a
specific decision" that should be delegated - powers to act in an area,
but not how that power should be wielded. How to organise and the
process for exercising a power is a decision in itself, and thus for the
delegate to decide.
Should a delegate make a decision, or create a process or proceedure
that the project is unhappy with, a Debian Developer is free to refer
this to a General Resolution to reverse any taken decision.
In a special case, where the decision is explicitly a matter of
technical policy, it may also be referred to the Technical Committee, to
decide the matter under 6.1.1:
"This includes the contents of the technical policy manuals, developers'
reference materials, example packages and the behaviour of
non-experimental package building tools. (In each case the usual
maintainer of the relevant software or documentation makes decisions
initially [...])". This requires a simple majority.
2) The status of Debian Policy Editors, and the ability to be delegated
To answer this, a series of questions should first be addressed;
* What can the DPL delegate?
In general, this reading of the constituion is being done from a
"permissive", rather than "restrictive" view. ie: a developer may do any
task which they have a general competence to do, rather than only being
allowed to do anything explicitly defined in the constituon. This seems
to follow the project's general favour towards "do-ocracy"
If a restrictive view is taken, then a number of issues arise. For
example, an individual may only make any technical or nontechnical
decision with regard to their own work, and may not affect other
people's work (3.1.1). It is likely that nothing that affects more than
one person's work would ever be completed without a prior delegation
from the DPL. Thus, a "permissive" view is more consistent with how
current practice in Debian has developed.
Further, the ability of the DPL to delegate is explicity not limited to
decisions that the DPL can themselves do. See 8.1.2 for example, as the
Debian Account Managers are not a function of the DPL, but are
delegates.
{ There are things that the DPL cannot delegate, for example the
secretary, and tech-ctte members/chair, these are appointments. }
However, what is key here, and covered above in the first part of the
mail, is that it is a decision,
Re: Updating the Policy Editors delegation
On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote: > Doing that now. :-) Also, I'm more worried with the interactions with > Constitution 6.1.1. It seems to me that a Policy Editors delegation > should have come from the TC, not the DPL. > Dear Secretary, what do you think? > Hia, Thanks for doing it officially :) Me and Kurt are looking at it now. There's two conflated issues, but we hope to get a full view out in a day or two. Neil -- signature.asc Description: Digital signature
Re: Updating the Policy Editors delegation
On Fri, Jan 03, 2014 at 05:58:19PM +, Ian Jackson wrote: > Furthermore, I don't think this delegation declaration is > constitutionally appropriate. The policy editors are, primarily, > maintainers of a package. > Indeed, there's potentially an issue here that the constitution states (8.3) "Delegates may make decisions as they see fit, but should attempt to implement good technical decisions and/or follow consensus opinion." By defining a process within a delegation, this removes this option, which a delegation cannot do. > The processes for how to maintain a package, and ordinary > maintainership succession, would seem to fall squarely within the > current maintainers' own discretion. Jurisdiction to adjudicate > package maintainership disputes, and oversight of the decisions of the > policy editors, are explicitly granted to the Technical Committee. > > So it seems to me, at the moment, that this delegation is ultra vires > and hence not binding on the policy maintainers. > Indeed, though please note that this isn't an official interpretation of the consitution. If you want that, please mail secretary@ :) Neil -- signature.asc Description: Digital signature
Re: Doing something about "should remain private forever" emails
On Wed, Jun 19, 2013 at 07:35:26PM +0200, Raphael Geissert wrote: > If people start asking for the non-disclosure of their messages in > other languages or any other way that prevents an automated process > then it is their problem. They would be fighting against their own > desire. > It's really not - the onus is on the person doing the declassification. Efforts to reduce this is welcome, but false positives (for declassification) must be reduced as much as possible, and this is only possible via manual processing. Hence the reason why the GR has never been enacted[0]. Additionally, changing the rules in this way from what was agreed the norms at the time is the very reason I seconded the amendment to that vote. Neil [0] And also the reason I dislike any votes which require a future theoretical person to do a large amount of work. -- signature.asc Description: Digital signature
Re: Position statements short of a GR - DPL statements
On Mon, Nov 19, 2012 at 08:19:27AM +0900, Charles Plessy wrote: > In particular, the constitution does not empower anybody to be the spokeperson > or representative of the Project, therefore it looks logical that only a GR > defines the opinion of the project. > Well, this could be interesting, as I've certainly done exactly this as a press officer, under the delegation at https://lists.debian.org/debian-devel-announce/2012/03/msg00011.html Neil -- signature.asc Description: Digital signature
Re: mjg59's blog on planet.d.o
On Tue, Oct 30, 2012 at 12:05:11PM +0100, Piotr Ożarowski wrote: > [Paul Wise, 2012-10-30] > > Content unrelated to Debian is specifically acceptable on Planet Debian: > > > > http://wiki.debian.org/PlanetDebian#What_Can_I_Post_On_Planet > > and this part is written in stone and we cannot change it? Not without changing the purpose of planet.d.o, no. Neil -- signature.asc Description: Digital signature
Re: General Resolution: Diversity statement results
On Thu, Jun 07, 2012 at 12:11:10PM +0100, Ian Jackson wrote:
> Michael Gilbert writes ("Re: General Resolution: Diversity statement
> results"):
> ...
> > Why is it that devotee has moved to a private development model? This
> > seems to be contrary to Debian's goal of maximal openness, and the
> > previous secretary openly published his work:
> > http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/devotee.git
I believe that this (certainly when I took over) was stored in arch. As
I had no knowlegde of arch, and the code was (and substantially still
is) the same, there wasn't much point in pushing it. I'm very pleased to
see a migration to git.
> I would be willing to write a patch to devotee to make it
> automatically publish its own source code. Kurt and Neil: would you
> accept such a change ? I can happily clone the code from master.
>
I'd be happy to take this, and though I can't speak for Kurt it sounds
sensible to me.
> > That's nice for review and study, bit it would be even more ideal if
> > the code were available on a DD-writable repo (perhaps within
> > collab-maint).
>
> IMO the requirement is for the Secretary to publish the code being
> used. Not for them to manage a collaborative development project,
> unless they want to.
>
Given the overhead of actually running a vote and trying to then deal
with people with broken mailers and estoric encodings, I'd really rather
not have to then re-deploy a package or something while we're in the
middle of a GR.
If someone wants to take whatever Ian's script produces and package it,
that's fine, although I'm not entirely convinced how useful that would
be. Having maintained 'blootbot' in the past, packaging programs that
are substantially used just on Debian services isn't actually a
productive use of time.
Neil
--
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/20120607122216.gp4...@camblue.cbg.collabora.co.uk
Re: Report from DSA Team Sprint in Oslo
On Thu, Apr 05, 2012 at 09:19:50PM +1000, Ben Finney wrote: > Neil McGovern writes: > > > For reference, I'm in contact with the Raspberry Pi folk, who are keen > > to do things with Debian. If anyone wants hardware, drop me a mail! > > Are you in a position to press for hardware specification that will > allow wholly free-software Debian on Raspberry Pi? My understanding is > that currently the hardware requires some number of non-free firmware > blobs. > No. I can't see that happening. The core SoC is a broadcom solution, and that requires blobs to make it work. If anyone knows someone in Broadcom that can drive this forward that'd be great, but until then it's not likely to happen :( Neil -- signature.asc Description: Digital signature
Re: Report from DSA Team Sprint in Oslo
On Thu, Apr 05, 2012 at 03:21:11PM +0800, Paul Wise wrote: > On Thu, Apr 5, 2012 at 10:40 AM, dE . wrote: > > > Maybe someone from the UK can provide a Raspberry PI. > > That probably wouldn't be useful. According to folks on IRC, the armhf > buildds are i.MX53 QuickStart boards, they're quite a bit faster than > the Pi and our armel buildd's are 1Ghz ARMV5 Marvell developer boards > with 1.5G of RAM and also have native SATA, also making them faster > than the Pi. > For reference, I'm in contact with the Raspberry Pi folk, who are keen to do things with Debian. If anyone wants hardware, drop me a mail! Neil -- signature.asc Description: Digital signature
Re: Finding sponsors for Debian
On Tue, Mar 13, 2012 at 10:13:38AM +0100, Holger Levsen wrote: > But I've learned that we need to communicate this a whole lot better. Ideas > how ... would be best directed to debian-project :) Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- 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/20120313091739.gk...@feta.halon.org.uk
Release Team meeting minutes (and release update)
Hello, As previously announced[RT:PM], the Debian Release Team held a meeting on 2 and 3 Oct, 2010 in Paris, France. The meeting was kindly sponsored by IRILL[RT:PMS]. The attendees were Adam D. Barratt (adsb), Luk Claes (luk), Julien Cristau (jcristau), Mehdi Dogguy (mehdi), Philipp Kern (pkern) and Felipe Augusto van de Wiel (faw). Documentation = We improved the documentation related to Point Releases[CL:PR] and documented the procedure for Releases[CL:RE]. We also updated the Release Team wiki[RT:WI] page and we'll be adding more information in the upcoming weeks. Stable Updates and Volatile === We discussed how Volatile will evolve based on our experiences managing it. Considering the fact that there is nothing in volatile-sloppy for Lenny and that having a separate archive is painful, we would like to propose a plan for a new workflow for Squeeze: [ urgent-upload ] [ upload ] \ / | [ security ][ p-u-NEW ] (visualised by queue-viewer) | | accept | [ p-u ] <-- autobuilding, users testing urgent uploads -->/ | / | [ stable-updates ] | \ | point release[1] \ | [ stable ] [1] Point releases: include removals, updates ready to be cherry-picked from proposed-updates, but all updates from stable-updates are included. The Volatile Team and the Release Team share the same members, we would like to merge the Volatile Team into the Release Team and change the suite name to 'stable-updates'. The new dynamics allow maintainers to do only one upload instead of separate uploads to stable and volatile. The Release Team can then copy the package to the appropriate suite; if it is an urgent upload, it will be made available quickly to our users through stable-updates. During a point release, we will merge proposed-updates, security and stable-updates into the point release. We are planning to have a stable point release every two months and an oldstable point release evert four months in between two stable point releases. We would like to create a new list for users to receive announcements about new packages in stable-updates and requests for testing of packages in proposed-updates. The final name for this list has not yet been decided; the current suggestions include debian-stable-announce. Have a look at #598939. Release notes and upgrade reports = The release notes for Squeeze are progressing well and a call for translations will be made soon. This means that if you are aware of an issue that should be mentioned in the release notes, you need to make sure a bug is filed for it, preferrably with proposed wording, *now*. Once this has occurred, we will be encouraging the testing of new installs of Squeeze and upgrades from Lenny to Squeeze. As a result of these tests there will be a number of bug reports against the installation-reports and upgrade-reports pseudo-packages (dealing both with successful upgrades and problems with the process) which will need processing, categorising and reassigning to the affected packages. If you are interested in helping with this process, please contact us. Release Update (Squeeze Status) === Freeze Status (Unblock Policy) -- The Release Team would like to remind everybody that we are under deep freeze. We are updating the current unblock policy to get stricter rules: A new version may only contain changes falling in one of the following categories (compared to the version in testing): - fixes for release critical bugs (i.e., bugs of severity critical, grave and serious) in all packages; - changes for release goals, if they are not invasive; - translation updates - documentation fixes Please upload packages fitting this description to unstable, then request the freeze exception by filing a bug against release.debian.org. You don't need to include the full diff (which we re-generate from the uploaded packages anyway), but please include the relevant changelog entries. Transitions and removals All transitions are done and we do not plan any new transitions. Recently, the Release Team had to made some decisions between package upgrades and package removals. Please understand that when you say "allow a new version or remove the old one", both options are valid from the Release Team's point of view and we may end up deciding in favour of the removal. Another important request: please, do not upload packages to t-p-u because you uploaded newer versions to unstable, always contact the Release Team. Bug Squashing Parties - The Release Team is still concerned about the number of release critical bugs affecting testing. We are still optimistic that curre
Re: Dropping the .0 on release numbers?
On Wed, Sep 15, 2010 at 04:22:43PM +0100, Matthew Johnson wrote: > On Tue Sep 14 12:25, Gunnar Wolf wrote: > > We have carried a major.minor scheme as a release numbering scheme > > since the Early Days, but it has lost relevance basically since Sarge > > (3.1 - But by the time it was finally released, some discussion was > > made whether Sarge should be 4.0 as the difference from Woody was > > already too large, to which the release team IIRC answered "it would > > be right but it's too late"). Since Etch released (2007), we have > > always used x.0. > > > > There was the suggestion of using 4.5 for Etch and a Half, but it was > > not implemented, even though Etch and a Half was eventually released > > [1]. And I might be living under a rock, but I never heard about Lenny > > and a Half. > > Perhaps (as is being discussed on IRC at the moment), we could use in 6.x.y > the > y for point releases and the x for things like 'and a half' release that add > more functionality? > I'd suggest we paint the release orange. Neil PS: http://bit.ly/squeeze-bugs-left -- [local irc server has just been brought up] suddenly there's quite some silence in the hacklab -- 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/20100915153140.gk17...@halon.org.uk
Re: Debian money
On Mon, Sep 14, 2009 at 06:42:46PM +0100, MJ Ray wrote: > Russ Allbery wrote: > > Charles Plessy writes: > > > [...] but Debian could support companies started by its developers > > > to make a living of their Debian-related activities, by contributing to > > > their capital. [...] > > > > We can't do that with moneys collected in the United States under the > > aegis of Software in the Public Interest. It would jeopardize the > > non-profit status of SPI. Non-profit charities are not permitted to make > > investments in for-profit businesses. > > Are they permitted to make loans? > > There are some non-charities like Debian-UK holding debian funds which > would not be restricted in that way, but I think it would be rather > out of character for debian to take a position of supporting > capitalism in this direct way. For reference, Charities in the UK can also invest in profit making entities, and indeed own them outright. Neil -- "Debian women - porting the most succesfull operating system to the most unknown architecture" -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Summary of the debian-devel BoF at Debconf9
On Tue, Aug 18, 2009 at 07:28:09PM +1000, Ben Finney wrote: > "Bernhard R. Link" writes: > > > Perhaps there is a way to […] discourage all meta-discussion or > > mentioning of "fallacy", "ad-hominem" or "strawman" on the other > > lists. > > Perhaps you have a better way of succinct terms to use when challenging > those logical fallacies? Surely you're not saying you want such > fallacies to go unchallenged in the forums where they appear? > Please find below a form which I hope you find useful: Dear _NAME_, It appears to me that you have a "logical fallacy", in your message _MSGID_. This first occurs on line _LINENUM_. [ ] argumentum ad antiquitatem [ ] argumentum ad hominem [ ] argumentum ad ignorantiam [ ] argumentum ad logicam [ ] argumentum ad misericordiam [ ] argumentum ad nauseam [ ] argumentum ad numerum [ ] argumentum ad populum [ ] argumentum ad verecundiam [ ] circulus in demonstrando [ ] complex question [ ] dicto simpliciter [ ] naturalistic fallacy [ ] nature, appeal to [ ] non sequitur [X] petitio principii [ ] post hoc ergo propter hoc [ ] red herring [ ] slippery slope [ ] straw man [ ] tu quoque Replies to have been set to debian-devel-prime. This is the same list as debian-devel, but adds a "X-Prime: 1" counter which increments with each suffix of -prime. Thus meta-meta-meta discussions are sent to debian-devel-prime-prime-pr...@lists.debian.org. This may not render your entire argument invalid, please re-submit your message for consideration once the above has been corrected, and everyone has had time for a glass of milk and a cookie. Hugs, and kisses, _MYNAME_ -- <@nurn> Paedophile Glitter arrives in UK <@nurn> is it me or does that sound like a very inappropriate brand name? <@sooB> the sort that would only be advertised in the run-up to christmas <@nurn> it's like a twisted my little pony name signature.asc Description: Digital signature
Re: Debian redesign
On Wed, Jul 29, 2009 at 12:46:04PM -0300, Margarita Manterola wrote: > Discussing about this on irc, some people seemed to agree with my view > that the female images are too sexual, and that the image of the > notebook on the pillow is disturbing. > I disagree. The images for the males are just as suggestive. I have no issue at all with these. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
On Wed, Jun 24, 2009 at 09:24:14AM +0900, Charles Plessy wrote: > Le Tue, Jun 23, 2009 at 08:13:22AM -0700, Don Armstrong a écrit : > > > > But all of that said, it still needs trusted people to review the > > packages, which is where we've traditionally started to have scaling > > problems. > > This is where a public peer-review has an advantage: when submitting and > reviewing a package we are exposed to the reviews of others. People who make > good reviews will build a reputation, and will be natural candidates if we > want > to maintain a team of trusted people who have the last word. And conversly, an > open system lets people try the task and test their commitment before asking > for a responsability. > I'm possibly confused here. You seem to be advocating popping the decision process from a team of trusted people who have the last word, and pushing it on to a peer-review system. Which can then be used to form a team of trusted people who have the last word. Could you explain? Neil -- doesn't the world come to an end if iDunno shaves? That's how the dinosaurs died then... and why the dodo was made extinct, the last known habitat for them was my beard... poor bastards didn't stand a chance. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: DAM and NEW queues processing
On Tue, Jun 23, 2009 at 02:47:11PM +0200, Lucas Nussbaum wrote: > Has Debian even ever received a cease and desist letter from a IP > lawyer? Under which circumstances? I am bit tired of lawyers being > mentioned each time the NEW problems are discussed, while it seems, > based on history, that Debian is relatively safe from legal attacks. > So let's just drop the source section. More seriously, I would strongly suggest that the "Well, we haven't been sued yet" argument is disregarded as fallacious. Neil -- hermanr_: I never studied german I can just read some of it because it makes sense . o O ( There is stuff Ganneff writes, which makes sense? ) -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Results of the Lenny release GR
On Sun, Jan 11, 2009 at 09:29:41AM -0800, Mike Bird wrote: > On Sun January 11 2009 08:17:52 Ean Schuessler wrote: > > Ironically, Bdale *is* warping the results of the vote and applying an > > editorial voice to the interpretation of the results. I say "ironically" > > because Bdale's actions go far beyond anything Manoj did with regard to > > imposing his desires or thoughts on the construction or result of a vote. > > Sadly, embarrassingly, nobody else has yet matched Manoj's > level of careful analysis. Robert Milan has at times come > close but the non-existent cabal apparently hates him as much > as they hated Manoj because the responses to his questions > are mostly insults and personal attacks which would cause > anyone but a member of the non-existent cabal to be banned. > Hi Mike, I've read this a few times, and still can't understand it. Could you try rephrasing it? Neil -- Maulkin: there is no html tag (yet? could be extended like foo -> Ganneff kills foo?) :) signature.asc Description: Digital signature
Re: Discussion: Possible GR: Enhance requirements for General Resolutions
On Tue, Dec 30, 2008 at 12:54:41AM +0100, Joerg Jaspert wrote: > General Resolutions are an important framework within the Debian > Project. Yet, in a project the size of Debian, the current requirements > to initiate one are too small. > > Therefore the Debian project resolves that > a) The constitution gets changed to not require K developers to sponsor > a resolution, but floor(2Q). [see §4.2(1)] > b) Delaying a decision of a Delegate or the DPL [§4.2(2.2)], > as well as resolutions against a shortening of discussion/voting > period or to overwrite a TC decision [§4.2(2.3)] requires floor(Q) > developers to sponsor the resolution. > c) the definition of K gets erased from the constitution. [§4.2(7)] > Hi Joerg, Thanks for bringing this up. I feel that 2Q is possibly too large however. I'd suggest: Therefore the Debian project resolves that: a) Section 4.2 of the Debian Constitution is amended, replacing all references to K with Q. b) 4.2.7 is reworded to state: Q is half of the square root of the number of current Developers. Q need not be an integer and is not rounded. Reasoning: a) Q people should be enough to start a GR. The use of the "override a delegate's decision immediately" is something that should not be taken lightly. This should still require 2Q. b) No more reference to K, tidy up. Keep the non-rounded float nature of Q. Cheers, Neil -- i get an error... i forget what it is ... but definitely an error, well, maybe a warning... or an informational message... but definitely an output Verbatim quote from #debian, irc.freenode.net, Sat Jan 12 00:31:16 GMT 2008 signature.asc Description: Digital signature
Re: Debian Logo stoled
On Mon, Oct 27, 2008 at 04:46:08PM -0700, C.M. Connelly wrote: > "BF" == Ben Finney <[EMAIL PROTECTED]> > > BF> For this, though, the relevant field is not copyright; it's > BF> trademark. > > BF> Debian does, IIRC, have a trademark monopoly on the Debian > BF> logos; but I can't find reference to that, so I may be > BF> wrong. I'll continue on the assumption that they *are* > BF> trademarks held by SPI. > > No, we don't. > > We have a trademark on the word ``Debian''. We do not have a trademark > on the swirl logo or any other logotype. > Just for avoidance of doubt, we have the word 'Debian' as a *registered* trademark, but not the logos. We do hold unregistered trademark on these. Neil -- irssiproxy appears to be crack cut with washing up powder signature.asc Description: Digital signature
Re: [VAC] Away for the end of the nomination period
On Thu, Mar 06, 2008 at 11:25:39PM -0600, Debian Project Secretary wrote: > If some kind person would email debian-devel-announce on Sunday > March 9th 00:01 UTC, and announce that the nomination period is over, I > would appreciate it. > Will do. Cheers, Neil -- 'Maybe you can try to find a nice hotel by shouting in the Mexico DF streets "where could a gringo find a decent hotel in this dirty third world lame excuse for a country?". I'm sure the people will rush to help you, as we south americans love to be called third world in a demeaning way.' signature.asc Description: Digital signature
Re: Debian GNU/Linux license violation
Quoting in full for benefit of board etc. Apologies for missing this, it seemed to get filed away in a different mailbox. SPI can certainly litigate against the misuse of the Debian trademark. Licence violations etc may be more interesting. If the project wishes (hence the CC: to leader@), we can approach Greg, the current SPI lawyer about this. Regards, Neil On Wed, Sep 05, 2007 at 06:41:13PM -0400, Branden Robinson wrote: > On Tue, Sep 04, 2007 at 08:35:26AM -0700, Gomi No Sensei wrote: > >-- Forwarded message -- > >From: Gomi No Sensei <[EMAIL PROTECTED]> > >Date: Sep 4, 2007 8:33 AM > >Subject: Fwd: PhotoVu Inquiry: 48889582 - 17" Frame, Open-source > >To: [EMAIL PROTECTED] > > > >The following email is self-explanatory. The device sold at > >[3]www.photovu.com is based on a modified Debian, but the company will > > not > >disclose the source. > > > >The quote is: "We will never have an open platform as we do not have the > >resources to support such an open product in the field. It's not that we > >wouldn't like to, as we believe in open source and in fact use a > >customized base debian distribution with the addition of all our custom > >software on top. The last reason is why we weld our units shut and > >the aluminum metal must be cut and drilled to open it up!" > > PhotoVu does *not* have to release source code of works they release in > binary form to any third party *unless* they fail to accompany their > digital photo frames with the corresponding code on a medium customarily > used for software interchange. I am quoting the requirements of section > 2b) of version 2 of the GPL[1]. (I am also assuming that the code PhotoVu > is using is not so fresh that it has any portions licensed GPL version 3.) > > The GPL also does not require the vendor to *tell* you if their product > ships with corresponding source code, though if they deceive you and you > are a U.S. resident, you may recourse to the consumer protection laws of > your state, or the state of Colorado, where PhotoVu claims to be > incorporated[2]. > > Given the tone of the email, I suspect they don't provide complete > corresponding source code as required by section 2b of the GPL2, and since > they have refused you in your capacity as "any third party" that source > code at any price (section 2c), I find reason to pursue a potential license > violation here. > > The best way to find out is to find a PhotoVu customer ask learn from them > if they received either the complete corresponding source code on a DVD-ROM > or other medium (2b) or a written offer, valid for three years for the same > (2c). > > To follow-up on something Gunnar Wolf said: > > While (to the best of my knowledge) Software in the Public Interest, Inc., > is not a copyright holder in any portion of Debian GNU/Linux, this is still > a matter worth bringing to SPI's attention. SPI owns certain U.S. > trademarks, and it is conceivable that retaining trademarked Debian logos > in a derived product while not honoring the copyright licenses on the > software comprising Debian GNU/Linux gives rise to a civil cause of action > against PhotoVu. > > Accordingly, I am CCing the SPI Board of Directors. > > A courteous letter from SPI's counsel setting out these issues may be all > that is required to achieve PhotoVu's compliance. Bradley Kuhn and Eben > Moglen have frequently counseled tact and patience when pursuing apparent > GPL violations. Assume ignorance or misunderstanding until and unless that > assumption is unsustainable. > > [1] http://www.gnu.org/licenses/old-licenses/gpl-2.0.txt > [2] http://www.photovu.com/bio.html > > In case it gets changed, I quote: > > PhotoVu custom manufactures each digital picture frame at their > Boulder, Colorado facilities, using the finest individually made wood > frames and matboards, coupled with brand new electronic components, > resulting in a truly one-of-a-kind product. Customers can also order a > custom tailored frame and mat to match a given décor. > > PhotoVu, LLC is a privately held and privately financed company > registered in the state of Colorado. > > -- > G. Branden Robinson|The basic test of freedom is > Debian GNU/Linux |perhaps less in what we are free to > [EMAIL PROTECTED] |do than in what we are free not to > http://people.debian.org/~branden/ |do. -- Eric Hoffer -- Neil McGovern Secretary, Software in the Public Interest, Inc. signature.asc Description: Digital signature
Re: Please appoint one new person to the DSA Team
On Thu, Dec 21, 2006 at 04:58:50PM +1000, Anthony Towns wrote: > Technically, fixing security vulnerabilities in packages used by on d.o > machines is an answer to your question. There's been some discussion > recently about help potentially being wanted on that score for etch > backports. > And I'll repeat it here :) http://blog.halon.org.uk/2006/12/16#etch_fixtit Neil -- hm, maybe wearing a black t-shirt while dusting my bedroom for the first time in years wasn't such a good idea signature.asc Description: Digital signature
Re: Proposal: SPI as international money transfer service
On Sat, Oct 14, 2006 at 07:45:09PM -0400, mmlacak wrote: > Neil, thanks for your answers. Pardon my ignorance, but > did you give them as an official SPI member? I didn't give them as an official response from the board of SPI, but it can be considered as officially the personal views of a board member of SPI :) > If so, may I ask you to reconsider accepting donations for any > developer and any project, not just supported ones. It is certainly something we can consider, but again I point out that this really isn't the right forum to do so. > I mean, there is no project which is set to financially support > general open source community. I'm not quite sure what you mean by 'general open source community'. Most developers who need funding seem to be attached to a project. > Your parent project, Debian, does this, only within its domain, that > is source code. Well, SPI is Debian's parent project, so I'm not sure what you mean by "my" parent project being Debian. > But, as much as Debian project contributes to an open source > community, it also draws much from the same. I'm not really sure about this. Have you got a example on how to draws resources away from the open source community? > So it seems to me that supporting only Debian and related projects is > one sided, and, in a long run, not in a best interests of both > community and Debian project. Well, SPI certainly supports more than Debian and it's associated projects. Have a look at http://www.spi-inc.org/projects > You can get only as much as you're giving away. Why give less, if you > could easily give more? This is possibly the crux of the matter: It's non-trivial to add more projects. Each one takes resources to manage the donations and account for them. To do this for a generic deveoper would be far beyond what we are able to offer. Regards, Neil -- * toresbe wonders what would happen if Ted Walther and Amaya were put in the same room toresbe: blood, sweat, tears and finally castration signature.asc Description: Digital signature
Re: Proposal: SPI as international money transfer service
On Sun, Oct 08, 2006 at 08:07:10PM -0400, mmlacak wrote: > So, my question is: can we make SPI ( http://www.spi-inc.org/, > http://www.debian.org/donations ) into monetary service which accepts > from and is able to transfer money to any country in the world? In short no. This isn't SPI's purpose. > Is able to deliver money basically from door to door ( > post-office/bank to PO/B ) ? Yes. > Doesn't require anything beside internet connection and local bank / > post office account? No, we need the co-operation of the receiving party. > Charges only some percentage for its own operational expenses, so > there could be some sense in donating just a few bucks, and be sure > that most of it gets to intended developer (and yes, this is crucial)? Yes > Accepts donations for any developer and any project, not just > supported ones? No. > Provides traceable and secure transactions, even if it doesn't deliver > within minutes, days, weeks? > Yes. I'm npt quite sure why this hasn't been brought before the attention of SPI first. Neil -- hm, maybe wearing a black t-shirt while dusting my bedroom for the first time in years wasn't such a good idea signature.asc Description: Digital signature
DebConf 7 location
Hi all, After a long meeting on #debconf-team last night, it has been decided by consensus that DebConf7 will be held in Edinburgh, UK. I would like to take this opportunity to thank both teams for their hard work, and exceptional presentation of the venues, and to thank all those who participated in the meeting. The minutes of the meeting are attached or also available with the log of the meeting (plain and formatted) at http://www.halon.org.uk/debian/dc7/ Many thanks, Neil McGovern -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 Meeting opens 18:52 UTC Agenda at http://wiki.debian.org/DebConf7Meetings In this text, SJJ = Sarajevo, EDI = Edinburgh. vedran_sjj was recognised as the Sarajevo delegate, moray as the Edinburgh delegate. 1. Priority list There was some discussion on the priority that various items should take when deciding on a venue. The final version is at http://wiki.debian.org/DebConfPriorityList 2. Venue weaknesses and other venue strengths AJ stated: so, what I thought (back when I was last awake...) would be interesting, would be seeing what the SJJ thought EDI's strengths were (the areas in which they'd have the most problems matching or beating) that matter for debian, and vice-versa; and seeing what SJJ and EDI thought there own weaknesses were? Sarajevo: 1. SJJ has no budget flights, while EDI has a lot of budget flights. This, obviously presents a problem for non-sponsored attendees, making it more expensive and complicated to visit SJJ 2. EDI has a well-known debian community They have several DDs on their team while our team is a strong general Linux community but less involved with Debian 3. SJJ might be less interesting to corporate sponsorship We had that problem when talking about another prospective FOSS conference 4. The cultural issues We tried to remove such issues, but some people don't seem responsive to this 5. We have a four star hotel as a venue 6. Everything is under one roof, and available 24/7 7. We have an already established Internet link + prospective donors for wireless, with internet available in rooms. 8. We have server & video rooms available 9. There's lots of breakout space in the venue as well as outside 10. The venues are flexible about network rearranging 11. We have a minibus for transportation of disabled people Edinburgh: 1. The main advantage for Sarajevo over Edinburgh is that it's a cheaper city for food/accommodation. 2. The Bosnians hope that they'll create some more interest in free software by having the conference there 3. It's probably a more 'exotic' location 4. A lot of people prefer the 'self-contained' venue they're proposing. 5. The bid team has a lot of experience of past debconfs, as well as other free software events and academic conferences, so I think we have a lot of experience between us to work to organise a good event. 6. We're proposing debconf in a very central location, so we have all the amenities of the city right on our doorstep 7. The city as a whole is accessible, with e.g. the taxis required to be able to transport wheelchairs, as well as wheelchair accessible buses. 8. The venues are flexible about network rearranging/mess etc. 9. There's lots of breakout space in the venue as well as outside 10. Edinburgh's a major network hub, we *might* be able to negotiate 1Gb/s from the venue, but it's certainly easy to get a nice (if slower than that) connection from one of our sponsor ISPs --- Weaknesses of Edinburgh: 1. We're competing with a lot of other events in Edinburgh to get venues/accommodation, especially since we're proposing a venue right in the middle of the city 2. Edinburgh is a more expensive city than Sarajevo, though this is mitigated because we'd be right in the centre (zero travel costs once you're there), and all the city-run tourist things are free 3. Weather - when I visited Sarajevo, it was consistently bright and mid-30s. While I've already explained that Edinburgh isn't wet compared to Glasgow, people *are* likely to see some rain while they're here ;) 2a. If DebConf7 was held in the other venue, would you still attend? SJJ: I would go. EDI: I'm sure that there will be a good representation from our UK bid team, wherever it is. 3. Questions Q. For SJJ (from marga): If DC7 is in SJJ, who will be the local-team leader and how will that work? A. Sapphire will be the leader, but our team works on democratic principles. There will be at l
Re: Reforming the NM process
On Wed, Apr 12, 2006 at 08:43:48AM +0200, Pierre Habouzit wrote: > Le Mer 12 Avril 2006 08:34, Benjamin Mesing a écrit : > > I would strongly suggest, allowing to restrict access to such a site > > to DDs. This is because not everyone feels comfortable having > > personal information (like your specific view on free software) > > world-accessable. Debian developers need to know, since you are about > > to become part of their community, but no one else needs to know more > > than is exposed by your membership in the Debian community anyways. > > then you shouldn't apply for becoming a DD because your so called > personnal views on free software are a requirement for beeing a DD. Oh > and btw, the application is public anyway. > Not entirely. From the templates: 3. Finally, please tell me about yourself, how you came to GNU/Linux and free software, and why you want to volunteer your time. Please describe the contributions you have made to Debian, your primary areas of interest within Debian, and any goals you plan to accomplish. Note: I would like to post a summary about your biography to a public mailing list so other developers can get to know you. Please indicate which parts I may publish and which not. The responses to the answers aren't public either. Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 signature.asc Description: Digital signature
Re: Pls comment if you have any knowledge about this
On Sun, Dec 18, 2005 at 06:53:54PM +0200, ECE KARACA wrote: > Dear Sir / Madam, > > I have received the following mail and searched the "google" for Crumbtech. > I was curious if this was a spam, or the offer was serious. There I came > accross with an e-mail address of debian.org. > > Pls comment if you have any knowlwde about this subject. > > Best Regards > > E.KARACA > > Hi there, This is standard spam which, unfortunately, hit one of our mailing lists. Regards, Neil McGovern -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Your Logos, My T-Shirts!
On Sun, Dec 18, 2005 at 11:33:28AM +, Scott Weedon wrote: > Hello, > > Let me intoduce myself, my name is Scott Weedon I live in England and am > starting up a small Linux retail unit. My question to you is this. Am I able > to use your Linux Logos on T-Shirts I am planning to sell. I have a lot of > respect for you guys, and so I want to donate a percentage of the > profits, from each T-Shirt I sell to your projects. > > So are there copyright issues regarding the use of your designs? > Hello Scott, You are welcome to use our Open Use Logo, which can be foun,d, along with copyright information at http://www.debian.org/logos/ Regards, Neil McGovern -- __ .` `. [EMAIL PROTECTED] | Application Manager : :' ! | Secure-Testing Team member '. `- gpg: B345BDD3| Webapps Team member `- Please don't cc, I'm subscribed to the list -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: problem with mount and ...
On Sat, Oct 29, 2005 at 09:35:27PM +0200, Wodzu Wodzowski wrote: > Hy. I've got two problems :> > > One is with mount command problem. I wrote in fstab file: > /dev/hda2 /mnt/winD ntfs ro,user,auto 0 0 > 1) NTFS volumes are read only 2) You've got the wrong list. You want debian-user@lists.debian.org Regards, Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li B345BDD3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
