RubyForge in Ruby?

Folks,

Not to stir up a hornet’s nest or anything… but…

It strikes me as a tad odd that RubyForge runs on a PHP code base. I
understand the reasons for using an existing tool, but it strikes me
that
Ruby and Rails is possibly the very best way known to man to build a
complex, powerful web site.

I know it’s also a large time suck to build a developer’s project
management
and code management web site… but imagine building the next generation
(oh
no, buzzwords) Web 2.0 developer site in Ruby. It would be a great way
to
demonstrate that Ruby can be used to build very complex projects that
scale
well (37 Signals is an excellent example, but more is better.) Imagine
a
‘show source’ link on each page that would show someone how the page was
created so that they see the beauty of R & R code. Think of the benefit
of
a Ruby-based development and project management tool that can be used in
businesses rather than bugzilla, etc.

Okay, I know… I’ve been hitting my glass pipe a little too much.
However,
when my SoC mentoring gig ends in a few months, I’ll have 6 hours per
week
to contribute to an RForge style project.

Please let me know your thoughts. Am I taking drugs or would this be
the
kind of project we could build in order to build excitement?

Thanks,

David

what about building it in .NET ?
:slight_smile:

sorry, just had to…

Stuart

On 6/23/06, David P. [email protected] wrote:

[snip] would this be the
kind of project we could build in order to build excitement?

IMO, there’s already quite a bit of excitement in the Ruby community.

Are you seeing any current problems with RubyForge that you think
would be fixed by a RoR rewrite? So far I haven’t uploaded any
projects but as a casual user RubyForge seems to work very well.

—John

sender: “Dark A.” date: “Sat, Jun 24, 2006 at 12:54:29AM +0900” <<<EOQ
what about building it in .NET ?
:slight_smile:

sorry, just had to…
Without disrespect, why? :slight_smile:

The man had a very good point: why not have a Ruby related site built on
Ruby? I don’t see the PHP site running on Perl (or to be more accurate
in the comparison, I don’t see pear.php.net or phpclasses.org running on
Perl either). PHP site is running on PHP, I even saw Lisp sites running
on Lisp, or ASP sites running on ASP (though they’d better be running in
PHP… :D).
There’s nothing wrong with the current RubyForge, don’t get me wrong.
It’s doing an excellent job. But if not even the Ruby sites are being
built
on Ruby, to ‘show off’ the qualities of Ruby, what sites do we expect to
run in it? The PHP site? :smiley:

Bottom line, proof of concepts are nice. I remember seeing a Lisp site
run on Lisp. Was quite nice. I actually was double impressed: first by
the info there, but also by seeing Lisp at work, and it worked nice…

How about this: those that think that RubyForge could be rewritten in
Ruby and the resulting code would be cleaner and easier to maintain
and/or extend please raise your hand :slight_smile:
Ok, ok… was a trick question, I agree :))

Anyway, I personally would be impressed if, a new RubyForge would
be built on Ruby, by the Ruby comunity, by us all. We could have it
as a ‘distributed quiz’ :), as the quiz with that game was: everybody
takes a little piece, and we all build it together…

Those that think PHP is better suited for the task raise your hand…
:slight_smile:

Cheers,
Alex

Alexandru E. Ungur wrote:

How about this: those that think that RubyForge could be rewritten in
Ruby and the resulting code would be cleaner and easier to maintain
and/or extend please raise your hand :slight_smile:
Ok, ok… was a trick question, I agree :))

Is it? Because that’s pretty much how this would happen. Someone with
enough interest and enthusiasm opens a rubyforge project for ruforge or
rforge or whatever, writes some code, gets a proof-of-concept going, and
asks for help in getting it done.

The OSS version of ‘raise your hand’ is ‘commit some code’


James B.

“In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about.”

  • Logan C.

On 6/23/06, Alexandru E. Ungur [email protected] wrote:

sender: “Dark A.” date: “Sat, Jun 24, 2006 at 12:54:29AM +0900” <<<EOQ
what about building it in .NET ?
:slight_smile:

sorry, just had to…
Without disrespect, why? :slight_smile:

Cheers,
Alex

It was meant as humor and sarcasm. I was not being serious.
Stuart

On Jun 23, 2006, at 11:45 AM, David P. wrote:

Okay, I know… I’ve been hitting my glass pipe a little too much.
However,
when my SoC mentoring gig ends in a few months, I’ll have 6 hours
per week
to contribute to an RForge style project.

Please let me know your thoughts. Am I taking drugs or would this
be the
kind of project we could build in order to build excitement?

I’ll add my vote to this one. Is RubyForge running the sourceforge
code right now? Looks really similar.

If you could make a re-deployable OSS project management suite in
Ruby I’m sure RubyForge wouldn’t be your only customer. I’m sure a
lot of small/medium sized development shops would like such a thing
as well.
-Mat

On Sat, 2006-06-24 at 04:16 +0900, Mat S. wrote:

Please let me know your thoughts. Am I taking drugs or would this
be the
kind of project we could build in order to build excitement?

I’ll add my vote to this one. Is RubyForge running the sourceforge
code right now? Looks really similar.

It’s running a slightly customized version of GForge:

http://gforge.org/

Yours,

Tom

On Jun 23, 2006, at 8:45 AM, David P. wrote:

‘show source’ link on each page that would show someone how the
page was
created so that they see the beauty of R & R code. Think of the
benefit of
a Ruby-based development and project management tool that can be
used in
businesses rather than bugzilla, etc.

Please let me know your thoughts. Am I taking drugs or would this
be the
kind of project we could build in order to build excitement?

Lots of people use GForge and submit patches to GForge and make it
better. Writing an RForge would reduce the amount of developers
submitting patches, so Tom would have to fix bugs all by himself, or
hope somebody fixed them for him.

I don’t want to speak for Tom, but he’s got enough on his plate that
he shouldn’t need to be maintaining an in-development RForge.

In other words, a GForge clone will be a very hard project to build,
you have to integrate mailman, cvs, svn, a bug tracker, file
uploads, …


Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

On Jun 23, 2006, at 22:28, Eric H. wrote:

well (37 Signals is an excellent example, but more is better.)
be the
In other words, a GForge clone will be a very hard project to
build, you have to integrate mailman, cvs, svn, a bug tracker, file
uploads, …

My suggestion would be something to complement RubyForge rather than
something to replace it. In addition to the the other arguments, I’d
add the fact that while it sounds great to have websites about
language X implemented in language X, it’s beginning to remind me of
the golden oldie “has it been used for anything apart from its own
compiler yet?” The fact that a language can be used to write a
website just doesn’t seem that surprising anymore, and it’s extra
boring when the site is just a port-rewrite of an existing service in
another language.

So, rather than re-implementing all the stuff that Eric mentions,
what else could we add? Something I’d dearly like to see for the
Ruby world is an indication of which libraries modify core classes,
preferably with an indication of whether any two might be
incompatible w.r.t. their modifications.

The inverse is probably true as well - an indication in the core
classes of which libraries extend them could be very helpful when
you’re looking for a library that performs a specific task.

Even as part of a general replacement for RubyForge, attention to
Ruby-specific features such as those would make the project a lot
more interesting than if it were to simply be a reimplementation.

matthew smillie.

On Sat, 2006-06-24 at 06:28 +0900, Eric H. wrote:

uploads, …
So true.

Also, supporting a project like GForge would be rather painful. Take a
read through the user forums on gforge.org and imagine fielding all
those questions, many of which come from folks who aren’t too savvy with
Unix. I don’t envy Tim Perdue his job, and I can see why he sells
GForge support contracts.

Yours,

Tom

On Jun 23, 2006, at 4:52 PM, Julian ‘Julik’ Tarkhanov wrote:

Could we just have a normal gem/tarball publishing gateway with a
good Ruby API to it, using YAML postdata or such instead of the
simulated clicks on the forge site?

Red Flag! Red Flag!

Any time a nerd uses the word “just” I find a situation where the
problem hasn’t been fully thought out and it is trivialized to death.
This is why we (as a whole/on average) miss release dates time and
time again. “Oh, that’ll just take x & y to finish” – bzzzzt!

Ryan D. wrote:

Any time a nerd uses the word “just” I find a situation where the
problem hasn’t been fully thought out and it is trivialized to death.
This is why we (as a whole/on average) miss release dates time and time
again. “Oh, that’ll just take x & y to finish” – bzzzzt!

:slight_smile:

Replace “Could we just have …” with "I’m going to prototype … " and
see it it still sounds like a good idea.

(BTW, I can imagine how something like that might work, but for very
slippery values of @something, @that and @work. And a little voice
going, “Yeah, but …”)


James B.

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.30secondrule.com - Building Better Tools

On 23-jun-2006, at 17:45, David P. wrote:

Folks,

Not to stir up a hornet’s nest or anything… but…

