Forum: Ruby WANTED: need a real web API for rubyforge.org

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Ryan D. (Guest)
on 2009-01-06 00:49
(Received via mailing list)
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?
Tiago N. (Guest)
on 2009-01-06 03:16
(Received via mailing list)
Ryan D. escreveu:
>
>
Ryan, I´m in!
I really like to participate and help in everything you need.
Regards,
- tiago nogueira
Thomas S. (Guest)
on 2009-01-06 07:10
(Received via mailing list)
On Jan 5, 5:43 pm, Ryan D. <removed_email_address@domain.invalid> 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 C. 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?
Tiago N. (Guest)
on 2009-01-06 13:17
(Received via mailing list)
Trans escreveu:
>> Is anyone up for the task?
> 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
Gregory B. (Guest)
on 2009-01-06 18:12
(Received via mailing list)
On Mon, Jan 5, 2009 at 5:43 PM, Ryan D. <removed_email_address@domain.invalid>
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
Gregory B. (Guest)
on 2009-01-07 17:55
(Received via mailing list)
On Tue, Jan 6, 2009 at 6:08 AM, Tiago N. <removed_email_address@domain.invalid>
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
Tiago N. (Guest)
on 2009-01-07 18:07
(Received via mailing list)
Gregory B. escreveu:
> 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
Gregory B. (Guest)
on 2009-01-07 18:24
(Received via mailing list)
On Wed, Jan 7, 2009 at 11:07 AM, Tiago N.
<removed_email_address@domain.invalid> 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
Tiago N. (Guest)
on 2009-01-07 18:39
(Received via mailing list)
Gregory B. escreveu:
>
> 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
Marcelo (Guest)
on 2009-01-07 19:09
(Received via mailing list)
On Wed, Jan 7, 2009 at 10:07 AM, Tiago N.
<removed_email_address@domain.invalid> 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 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
Ben B. (Guest)
on 2009-01-07 19:20
(Received via mailing list)
On Wed, Jan 7, 2009 at 9:08 AM, Marcelo <removed_email_address@domain.invalid>
wrote:
> 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
Gregory B. (Guest)
on 2009-01-07 19:34
(Received via mailing list)
On Wed, Jan 7, 2009 at 11:38 AM, Tiago N.
<removed_email_address@domain.invalid> 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
Tiago N. (Guest)
on 2009-01-07 19:46
(Received via mailing list)
Gregory B. escreveu:
> It's great that you want to contribute to the community, but unless
> 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
Bryan R. (Guest)
on 2009-01-07 19:59
(Received via mailing list)
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
Daniel B. (Guest)
on 2009-01-07 21:13
(Received via mailing list)
Hi,

On Jan 7, 10:58 am, "Bryan R." <removed_email_address@domain.invalid> 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).

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
Thomas S. (Guest)
on 2009-01-07 23:11
(Received via mailing list)
On Jan 7, 12:19 pm, "Ben B." <removed_email_address@domain.invalid> wrote:

> 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.

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.
James G. (Guest)
on 2009-01-07 23:53
(Received via mailing list)
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.

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 G. II
Daniel B. (Guest)
on 2009-01-08 00:15
(Received via mailing list)
On Jan 7, 2:10 pm, Trans <removed_email_address@domain.invalid> wrote:

<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
Ben B. (Guest)
on 2009-01-08 03:00
(Received via mailing list)
On Wed, Jan 7, 2009 at 11:12 AM, Daniel B. 
<removed_email_address@domain.invalid>
wrote:
> 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
Ben B. (Guest)
on 2009-01-08 03:07
(Received via mailing list)
On Wed, Jan 7, 2009 at 1:10 PM, Trans <removed_email_address@domain.invalid> 
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
James G. (Guest)
on 2009-01-08 03:11
(Received via mailing list)
On Jan 7, 2009, at 6:59 PM, Ben B. wrote:

> 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 would be interested to hear what percentage of GForge features see
any kind of widespread use.  I know some use them all, but I suspect
quite a few do not.  I feel GForge has a pretty clumsy interface that
detracts a lot from what it provides and probably encourages users to
avoid some hassle.  I admit that I'm guessing though.

> which means everything that's on RubyForge now needs to be migrated.

Has the RAA been migrated anywhere?

I'm not trying to disagree with you.  I just don't see these issues as
being so critical as you do.  Projects are migrating to Github in
pretty big numbers now.  Obviously some are OK with the feature
differences and aren't too worried about migrating content.

James Edward G. II
Tiago N. (Guest)
on 2009-01-08 03:17
(Received via mailing list)
Daniel B. escreveu:
> I don't see forums.
>
> Github, an example of the future? The future isn't all it's cracked up
> to be apparently.
>
> Dan
>
>
>
In this case ,i agree with you, dan.
- tiago
Daniel B. (Guest)
on 2009-01-08 03:27
(Received via mailing list)
Ben B. wrote:
>> 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.

I'm not sure how division in the community over where projects live
matters in any practical sense, except for Rubygems and your GEM_PATH
setting. Even then, Tom could make it so that you wouldn't need to
change anything, as he could script where the gems actually live.

> 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.

Oh, yeah? Who's gonna build it? And even _if_ someone undertook the
project, no one is going to agree on how it should look, feel and act
anyway, so it will _still_ result in division no matter how you slice
it.

Regards,

Dan
Tom C. (Guest)
on 2009-01-08 03:58
(Received via mailing list)
On Jan 7, 2009, at 12:33 PM, Gregory B. wrote:

>
> repository top notch, but github has really filled in the gap (at
> least temporarily).  There are other bigger, wider holes to be filled.


Yeah, this is a good discussion to have, and thanks to Greg for giving
me a heads up on it.

I go back and forth on this - I'd love to have RubyForge written in
Rails with a nice ActiveRecord model and a RESTful API and all that...
but, for one thing:

$ pwd
/var/www/gforge-3.0
$ find . -name "*.php" | xargs wc -l | sum | cut -f 1 -d " "
62284

For another, in my opinion, GForge isn't too bad; it's not the best,
but it's not terrible.  And I don't know, when I think about rewriting
it, I start thinking that I should just read my PHP books and make any
changes that need to be made in the current language.

Porting everything to Redmine is an idea, but the thought of migrating
the current data gives me a headache, and I'd hate to lose any
features.  On the other hand, like someone said many features aren't
used.

Another thing I think about that's tricky is the cutover.  Maybe if
there was a way to switch things over little by little... but again,
is the implementation language really the problem?   And are there
better places where that copious spare time can be spent?  I dunno.

Well, anyhow, those are some noodlings on the matter,

Yours,

Tom

P.S.  I might be overstating the difficulty of a rewrite.  If the DB
schema was fixed (which would require lots of set_primary_key and
has_many :through, :foreign_key => blah), at least for the time when
it was being ported, it might not be too painful.
Tiago N. (Guest)
on 2009-01-08 05:13
(Received via mailing list)
Tom C. escreveu:
>>
>> ported to 1.9 if we plan to move forward as a community.
> Rails with a nice ActiveRecord model and a RESTful API and all that...
> changes that need to be made in the current language.
>
>
>

Well Tom, your arguments are valid and I agree completly. I think this
subject is causing a good discussion and i propose a votation here.I
think that the hard job to rewrite will not be a problem if we make a
"union of forces" :-)

-tiago
Anthony E. (Guest)
on 2009-01-08 13:22
(Received via mailing list)
Just out of curiosity, rather than rewriting the GForge app or
modifying the PHP, why not just build a separate app that provides
only the API? That could be done in any flavor of web framework and
would be independent of the GForge code.

Sincerely,
Anthony E.

On Wed, Jan 7, 2009 at 8:57 PM, Tom C. <removed_email_address@domain.invalid> 
wrote:
>> I've pinged Tom.  He should either join in here, or send you an email
>>
> one thing:
>
>
> Yours,
>
> Tom
>
> P.S.  I might be overstating the difficulty of a rewrite.  If the DB schema
> was fixed (which would require lots of set_primary_key and has_many
> :through, :foreign_key => blah), at least for the time when it was being
> ported, it might not be too painful.
>



--
GMU/IT d- s: a32 C++(++++)$ UL@ P--- L+(++) !E W+++$ !N o? K? w--- !O
M++ V PS+ PE Y PGP t+ !5 X- R tv b++ DI+ D++ G- e++ h---- r+++ y++++**

http://anthony.mp
Thomas S. (Guest)
on 2009-01-08 15:24
(Received via mailing list)
On Jan 7, 8:16 pm, Tiago N. <removed_email_address@domain.invalid> wrote:
> > I don't see forums.
>
> > Github, an example of the future? The future isn't all it's cracked up
> > to be apparently.

Dan, I think you over value some of these features -- download stats
on Rubyforge aren't very accurate, announcements would be better
handled by a dedicated mailing list, and why attach external documents
when we can just add them to our repos? Also, GitHub does have code
snippets.

Yes, some additional features would be nice. But I see no reason why
they eventually can't be added -- I'm sure the GitHub folks have plans
for the future too.

In any case, I don't think it's a good idea to think in terms of
shutting the original Rubyforge down and starting Rubyforge2 up,
rather I think it would be better to make a smooth transition. Let
people move over at their leisure. The first adopters can be the ones
who are okay with the more limited feature set.

T.
Daniel B. (Guest)
on 2009-01-08 17:46
(Received via mailing list)
On Jan 8, 6:23 am, Trans <removed_email_address@domain.invalid> wrote:
>
> > > 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, I think you over value some of these features -- download stats
> on Rubyforge aren't very accurate

Except for a few projects that have either inadvertently or
intentionally pumped their own download stats, they're fairly
accurate. I track the download stats, so I can trend out the projects.

> announcements would be better handled by a dedicated mailing list

An RSS feed is even better. You can already do this for news on
individual projects. I've asked Tom about a site-wide RSS feed for
news announcements.

> and why attach external documents
> when we can just add them to our repos?

Because I don't necessarily want to download them. I may just want to
view them.

> Also, GitHub does have code
> snippets.

Ok, cool.

> Yes, some additional features would be nice. But I see no reason why
> they eventually can't be added -- I'm sure the GitHub folks have plans
> for the future too.

But if RF already has the features, why switch to github? And Redmine
has an even richer feature set.

> In any case, I don't think it's a good idea to think in terms of
> shutting the original Rubyforge down and starting Rubyforge2 up,
> rather I think it would be better to make a smooth transition. Let
> people move over at their leisure. The first adopters can be the ones
> who are okay with the more limited feature set.

In terms of rubyforge -> rubyforge2, I think a 3-5 year transition
would be fairly smooth. If you're referring to github, people will
transition, or not, at their leisure.

Regards,

Dan
Ryan D. (Guest)
on 2009-01-08 21:29
(Received via mailing list)
On Jan 8, 2009, at 03:21 , Anthony E. wrote:

> Just out of curiosity, rather than rewriting the GForge app or
> modifying the PHP, why not just build a separate app that provides
> only the API? That could be done in any flavor of web framework and
> would be independent of the GForge code.

which is exactly what I was asking for before trans hijacked yet
another thread with his tangental mentarbations. I want to do the
simplest thing that works to improve the current situation. We're
talking a couple hundred lines of code, max.
Thomas S. (Guest)
on 2009-01-08 22:07
(Received via mailing list)
On Jan 8, 2:28 pm, Ryan D. <removed_email_address@domain.invalid> wrote:
> talking a couple hundred lines of code, max.
And I did not hijack the thread. I just ask a related question.

Why didn't you answer the questions I asked directly related to what
you suggest?  I'm begging you Ryan, please put your personal feelings
about me aside and have a civil conversation about this.

T.
Tom C. (Guest)
on 2009-01-09 05:19
(Received via mailing list)
On Jan 8, 2009, at 2:28 PM, Ryan D. wrote:

>  I want to do the simplest thing that works to improve the current
> situation. We're talking a couple hundred lines of code, max.

Hm, this is pretty interesting.  I wonder if we could do
api.rubyforge.org, in Rails, with Group/Package/Release/ReleaseFile as
resources.  Ryan, is there anything else that hoe would need?  Maybe
User?

Maybe we should shift this discussion to the RubyForge support
project; I just fired up a new forum for it here:

http://rubyforge.org/forum/forum.php?forum_id=29548

Yours,

Tom
Ben B. (Guest)
on 2009-01-09 06:50
(Received via mailing list)
On Wed, Jan 7, 2009 at 5:10 PM, James G. <removed_email_address@domain.invalid>
wrote:
>> which means everything that's on RubyForge now needs to be migrated.
>
> Has the RAA been migrated anywhere?

Nope, but I feel pretty strongly that we'd all be better off if it had
been.

> I'm not trying to disagree with you.  I just don't see these issues as being
> so critical as you do.  Projects are migrating to Github in pretty big
> numbers now.  Obviously some are OK with the feature differences and aren't
> too worried about migrating content.

Sure, some are... but if we're really talking about replacing
RubyForge, what about all the people who use it who aren't happy with
the feature differences?  That's really the point I'm trying to make.

Ben
Ben B. (Guest)
on 2009-01-09 06:56
(Received via mailing list)
On Wed, Jan 7, 2009 at 5:26 PM, Daniel B. <removed_email_address@domain.invalid>
wrote:
> I'm not sure how division in the community over where projects live matters
> in any practical sense, except for Rubygems and your GEM_PATH setting. Even
> then, Tom could make it so that you wouldn't need to change anything, as he
> could script where the gems actually live.

Those are good points.  I guess it's a matter of whether or not this
theoretical RubyForge replacement would actually take over
rubyforge.org or not.  If it would, then what is done with all of the
projects on RubyForge now that can't or don't want to transition?

I'm also not excited about having to go to four or five different
sites to find the library that I'm looking for.  There's already
enough problem with trying to find the "canonical" gem when you've got
GitHub's source enabled... imagine if there was even one more gem
source in common usage.

> Oh, yeah? Who's gonna build it? And even _if_ someone undertook the project,
> no one is going to agree on how it should look, feel and act anyway, so it
> will _still_ result in division no matter how you slice it.

Maybe... the division I'm concerned about is having a lot of sites
crop up that are trying to do what RubyForge does.  If the idea is to
replace RubyForge with something better, my opinion is that RubyForge
as it is today should be shut down at the end of the process.  No
division, just new infrastructure serving the same purpose.

Ben
Gregory B. (Guest)
on 2009-01-09 07:04
(Received via mailing list)
On Thu, Jan 8, 2009 at 11:55 PM, Ben B. <removed_email_address@domain.invalid>
wrote:
> On Wed, Jan 7, 2009 at 5:26 PM, Daniel B. <removed_email_address@domain.invalid> wrote:
>> I'm not sure how division in the community over where projects live matters
>> in any practical sense, except for Rubygems and your GEM_PATH setting. Even
>> then, Tom could make it so that you wouldn't need to change anything, as he
>> could script where the gems actually live.
>
> Those are good points.  I guess it's a matter of whether or not this
> theoretical RubyForge replacement would actually take over
> rubyforge.org or not.  If it would, then what is done with all of the
> projects on RubyForge now that can't or don't want to transition?

old.rubyforge.org  ?

:)

> I'm also not excited about having to go to four or five different
> sites to find the library that I'm looking for.  There's already
> enough problem with trying to find the "canonical" gem when you've got
> GitHub's source enabled... imagine if there was even one more gem
> source in common usage.

Yes, I agree here.

>> Oh, yeah? Who's gonna build it? And even _if_ someone undertook the project,
>> no one is going to agree on how it should look, feel and act anyway, so it
>> will _still_ result in division no matter how you slice it.
>
> Maybe... the division I'm concerned about is having a lot of sites
> crop up that are trying to do what RubyForge does.  If the idea is to
> replace RubyForge with something better, my opinion is that RubyForge
> as it is today should be shut down at the end of the process.  No
> division, just new infrastructure serving the same purpose.

But if you close support for creating new projects and make RubyForge
for archival / legacy projects only, what's the problem with that?

-greg
Simon C. (Guest)
on 2009-01-09 16:53
(Received via mailing list)
I know very little about this but I have always wondered if it would
be possible to write another skin for the rubyforge data.  Fix the DB,
then implement features incrementally (as needed/desired) in the ruby-
based skin while keeping alive the existing program.

Any more insights, Tom?
Tom C. (Guest)
on 2009-01-09 18:29
(Received via mailing list)
On Jan 9, 2009, at 9:52 AM, Simon C. wrote:

> I know very little about this but I have always wondered if it would
> be possible to write another skin for the rubyforge data.  Fix the DB,
> then implement features incrementally (as needed/desired) in the ruby-
> based skin while keeping alive the existing program.
>
> Any more insights, Tom?

Yeah, that's a good thought.  When I think about doing that, the
tricky thing in my mind is maintaining all the permissions and
privileges and such for the Ruby side so that no one can add a file to
someone else's project or whatever.  But yeah, if that could be sorted
out, that sounds like a good idea.

Yours,

Tom
Gregory B. (Guest)
on 2009-01-09 18:35
(Received via mailing list)
On Fri, Jan 9, 2009 at 11:28 AM, Tom C. <removed_email_address@domain.invalid> 
wrote:
> Yeah, that's a good thought.  When I think about doing that, the tricky
> thing in my mind is maintaining all the permissions and privileges and such
> for the Ruby side so that no one can add a file to someone else's project or
> whatever.  But yeah, if that could be sorted out, that sounds like a good
> idea.

Tom, could you possibly prepare a database dump that strips out the
accounts and non-public data.  (If I'm creating a lot of work for you,
just let me know :)

But having a sandbox RubyForge db might help people w. this task.

-greg
Tom C. (Guest)
on 2009-01-12 17:35
(Received via mailing list)
On Jan 9, 2009, at 11:34 AM, Gregory B. wrote:

> Tom, could you possibly prepare a database dump that strips out the
> accounts and non-public data.  (If I'm creating a lot of work for you,
> just let me know :)
>
> But having a sandbox RubyForge db might help people w. this task.

That's a great idea.  Let me spend some time figuring out which fields
can be safely sanitized and I'll post back here,

Yours,

tom
This topic is locked and can not be replied to.