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
···
--
--------
David Pollak's Ruby Playground
http://dppruby.com
what about building it in .NET ?
sorry, just had to....
Stuart
···
On 6/23/06, David Pollak <pollak@gmail.com> 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.
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
--
--------
David Pollak's Ruby Playground
http://dppruby.com
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
···
On 6/23/06, David Pollak <pollak@gmail.com> wrote:
[snip] 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 Jun 23, 2006, at 11:45 AM, David Pollak 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.
[snip, cost/benefit details]
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?
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, ...
···
On Jun 23, 2006, at 8:45 AM, David Pollak wrote:
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.
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?
--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant
http://trackmap.robotcoop.com
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 23-jun-2006, at 17:45, David Pollak 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.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
sender: "Dark Ambient" date: "Sat, Jun 24, 2006 at 12:54:29AM +0900" <<<EOQ
what about building it in .NET ?
sorry, just had to....
Without disrespect, why?
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? 
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
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...
Cheers,
Alex
It's running a slightly customized version of GForge:
http://gforge.org/
Yours,
Tom
···
On Sat, 2006-06-24 at 04:16 +0900, Mat Schaffer 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.
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 Sat, 2006-06-24 at 06:28 +0900, Eric Hodel wrote:
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, ...
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 Jun 23, 2006, at 22:28, Eric Hodel wrote:
On Jun 23, 2006, at 8:45 AM, David Pollak wrote:
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.
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, ...
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!
···
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?
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 Thomas' 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 Britt
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - 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
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
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 Britt
"In Ruby, no one cares who your parents were, all they care
about is if you know what you are talking about."
- Logan Capaldo
It was meant as humor and sarcasm. I was not being serious.
Stuart
···
On 6/23/06, Alexandru E. Ungur <alexandru@globalterrasoft.ro> wrote:
>>> sender: "Dark Ambient" date: "Sat, Jun 24, 2006 at 12:54:29AM +0900" <<<EOQ
> what about building it in .NET ?
>
>
> sorry, just had to....
Without disrespect, why?
Cheers,
Alex
Ryan Davis 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!
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 ...")
···
On Jun 23, 2006, at 4:52 PM, Julian 'Julik' Tarkhanov wrote:
--
James Britt
http://www.ruby-doc.org - Ruby Help & Documentation
Ruby Code & Style - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.30secondrule.com - Building Better Tools
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 24-jun-2006, at 18:32, James Britt wrote:
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 Thomas' talk on application deployment, at RailsConf 2006.
Just a moment...
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.
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
James Britt wrote:
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? 
···
--
M. Edward (Ed) Borasky
http://linuxcapacityplanning.com
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.
···
On 24-jun-2006, at 8:22, James Britt wrote:
Ryan Davis wrote:
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!
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 ...")
--
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl
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
···
On 6/23/06, James Britt <james.britt@gmail.com> wrote:
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
> 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'
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.
···
On Jun 24, 2006, at 11:39 AM, Julian 'Julik' Tarkhanov wrote: