Re: CoC / procedural abuse

[Ean Schuessler]

Can we just generate that procmail file or at least the section in
question? We can take this to private email if you like and blog about
next steps and or progress.

- "Don Armstrong"  wrote:

> There isn't any. You write procmail in the correct configuration file
> to add a ban. You remove procmail in the correct configuration file to
> remove the ban.
> 
> If you're willing to commit to write an appropriate tool that can be
> called from within a procmail script to implement banning and unbanning
> on the based of a passed message, then I believe listmaster@ (or at
> least, I) would be willing to write up a specification for the
> software.

-- 
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
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/27733420.7531411176573361.javamail.r...@newmail.brainfood.com

Re: CoC / procedural abuse

[Ean Schuessler]

- "Russ Allbery"  wrote:

> The actual code may be extremely simple, only two or three lines. It's
> getting the right lines in the right place in a way that works for the
> people who are doing the day-to-day work that's the hard part.

I hereby do solemnly volunteer to write an "coc unban [ADDRESS]" command that
can be triggered by at.

Obviously the parties responsible for empowering me to do this are on
this list because they would ban me if I called them mean names. 
Responsible parties, please let me know where to start reading the code
for the existing ban process. I will provide a GIT repo to pull from.

Thank you.


-- 
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/23002822.7401411167622170.javamail.r...@newmail.brainfood.com

Re: CoC / procedural abuse

[Ean Schuessler]

- "Charles Plessy"  wrote:

> I guess that the story is simpler than this: time-limited bans do not seem to
> be supported natively in Debian's mailing list engine (SmartList), so if one
> wants to see our listmasters use time-limited bans more often, then somebody
> has to spend time to implement this function.

http://unixhelp.ed.ac.uk/CGI/man-cgi?at


-- 
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/15203641.6761411152990482.javamail.r...@newmail.brainfood.com

Re: Code of Conduct violations handling process

[Ean Schuessler]

- "Ean Schuessler"  wrote:

> I'm saying it *does* do that but I am saying that we can't ever
> allow it to.

Oops. Should read "I'm not saying it *does* do that...". Sorry.


-- 
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/20794350.13621409856747573.javamail.r...@newmail.brainfood.com

Re: Code of Conduct violations handling process

[Ean Schuessler]

- "Russ Allbery"  wrote:

> At least in the United States, people who use the term "political
> correctness" in all seriousness as something they dislike and think is
> bad are generally people with whom you would not want to share a project
> and people who you would be best off avoiding.  This viewpoint is correlated
> with racism, sexism, and other really anti-social behavior.  Its most
> vocal public proponents, in the US political arena, are people who feel
> the major problem facing society is not that bigotry is tolerated in the
> public sphere but that other people dare to call them on their bigotry and
> imply it's unacceptable.  Expect to see, for example, the KKK ranting
> about "political correctness."

I don't think this is true. If you believe Wikipedia:

The term "politically correct" was used disparagingly, to refer to 
someone whose loyalty to the CP line overrode compassion, and led to
bad politics. It was used by Socialists against Communists, and was
meant to separate out Socialists who believed in egalitarian moral
ideas from dogmatic Communists who would advocate and defend
party positions regardless of their moral substance.

-- "Uncommon Differences", The Lion and the Unicorn Journal

As with many politically charged terms in the US, the phrase has been
warped by both conservatives and liberals to suit their purposes.
American politics is especially effective at warping meanings so I
suppose your associating the term with the KKK is an easy mistake.

It is interesting to analyze the original critical intent of the phrase
when it is framed in the Debian context. We aren't trying to
feed and clothe people so compassion is probably not the focus of
Debian as a political program. I would guess, if anything, it is honesty
and liberty. The intent of the Social Contract, as I understood it
in my mind, was for us to prevent our computer systems from being
controlled by some entity that had its own agenda. The Operating
System is an instrument created by us to amplify the potential of
our minds and our mutual contract with each other is to ensure that the
instrument is unbiased and unfettered by external controls. The
"policy compliance to the point of overriding compassion" in the case
of Debian would seem to be "policy compliance to the point of overriding
honesty and liberty".

I have complained about the CoC from its inception because it frightens
me. However, I can see that mailing lists full of endless and repetitive
debate will exhaust a rational person's desire to participate. We must have
some rules to maintain decorum. What we cannot allow is for our sense of
etiquette or manners to prevent us from being honest about the character
of the ideas being discussed. If the CoC closes the door to rational
criticism then it strikes at the heart of our effort. I'm saying it
*does* do that but I am saying that we can't ever allow it to.

One observation I will make is that "politically correct" behavior is
something I associate with corporate environments. I have done business in
many large organizations and I know how to adopt a professional demeanor.
I know enough to keep my mouth shut when the person who holds the purse
strings says something silly. I also know how to get things done in those
environments and still get software built. What I do dearly hope is that
we are not trying to turn Debian into *that* environment. If this "safe
and welcoming" place that we are trying to build ends up with the flavor
of a corporate campus then, well, I suppose we will have come full circle.


-- 
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/5635192.12681409842647228.javamail.r...@newmail.brainfood.com

Re: Code of Conduct violations handling process

[Ean Schuessler]

- "Zenaan Harkness"  wrote:

> Or perhaps a +1/-1 button, and it acts as a voting process,
> whilst the +1s are winning the microphone stays on :)

+1!


-- 
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/13099329.9881409755632229.javamail.r...@newmail.brainfood.com

Re: open source or free software?

[Ean Schuessler]

Neither term is trademarked. It seems like the only sane point of view
for Debian, in its context, is to regard them as synonyms for "compliant
with the DFSG". Anything else will involve a lot of hair splitting and
countings of angels on the heads of pins.

- "Daniel Pocock"  wrote:

> There has been some chat on my recent blog post[1] and #debian-devel
> about whether the terms "open source" or "free software" provide more
> correct or useful terminology.

-- 
Ean Schuessler, CTO
e...@brainfood.com
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
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/22054818.5741409444155343.javamail.r...@newmail.brainfood.com

Re: The Code of Conduct needs specifics

[Ean Schuessler]

- "Russ Allbery"  wrote:

> I think this is a mistake.
> 
> The experiences of other groups have mostly convinced me that the
> point of
> a Code of Conduct should be to scare away potential contributors who
> cannot or are unwilling to behave according to the standards that we
> expect of our community, and to reassure the people who would be
> injured
> by violations of those standards that we're serious about declaring
> those
> people unwelcome in our project.  Not welcoming them and attempting
> to
> quietly encourage them to become better people (which doesn't work).

I agree with Russ. I also think that specificity avoids a perception 
of people who run astray of the CoC to claim that they have been 
targeted by "The Cabal". The legend that there is a secret inner core 
of Debian members that controls things and plays favorites is almost 
as long-running as Debian's reputation for being inhospitable 
and unfriendly. I don't think its a perception that we want to
encourage.

Would it be possible for us to give a rich set of examples while,
at the same time, stating clearly that they constitute a 
guideline and that final decisions are left to the listmasters? If
it does turn out, eventually, we have someone in a position of 
authority who is repeatedly arbitrary then these examples would
help speak to them about how they should conduct themselves.


-- 
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/19099685.69041395693743073.javamail.r...@newmail.brainfood.com

Re: GR proposal: code of conduct

[Ean Schuessler]

- "Henrique de Moraes Holschuh"  wrote:

> Agreed.  It will serve no purpose but to put everyone at risk [of
> legal
> actions] and extra nuisances.  We can have a private location with
> this data
> which only DDs can access for governance purposes, if required (and I
> *do not* think it is required at all).

I feel we are also at risk when there is a lack of policy and
proper documentation. A ban, especially a long term ban on a DD, is
a strong statement against the character of a person even when not
advertised publicly.

In the physical world, it is as if you barred someone from entering a 
clubhouse. Friends inside will wonder what the person did to deserve
the treatment and potentially make up stories. People working with them
may lose confidence in any effort they are collaborating on. It is not
necessary to put a sign on the door that says "So and so is not allowed"
even though that is obviously worse.

If the policy for barring entry is understood by everyone in advance
then participation in the club is effectively "consent" in the governing
policy. This is still true for a policy of "don't upset the list masters
or they will throw you out" but such a policy leaves a great deal of
personal responsibility on the "behavior police". To me, policy and
documentation are a shield that decreases legal risk rather than
increasing it. I'd hate to be a football referee if there were no rules.

IANAL.

I support the CoC GR. I accept the position that the GR represents
a codification of status quo rather than the generation of new policy. 
I would love to see additional clarity around the rules and the record
keeping because this policy (the CoC) is definitely going to cause hard
feelings at some future date and I think clarity is a guard against that. 
Russ has expressed quite clearly how process protects us in prickly 
scenarios.

I will vote for the CoC GR in its current form but with the reservations
I've noted. I just wanted to get my opinion out there so that I can say
"I told you so" when things go terribly wrong.

Ha, ha. Just kidding. Still an acceptable email? Too much comedy?


-- 
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/3507416.22421392315930297.javamail.r...@newmail.brainfood.com

Re: GR proposal: code of conduct

[Ean Schuessler]

- "Ian Jackson"  wrote:

> This isn't really true IMO.  Someone who is banned can always send a
> message privately to a sympathetic contributor, who can forward it if
> it seems relevant or interesting.  (I have in fact done this for a
> contributor who was under some kind of cloud, when they had a
> relevant and constructive contribution to make.)

I have seen this used in years past and its seems to underscore the
"second class" status of the person involved rather than relieve it.
This is, of course, my opinion.

> I disagree.  I don't think that making these processes heavyweight is
> a good idea.  I have had very poor experiences with "policy-driven"
> processes of this kind.

I agree. No one likes red tape. I don't think basic record keeping
has to be heavy weight. A ban is an infrequent event and is regarded 
seriously. A process just slightly less onerous than a kernel commit
does not seem like too much to ask.

> I get the impression from your mail that you would vote against the
> CoC in its current form.  That's your prerogative, of course.  Do you
> intend to draft a counterproposal and if so how long do you expect
> that process to take ?  The CoC in its current form has been
> extensively discussed on -project already, of course.

I am actually for the CoC. My complaint is that the GR does not require
a record keeping process. I actually agree with Steve that we should not
be concerned about publicly advertising the bans. A ban should have been
proceeded by a warning and should be reasonable and clear-cut given the
circumstances. By the time a ban is issued it should have been fairly
obvious that the recipient effectively "signed on the dotted line" 
for it.

It does not seem unreasonable to me that if a developer is curious about
why another developer was banned that they should be able to find out
what messages provoked the ban, when a warning was issued, who 
implemented the ban and why (briefly) the band was warranted. This
could be as simple as the listmaster forwarding a couple
of signed messages to a procmail script. 

I would be willing to help modify the necessary scripts.

The current procmail rules do not contain documentation about the 
messages that provoked the ban. Ironically it is currently easier to find
out who has been banned than it is to find out why.

ps. I will also be working on an automated sarcasm detector which may or
may not be helpful in streamlining the ban workflow.


-- 
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/13336517.22291392250726231.javamail.r...@newmail.brainfood.com

Re: GR proposal: code of conduct

[Ean Schuessler]

- "Wouter Verhelst"  wrote:

> # Debian Code of Conduct
... 
> ## In case of problems
> 
> 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 [the page on Debian's organizational
> structure](http://www.debian.org/intro/organization)

It seems to me that with the Code of Conduct (afterwords CoC) that we are
institutionalizing a penal system in Debian. With that in mind, I think we
should follow some of the best practices typical of these processes in
other organizations. I also think some aspects of the CoC relate to
obligations we have taken on in the Social Contract.

It is well understood that secret laws and secret courts are not a
desirable feature for any government. I feel that the same should 
hold true for our community. The procedures leading up to a ban, the
evidence collected, the criteria the evidence must meet and the persons
making the final decision should all be public record. I reference the
Social Contract mandate to "not hide problems" in support of this
concept.

Please do not interpret this suggestion as an attack on the character of
the listmasters or any other project member who donates their valuable
personal time to make things happen. That is not the intent. I have the
highest level of respect for everyone who contributes to the project and
they have my heartfelt thanks for the operating system I use every day.

I feel we must see clearly that the CoC and its related ban punishment
effectively amounts to a nascent "court system" for the project. Bans
have been treated as an embarrassing thing that we want to keep out of
the public eye but they constitute a very serious punishment. A 
comprehensive ban is effectively a "death sentence" for its target
because, from the perspective of the project, that person will cease
to exist. This may seem strong language but some members of the project
feel a great deal of passion for the effort and would regard an
eviction as catastrophic.

I hope many of you will agree that while the CoC may be a necessary
feature for our community it should be governed in a transparent,
policy-driven and unbiased manner with detailed record keeping and
peer review.


-- 
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/24545501.20871392227105291.javamail.r...@newmail.brainfood.com

Re: Debian services and Debian infrastructure

[Ean Schuessler]

- "Thomas Goirand"  wrote:

> My first remark about this would be: do we have any other cloud
> software
> that can extensively use something like Ceph for distributed storage?
> Because for me, distributed storage is a mandatory piece which we
> have
> to implement when thinking about cloud computing.

We use a MooseFS cluster for Brainfood's hosting cluster and use files
on the distributed filesystem for our KVM disk images. Moose does not
have Ceph's RADOS block device level integration but it does have some
very useful features that Ceph does not. For instance, it has the 
ability to do shallow clones of a file (which Ceph can also do) and
does not require that all children be removed before the original parent
(a disadvantage which Ceph suffers from). We have found the performance
of Moose to be adequate for our needs using an Infiniband interconnect
and the reliability has been excellent.

> If the DSA wont go with OpenStack, please name another (comparable)
> solution that would fit.

We use OpenNebula because we started fairly early and at the time we first
began the OpenNebula packaging on Debian was much more mature. That picture
may have changed by now. We have considered looking more deeply into 
OpenStack but OpenNebula is a breeze to script and we do not want to make
a decision that is "hype based" as some accuse the CERN switch to have been.

We also have a smaller Eucalyptus installation that we are experimenting with
for AWS based services such as Asgard.

> The puppet receipt for setting-up OpenStack are open source, and
> eNovance actively works on that right now (to have a "private cloud"
> product based on just that...).

We have been using Ansible for our host configuration. We first learned of
Ansible through our involvement with the Eucalyptus web UI development
effort and some "family ties" between the Eucalyptus team and Ansible. We
helped Ansible with some early web development efforts and, as a result,
were able to get started with their product earlier in its life. I don't
really have anything negative to say about Puppet or Chef but I would say
that our use of Ansible has flourished a rate that never happened with
either of those products.

> Another thing: I've been providing a bit more than a dozen VMs based
> on
> GPLHost Xen solution (I am the main owner of GPLHost, and it's been
> now
> more than 10 years...) for various people within the Debian project.
> The
> only requirement was that a DD would ask and write his PGP key ID
...
> or if this is because this is not well known enough. Anyway, I'm
> very happy I could help, but I'm still a bit frustrated that this
> isn't really part of the Debian official infrastructure.

Similarly we have handed out some pro-bono virtual machines to various
DDs over time just to get their feedback on how our environment worked
from their perspective. I would agree that we have not had DDs "beating
down our door" to request this service. If the availability of these
kinds of machines was more clearly advertised to DDs that might be a
different story. We have also seen some use of the machine for personal
services. That is not a problem from our perspective but I can understand
how there could be other viewpoints.

We would also be happy to collaborate in an effort to organize this kind
of service into a more clearly defined "Debian cloud platform" that
provides some well understood set of services (authentication, VPNs,
GIT repos, etc.)

-- 
Debian, choice of a GNU generation.


-- 
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/8080424.13861391797081490.javamail.r...@newmail.brainfood.com

Re: Debian services and Debian infrastructure

[Ean Schuessler]

We've implemented OpenNebula here at Brainfood and after having had some
experience with it I would say that having that kind of infrastructure
simplifies management rather than making it more complicated. Having a
bunch of hand baked KVMs running without coordinated migration or shared
storage is a lot more fragile, confusing and slow to work with. For 
instance, if we need to service a machine we can tell OpenNebula to "flush"
that host and it will automatically balance all the virtual machines
running on that machine to other hosts. That's a big convenience.

I'm sure OpenStack has similar capabilities. We evaluated it along with
a number of other infrastructures and for us OpenNebula was just the
easiest to get going from the stock Debian packages. We also have found
it to be very hackable. A lot of its functionality actually lives in
shell scripts rather than some DSL or Ruby code.

- "Lucas Nussbaum"  wrote:

> 3. to provide a place to experiment with new services
>+ create a "Debian cloud" with virtual machines to develop new
> services
>  (maybe providing manually-created VMs would be enough -- I'm not
> sure we 
>  need a complex infra such as OpenStack).


-- 
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/27143708.9661388951071865.javamail.r...@newmail.brainfood.com

Re: Proposed MBF - mentions of the word "Ubuntu"

[Ean Schuessler]

It is hard to avoid the irony in asserting ownership of the word
"ubuntu". The contrast with its native meaning, "all of us contribute
to the identity of one and other", is striking.

In a philosophical sense, the action approaches satire. Its an 
Orwellian joke on Desmond Tutu and Nelson Mandela.

- "Ian Jackson" wrote: 
> It appears that Canonical have gone to war with anyone who mentions 
> the word "Ubuntu" in a way they don't like: 
>   
> http://arstechnica.com/information-technology/2013/11/canonical-abused-trademark-law-to-target-a-site-critical-of-ubuntu-privacy/
>  
> Normally we take a relaxed approach to trademarks.  We use them, 
> expecting that in the cases where trademark law gives the trademark 
> holder a say, the holder approves of our uses, which we think are 
> unobjectionable. 

-- 
Ean Schuessler, CTO 
e...@brainfood.com 
214-720-0700 x 315 
Brainfood, Inc. 
http://www.brainfood.com 


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/1749262.216421383934411353.javamail.r...@newmail.brainfood.com

Re: [Debconf-discuss] "Anonymous donation" to Debconf 13

[Ean Schuessler]

This point makes an awful lot of sense. Is it actually against an official 
policy to consider (not accept, mind you, since it was not actually accepted) 
an anonymous donation with strings attached? While it may seem that certain 
things are "common sense" we really cannot hold people to unstated policies for 
rather obvious reasons. Imagine if packaging was approached in such a way! 

The activity that seems more concerning to me is the allegedly purposeful 
misrepresentation of the character of the donations by DebConf personnel . 
While I can't find anything in the Debian Constitution explicitly stating that 
official personnel must not lie about their activities, I think we can all 
agree on that one. It would be nice if the consequences of such an action had 
already been spelled out before now. 

I'm not suggesting we figure out these questions in this thread. It might be 
important to take up a separate discussion spelling out a policy for officials. 
They really should understand, in advance, their obligations and have a clearly 
spelled out reference to guide their activities. 

- "Russ Allbery" wrote: 
> Ian Jackson  writes: 
> The part that I'm missing here is what you felt should have been done 
> differently. 
> Let's assume that Debian has no control over the offering of the donation 
> (or loan) in the first place. I think that's a reasonable assumption. 
> What I would then expect is for the team to discuss the offer (since no 
> decision is ever going to be made out of hand), and then reject the offer 
> as being insufficiently transparent and posing other problems with 
> oversight and possible undue influence. 
> That seems to be exactly what happened. So unless I'm missing something, 
> the reaction indicated seems to be "well done, thank you for handling this 
> ethically and professionally." I'm not inclined to blame people for 
> temporarily discussing something, or even temporarily using it as an 
> argument, before thinking it through further. Asking people to not do 
> that seems to be an impossibly high standard to which to hold people. One 
> of the ways that high-functioning groups develop and maintain ethical 
> standards is to discuss ethical quandries in public. 
> I'm not seeing any evidence on this thread (and, indeed, directly 
> contrary assertions from people I think we all have reason to trust) that 
> the withdrawn offer had any material effect on the choice of venue. 

-- 
Ean Schuessler, CTO 
e...@brainfood.com 
214-720-0700 x 315 
Brainfood, Inc. 
http://www.brainfood.com 


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/8253955.98481355412499097.javamail.r...@newmail.brainfood.com

A Software Populist Who Doesn't Do Windows

[Ean Schuessler]

I don't know how many of you caught sight of this article about Ubuntu in the 
New York Times, its an amusingly stilted read. 

http://www.nytimes.com/2009/01/11/business/11ubuntu.html 

I know its now considered bad form to whine about Ubuntu's chronic success at 
taking credit for Debian's achievements... so, I... won't. 

I do like how the article mentions Debian's 1000+ volunteers in place of a 
count of Ubuntu's. I also like Mark's lead quote: 

“It feels pretty clear to me that the open process produces better stuff,” 

-- 
Ean Schuessler, CTO Brainfood.com 
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 

Re: Results of the Lenny release GR

[Ean Schuessler]

- "Russ Allbery" wrote: 
> If he wants to stop the release, he needs to propose a GR to override the 
> delegate decision, and it has to pass. Neither of those things have 
> happened. Until they do, this is all pointless noise. 

Some people cannot just leave well enough alone. Please do not ask for another 
GR unless you want one. 

-- 
Ean Schuessler, CTO Brainfood.com 
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 

Re: Results of the Lenny release GR

[Ean Schuessler]

- "Kalle Kivimaa" wrote: 
> Umm, why shouldn't Bdale have his opinion about the results? Nowhere 
> does it say that the (acting) Secretary is the authority to 
> interprete GR results (that's not interpreting the Constitution). 
> The people who do the interpretation are obviously the release team, 
> with the DPL being the potential sanity checker. 

It is clear enough that, recently, Manoj was the "roadblock" to release because 
he was the primary consitutionally empowered person that was pushing us to 
honor the Social Contract, honor the consitution and its majority requirements 
and generally follow procedure. Now that Bdale is the acting Secretary there 
should be no further resistance to releasing Lenny. I think you will find that 
Bdale's intrepretation is going to stick. Just a hunch on my part but I'm a 
gambling man. 

Do not take this as an expression of distaste on my part. There are no 
"enemies" here, just people disagreeing passionately. Passion is good, we just 
need to channel it properly. 

-- 
Ean Schuessler, CTO Brainfood.com 
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 

Re: Results of the Lenny release GR

[Ean Schuessler]

- "Robert Millan" wrote: 
> The majority of developers voted to make an exception for firmware in 
> Lenny. They did NOT vote to empower the Release Team to make exceptions 
> as they see fit. Results of GR 2008/003 are crystal clear about this. 

Unfortunately, nothing can be crystal clear about GR 2008/003 because there is 
simply nothing crystal clear about it. 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. Amusingly, those who called for Manoj's head have now 
fallen quite silent. 

There are some things that are clear to me: 

* I have a very high level of trust in Bdale, even when he starts doing 
peculiar things. 
* We should not delay Lenny for further political discussion because people's 
operations depend on our release. 
* Discussion of these issues in the shadow of Lenny warps people's minds and 
makes sane discourse impossible. 
* We have already made several such releases in the past and do not have a 
soberly constructed framework for solving the problem permanently. 

With that in mind, I am inclined to go along with Bdale's "release Lenny by all 
means possible" reading of 2008/003. However, if anyone views this as a victory 
then they are smoking extremely powerful crack. I would rosily call this a 
"convenient failure of democratic discipline" on Debian's part. It would be 
VERY, VERY UNFORTUNATE if it continutes to be a permanent pattern. I think the 
very survival of our organization depends on us coming to a well defined 
solution by the next release. 

So I'm sorry Robert, your heart is absolutely in the right place but I agree 
that we should release Lenny. I encourage you to "go with flow" and think about 
structuring the solution down the road. 

-- 
Ean Schuessler, CTO Brainfood.com 
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315 

Re: Call for vote (Re: call for seconds: on firmware)

[Ean Schuessler]

Does 5 refer only to firmware that is not currently identified as being 
non-free? If that is the case, is 5 a viable choice? If it doesn't resolve the 
problem completely and allow us to release then it needs to be accompanied by a 
plan for the other problem firm/software.

- "Manoj Srivastava"  wrote:

> Here is the *DRAFT DRAFT DRAFT* ballot for the GR. Please note
>  the dates on the ballot; voting is not open yet.
> 
> Please send comments to the debian-v...@lists.debian.org list.

-- 
Ean Schuessler, CTO Brainfood.com
e...@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: [OT] Free software for social networks.

[Ean Schuessler]

- "Charles Plessy" <[EMAIL PROTECTED]> wrote:

> The core of the problem is obviously that there is no easy platform to  build
> interoperable social networks with free software. And it is a pity because
> there is a real demand. In two of the professional associations where I am
> member, there was interest to pay people to build software to manage the 
> social
> network of the members, but the projects never started, partly for management
> reasons, but also because the current proprietary platforms are so strong and
> the free alternatives – be them building blocks – are so weak (or well 
> hidden).
> Developers in France or Japan (or people who can issue proper bills to
> associations having bank accounts in these countries) can contact me in 
> private
> if they have suggestions and interest to try to revive the project (expect a
> low probability of success, we lost the momentum to get public money).

Nah. Its not true! Redhat has MugShot. There is ShinDig from Apache. I've been 
doing some work to hook ShinDig into OFBiz, which has its "party management" 
tools that are quite a bit more sophisticated than the consumer social network 
models.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Debian on Causes (Facebook and MySpace)

[Ean Schuessler]

I just created a "Cause" for Debian on Facebook and MySpace. I think we should 
do this for all of the SPI projects.

If you are on Facebook or MySpace, please join it and spread it!

Some of you are probably saying "Eeee gads! Not accursed proprietary social 
networks!". Some of us have friends who aren't die-hard computer nerds and, 
yes, there is a world beyond Advogato. Now shut up and go make your less nerdy 
friends give money to Debian.

Oh, I gave $50 to Debian too.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Member distributions and popularity

[Ean Schuessler]

- "Florian Weimer" <[EMAIL PROTECTED]> wrote:

> I don't know.  Paid membership by companies seems to be an integral
> part of what Eclipse is doing in this area.

No, I'm not talking about charging. We aren't interested in money, we are 
interested in co-promoting those distributions who view themselves as part of 
the Debian ecosystem rather than as a competitor. They would promote us and we 
would promote them. That's more valuable than money.

I'm pointing to Eclipse as an example of another open project that is doing 
this sort of thing. The Eclipse variants are not buried down deep in their 
site, they are heavily promoted at a top level. That's what I'm saying we 
should mimic.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Member distributions and popularity

[Ean Schuessler]

- "Andreas Tille" <[EMAIL PROTECTED]> wrote:

> I do not think that Ean is talking about Debian Pure Blends because the
> most important feature of a Blend is that it is actually NO derivative.
> (That's why we call them now not CDD any more because this very frequently
> remained unclear for people who just recognised the name.) But what I would
> like to see in connection to Ean's mail is that we try to propagate the
> idea about the advantages a derivative could gain if it would merge back
> into Debian and *become* a Blend (for instance there was a time when
> DeMuDi (Debian Multimedia Distribution) intended to do this but this plan
> was dropped as far as I know).  The profit for both sides would be evident
> in my opinion: Debian will become better multimedia support (to stick to
> the DeMuDi example) and 64studio (offspring of the DeMuDi project) would
> join a team of 1000+x developers to work on the same goal.
> 
> Regarding Ean's original mail: IMHO there is no need to call this an
> "effort" or whatever.  It might have been sufficient if Ean would have
> actually prepared the needed wml code that generates the web page he
> has in mind and fix the menu on www.debian.org to make it easily
> accessible.  There is not much need to talk about this - it would be
> better to announce that it is just implemented.

"Debian Pure Blends" are definitely part of the picture. It would be really 
great if we promoted Debian Pure Blends on the "Getting Debian" page. I'm not 
sure if we want to say that *only* Debian Pure Blends would be promoted by us. 
For instance, if Google were to distribute a signed G1 firmware with a real 
Debian distribution... how would that be handled?

Debian Pure Blends is very far along the way to what I'm talking about. I've 
known about CDDs and I've used the live-helper tools (which are very cool) but 
I've never had an occasion to read the Debian Pure Blend docs. We should be 
more actively promoting these kinds of things off of the main landing pages.

To your point about not wasting lots of keystrokes... I will comp up a version 
of the "Getting Debian" page that has my changes and send that to the list for 
commentary. I guess the thing I'm looking for (and the reason that I'm not just 
going to go change pages) is that the policy for collaborating with 
distributions is something that the project should be behind and not something 
I just made up.

(sorry if this mail is hard to read in mutt... I'm using Zimbra and I'm trying 
to figure out how to fix its formatting)

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Member distributions and popularity

[Ean Schuessler]

- "Sven Luther" <[EMAIL PROTECTED]> wrote:

> What about also listing in the same area, but under a different header,
> those distros which are debian based, but don't follow the above rule ?
> This would allow us to put more visibility on the fact that those
> distros are debian derivatives to some degree, even if they don't
> advertise that fact, and i think would have a positive impact on the PR
> value of this effort. We don't necessarily will go in as much detail as
> we would for "official debian derivatives".

I don't think that would be a problem... but the point is specifically to 
promote those distributions that maintain a good working relationship (and some 
level of compatibility) with us.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Member distributions and popularity

[Ean Schuessler]

- "Javier Fernandez-Sanguino" <[EMAIL PROTECTED]> wrote:

> You mean something like this:
> http://www.debian.org/misc/children-distros

Yes!
 
> I started it off a long time ago although I don't have the time to
> maintain it. Of course, there's lots of room for improvement there.

Right. I think one of the first areas for improvement would be making the page 
easier to find! The only thing I can see on www.debian.org that links to this 
is the Debian FAQ. Ideally, this list would show up as a direct link off of 
"Getting Debian".

My main suggestion is that rather than promoting all Debian variants we would 
promote those that follow some rules. For instance:

* The dist must display a "Real Debian GNU/Linux" logo (or something like that) 
on their site.
* The dist must pass some test suite we would make up that checks whether 
things work as we expect them to work in Debian.
* The dist developers go through some kind of Debian Developer kind of 
initiation where they promise us to play nice or something.
* Use our issue tracking/patch management/release/whatever procedures in a 
certain way that we define.
* Whatever else we decide they need to do.

In return for these considerations they would get their fancy new dist promoted 
on our world famous web site. These dists can take care of all kinds of 
specialized markets that we don't explicitly cater to.

* Incredibly computer illiterate people who can barely use their computer
* Kids/infants (who can later teach those just mentioned)
* Giant corporations who want to install Debian onto their weird proprietary 
thing and otherwise be very nice
* Other people who love to distribute proprietary blobs

The good news is that lots of these mini-dists already exist and would love 
this kind of program. It would give them more visibility and a sense of quality 
and good community behavior. It would help users avoid things that we know are 
badly behaved. Most of all it would expand the visibility of the Debian 
umbrella so that we feel like we are growing (which we are) rather than 
shrinking.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Member distributions and popularity

[Ean Schuessler]

- "Noah Meyerhans" <[EMAIL PROTECTED]> wrote: 

> When Ean suggested borrowing ideas from Eclipse, I don't think he meant 
> charge people to be Debian derivatives (or did you interpret it some 
> other way?) 

Right. I'm more suggesting that we provide an "official derivatives" page in a 
prominent way on our site. The listing would provide a description of what the 
dist specializes in (ie. kids, realtime audio, proprietary games, whatever) as 
well as, perhaps, user ratings or even reviews of the distribution. 

> OTOH, I'm not sure what he suggested. I think we already do quite a 
> good job of working without derivitives. But much of how we work with 
> them depends on how they choose to work with us. If somebody chooses to 
> simply grab our distro, make some changes, and call it their own, we 
> can't stop them. We can, and do, encourage them to work with us. I'm 
> not sure what else we should do. 

That's exactly what I'm driving towards. To get on this list, a distribution 
would have to follow certain rules. For instance, if you break Debian policy in 
such a way that major Debian packages won't work on your distribution then you 
could lose your "official distribution" status. We wouldn't charge for this 
status. Rather, we would provide a set of guidelines you have to follow to 
achieve it. Sort of like "Linux Standard Base" but with the difference of being 
more directly Debian oriented. 

Derivative distributions are not going away. We don't want them to go away. 
We've even gone to a lot of trouble to make sure its easy to create them. 
Instead of being sad about "losing users to derivative distributions" we should 
view the derivatives as part of our installed base and set up some guarantees 
for users about which ones they can trust. 

For instance... SimplyMEPIS recently went back to a straight Debian core with 
their own added value stuff on top. They would probably love to have this kind 
of exposure. 

(sorry if my emails aren't word wrapping in mutt. I'm using zimbra and can't 
figure out how to get it to wrap.)

-- 
Ean Schuessler, CTO Brainfood.com 
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Member distributions and popularity

[Ean Schuessler]

Hi.

As everyone is aware, there has been plenty of debate about how Debian is 
losing popularity. At the same time, the overall number of .deb packages 
installed in the world is just going up and up and up. The "problem" is that 
these .debs are often installed by a Debian derivative distribution. Some 
people think this is good, some people think this is bad. The one thing we can 
say for sure is that it is causing lots more .debs to be installed.

We want to grow our base of users and developers. We also want to insure that 
when people install .debs that they are truly getting a Debian experience. 
Perhaps one way that we can have our cake and eat it to is by helping to 
promote Debian derivatives that don't break the overall experience and work 
with us in a happy and productive way.

This is how the Eclipse project works with their derivatives. Maybe we can 
borrow some ideas from them?

http://www.eclipse.org/membership/special_programs/member-downloads-program.php

Thanks.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "Debian Powered" Logo

[Ean Schuessler]

On Monday 03 July 2006 09:30, Yavor Doganov wrote:
> Putting a note on the shop "We don't sell poison, it's not part of our
> articles' list" does not actually mean that you don't when poison is
> clearly available among other goods.  Anyway, we'll never reach any
> agreement and it's pointless to discuss, so I'll stop.

It is really more simple than that. There is non-free software that is 
pre-integrated with Debian that we make available for support purposes and 
the convenience of our users. The core system, however, is completely 
operational without that software. You will never see a situation (to the 
extent it is within the power of the project to prevent it) where you must 
install parts of non-free in order to use Debian.

The distinction is quite clear.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Minutes of an Ubuntu-Debian discussion that happened at Debconf

[Ean Schuessler]

Lucas Nussbaum wrote:

I've been working on this specifically. The idea is to create an Ubuntu
team which would interact by volunteer DD more closely (filing bugs for
their packages in the BTS for all relevant issues, for example).
On the other hand, the DD would have to act promptly on those bugs,
so Ubuntu can get the new Debian package ASAP.

This is detailed in https://wiki.ubuntu.com/DCT and
https://wiki.ubuntu.com/DCT/Proposal . However, this hasn't been
discussed (enough) with others Ubuntu developers, and I won't have time
to work on this in the next weeks. So, if somebody wants to take this and
move it forward, ping me by mail/IRC.
  
One can also make the argument that since Ubuntu paid people to fork 
away from Debian code that they should return the favor and do the brunt 
of the work to reintegrate the useful parts back in.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: "Debian Powered" Logo

[Ean Schuessler]

Raphael Hertzog wrote:

Indeed, that's why it's great that Ubuntu is ready to make it more
obvious that they are Debian based.
  
I very much agree. I never had a problem with the fact that Canonical is 
willing to capitalize improvements to Debian. I never cared for their 
"de-branding" of Debian's work and creating negative press for the 
project. True or not, Ubuntu entered the marketplace with the message of 
"we're going to fix Debian because its broken" and changed Debian 
branding throughout the project to their own. I'm sure that no one at 
Canonical intentionally set out to make Debianers angry but it wasn't an 
ideal way to start the relationship.


The Ubuntu site says that ubuntu means "I am what I am because of who we 
all are". If Ubuntu is ready to live up that slogan and publicly 
acknowledge that it is what it is *because* of its Debian origins, 
rather than despite them, then I think that is great.

I find this overkill and the kind of administrative work that we shouldn't
have to do. The DFSG authorizes any derived work, there's no reason for us
to create a difference "good/bad derived work".
  
There is something to be said for having a Debian brand that means "you 
can install Debian-stable packages on this distribution and they will 
work". The testing process for something like that would be interesting. 
It could be regarded more as a strategic committment on the part of the 
distribution to achieve that goal.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

[Ean Schuessler]

Frans Pop wrote:

Bah. That is a gross overexaggeration. No arch has been killed in d-i.
d-i is, and will remain, perfectly capable of installing powerpc.

As I've said before, there may be a temporary reduction in support 
(specifically for the lesser used subarchitectures), but there is 
absolutely no basis for claiming that powerpc support is being killed.
  
That is where I have a spot of confusion. No one seems to deny the fact 
that Sven plays a critical role in producing the PPC port of the 
installer. It frames his antics in a different light if his 
contributions have been minimal. If he does very little for the project 
and makes this much noise then I can see why his elimination is sensible 
and even beneficial.


I suppose it comes down to what a "temporary reduction in support" looks 
like. Ideally this staffing change should produce improved performance. 
Could you outline the improvements you expect to achieve through Sven's 
elimination and the timeframe they might arrive in? Do you have some 
specific people in mind who have committed to make #d-i a more 
productive group if Sven's presence is eliminated?


I don't mean to play 20 questions, I've just gotten curious.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

[Ean Schuessler]

Manoj Srivastava wrote:

We are indeed a volunteer group.  We need to at least work
 well enough together so it remains fun enough for the volunteers to
 continue to volunteer.  When one individual cause enough fun to be
 sucked out from other people, we need ti step back and figure the
 sweet spot. Sticking to retaining people no matter how socially
 dysfunctional they are is not it.
  
Certainly I will not argue that any fool should be allowed to harass the 
rest of the project to their heart's content. Finding the sweet spot is 
critical and have a way to make these decisions in a process-oriented 
manner instead of the ad-hoc personal feelings of those in "command" at 
a given time.


I'm sure we are roughly in agreement that Sven should suspend his tirade 
and try sending some patches or even fork the repository. That aside, I 
still wonder why his mailing list access wasn't clipped instead of his 
CVS account.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

[Ean Schuessler]

Matthew Garrett wrote:
No. A GR can override any decision made by the DPL, a delegate or the 
technical committee. A GR can not override a decision made by an 
individual developer or a team of developers.


I guess you could argue that svn.debian.org is adminned by a delegate of 
the DPL, and a GR could force them to restore Sven's commit access. But 
the d-i team could then move their svn archive somewhere else and refuse 
to provide Sven with commit access.
  
A single developer can hardly hold back the will of the entire project. 
If the d-i team takes action that the rest of the project does not agree 
with then the project is perfectly capable of deciding that they are no 
longer the d-i team. That is obviously not the case here but it doesn't 
preclude the possibility.


I agree that Sven overstepped the limits of good taste in his list 
conduct. I also see why Sven would snap a twig over #d-i killing the PPC 
install. That is a pretty radical step.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

[Ean Schuessler]

Manoj Srivastava wrote:

It is also very upsetting when technical discussions
 immediately escalate into insults, distortion of motivation,
 accusations of wanting to hurt Debian, or the users, of being hide
 bound in pride and stupidity, having agendas that smack of
 discrimination, power grabs, or worse -- all the while actively
 casting impediments in actually finding a working solution by
 drowning the technical discussion in polemics and ad hominems and
 casting to apportion blame before looking at the technical issues.
 Add to it argument from extremes, bug severity inflation, and
 constant little pin pricks that make it impossible to collaborate, I
 would think that some times, it is better to reject contributions if
 the net contributions decrease due to the presence of one person.
  
Agreed. The trouble being that we have no formal processes or hard 
metrics for these problems.

Rubbish. Debian has always been far more than a cold, harsh,
 faceless  corporate entity with no social presence.  Technical
 excellence does mitigate a lack of social graces, but there are
 limits to how much disruption is to be tolerated.  Where you have
 social interactions, and you have politics, you have subjective
 social politics.
  
I respectfully disagree. In my experience corporations are rarely cold, 
harsh and faceless in their internal structure. Rather, they are most 
often a continually embattled mass of people fervently trying to 
displace one and other in order to increase their standing in the 
organization. It is only with rare excellent management and strong 
leadership that you see for-profit organizations where technical 
excellence comes before personality and influence. I agree that there 
are limits and Debian has only recently begun to define those limits.


Sven's case seems to stand in rather sharp contrast to Ted Walther's.

We have, by and large, despite the cat-calls about cabals from
 the peanut gallery, managed to make broad decisions rationally.  I
 don't think we are all in a vast conspiracy to gang up on a fine
 contributor without actually looking at the broad picture and the net
 results of his presence or absence on a team.
  
I agree but we must focus on results. I'm afraid of Debian becoming some 
painfully polite court where people are forever trying to score points 
on one and other by faulting their manners. Keeping things friendly is 
critical and etiquette can be a very effective method of intimidating 
people. Technical results should be of at least equal import to social 
considerations. After all, we're a volunteer OS not a volunteer 
international vacation club.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Call for a new DPL mediation ... This will be the only thread i will reply to in the next time about this issue.

[Ean Schuessler]

cobaco (aka Bart Cornelis) wrote:

- AFAIK nobody is arguing that Sven's patches aren't up to snuff
  technically
- AFAIK he hasn't ever abused his d-i commit rights (when he had them)
  
These are critical questions. As an uninvolved third-party I have still 
not been able to determine why his access was stripped in the first 
place. If Sven makes critical (or even genuinely useful) contributions 
to the PPC port and there is no replacement for him then there must be a 
really great reason to suspend his access. Did he do something nasty to 
the codebase?


Was his access suspended because he simply was not liked? If Sven is a 
socially dysfunctional person and holds this work dear because of 
extensive personal labor then I can understand this emotional explosion. 
It is very upsetting if you make genuine contributions to a project and 
find yourself excluded because of some clique of more skillful social 
players. That might explain the grade school references that keep coming up.


Social politics creeping into Debian is one of the greater mortal 
dangers that we face. If Sven makes genuinely important technical 
contributions to the PPC installer and is being excluded for purely 
social reasons then we should take that very seriously. It might be more 
expedient for SPI to pay for some psychological therapy for Sven. :-D



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian-niggers and debian-lgbt projects.

[Ean Schuessler]

Matthias Julius wrote:

Or a little more direct:


Matthias
I have suspected for some time the GNAA has a number of "sleeper agents" 
infiltrated into Debian.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Discussion of bug #311683, default kde install shows porn

[Ean Schuessler]

On Saturday 04 June 2005 7:23 am, R. Armiento wrote:
> The thing is, I *perfectly* agree with these statements. The "bug" here
> is just about that the current setup may make it a little too easy for
> people who will be offended by WebCollage to still accidently install
> and use it. It is sensible to both 1) keep things available for people
> who want to use them 2) help people avoid running things they do not
> wish to run. Don't you agree with this general principle?

This all seems a little foolish. If you want to insure that users do not 
accidentally stumble across porn the only reasonable solution is to block 
access to the Internet itself. WebCollage does precisely what it claims to 
do, which is load random images from the Internet. If you want the 
distribution to automatically protect users from unrated or pornographic 
material then that is a feature request, not a bug. (PICS rating recognition 
on webcollage might be one solution)

Anyone who connects to the Internet will eventually (usually sooner rather 
than later) come into contact with every form of pornography that the mind 
can conceive. Our responsibility is to provide access to the world's 
information resources, not to filter and censor them to meet some 
unquantifiable moral ideal. Users should make those choices for themselves.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Advertising on Planet Debian

[Ean Schuessler]

On Monday 02 May 2005 10:55 pm, Martin Schulze wrote:
> Writing about ones work and how the own company or job evolves should
> be pretty ok.  Even reporting *about* the new strategy of the company
> should be fine.  However, I believe that simply quoting the company's
> press release is advertising (oh, and hence should be fined with
> $1,000, whoops *g*).  We are not accepting this on the debian-* lists
> normally, so why should Debian honor this on Planet Debian?

In the end, isn't this a blog aggregator? It isn't a mailing list and I don't 
think the same rules apply. Effectively, Planet is trying to impose editorial 
conditions on peoples *diaries*.

What are the conditions to be aggregated on Planet anyway? Be a Debianer? If 
that's the only criteria then you should just tough it out through the 
occasional press release. It only takes a day for something like that to roll 
off.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: getting lully back on-line [Was, Re: I'll be a son of a bitch.]

[Ean Schuessler]

On Thursday 14 April 2005 06:39 am, Martin Michlmayr - Debian Project Leader 
wrote:
> Yes, and these offers are the reason I haven't suggested spending
> money on lully so far; but if people think fixing lully makes more
> sense, I'm more than willing to spend money on it.

I don't think we are talking about any great investment here. It just needs an 
IDE boot drive. It might be worth buying two and doing RAID so that we don't 
end up in this situation again.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I'll be a son of a bitch.

[Ean Schuessler]

On Wednesday 13 April 2005 11:22 pm, Steve Langasek wrote:
> In any case, the two obvious contenders for inheriting this responsibility
> would be debian-admin and debian-alpha; the former being the ones that
> listed lully's status as "no response from local admin", and the latter
> having received no communication from anyone about this issue.  In fact, it
> seems I had more information about lully's status than DSA did, and only
> because I had talked with Adam Heath about it on IRC.  If there's work that
> needs doing, I'm happy to help, but it's certainly not as if this was
> something the "alpha folks" dropped the ball on -- until now, there was
> never any reason to think it was our ball...

I was just reacting defensively to Andreas pointing the Alpha problem in 
Brainfood's direction. We're doing what we can to help and we've even done 
some physical repair on that machine but we aren't prepared to take up active 
development on Alpha. What you've pointed out sort of drives the point home.

We don't like having a big dead Alpha taking up rack space. We'd rather have a 
big happy Alpha compiling packages and making its space consumption a useful 
phenomena. I don't know how we were "unresponsive", Adam is usually a fixture 
on IRC and I've been around more steadily myself. I've never received an 
email about Lully. Adam may have corresponded with someone.

If someone's idea of unresponsive is us saying "root disk is dead and we don't 
have time to figure out an Alpha install" then that may explain the current 
status.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GFDL freedoms

[Ean Schuessler]

On Thursday 14 April 2005 12:58 am, Glenn Maynard wrote:
> Computer programs are useful tools, even if you can't change them.

So are laws?

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I'll be a son of a bitch.

[Ean Schuessler]

Adam believes that it boots off of IDE rather than SCSI but isn't 100% sure. 
The unit does have both IDE and SCSI.

On Wednesday 13 April 2005 11:43 pm, Martin Schulze wrote:
> If it only lacks a boot drive, this can probably be arranged.  I assume,
> that lully read SCSI, so either an older SCSI disk or a new one with a
> proper connector will do.  Looking at SPI's/Debian's funds, even a purchase
> should be possible (assuming that the then or now DPL agrees).

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I'll be a son of a bitch.

[Ean Schuessler]

On Wednesday 13 April 2005 7:52 pm, John Hasler wrote:
> Then complaints about the posted status are not criticism of you.

Oh. Good point. I guess I'm mashing Andreas' criticism in with Dave's message. 
Maybe that isn't what he meant at all.

In any case, if someone wants to requisition a new drive and figure out what 
it takes to put an image on it then we can get Lully booting again. We can 
even buy it local if I see some kind of SPI/Debian expense approval on buying 
some particular size/model.

I have no idea what does and does not work correctly in that unit.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I'll be a son of a bitch.

[Ean Schuessler]

On Wednesday 13 April 2005 7:24 pm, Dave Hornford wrote:
> Then shouldn't its status be updated to indicate its real status rather
> than 'root fs drive died, no response from local admin'
> The accurate story indicates a need for help & hardware, the posted
> status something else.

I don't know if it is possible to catch more sh*t from people for helping them 
out. If someone wants Lully I will put it in a box tommorrow and ship it to 
them. If someone from the Alpha port actually wants to update the status, 
build me an image and ship me a drive then we will happily install it in the 
system and bring it back online.

We're providing the machine bandwidth and rackspace at our expense and we're 
happy to do it. We don't have time to shoulder the burden of becoming 
developers in the Alpha port. Moreover, we don't really have any interest in 
doing that. If someone wants Lully on-line then get us a bootable volume, or 
really explicit instructions that a full-time busy shop can follow and 
reliably get it back on-line.

I didn't post that status nor are we actively monitoring it. Someone from 
Alpha needs to get proactive and run the ball if they care about that 
machine. Its my responsibility to see it has happy power, space and a 
connection. Its a very happy, very well connected, air conditioned and 
completely useless machine. If you would like to fix that I'm sure you could 
arrange to do something. I'm already doing more than you are with regard to 
Lully so why don't you pitch in?

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Debconf5 IRC meeting minutes

[Ean Schuessler]

On Tuesday 05 April 2005 3:06 am, Petter Reinholdtsen wrote:
> For the video recording, do remember post-processing.  In Oslo, we
> tried to do video recording, but when the recordings were done, no-one
> had thought about the need for post-processing, and the tapes just
> ended up on my desk.  They are still there. :)
>
> Also, the audio recording level is important.  Part of the problem
> with the tapes from Oslo was that the audio level was too low, so they
> would require a lot of work to make sensible video films from them.
>
> (Hm, not sure if this is the correct list to send it to, but will take
> my chance. :)

I have a rig that I built here with Conexant encoder based cards and Sony 
analog HAD cameras for a Halloween party. After some experimentation I feel 
that this is a better setup because it gives you a lot more flexibility.

The array of analog cameras and sound equipment available for attachment is 
very broad and very inexpensive. The Sony survellience cameras I bought off 
ebay, for instance, have sensitivity down to 1 lux (real 1 lux, not the fake 
IR LED assist stuff) and were only $150 each. You can then mike the stage 
directly or even pull stereo RCAs off of a sound board.

The Conexant encoder cards are <$100 here in the US and I was able to drive 
three of them (exporting the streams on the network and recording locally) 
off of an older Athalon 800 with absolutely no problem at all. This also 
gives the convenience of routing the video over the network.

Just my .02

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: I'll be a son of a bitch.

[Ean Schuessler]

We already dismantled that machine's power supply to resolder a new fan into 
it, Mr. Fingerpointer.  Are you volunteering to provide a new boot drive? How 
very awesome!

Just because Lully is hosted here doesn't mean there is local Alpha expertise. 
There is just free bandwidth and a free rack and free power cycles and free 
power supply repairs and a local Debian mirror.

Bitching is easy. Get Debian to buy a new drive, have someone with Alpha 
expertise image it, ship it here and we'll swap it. Do two and configure it 
for RAID 1 while you are at it.

Thanks!

On Wednesday 13 April 2005 2:26 pm, Andreas Barth wrote:
> Actually, there are things I'm much more worried about. E.g. lully being
> down for ages, and http://db.debian.org/machines.cgi?host=lully reads:
> Status: down - root fs drive died, no response from local admin

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: feedback, please: what was good, what bad?

[Ean Schuessler]

On Tuesday 12 April 2005 7:53 pm, Pascal Hakim wrote:
> As a last resort, you can probably copy-paste the ballot from somewhere
> like: http://lists.debian.org/debian-vote/2005/04/msg00022.html

Can I really do that? I thought that the hex crypto salt thingy does something 
magical for authenticity.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: feedback, please: what was good, what bad?

[Ean Schuessler]

On Tuesday 12 April 2005 4:16 pm, MJ Ray wrote:
> I've heard both grumbles and praise from people who have worked
> on things with you. On the whole, I liked the sound of most of
> your ideas and think they could move debian on. I was slightly
> disappointed with proportion of -vote emails answered and a weak
> showing in the IRC debate. I'm not sure how clearly your ideas
> were expressed to people who hadn't seen similar things before.

I haven't said anything about this because I didn't want to look stupid (as if 
that ever stops me from doing anything) but I never received my ballot. I 
even did the "Leader 2005" subject thing (or whatever) to request a resend. I 
was convinced that it was my spam filtering or some nonsense but I still 
can't find it. I'm at a loss.

I'm pretty much 100% sure that this is a problem on my end but now my 
curiosity is piqued.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

I'll be a son of a bitch.

[Ean Schuessler]

I don't understand it and I'm not happy about it but I accept it. A market 
almost always makes better decisions than an individual. If the majority of 
the Debian project doesn't carry a grudge about the SPI accounting mishap 
then I guess I can't either.

I officially bury the hatchet, smoke'em peace pipe and extend the olive 
branch.

Branden, congratulations on your election and good luck as DPL.

~Ean

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


pgpR0PvEqnQaN.pgp
Description: PGP signature

Re: [Spi-trademark] Re: debian domains

[Ean Schuessler]

Just go into this with your eyes open.

I would imagine that a company specializing in predatory domain trading comes 
well prepared to handle itself in court. I'd guess they will immediately back 
away from it at the first sign of organized resistance or they are totally 
prepared to mess with you in court and waste your time. Keep in mind that 
these guys are professional trademark infringers. That's what they do for a 
living.

I'm just doing the due diligence bit. Sending them a cease and desist probably 
won't lead to trouble. They'll probably walk away from a stupidly long domain 
name like that. I just wish that we had our ducks in a row from a "trademark 
license agreements with existing friendly entities" point of view. You guys 
do whatever you think best.

On Saturday 02 April 2005 09:27 pm, Bruce Perens wrote:
> Yes. FROM US. It's time to stop being fearful little pansies about this.
> While we whine and quake "Ooooh, somebody could sue us, oh no oh no oh
> no" we are in significant danger of creating an estoppel that will allow
> anyone to use the Debian trademark for anything.
>
> It is time to defend what is ours.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: debian domains

[Ean Schuessler]

We've been over this many times but just to be sure. Understand that sending a 
cease and desist can lead to litigation. One move from an opposing party 
would be to file suit in their location to establish jurisdiction that favors 
them. If we fail to answer that lawsuit we may be subject to a summary 
judgement and an award of damages. Answering the lawsuit might require us 
putting legal staff on the ground in someplace other than New York.

Understanding all of these things let's just make sure we go into these 
disputes with our eyes open. We either need to start being a *lot* more 
assertive about how the mark is enforced or a *lot* less assertive. Having a 
half-baked position is just going to lead to a position that is difficult to 
defend.

I am not a lawyer but this was my lawyer's opinion at the time I was involved 
in SPI.

On Friday 01 April 2005 02:35 pm, Jimmy Kaplowitz wrote:
> On Fri, Apr 01, 2005 at 10:46:25AM -0600, John Goerzen wrote:
> > I don't really know myself what the procedures are, but I'm CCing the
> > trademark list on this for their feedback.
>
> I am not a trademark lawyer or otherwise especially knowledgeable, but
> I'd imagine that a C&D followed if necessary by an ICANN UDRP proceeding
> would be the way to go. I await the trademark committee's input.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Small teams and other platform positions...

[Ean Schuessler]

On Sunday 27 March 2005 02:10 pm, Jaldhar H. Vyas wrote:
> Employees maybe not, but the majority of the work in Debian is done by
> people who probably spend 20+ hours a week on it and if that's not
> professional it certainly isn't what I'd call amateur either.
>
> Then we have many DDs who just basically react to bugs in their packages
> but otherwise don't really pay much attention to project matters.
>
> It seems rather pointless to hobble the first class just to cater to the
> second class and equally pointless to make the second class have to jump
> through hoops just because the first class can.

I'm not sure we are working with the same definitions of first and second 
class. I am talking about the difference between developers who can fly to 
several meetings a year and developers who cannot. 

> Well, it's related because as you can tell, I think trying to keep Debian
> the way it used to be is a dead end.  So the task becomes one of triage.
> How can we preserve all the good things such as democracy and openness in
> the new order?  I don't claim to have all the answers but I think this is
> a promising avenue for discussion.

In your mind how did Debian "use to be" and what has changed now?

> Yes there should be accessible documentation for what all the teams are
> upto and electronic systems could automate a lot of that. But eventually
> someone has to monitor the electronic systems and then we are right back
> to square one.  Only those with an inordinate amount of time will be able
> monitor everything.  Those without time will have to choose the particular
> bits they are informed about and will be at sea and unhelpful on the bits
> they don't know about.

My point is that you can monitor an electronic system *remotely* which is much 
easier for someone who can't fly to 3 or 4 strategic Debian business meetings 
a year.

> Come on let's be realistic now.  There's no guarantee but people _are_
> nice at face-to-face meetings.

Now, why don't you be realistic? Physical meetings are not a silver bullet for 
making people play nicely together. Most disagreements have some 
philosophical basis that is orthogonal to the communications medium.

> You missed the low-intensity part.  In fact it is basically the idea
> behind the US consitutions systems of checks and balances.  Or
> alternatively look at the Mafia's system which by "organizing"  crime
> actually substantially reduced the amount of killing and risk to innocent
> bystanders.  Yet the tribal nature of the Mafia family prevented the
> "commission" from degenerating into a bureaucracy -- which is just as
> inimical to liberty as anarchy.

Petty street crime is "low intensity" when compared with a full-scale war but 
I think the analogies are not serving us. If you are saying that an 
equilibrium of competing small organizations is the most free and efficient 
system then I think we agree. One key is to avoid the creation of oligopilies 
or monopolies. That is exactly why I'm against these physical meetings for 
decision making.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Small teams and other platform positions...

[Ean Schuessler]

On Friday 25 March 2005 8:50 pm, Steve Langasek wrote:
> That would be nice.  Which did you just do?  What makes a cabal -- a group
> of people meeting in person to sort out a problem, or a group of people
> making noise about the fact that people met in person to work on problems?
>
> The leap from "team" to "clique" boggles my mind.  The Vancouver meeting
> was essentially a meeting of the release team and the ftp team to discuss
> issues of common concern within areas of shared interest.  What makes it a
> clique -- the fact that these are the people on the teams doing the work,
> or the fact that we got together to work most effectively as a team in
> person?

I believe that I focused on discrete systems. I stated the somewhat obvious 
fact that these meetings are not something everyone can participate in. The 
criteria for participation shifts radically away from the egalitarian 
approach that built Free Software.

Would the next logical step be to locate members of the "critical team" in the 
same office? That would maximize the efficiencies.

I'm simply suggesting that from a leadership perspective we should be focused 
on electronic methods to improve our ability to cooperate. Physical meetings 
are fine, but not as a method for day-to-day operations. IMHO.

> Your post was which of these?

I'm a one-man cabal, so everything I say should be regarded as propaganda.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Small teams and other platform positions...

[Ean Schuessler]

On Friday 25 March 2005 5:49 pm, Jaldhar H. Vyas wrote:
> We already have a two class society.  (But TINC...yet)

http://tinc.debian.net/

> >. Create several "key gatherings" a year and only a "professional
> >  Debianer"  will be able to keep up.
>
> This is already the case even with (or probably because of) electronic
> communication.

I disagree. The bulk of work in Debian is not done by employees of 
professional Debian service companies that regularly attend required events.

> Instead we should recognize and formalize the reality of these two
> classes.  Being a "second class citizen" DD ought not to be a stigma but a
> simple recognition of how much one is actually able to contribute.

See above.

> It should be easy for people to jump into Debian for a few months and jump
> out.  Maybe they could do it repeatedly if they felt like it.  The
> structure to do this would involve both electronic and real life bits.

Agreed. Seems like a different topic of discussion.

> Face-to-face meetings provide higher bandwidth for discussions and people
> are less likely to flame or mistrust those have actually talked to and
> socialized with.  (And reducing flames would in itself do wonders for
> Debian efficiency.)

I agree that there are advantages. I also think face-to-face meetings should 
be held for social purposes. I assert that core Debian "business processes" 
should always center around cooperative electronic mechanisms that are 
publicly archived for reasons of accessibility, transparency, repeatability 
and "fairness". Mailing lists have a flame problem, the incoming queue does 
not. The fact that mailinglists have flames does not undermine the argument 
that electronic systems can be more efficient than expensive physical 
meetings.

There is also no guarantee that people will be nice at face-to-face meetings. 
There is even the possibility that some motivated party (ie. Unabomber++) 
might take it on themselves to blow a DebConf to kingdom come.

> Well I happen to believe constant low-intensity warfare between small,
> mutually suspicious tribes is the optimum environment for liberty but
> that's another discussion.

Sounds more like a recipe for being mugged repeatedly by street gangs and 
hiding fearfully in your house. Might even throw a nice raping in there for 
good measure. I hear that's popular with lawless warlord types.

-- 
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Small teams and other platform positions...

[Ean Schuessler]

I sent this to debian-vote initially since it is about platforms. Maybe 
discussion belongs in -project.



The Vancouver Prospectus, SCUD and "small teams" have given me pause for
thought. On the surface, it seems that there cannot be much wrong with
Debianers gathering together physically to talk and make decisions about the
direction of the operating system. I personally had the good fortune to
attend DebConf in Puerto Alegre and very much enjoyed meeting people, having
drinks and all the other fine things that come from face-to-face meetings.
Without a doubt, communication is much more fluid and productive in such a
context.

However, I have grave concerns about placing emphasis on face-to-face
 meetings as a methodology for moving the project forward. Could we
 accidentally create a "two class" society in the process? What will happen
 if we divide Debian into a group of those who can attend these meetings and
 those who cannot?

Taking time off from work and traveling to a DebConf is a significant
investment. For many Debianers (the majority, perhaps) this is an investment
that is out of their reach or requires giving up a "normal" vacation. Create
several "key gatherings" a year and only a "professional Debianer"  will be
able to keep up. You will either have to be independently wealthy or work for
an organization with some direct financial interest in Debian. I didn't sign
up for that. I could have run my business on Red Hat long ago. I want to
"share the software" on a level playing field.

We should focus our energies on electronic infrastructures. Tools such as the
"testing" distribution. Electronic tools are accessable by everyone- whether
they can walk well, can afford to fly or are good public speakers. We should
design systems using tools that are equally accessible. Mailinglists, wikis
and the usual fare should never be replaced with isolated face-to-face
meetings sponsored by commercial vendors. Building concensus via the net *is*
the revolutionary part of Debian. Face-to-face meetings have been around for
thousands of years. They aren't new. They may be fun, but they lead to
trouble.

Automated systems enforce quality policies in a uniform way without getting
frustrated, flaming people or retiring. You can't code favoritism into an
electronic tool without it being plainly visible to the trained eye. Accounts
that get special treatment, or have special capabilities, will be easy to
spot and will require explanation. Certain users will always require "special
powers" but in a social system influence becomes a matter of fuzzy logic
rather than discrete fact.

It is fun to meet in person. We should have big parties, big dinners, chances
to get to know each other, make friends and have a drink. But let's try to
make sure that attending such meetings never become a requirement for
participation. That will kill something central to what we are.

The world of politics between humans is well explored. It runs your
 government and your business. I put it to you that "small groups" doesn't
 add up to "loving relationships". In general, it leads to war. History tells
 this story again and again. I hope we can focus our group on discrete
 systems instead of cliques and cabals. With code, even the most antisocial
 person can distill good intentions into a tireless and helpful servant.
 Humans will always be subject to their personal failings and tantrums. Let's
 remember to be lazy programmers and leave everything we can to machines.

When you vote, remember, code is more important than commercials.

--
Ean Schuessler, CTO
[EMAIL PROTECTED]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Annual report.

[Ean Schuessler]

One of my responsibilities as SPI President was to provide an annual report of 
SPI's operations for the year. I have not been able to obtain sufficient 
information to prepare such a report. The only details I have in my personal 
possession are the results from processing the backlog of SPI financial 
information.

With the permission of John Goerzen I have delivered the information I have to 
the new SPI board. They will prepare a report when the past Treasurer and 
other officers have provided reports on their activities.

Re: Idea: debian representative @ conferences

[Ean Schuessler]

Barring our lead representative from speaking at public functions seems 
counter productive to me. If you have a problem with a DPL who just goes to 
conferences there is a simple solution. Don't vote for that person again.

On Saturday 31 July 2004 11:03 am, David N. Welton wrote:
> I had a random thought: why not institute a rule/program that only
> past Debian leaders may speak at conferences (except for debconf)?

--
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com

A few comments.

[Ean Schuessler]

Some of you have noticed that I did not attempt to renew my position in SPI. I 
don't want anyone to take this the wrong way so I'm dropping a line to 
annouce my position and intentions.

I'm still 100% with Debian. I haven't given up on the idea that a community 
operating system can give the proprietary boys hell. I'm still using Debian 
as the base for my business and I don't see that changing in the near future. 
What I am giving up on, for the time being, is changing the attitudes and 
lack of process in SPI.

Those words hurt and some people will take issue with them. That's fine. I'm a 
big boy and I'm ready to go to bat. I found it completely impossible to push 
SPI in a credible and useful direction. Anyone who thinks I didn't try hard 
enough has a flame war with their name on it. Come and get it.

I'm a professional. I deliver value for significant organizations every day 
and I do it with Free Software. I haven't made a place for myself as some 
sort of "community spokesman" and I have no intention to. I'm just another 
guy, like you, who is trying to make it day by day running a business. Like 
you, I want to see Free Software succeed for the most basic reasons. I use 
it. I depend on it. It has to succeed so that I can succeed along with it.

I don't have the ability or personaility to make a difference in SPI. Maybe it 
is personal politics or a misguided mission. I'm not sure. I tried, and tried 
as hard as I could, to make a difference. I failed.

I was able to inform a few of our donors about our inability to process their 
checks. I was able to bring our lack of professionalism to your attention. 
That wasn't enough. I was not able to make a lasting change. The culture and 
status quo stood in my way of making a difference.

It's not over.

We have some great new faces coming on board. Bdale is a completely solid guy 
who has a sterling reputation with a strong and moral corporation of 
significance. I hold some real hope that he will be able to inact a change. 
Branden is also a good guy with a lot of heart. Sometimes his actions don't 
measure up to his words (and I'll take that straight to the mat with you 
Branden) but I have no doubt that he wants to do good.  We need to watch SPI 
closely and hold a strong rule to its actions.

I question SPI's integrity. It has become a paper crown that people wear to 
prop themselves up. It lacks muscle and dedication. I have the stripes to 
pull that card. I will and I do. Hopefully that can change.

Debian is more important than SPI and every Debianer needs to watch in the 
coming months to take their measure of whether SPI is helping us achieve our 
goals or holding us back . If change cannot be affected from within SPI then 
we should do whatever it takes to move the project forward.

None of this is meant to cast a dark cloud on those who tried to make SPI 
work. If the experiment is deemed a failure then it is a failure of approach 
and technique but not of spirit. We will debug the code and the system will 
operate. One way or another, one day or another.

Faithfully yours in happy hacking,
~Ean

ps. I would like to thank Wichert Ackerman for the fine work he has done with 
SPI's web infrastructure. He may not have always responded to my email but he 
has done more than anyone else to make SPI presentable on-line.

--
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com

Re: GNU Hurd and Linux

[Ean Schuessler]

Yes. We will indeed be phasing out Linux support when Hurd is ready. We plan 
to do this in tandem to our switchover to 100% photon based computing cores 
and the new GNUeron Hallucinatronic machine-brain interface. Some people 
claim this deadline is not reachable by 2012. The Mayan lunar production 
calendar shows the Space Brothers will return for code review and world 
destruction around that time.

I'd ask RMS or the Catepillar from Beyond the Looking Glass if you are looking 
for a more deterministic answer.

+1 Schuessler Troll!

On Saturday 03 July 2004 5:47 pm, James Thayer wrote:
> Once GNU Hurd is ready for production use, will you still support Linux
> versions of Debian, or will GNU Hurd be the only kernel Debian supports?
> That is, will you support both?

On the uselessness of Debian trademarks.

[Ean Schuessler]

I've been having some discussions with Chris Rourk (SPI counsel) lately about 
Debian trademarks and his points are worth discussing. His opinion is that 
Debian would be best served by abandoning its marks and purposefully making 
the term "Debian" generic. There are some clear benefits.

Programmers (like myself) try to map our perceptions of systems we know and 
love onto others that have little to do with computation. Law is probably one 
of the worst. We like to think of trademark law as something like firewall 
rules where we can say "this is ok, this isn't, except in this situation" and 
so forth. If you look at real trademarks this is not the case.

For instance, take Coke or Star Wars or anything of that caliber. You will 
see, quite consistently, that the owners of these marks show absolutely no 
leniency in enforcement. You can be assured that making Coke t-shirts without 
permission will meet serious legal resistance. This enforcement is the only 
way that a trademark can truly be held. The owner must be the universal and 
final arbitrator of use and must show that use is carefully monitored and 
enforced.

With the Debian trademark we want use that is almost entirely unenforced 
except for a few particular (and somewhat poorly defined) situations. This 
policy will put us in a difficult position if we have to litigate. The 
defendant will put forth the argument that there is no clear definition of 
proper use and claim that our mark is generic. Our only alternative is to 
religiously shut down everyone who is using the word Debian without our 
explicit permission. That isn't very Debian. Why not just cut to the chase?

I'm not sure if Chris is right, but I see the logic in his reasoning. If 
anyone can put this email in front of any attorneys, I would be very curious 
to hear their thoughts.

E
 
--
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com

Re: Please Join SPI (was Re: The Sky is Not Falling)

[Ean Schuessler]

Just so. It also isn't just a matter of payment. It would be wonderful if the 
Internet and the things that happened on it were not subject to normal human 
law but that just isn't the case. Ultimately, everything that Debian does is 
done by people and those people are subject to the laws of their nations.

If Debianers try to make the law go away by ignoring it then the inevitable 
result will be some tragic miscarriage of justice that Debian is grossly 
unprepared for. Cryptography law (BXA) is certainly a major concern.

The fact that SPI is a US corporation is actually a convenience. The United 
States has unparralleled resources for making its will felt anywhere in the 
world. Solving legal problems here is probably a good first step towards 
solving them in many other places. Sad, but true.

(I'm going to continue this kind of conversation on debian-project)

On Thursday 06 May 2004 03:41 am, Tomas Pospisek's Mailing Lists wrote:
> I guess someone needs to pay for some of Debian's infrastructure,
> assumed that no sponsor would be giving it to Debian for free. That
> needs to be *some* entity. The fact that it's an US one is secondary.
 
--
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com

Re: Re: Kill the DPL! (Elections are almost over)

[Ean Schuessler]

> Clearly, we should make him SPI president!

Being the SPI President is a much uglier responsibility, as you shall soon 
learn.

-- 
Ean Schuessler, CTO
Brainfood, Inc.
http://www.brainfood.com

Re: Re: Kill the DPL! (Elections are almost over)

[Ean Schuessler]

No, no. David, you are missing the subtle genius of my plan.

Being awarded the DPL wouldn't make you responsible for doing anything, it 
would recognize what you have already done.

This whole silly notion that the DPL represents the opinion of Debianers can 
just go away. There is only real way to ask Debian's opinion is a GR. Debian 
is fluid and organic. People package things because they want to, not because 
a DPL consulted his cabinet and ordered them to.

My good friend and fellow cabal member Bruce Perens, for instance, speaks at 
far more conferences and talks with many more executives than any DPL ever 
will. He should just be a member of the "Debian Speakers" team, any of whom 
can be approached for your conference, formal dinner or Baht Mitzvah.

Cheers,
E

David Moreno Garza <[EMAIL PROTECTED]> wrote:
> Well, maybe the most active 'debianer' would do more, if (s)he is not
> DPL. Attending conferences and Debian stuff would be a decrease on the
> efficiency.
> 
> Besides, you cannot force anybody to be someone or something: If he
> wants to be DPL, he will postulate and show work which endorse it.

-- 
Ean Schuessler, President of Diabolical Sneakiness
Software in the Interest of the Debian Cabal, Inc.
http://www.spi-inc.org

A sensible plan for non-free

[Ean Schuessler]

-BEGIN PGP SIGNED MESSAGE-

The Social Contract demands that we support users of non-free software. Debian
has always been grounded in realism and we have always understood that some
organizations may need to use systems on Debian that are not going to be
Free.

At the same time it has been clearly identified that non-free files are not
part of Debian. The people that created them refused to license them to the
community and the community has no obligation to do the work of spreading
their non-free software. We have always provided developers and distributors
who had an interest in non-free a way of getting to it but we have always
excluded it from distribution.

Since the time of the Social Contract's inception the growth of broadband and
the Internet has been astonishing. Today we see that the Debian servers are a
major form of distribution for non-free software. Clearly, that is not
acceptable.

Therefore, I propose the following:

Non-free and contrib should stay exactly where they are. They should be in the
current bug system and in every way, from a development point of view, they
should be dealt with in the way that we currently deal with them.

The change I suggest is that the non-free and contrib sections be protected by
certificate authentication. Certificates will be distributed to 3rd parties
who sign up as an official 3rd party distributor of the non-free and contrib
sections. All developers will also be issued a certificate for development
purposes. Beyond these groups no end user will be able to download non-free
or contrib software from a Debian controlled server.

All 3rd party distributors will execute an agreement with Debian indemnifying
Debian against damages that result from their distribution of software
retrieved from Debian servers. It will be up to these organizations to
establish a valid business model for their distributions and to take
responsibility for any legal mishaps that occur because of their actions.

This plan is precisely in line with current 3rd party CD distribution
policies. It simply reorganizes network distribution to follow a structure
similar to the well established physical distribution. Most importantly it
ends Debian's distribution of non-free without adversely impacting current
development procedure.

In the sense that these packages will no longer be available by direct
download I suggest that they be considered to "no longer be in the archive"
and in compliance with Proposal-0008. I also suggest that the legal agreement
drafted for network distribution deal with physical distribution and require
existing 3rd party physical distributors to execute the agreement.

I would like to hear opinions on whether this plan requires a further General
Resolution or whether it could be adopted as a methodology of fulfilling
Proposal-0008 and put into action by the DPL if the DPL is so inclined.

- --
Ean Schuessler, President
Software in the Public Interest, Inc.
http://www.spi-inc.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)

iQCVAwUBQFIou1p7Rmblcu9ZAQGLPgQAveJuiaMMG2TSPsDpZtI1KAChwEwsUZS+
YhoHal2i+K5cyEosuyQeS5LWi2BbiI7v3S5wlMlCgTRDW16LWz5/d4PoNji7DH2u
ftZpArXM/ECgjVtxod2WraJ1W2x19PTHuCkRoBeYs13XDchGLSaRBmwqgrid0xut
VjxBEh6m+V0=
=pYEO
-END PGP SIGNATURE-