I just released version 1.0.2 of the rubyforge command line client. It sucks. We could do a lot better. In particular, we really need a real API for rubyforge, not a web scraper. It is too error prone.
It would need to support everything the current command line client supports (basically: login, logout, add group, add package, add release + some project data gathering) and conform to gforge's schema.
Is anyone up for the task?
Ryan Davis escreveu:
I just released version 1.0.2 of the rubyforge command line client. It sucks. We could do a lot better. In particular, we really need a real API for rubyforge, not a web scraper. It is too error prone.
It would need to support everything the current command line client supports (basically: login, logout, add group, add package, add release + some project data gathering) and conform to gforge's schema.
Is anyone up for the task?
Ryan, I´m in!
I really like to participate and help in everything you need.
Regards,
- tiago nogueira
How do you plan to implement this? I've thought about too. I believe
GForge provides a SOAP-based API, but I'm not sure Rubyforge is up to
date with the latest and greatest. (Not to mention yuk! SOAP). I've
suggested to Tom Copeland that the current rubyforge gem code could be
converted into a server side REST API, although obviously that's not
ideal. So I am curious as to what you have in mind.
Going further. Doesn't it seem like it's about time for Rubyforge to
run on Ruby?
On Jan 5, 5:43 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
I just released version 1.0.2 of the rubyforge command line client. It
sucks. We could do a lot better. In particular, we really need a real
API for rubyforge, not a web scraper. It is too error prone.It would need to support everything the current command line client
supports (basically: login, logout, add group, add package, add
release + some project data gathering) and conform to gforge's schema.Is anyone up for the task?
Though we haven't really advertised it yet, the source for RubyForge
itself (which is indeed almost entirely GForge) is now up on
RubyForge:
http://support.rubyforge.org/svn/trunk/support/gforge402/
This might help those interested in integrating such a feature.
-greg
On Mon, Jan 5, 2009 at 5:43 PM, Ryan Davis <ryand-ruby@zenspider.com> wrote:
I just released version 1.0.2 of the rubyforge command line client. It
sucks. We could do a lot better. In particular, we really need a real API
for rubyforge, not a web scraper. It is too error prone.It would need to support everything the current command line client supports
(basically: login, logout, add group, add package, add release + some
project data gathering) and conform to gforge's schema.Is anyone up for the task?
--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com
Trans escreveu:
On Jan 5, 5:43 pm, Ryan Davis <ryand-r...@zenspider.com> wrote:
I just released version 1.0.2 of the rubyforge command line client. It sucks. We could do a lot better. In particular, we really need a real API for rubyforge, not a web scraper. It is too error prone.
It would need to support everything the current command line client supports (basically: login, logout, add group, add package, add release + some project data gathering) and conform to gforge's schema.
Is anyone up for the task?
How do you plan to implement this? I've thought about too. I believe
GForge provides a SOAP-based API, but I'm not sure Rubyforge is up to
date with the latest and greatest. (Not to mention yuk! SOAP). I've
suggested to Tom Copeland that the current rubyforge gem code could be
converted into a server side REST API, although obviously that's not
ideal. So I am curious as to what you have in mind.Going further. Doesn't it seem like it's about time for Rubyforge to
run on Ruby?
Trans wrote:
"...Going further. Doesn't it seem like it's about time for Rubyforge to
run on Ruby?"
And i agree !
- tiago nogueira
\
Trans wrote:
"...Going further. Doesn't it seem like it's about time for Rubyforge to
run on Ruby?"
And i agree !
Yeah, you guys get started on that. And when you have a very stable,
broadly appealing project that you're willing to maintain and help Tom
manage serverside, come talk to us at RubyForge.
(100% serious, though it may sound snarky 
-greg
On Tue, Jan 6, 2009 at 6:08 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com
Gregory Brown escreveu:
On Tue, Jan 6, 2009 at 6:08 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
\
Trans wrote:
"...Going further. Doesn't it seem like it's about time for Rubyforge to
run on Ruby?"
And i agree !
Yeah, you guys get started on that. And when you have a very stable,
broadly appealing project that you're willing to maintain and help Tom
manage serverside, come talk to us at RubyForge.(100% serious, though it may sound snarky
-greg
Ok. I'm here waiting for instructions sir 
-tiago
we would need a system with comparable functionality that can run on
our hardware and be generally preferred by the community.
If you are serious about working on such a thing, I'll put you in
touch with Tom, and he could fill you in on the details.
But this has come up about 1000 times before. I was even one of the
people who suggested it in the past.
-greg
On Wed, Jan 7, 2009 at 11:07 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
Ok. I'm here waiting for instructions sir
--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com
If you are serious...
Basically:
1. Create a Ruby clone of Trac (http://trac.edgewall.org/\)
1.1. Make it easy to support multiple independent projects.
1.2. Don't waste time supporting SVN, go for Git from the start
By this point you have an issue tracker (which doubles as a project
manager tool) and a wiki, both hooked up to a RCS, which provides
source browsing. Look at Basecamp for inspiration.
2. Integrate this with a documentation browsing tool.
3. Add some sort of peer review system.
By this point you've got something akin to CPAN.
4. Add mailing list / forum support.
By this point, you are 90% done, I'd say.
Very roughly, that's about it,
Marcelo
On Wed, Jan 7, 2009 at 10:07 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
Ok. I'm here waiting for instructions sir
Gregory Brown escreveu:
On Wed, Jan 7, 2009 at 11:07 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
Ok. I'm here waiting for instructions sir
we would need a system with comparable functionality that can run on
our hardware and be generally preferred by the community.
If you are serious about working on such a thing, I'll put you in
touch with Tom, and he could fill you in on the details.But this has come up about 1000 times before. I was even one of the
people who suggested it in the past.-greg
Greg , i'm really talking serious. I really want to contribuite with our community and i have time every night to dedicate
and to do it.
-tiago
1. Create a Ruby clone of Trac (http://trac.edgewall.org/\)
There already is one in RedMine.
1.1. Make it easy to support multiple independent projects.
RedMine does.
1.2. Don't waste time supporting SVN, go for Git from the start
What? No.
Here's the problem with converting RubyForge from GForge to something
written in Ruby.... you can't take features away, because they're all
in use. That means that whatever gets written needs to support CVS,
SVN *and* Git. It needs to have integrated forums and mailing lists
with management for both. It needs a news system, bug trackers and a
file release system and a built-in gem indexer/server. It needs wikis
and web space, file download and scm statistics.
This is an extremely difficult problem to solve. GForge is a very
complex piece of software used by tons of people whose needs all need
to be balanced. I feel pretty strongly that anything other than a
feature-for-feature clone is doomed to failure, and then we'll have
nothing.
Ben
On Wed, Jan 7, 2009 at 9:08 AM, Marcelo <marcelo.magallon@gmail.com> wrote:
Would it be worthwhile to consider Redmine (http://www.redmine.org)? It's
pretty much a Ruby clone of Trac and supports Git. Not sure if it does 1.1,
2, or 3, but I know it has at least part of 4 (forum support).
--
Bryan
On Wed, Jan 7, 2009 at 10:08 AM, Marcelo <marcelo.magallon@gmail.com> wrote:
On Wed, Jan 7, 2009 at 10:07 AM, Tiago Nogueira <tjnogueira@oomaster.com> > wrote:
> Ok. I'm here waiting for instructions sir
If you are serious...
Basically:
1. Create a Ruby clone of Trac (http://trac.edgewall.org/\)
1.1. Make it easy to support multiple independent projects.
1.2. Don't waste time supporting SVN, go for Git from the startBy this point you have an issue tracker (which doubles as a project
manager tool) and a wiki, both hooked up to a RCS, which provides
source browsing. Look at Basecamp for inspiration.2. Integrate this with a documentation browsing tool.
3. Add some sort of peer review system.By this point you've got something akin to CPAN.
4. Add mailing list / forum support.
By this point, you are 90% done, I'd say.
Very roughly, that's about it,
Marcelo
I've pinged Tom. He should either join in here, or send you an email directly.
It's great that you want to contribute to the community, but unless
this is a need that is really, really, important to you, there are
lots of other worthy projects that aren't at the level of 'would be
nice', but instead at the level of 'really, really important'. I
won't be one to judge which are which generally, but my point is there
is software out there that needs to exist for Ruby that hasn't even
been started. There is also a lot of code out there that needs to be
ported to 1.9 if we plan to move forward as a community.
I do think there is significant merit in making our central project
repository top notch, but github has really filled in the gap (at
least temporarily). There are other bigger, wider holes to be filled.
-greg
On Wed, Jan 7, 2009 at 11:38 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
Greg , i'm really talking serious. I really want to contribuite with our
community and i have time every night to dedicate
and to do it.
--
Technical Blaag at: http://blog.majesticseacreature.com
Non-tech stuff at: http://metametta.blogspot.com
"Ruby Best Practices" Book now in O'Reilly Roughcuts:
http://rubybestpractices.com
Hi,
Would it be worthwhile to consider Redmine (http://www.redmine.org)? It's
pretty much a Ruby clone of Trac and supports Git. Not sure if it does 1.1,
2, or 3, but I know it has at least part of 4 (forum support).
Remine 0.8.0 supports CVS, SVN, Mercurial, Bazaar, Darcs and Git.
The best approach, in my opinion, is to:
1) Register http://www.rubyforge2.org using Redmine.
2) Encourage people to register their projects there instead of the
current system.
3) After about 6 months, if all goes well, ban new project creation on
the current Rubyforge (though leaving everything else intact).
4) Strongly encourage people to migrate their projects over to the new
system.
5) After 3 (4, 5?) years, shut down the old RubyForge, making
rubyforge2.org an alias for rubyforge.org.
I don't think there's any hope of "migrating" projects from the
current system to Redmine, though. Perhaps as a paid service, but
while tickets might be easy, mailing list archives and wiki
information would be especially difficult. Maybe I'm wrong, though.
Anyway, that's the approach I would take if I were running the show.
Regards,
Dan
On Jan 7, 10:58 am, "Bryan Richardson" <btri...@gmail.com> wrote:
To me GForge seems very dated. I think GitHub is much better example
of the future. It has most of the features developers need. In fact,
except for mailing lists I'm not sure one actually needs anything
else. Some of Rubyforge's features are never used such a Surveys. The
news feature always seemed a bit redundant to me too, why not just
have a ruby-announce mailing list? And some features can be handled
differently, like ticket tracking can be done with Ditz instead of
using a web-based app. Hek, maybe the GitHub people would be willing
to brand a version of their software for an oss only RubyHub? It might
be a good way for them to drive more proprietary business to their
main site and it would rock (IMHO) for the Ruby community.
T.
On Jan 7, 12:19 pm, "Ben Bleything" <b...@bleything.net> wrote:
Here's the problem with converting RubyForge from GForge to something
written in Ruby.... you can't take features away, because they're all
in use. That means that whatever gets written needs to support CVS,
SVN *and* Git. It needs to have integrated forums and mailing lists
with management for both. It needs a news system, bug trackers and a
file release system and a built-in gem indexer/server. It needs wikis
and web space, file download and scm statistics.This is an extremely difficult problem to solve. GForge is a very
complex piece of software used by tons of people whose needs all need
to be balanced. I feel pretty strongly that anything other than a
feature-for-feature clone is doomed to failure, and then we'll have
nothing.
Gregory Brown escreveu:
On Wed, Jan 7, 2009 at 11:38 AM, Tiago Nogueira <tjnogueira@oomaster.com> wrote:
Greg , i'm really talking serious. I really want to contribuite with our
community and i have time every night to dedicate
and to do it.
I've pinged Tom. He should either join in here, or send you an email directly.It's great that you want to contribute to the community, but unless
this is a need that is really, really, important to you, there are
lots of other worthy projects that aren't at the level of 'would be
nice', but instead at the level of 'really, really important'. I
won't be one to judge which are which generally, but my point is there
is software out there that needs to exist for Ruby that hasn't even
been started. There is also a lot of code out there that needs to be
ported to 1.9 if we plan to move forward as a community.I do think there is significant merit in making our central project
repository top notch, but github has really filled in the gap (at
least temporarily). There are other bigger, wider holes to be filled.-greg
Greg ,
I know exactly what i want and i want to contribute with this big cause
-tiago
I've really come to feel this way too. There's definitely more it could do, but the fact is that I already prefer to work with it.
James Edward Gray II
On Jan 7, 2009, at 3:10 PM, Trans wrote:
To me GForge seems very dated. I think GitHub is much better example
of the future. It has most of the features developers need.
<snip>
To me GForge seems very dated. I think GitHub is much better example
of the future. It has most of the features developers need.
I don't see a way to submit bugs.
I don't see forums.
I don't see mailing lists.
I don't see a way to broadcast announcements.
I don't see download stats.
I don't see a way to monitor what new Ruby projects have been created.
I don't see a way to logically group different, but related, libraries
together.
I don't see a way to attach external documents.
I don't see a way to track all of the bugs and feature requests I've
submitted on other projects.
I don't see a place to paste code snippets.
Github, an example of the future? The future isn't all it's cracked up
to be apparently.
Dan
On Jan 7, 2:10 pm, Trans <transf...@gmail.com> wrote:
The best approach, in my opinion, is to:
1) Register http://www.rubyforge2.org using Redmine.
2) Encourage people to register their projects there instead of the
current system.
3) After about 6 months, if all goes well, ban new project creation on
the current Rubyforge (though leaving everything else intact).
4) Strongly encourage people to migrate their projects over to the new
system.
5) After 3 (4, 5?) years, shut down the old RubyForge, making
rubyforge2.org an alias for rubyforge.org.
I think this is a *terrible* idea. The last thing we need is further
division in the community about where projects live. Don't get me
wrong, I think the spirit is right, but doing it *in this manner*
makes me uncomfortable.
It would be far better IMO to build a new RubyForge from the ground
up, and when it's reasonably feature-complete and the community
agrees, migrate over and shut the GForge instance down.
I don't think there's any hope of "migrating" projects from the
current system to Redmine, though. Perhaps as a paid service, but
while tickets might be easy, mailing list archives and wiki
information would be especially difficult. Maybe I'm wrong, though.
I don't necessarily agree that Redmine is the right solution to this
problem, but I believe that any replacement needs to be relatively
transparent... which means everything that's on RubyForge now needs to
be migrated.
Ben
On Wed, Jan 7, 2009 at 11:12 AM, Daniel Berger <djberg96@gmail.com> wrote:
To me GForge seems very dated. I think GitHub is much better example
of the future. It has most of the features developers need.
I think that GitHub demonstrates many aspects of the model that
RubyForge should head down. I don't agree that it's The Future or
should be considered as a potential replacement for RubyForge. For
just one thing, it enforces too much on the user... I like git and use
GitHub, but I also like and use Subversion and have projects that I
don't want to convert.
In fact, except for mailing lists I'm not sure one actually needs
anything else. Some of Rubyforge's features are never used such a
Surveys.
Are you sure, though? I have no idea if people use them or not... maybe
nobody does, or the people who do don't care if they're removed. The
point I'm trying to make, though, is that it's better to ask than to
just remove a feature that is assumed to not be in use.
The news feature always seemed a bit redundant to me too, why not just
have a ruby-announce mailing list?
Agreed, and not just because it's a pain to deal with the news, heh.
And some features can be handled differently, like ticket tracking can
be done with Ditz instead of using a web-based app.
Gross. I don't want my release system's bug tracker dropping turds in
my repo. No thanks. Sure, it's possible, but it's not a good user
experience for anyone except people who already use it and think it's
cool.
Hek, maybe the GitHub people would be willing to brand a version of
their software for an oss only RubyHub? It might be a good way for
them to drive more proprietary business to their main site and it
would rock (IMHO) for the Ruby community.
I don't think anyone wins here. Ruby people can just use GitHub as they
already are.
Ben
On Wed, Jan 7, 2009 at 1:10 PM, Trans <transfire@gmail.com> wrote: