Carlos Laviola asked,
"how many female developers
there are right now in debian, if any?"
An Thi-Nguyen Le replied that
she thought there were a few, although she herself was still in the process
of becoming one. She added,
"I can't see how
this matters all that much though. We're all just dudes who happen to work
on Debian."
Sean Perry felt that Debian was the
"epitomy of the all guys testosterone engineering groups"
and mentioned
"We fight, angle for superiority, and
generally act like animals fighting for dominancy"
as evidence. Diana
Galletly said at one point,
"I can't say I've
noticed many differences in attitude between debian-devel and my normal
social circle. But then, that's hardly surprising ;-)."
She added,
"Some women do want to be a part of Debian;
I'm one of them (although I'm shamefully lacking in time at the moment,
and Debian's not top of my priority list, I'm afraid)."

Elsewhere, Sean said,
"Open Source is for many people
about ego. "Look at what I did", or "I could write that better than they did".
This is a very male tendency."
He added,
"my
experience in the CS world is that women find hacking on minutiae because it
is fun quite boring actually. Most of them are more of the "does it work,
good enough". As I said, this is from my own college and work experience.
Men in computers seem willing to devote hours to trivial matters or work
hard and long while many bitch and complain. Few women in computers I have
met cared."

S.J. Black said,
"fellas don't have a copyright on
ego. There are a lot of women who, for various reasons, trade in it too -
but, like wizards (or sysadmins!), are subtle...and many have not learned
the value of the "direct approach" in their daily pursuits."
And
added,
"There are both guys and women who will sell
someone else down the river for their own ends. It's not a specifically
gender-based tendency, nor is it without its place. But it's not best-used
in general information exchange, nor is it all that helpful in the school
or the workplace on a daily basis."
And concluded:

It'd be a very cool thing to see more women getting into technical
anything...a good many don't for the simple reason that they've been raised
to believe it's not ladylike, or that they ought to be thinking more along
the lines of socially-related occupations, or artistic pursuits, or any
number of stupid and destructive beliefs about females in non-traditional
occupations/hobbies/ whatever.

The guys who want to see more of a balance between the genders in debian/
tech in general might want to let their sisters, girlfriends, moms, female
acquaintances know that they *can* learn to do tech stuff, that their company
in such pursuits is welcome. Encourage confidence in ability.

Show patience when they learn. Women might try to get each other
turned onto Open Source projects, or even collaborate to get some new ones
going. Whatever. It boils down to interest, and to a welcome environment in
which to exercise that interest.

Later, S.J. asked,
"I wonder if more women code in
Java than in C/C++? Or whether VRML is the language of choice?"
Jan
Martin Mathiassen replied,
"women code in
java/c/c++, men code in assembler (and cry a lot). :)"
S.J. replied:

See, and i can tell you from personal experience that most women are more
inclined to boom obscenities at their non-compiling code than to cry. But
then, even when we do venture into doing assembler, we instinctively know that
any machine that understands and obeys such language is impervious to tears.
8)

We, however, are not. <g>

Elsewhere, someone mentioned that his "partner" used 'mh' for email and
'vi' for editing. Branden Robinson replied,
"No
wonder this guy couldn't get around to packaging perl 5.6. His sex life must
be great, with them moaning ed scripts at each other and quoting RFC's during
orgasms..."
Diana replied,
"Funnily enough,
geek and girlgeek tend to leave geekiness behind when in bed ... at least,
they do round here (damn, I'm not on #chiark, perhaps I ought to censor this
email .... ;-))"

At one point, Julian Stoev said,
"I am currently
trying to show Debian to my wife. It works slowly by slowly. But I really
can't imagine she is going to read 10 mail lists. This is a problem,
because I got most of my experince browsing Internet and asking on mail
lists. I am afraid I will have a problem to explain her, that this is the
best way. She reads the book, but IMHO she will have to ask people when
she does not understand something more complicated. Maybe this is something
specific to males?"

Magni Onsøien replied,
"I am currently trying
to show Debian to my brother. It works slowly by slowly. But I really can't
imagine he is going to read 10 mail lists. This is a problem, because I got
most of my experince browsing Internet and asking on mail lists. I am afraid
I will have a problem to explain him, that this is the best way. He reads the
book, but IMHO he will have to ask people when he does not understand something
more complicated. Maybe this is something specific to sisters?"

DebianHELP's name is self-explanatory and the site is a slash-like
format designed to feature helpful articles/advice on running Debian
GNU/Linux, and for people to trade tips/carry on conversations to
solve problems. For a more verbose idea of the site, read <http://www.debianhelp.org/about.php>.

The purpose of this message is to solicit articles and helpful advice
for the web site.

These articles will hopefully be more likely to be read compared to some
of the gems which come through the mailing lists and are tucked away in the
list archives.

What kind of articles are needed? Everything! These don't have to be
in-depth articles, but anything that shares your experience and would help
a rookie Debian user. For example, here are some thoughts:

How about something explaining the mail system? Explain MTAs, MUAs,
the role of procmail. Or how about giving some explanations for typical
setups and how a newbie would configure their system using "eximconfig"?

Have you examined all of the various packages of a certain type of program
(e.g. mail clients or proxy servers or mailing list managers or ...) lately
while choosing which one was best for you? Why not write up a short summary of
your experiences and save someone else the trouble of doing what you did?

How about giving an overview of the various states/stages of a Debian
release -- what is unstable, frozen, stable, and why or why not someone
should run a particular version?

How about explaining common security measures that a typical newbie
will overlook? Or typical measures that you take for extra security when
installing a new Debian system?

Why not tackle a small HOW-TO on how to create a Debian kernel with
Debian's own tools?

How about explaining some of the many tips that experienced Debian users
know but that newbies take a while to learn? For example, how to make a new
startup script with update-rc.d or what /var/lib/dpkg/info/*.list is for?

Can you think of any other ideas? Go for it!

It doesn't matter what your level of expertise is -- believe me,
I'm sure there's knowledge you have that you can write up and share
which would benefit others. If you feel the same way, drop by <http://www.debianhelp.org> and post
an article and share the wealth.

Jordi Mallach and others pointed out that this was much the same as
the http://www.debianplanet.org
project. Some folks felt this was unnecessary duplication of effort, while
others felt there was nothing wrong with having multiple Debian-related
forums. But there was not much discussion at all.

Paul Martin reported,
"I made an upload to master
on Friday, and I haven't had the usual "files moved to othermachine" email
confirmations, and the files haven't appeared in incoming. Has something
got stuck, or is it just me?"
James Troup explained that the relevant
install daemon hadn't been restarted when 'master' had been rebooted. Mark
Brown and Petr Cech also added that developers should upload to 'auric' instead
of 'master' anyway, since uploading to 'master' would just go from 'master'
to 'samosa' to 'auric', giving the same result after more indirection.

I would like two additional BTS tags:
<dl>
<dt>doc</dt>
<dd>
bug is a documentation bug
</dd>
<dt>fixed-in-next-version</dt>
<dd>
bug has been fixed in the maintainer sources, but that isn't
yet uploaded; this is very useful for packages like
boot-floppies where there are many people working from CVS
for the next version -- it lets them know not to both fixing
a given bug.
</dd>

There was a short discussion about the length of the
tag name fixed-in-next-version. Using fixed
was suggested and rejected, since there was already such a
tag, for items that bugs that were fixed by e.g. an NMU.
The term pending met with some approval.

There was some confusion over the difference between
a tag and a severity.
Manoj Srivastava, voiced his concerns:

The concern I have is this: Suppose someone reports a
grave/important bug; and I fix it in my CVS sources; can I then just
change the severity to fixed-in-next-version? (or pending, or
whatever).

But the release management process is strongly tied to the
severity levels grave/critical/important; and the pending severity
should not be a loophole/end run around that.

In other wirds, one should not be able to downgrade high
severity level bug reports just because we have it fixed on some
random machine out in the known universe.

In fact, tags and severities are orthogonal, so
adding a pending tag does not get around the
release management.
As Julian Gilbey said, a bug with a pending tag
"
retains its severity, but is noted that it is fixed in
CVS or wherever.
"
Josip Rodin pointed Manoj at
http://www.debian.org/Bugs/Developer.en.html#tags (http://www.debian.org/Bugs/Developer.en.html#tags)
.

Norbert Veber was confused, and asked,
"
How does dpkg-buildpackage determine the source version? I dont know why,
but it keeps thinking that my package is debian native, and doesnt produce a
package.orig.tar.gz or a diff, instead it just builds it as a debian native
package..
"

Adam Heath suggested looking at the version string in debian/changelog,
"
If it doesn't contain a -, then it is a native package.
"
In Norbert's package, however, the version did have a dash.

Adrian Bunk came through with the answer,
"
Is there a ../radiusd-cistron_1.6.3.orig.tar.gz? If not that's the reason
why dpkg-buildpackage think's it's a native package.
"

It later emerged that Norbert had the original source in a file
named ../radiusd-cistron-1.6.3.tar.gz. He thought this was sufficient
because it had worked on another package that he debianized using
dh_make. What escaped his notice, however, is that
dh_make did the renaming of ../foo-x.y.z.tar.gz to
../foo_x.y.z.orig.tar.gz.

(ed. [Steve Robbins]
The moral of the story is: read and re-read the packaging
manual. I got caught by the same mistake recently!
)