Hi all -
Me and some other folks are looking into switching RubyForge over to use
Redmine. If you’d like to help, the migration script is underway here:
Or if you think this is a terrible idea, please speak now…
Thanks,
Tom
On Jun 16, 10:43 am, Intransition [email protected] wrote:
So it the Redmine just a issues? Or more than that?
So IS the Redmine just FOR issues?
On Jun 16, 8:14 am, Tom C. [email protected] wrote:
Hi all -
Me and some other folks are looking into switching RubyForge over to use Redmine. If you’d like to help, the migration script is underway here:
GitHub - rubycentral/rubyforge: Moving RubyForge from PHP to Ruby
Err… woozahhh
I thought you guys were “moving on”. I am very surprised to see you
are actually converting Rubyforge from PHP to Ruby. Is this in
production?
So it the Redmine just a issues? Or more than that?
I posted about it before, but I fell Rubyforge would do well to become
a “dashboard” app withsplugins for managing various services related
to their projects whether internal or external.
On Jun 16, 8:14 am, Tom C. [email protected] wrote:
Hi all -
Me and some other folks are looking into switching RubyForge over to use Redmine. If you’d like to help, the migration script is underway here:
GitHub - rubycentral/rubyforge: Moving RubyForge from PHP to Ruby
Or if you think this is a terrible idea, please speak now…
I just wonder what is going to happen with file hosting.
I’m fine with a modernized structure, but want to know what to expect
to be able to better plan RubyInstaller and other projects tracking
needs.
On Jun 16, 2:06 pm, Intransition [email protected] wrote:
On Jun 16, 10:43 am, Intransition [email protected] wrote:
So it the Redmine just a issues? Or more than that?
So IS the Redmine just FOR issues?
No:
But the question is not that, is what would happen with file being
hosted there, the package model do not fit the old RubyForge one.
On Jun 16, 2010, at 10:43 AM, Intransition wrote:
are actually converting Rubyforge from PHP to Ruby. Is this in
production?
It is not… we must first code up a migration script and port various
cronjobs and what have you.
So it the Redmine just a issues? Or more than that?
It does lots, and the bits it doesn’t do we’ll write.
I posted about it before, but I fell Rubyforge would do well to become
a “dashboard” app withsplugins for managing various services related
to their projects whether internal or external.
Yup, we probably need something like “the code is over here on github”
as an SCM option.
Yours,
Tom
On Jun 16, 2010, at 3:15 PM, Luis L. wrote:
But the question is not that, is what would happen with file being
hosted there, the package model do not fit the old RubyForge one.
True, yup, Redmine has a files tab but I think it’s pretty much a linear
list.
How much of the RubyForge Package/Release/File structure do you think we
need?
Thanks,
Tom
On Jun 16, 2010, at 1:30 PM, Luis L. wrote:
I just wonder what is going to happen with file hosting.
I’m fine with a modernized structure, but want to know what to expect
to be able to better plan RubyInstaller and other projects tracking
needs.
We’ll still do file hosting… but gems will definitely stay with
gemcutter (i.e., rubygems.org).
Yours,
Tom
On Jun 16, 4:11 pm, Tom C. [email protected] wrote:
But the question is not that, is what would happen with file being
hosted there, the package model do not fit the old RubyForge one.True, yup, Redmine has a files tab but I think it’s pretty much a linear list.
Linear works for me. I’m worried that file releases for RubyInstaller,
tar files for projects like SQLite3-Ruby and others are lost.
Just that.
How much of the RubyForge Package/Release/File structure do you think we need?
RubyForge release cycle is overkill, that one of the reasons I think
gemcutter make gem releases blossom, it lowered the release barrier.
Thanks,
Thanks to you man.
On Jun 18, 2010, at 12:10 PM, Caleb C. wrote:
time I do that is (a little bit of) extra work. The ‘release’ of a
file is implicitly stored in the file’s name anyway.
Hm, interesting, yeah, seems like the date and filename
(foobar-1.2.3.tar.gz) gets you most of the way there.
While we’re on the subject, it would be extremely nice if the urls to
files were friendlier. Something like
http://rubyforge.org// is what I would like to
see, rather than the current scheme which involves numbers in the url
as I recall. (OTOH, files currently on rubyforge might need to keep
their current urls as well, otherwise you risk breaking external
links…)
Cool, yup, I think Redmine generates reasonable URLs for files.
For external links, maybe we can generate a huge rewritemap… hm, or
have a custom route that looks things up by “old_frs_file_id”… well,
lots of possibilties, but yup, it would be good to keep those external
links working.
Yours,
Tom
On Jun 18, 2010, at 1:20 PM, Luis L. wrote:
Linear works for me. I’m worried that file releases for RubyInstaller,
tar files for projects like SQLite3-Ruby and others are lost.Just that.
Cool. No worries, yup, we’ll keep all that data (and the files) in some
form.
RubyForge release cycle is overkill, that one of the reasons I think
gemcutter make gem releases blossom, it lowered the release barrier.
Excellent, so sounds like a lighter release mechanism is a good thing…
glad to hear it…
Yours,
Tom
On 6/16/10, Tom C. [email protected] wrote:
True, yup, Redmine has a files tab but I think it’s pretty much a linear
list.How much of the RubyForge Package/Release/File structure do you think we
need?
Personally, I don’t see much point to having rubyforge model releases.
A separate directory for each package is clearly needed, but I just
want a place to dump my tarballs. Having to ‘create a release’ each
time I do that is (a little bit of) extra work. The ‘release’ of a
file is implicitly stored in the file’s name anyway.
While we’re on the subject, it would be extremely nice if the urls to
files were friendlier. Something like
http://rubyforge.org// is what I would like to
see, rather than the current scheme which involves numbers in the url
as I recall. (OTOH, files currently on rubyforge might need to keep
their current urls as well, otherwise you risk breaking external
links…)