It strikes me as a tad odd that RubyForge runs on a PHP code base. I
understand the reasons for using an existing tool, but it strikes
me that
Ruby and Rails is possibly the very best way known to man to build a
complex, powerful web site.

What strikes me is that we still have to resort to absolutely abysmal
hacks to publish releases a least semi-automatically,
that is doing rake release usually implies sending some wicked
manually encoded forms in base64 and breaks every other day.

Could we just have a normal gem/tarball publishing gateway with a
good Ruby API to it, using YAML postdata or such instead of the
simulated clicks on the forge site?

On 24-jun-2006, at 8:22, James B. wrote:

bzzzzt!

:slight_smile:

Replace “Could we just have …” with "I’m going to prototype … "
and see it it still sounds like a good idea.

(BTW, I can imagine how something like that might work, but for
very slippery values of @something, @that and @work. And a little
voice going, “Yeah, but …”)

I can try that in July, but I need to know how far Rubyforge deviates
from the standard GForge database schema.
Besides, for something as special as Rubyfogrge and gem distribution
I expect an obscene amount of political nitpicking. I already have
one project on me
which has that in great quantities and this is anything but pleasant
to “prototype” something with that in mind.

James B. wrote:

:slight_smile:

Replace “Could we just have …” with "I’m going to prototype … "
and see it it still sounds like a good idea.

(BTW, I can imagine how something like that might work, but for very
slippery values of @something, @that and @work. And a little voice
going, “Yeah, but …”)
Hmmm … why not something “more agile” than GForge? I’ve always been
overwhelmed by all the “features” in GForge. How many projects are big
enough to use them? For that matter, how many projects on RubyForge have
more than, say, three developers?

The closest I’ve seen to what I’d call an “agile” software project
management web app is Trac … but that’s in Python, right? :frowning:


M. Edward (Ed) Borasky

http://linuxcapacityplanning.com

On 6/23/06, James B. [email protected] wrote:

asks for help in getting it done.

The OSS version of ‘raise your hand’ is ‘commit some code’

Well, I am not going to write rforge as I got other stuff to waste my
time on.

However, it might be interesting to get some idea what parts are
already available and what parts would have to be written.

So what rforge should include? How these parts should look like? Are
they already available? Is what is available satisfying?

I’d guess that there has to be some cms integration, some sort of
issue tracking, one would want some email integration, some
documentation and code browsers, perhaps some forums and/or wiki.

Many of these could be useful for other projects as well.

Thanks

Michal

Julian ‘Julik’ Tarkhanov wrote:

Could we just have a normal gem/tarball publishing gateway with a good
Ruby API to it, using YAML postdata or such instead of the simulated
clicks on the forge site?

This brings to mind some comments I’ve read about Dave T.’ talk on
application deployment, at RailsConf 2006.

http://glu.ttono.us/articles/2006/06/23/dave-thomas-keynote

I have flashbacks of WAR files and EAR files and deployment
descriptions, none of which make me feel warm and fuzzy, even with the
idea of replacing XML with YAML.


James B.

http://www.ruby-doc.org - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://web2.0validator.com - We’re the Dot in Web 2.0

On 24-jun-2006, at 18:32, James B. wrote:

I have flashbacks of WAR files and EAR files and deployment
descriptions, none of which make me feel warm and fuzzy, even with
the idea of replacing XML with YAML.

I am talking about something completely different. What I am talking
about is making the release of a rubygem/tarball to rubyforge not
500% painful as it is now, because:

  1. you have to click ten forms in a row just to publish one gawddamn
    file
  2. your only option if you want to avoid the n. 1 is to write a
    script that clumsily simulates the No 1 and breaks every other minute.

Currently there are like 3 different Rake tasks for publishing gems
(all of them UNOFFICIAL) and I had problems with all of these.

On Jun 24, 2006, at 11:39 AM, Julian ‘Julik’ Tarkhanov wrote:

I am talking about something completely different. What I am
talking about is making the release of a rubygem/tarball to
rubyforge not 500% painful as it is now, because:

  1. you have to click ten forms in a row just to publish one
    gawddamn file
  2. your only option if you want to avoid the n. 1 is to write a
    script that clumsily simulates the No 1 and breaks every other minute.

Or you could quit being a drama-queen and be a bit more realistic.
Not counting login it takes exactly 1 form to create a new release
including uploading the file.

Currently there are like 3 different Rake tasks for publishing gems
(all of them UNOFFICIAL) and I had problems with all of these.

That has little (if anything) to do with rubyforge itself.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs