Now look guys, I don't want to deal with crap like this. Grow up, or release 
your maintenance positions to me. You can't maintain these packages or help 
with their development unless you're willing to get involved. Step up, or step 
down, it's that simple.

As I say below, I don't want to be angry, but a little give and take, rather 
than you guys breaking every single communication channel I try to open is the 
only way I can start to fix things. That's a fact of communication, it's a two 
way process that requires a common transport medium, and I am NOT willing to be 
a manual email hub just because you're being resistant, I'm putting enough time 
in trying to arbitrate already. Sadly, it's likely that if this warning is not 
received with a mature view, then this effort may fail before it's even really 
begun, in which case, I'll be dealing with the SUSE folks only, as they seem to 
be the only ones not nit-picking over communications, methods and mediums; 
instead they're working with me, promptly, and providing plenty of help, even 
infrastructure. They're on my gold list. Mails like below push you toward the 
.... list, for exceedingly obvious reasons.

Finally, if you don't agree, please sleep on it, maybe for a week, then come 
back. If you still feel raw about it, then like I say, give up your maintenance 
positions, and walk away. I'm not having these arguments *again*, as neither of 
you can provide a real rationale behind your resistance.

Current open channels:

Direct email - please don't use this for design input, as I need everyone to be 
on the same channel for that.
Mailing list - sign up, or step down.
Wiki - to keep a central record of longer term decisions, avoiding bikeshed 
discussion and so on. I want this to be a summary of the facts. I could move 
this elsewhere, but I'd have to sign up, and so would the rest of the rubygems 
core team (who are already signed up on github, all of them, for a long time 
now).
IRC - #rubygems and talking to me directly on freenode (raggi) is fine, 
although once again, this is purely for a realtime channel, facts need to be 
persisted to the wiki.

Now I can open up more wiki's at other places (but at least one of us is going 
to have to give and sign up for anywhere else that's spam resistant). I can 
open up more IRC channels, but that's not persistent, and not suitable for the 
long term stuff. I can provide access to Campfire, or Talkerapp, or Teamvox, or 
etherpad, or a gist, or rubyforge wikis, or, or, or, or. They all have 
something in common, someone out of the lot of you, or more, is going to have 
to pull a finger out and sign up.

I made a proactive set of (sane) choices based on (good) evidence for what is 
(commonly) available to our (main) userbase and (all) our maintainers. You're 
with us, or not. If not, once again, please step down.

I'm willing to listen to rational arguments against my choices, but not being 
signed up to the rubygems ML when you're responsible for maintaining ports of 
rubygems packages as non-rubygems or not signing up to github because you're 
"not sure of the ramifications" are both truly pathetic reasons, and if you 
feel strongly about those two things you really shouldn't be holding any 
maintenance positions on these projects, because not doing so leaves you 
without suitable infrastructure to do so. More than that it should be against 
maintenance policies of distributions to be so disconnected and irresponsible.


On 31 Mar 2010, at 06:36, Lucas Nussbaum wrote:

> FYI. It might be better to keep the discussion off-list, then.
> 
> - Lucas

NO. You're involved with rubygems development, whether you like to admit it or 
not, you need to be on that ML. I'd dig up Debian policies about responsible 
administration of packages, but you guys are supposed to know those already.

On 31 Mar 2010, at 10:02, Hugh Sasse wrote:
> I can't seem to edit this without a github account.  I've not
> worked out all the ramifications of that yet, so not chosen a
> package for github.  I know Wikis can't be totally open because
> of what happened to RubyGarden.  Hopefully there's a way around
> this. I don't know what the Venn diagram would look like for 
> wanted contributors and those that have github accounts.

I've counted to 10.

I've tried really hard to squash the feeling that you're nit-picking.

I've tried to understand a rational reason of where you're coming from.

I don't get it, and whilst I agree with everything else you've said in the 
mail, my reply to this is presently "grow up".

Security is no excuse.

Mail volume is no excuse.

Professionalism is no excuse.

Cost is no excuse (it's free).

Remember please: HELP ME TO HELP YOU. There are limits to my time and effort on 
this and discussing philosophical lies about signing up for accounts on MASSIVE 
well known services is NOT what I am here for.

http://github.com/blog/620-committing-like-crazy

They handle 10x more open source commits per day than SourceForge, so like I 
say, grow up, sign up, and lets get down to some /real work/.

Enough said, I'm very sorry if you find this mail upsetting, but you hit a bad 
button here, as the Debian folks are also currently trying to make me move off 
the rubygems ML too, because they don't want to sign up. It's PATHETIC, people 
are nit picking at stuff that's totally irrelevant, and it seems that they're 
either insane, evangelists, or just trying to wind me up and demoralise my 
effort to really fix this stuff. I'm here to fix rubygems, not people 
attitudes. Maturity and professionalism from here on in please, I don't want to 
be angry anymore. And YES I've been asked to sign up to places plenty of times 
in professional environments, and I don't give clients hell over it, it's bad 
for business and bad for karma.

http://help.github.com/terms/
http://help.github.com/privacy/

Questions to: supp...@github.com


_______________________________________________
Rubygems-developers mailing list
http://rubyforge.org/projects/rubygems
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers

Reply via email to