[ruby-core:26388] suggestion: gems.ruby-lang.org

[Yusuke ENDOH]

Hi --

I, as one user of ruby and rubygems, want to suggest establishing
the official repository of rubygems.


I'm surprised to hear that gems.rubyforge.org will be stood down.
I thought two lessons.

* `stable gems' repository
I have felt a distinction between the role of gems.rubyforge.org
and gems.github.com; the former provided stable gems and the
latter did unstable or development version of gems.

Though this distinction was not strict because it may have been
made by accident, it was actually useful (for me, at least).

GemCutter will play a role in development gem repository.  So
stable gem repository is needed.


* `dependable' repository
The default repository of rubygems should be dependable because
it is now a part of ruby.  It should not be changed so easily.

The core team and rubyforge are separate entities, so rubyforge
has the right to determine the elimination and consolidation of
gems.rubyforge.org.  But if they do so easily (without prior
consultation with the core team), I think that the repository is
not dependable for the official ruby.

Please don't consider I'm blaming rubyforge.  I'd like to just
say that rubygems can depend upon the external resource only if
it is dependable.


With these lessons, I'd like to make a suggestion for the future.

Why don't we prepare gems.ruby-lang.org as the default and official
source of rubygems?  It provides `ruby semi-standard libraries'
under the following two rules:

- only stable and well-selected gems are put there

- the gems will be tested by the core team before releasing ruby

Because of the rules, the gems will always work on the newest
ruby, which allow users to depend on them.  In addition, ruby core
package can become slim by moving nonessential standard libraries
like tk, drb, gdbm, base64, curses, etc.

I think that the biggest problem is human-resource, IOW, who will
establish and maintain gems.ruby-lang.org? :-)


What do you think?

--
Yusuke ENDOH <mame@...>

[John Barnette]

On Wed, Oct 28, 2009 at 3:20 AM, Yusuke ENDOH <mame@...> wrote:
> I'm surprised to hear that gems.rubyforge.org will be stood down.
> ...
> The default repository of rubygems should be dependable because
> it is now a part of ruby.  It should not be changed so easily.

The default repository would never be changed without a careful migration plan.

Gemcutter will be the official RubyGems source. It will live at
rubygems.org. gems.rubyforge.org will not stop working, it will be
transparently migrated to the new source.

All gems published to RubyForge are automatically synchronized with
GemCutter, and gem requests sent to gems.rubyforge.org will forward to
rubygems.org when the transition is complete.

Does this help your concerns, or do you have others?


~ j.

[Yusuke ENDOH]

Hi,

2009/10/29 John Barnette <jbarnette@...>:

> On Wed, Oct 28, 2009 at 3:20 AM, Yusuke ENDOH <mame@...> wrote:
>> I'm surprised to hear that gems.rubyforge.org will be stood down.
>> ...
>> The default repository of rubygems should be dependable because
>> it is now a part of ruby.  It should not be changed so easily.
>
> The default repository would never be changed without a careful migration plan.
>
> Gemcutter will be the official RubyGems source. It will live at
> rubygems.org. gems.rubyforge.org will not stop working, it will be
> transparently migrated to the new source.

I don't talk about url nor hostname.  The operation policy and principle
will be changed, won't it?  As a result, both of quantitatively and
qualitatively of gems that can be installed from gems.rubyforge.org will
be also changed widely.
I think we can say that "traditional rubyforge will disapper."

This is a good chance to review the policy of rubygems.

Even so, I have no idea if gems.rubyforge.org should be removed from
default repositories of rubygems or not.


After I have sent my mail, I found this is not a new idea.  A similar
idea was discussed when rubygems was imported.  [ruby-dev:31320]
The discussion seems to include other various topics and to be quite
confused.  I will read it later.

--
Yusuke ENDOH <mame@...>

[Luis Lavena]

On Wed, Oct 28, 2009 at 9:00 PM, Yusuke ENDOH <mame@...> wrote:

> Hi,
>
>> [...]
>>
>> Gemcutter will be the official RubyGems source. It will live at
>> rubygems.org. gems.rubyforge.org will not stop working, it will be
>> transparently migrated to the new source.
>
> I don't talk about url nor hostname.  The operation policy and principle
> will be changed, won't it?  As a result, both of quantitatively and
> qualitatively of gems that can be installed from gems.rubyforge.org will
> be also changed widely.
> I think we can say that "traditional rubyforge will disapper."

Right now the only difference between gemcutter and RubyForge is that
RubyForge requires approval of the project, but anyone can publish a
gem, any type of gem.

> This is a good chance to review the policy of rubygems.

Quoting your original email:

"GemCutter will play a role in development gem repository.  So
stable gem repository is needed."

That is not true. Gemcutter do not plan to replace the chaotic
workflow gems.github.com introduced.

GemCutter (to become rubygems.org) will play the role of
gems.rubyforge.org, exactly the same, with owners of each gem and
contributor pushing new releases as that fit their release schedule.

Gem publishing and workflow for existing project will still be in the
hands of the original team.

GitHub has discontinued the gem building and hosting and a "subdomain"
approach will live in *.gemcutter.org, not interfering with
rubygems.org

Further down, you suggest:

"Why don't we prepare gems.ruby-lang.org as the default and official
source of rubygems?  It provides `ruby semi-standard libraries'
under the following two rules:

- only stable and well-selected gems are put there

- the gems will be tested by the core team before releasing ruby"

This will create more confusion.

Right now Ruby embeds Rake and RubyGems, and that means when those
packages get a "blessing" they get updated in Ruby itself.

Thinking on a "blessed" repository will mean more stagnated versions
of gems that users will not updated because rubygems.org will not be
in that list and because RubyForge lacks the ability to install gems
from across repositories.

This situation can be also extended to projects that work on platforms
not fully blessed or supported by Ruby (ehem, Windows) and will make
things more difficult for new comers (so many repositories to choose!)

Now that GitHub as gem hosting is fading away, we have the opportunity
to syndicate and consolidate one true gem repository source, should we
segmented it again?

Just my two cents.

Regards,
--
Luis Lavena
AREA 17
-
Perfection in design is achieved not when there is nothing more to add,
but rather when there is nothing more to take away.
Antoine de Saint-Exupéry

[Yusuke ENDOH]

Hi,

2009/10/29 Luis Lavena <luislavena@...>:
> Right now the only difference between gemcutter and RubyForge is that
> RubyForge requires approval of the project, but anyone can publish a
> gem, any type of gem.

I know, so I said:

> Though this distinction was not strict because it may have been
> made by accident, it was actually useful (for me, at least).

I wonder if only I felt and liked this difference?


> Quoting your original email:
>
> "GemCutter will play a role in development gem repository.  So
> stable gem repository is needed."
>
> That is not true. Gemcutter do not plan to replace the chaotic
> workflow gems.github.com introduced.

Gemcutter does NOT?  If Gemcutter DOES, it's a good news.  But,

> Gem publishing and workflow for existing project will still be in the
> hands of the original team.

I'm calling the situation `development gem' repository.
I could say that more strict and stable repository than traditional
rubyforge is wanted.


> Right now Ruby embeds Rake and RubyGems, and that means when those
> packages get a "blessing" they get updated in Ruby itself.
>
> Thinking on a "blessed" repository will mean more stagnated versions
> of gems that users will not updated because rubygems.org will not be
> in that list and because RubyForge lacks the ability to install gems
> from across repositories.

Sorry I can't get your point.
Do you worry that development of gem in "blessed" repository will
become inactive?  I said that only already-stable gems are put in
the repository.


> This situation can be also extended to projects that work on platforms
> not fully blessed or supported by Ruby (ehem, Windows) and will make
> things more difficult for new comers (so many repositories to choose!)
>
> Now that GitHub as gem hosting is fading away, we have the opportunity
> to syndicate and consolidate one true gem repository source, should we
> segmented it again?

I think so.  You said "so many repositories to choose!", but just two
repositories.  The stable, official and default repository, and actively
developped one.  I hate to choose so many wheat and chaff gems from one
gem repository, like CPAN.

--
Yusuke ENDOH <mame@...>

[Aaron Patterson-3]

On Thu, Oct 29, 2009 at 12:50:20PM +0900, Yusuke ENDOH wrote:

> > Right now Ruby embeds Rake and RubyGems, and that means when those
> > packages get a "blessing" they get updated in Ruby itself.
> >
> > Thinking on a "blessed" repository will mean more stagnated versions
> > of gems that users will not updated because rubygems.org will not be
> > in that list and because RubyForge lacks the ability to install gems
> > from across repositories.
>
> Sorry I can't get your point.
> Do you worry that development of gem in "blessed" repository will
> become inactive?  I said that only already-stable gems are put in
> the repository.

Who would choose those gems?  Presumably not the author.  That means it
will take time for an author to request that their gem become part of
the "stable" repository, then time for the gem to become approved.

Increasing the difficulty for gem publishing will cause stagnation.  Why
would I try to get my gem in the stable repository if it takes more work?
Why send updates to the stable repository if it takes more work?

> > This situation can be also extended to projects that work on platforms
> > not fully blessed or supported by Ruby (ehem, Windows) and will make
> > things more difficult for new comers (so many repositories to choose!)
> >
> > Now that GitHub as gem hosting is fading away, we have the opportunity
> > to syndicate and consolidate one true gem repository source, should we
> > segmented it again?
>
> I think so.  You said "so many repositories to choose!", but just two
> repositories.  The stable, official and default repository, and actively
> developped one.  I hate to choose so many wheat and chaff gems from one
> gem repository, like CPAN.

Who will do the work to determine stability?  Would you trust that
person?  Will that person be looking for new and better gems to add to
the stable repository?  How will authors make sure their gem updates
get added to the stable repository?  What are the criteria for
determining that a gem is "good enough" to join the stable repository.

This sounds like a lot of work that (in my opinion) no one would want to
do.

Picking wheat from chaff is the price you pay for competition among
libraries.

</2cents>

--
Aaron Patterson
http://tenderlovemaking.com/

[Yusuke ENDOH]

Hi,

2009/10/30 Aaron Patterson <aaron@...>:
>> Do you worry that development of gem in "blessed" repository will
>> become inactive?  I said that only already-stable gems are put in
>> the repository.
>
> Who would choose those gems?  Presumably not the author.

Maybe the core team (and matz) will.  It's `semi-standard library.'


> That means it
> will take time for an author to request that their gem become part of
> the "stable" repository, then time for the gem to become approved.

Yes.  It will take lots of hard work.  It will be as hard as (or a bit
less than) work that you request that your library become standard
library.  This work will ensure the dependability of gems.ruby-lang.org.


> Increasing the difficulty for gem publishing will cause stagnation.  Why
> would I try to get my gem in the stable repository if it takes more work?
> Why send updates to the stable repository if it takes more work?

You can publish your gems in GemCutter conventionally, which never
causes stagnation of your gems.  Rather, such actively-developed
gems SHOULD be put in GemCutter.

If anyone suggests importing your gems to gems.ruby-lang.org and the
core team considers your gems as enough stable and important for
ruby, your gems may be imported to gems.ruby-lang.org.  If you don't
want, of course you can reject it.  It's the same as standard library.


>> I think so.  You said "so many repositories to choose!", but just two
>> repositories.  The stable, official and default repository, and actively
>> developped one.  I hate to choose so many wheat and chaff gems from one
>> gem repository, like CPAN.
>
> Who will do the work to determine stability?

The core team.

> Would you trust that person?

I do.  If you don't trust the core team, you should not use standard
library :-)

> Will that person be looking for new and better gems to add to
> the stable repository?  How will authors make sure their gem updates
> get added to the stable repository?  What are the criteria for
> determining that a gem is "good enough" to join the stable repository.

Good questions.  I'd like to ask the same questions about the
standard library.  These are not problems that newly occur.  It is
good to clarify the rule even if gems.r.o is rejected.


> Picking wheat from chaff is the price you pay for competition among
> libraries.

I'm slightly tired to say "it seems to be wheat, but it does not work
on the recent 1.9!"

You blame the core team for changing the spec?  But in fact, the core
team often estimates the impact of change by examining the standard
library.  The standard library also plays the role in the regression
tests to find unexpected change.  I expect gems.ruby-lang.org to also
enhance this effect.

--
Yusuke ENDOH <mame@...>

[Tom Copeland]

On Oct 29, 2009, at 12:43 PM, Aaron Patterson wrote:

> Picking wheat from chaff is the price you pay for competition among
> libraries.

I think some sort of "these gems work well together" functionality is  
being considered for the future, something along the lines of tattle:

http://chadfowler.com/2007/1/8/tattle-the-ruby-census

Might be easier to implement something like that once we cut over to  
gemcutter; will be a little easier to add features.

Yours,

tom

["Martin J. Dürst"]

On 2009/10/29 9:20, Luis Lavena wrote:
> On Wed, Oct 28, 2009 at 9:00 PM, Yusuke ENDOH<mame@...>  wrote:

> Further down, you suggest:
>
> "Why don't we prepare gems.ruby-lang.org as the default and official
> source of rubygems?  It provides `ruby semi-standard libraries'
> under the following two rules:
>
> - only stable and well-selected gems are put there
>
> - the gems will be tested by the core team before releasing ruby"
>
> This will create more confusion.

Not only that, it will also create more work for the core team. Several
standard libraries had to be removed because we didn't find maintainers.
If we can't keep standard libraries in good shape, then I'm not sure we
can take on the work of taking care of (semi)official gems.

Regards,   Martin.


--
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@...

[Gavin Sinclair]

>>> Do you worry that development of gem in "blessed" repository will
>>> become inactive?  I said that only already-stable gems are put in
>>> the repository.
>>
>> Who would choose those gems?  Presumably not the author.
>
> Maybe the core team (and matz) will.  It's `semi-standard library.'

You make some good points, Yusuke.  There would definitely be some
benefits to a conservative gem collection that forms a subset of all
gems.

The only way I see it coming to life is if you create it.  It doesn't
need to be official.  If it's good, people will use it, others may
help you maintain it, etc.  If it proves to be a good idea, maybe
eventually it will become official.

Just like GemCutter was a good idea and is now becoming more or less
official.  It had to be created first.

You don't need a bureaucratic process to put a gem in your collection.
 Just cherry-pick.  Accept nominations from anybody.  Unless I'm
mistaken, you don't need an author's permission to add their gem to
your collection.  (Notification would be polite, and allowing them to
opt out.)  Set your own standards for inclusion; nobody who isn't
helping you can complain.

Sounds like a lot of work, though!

Come to think of it, you don't even need a gem source.  A webpage
listing what you consider to be production-ready gems would be
sufficient.  People can get their information from there and just
install the gems as usual.  Who cares where the gem comes from?

--
Gavin Sinclair

[Yusuke ENDOH]

Hi,

2009/11/2 "Martin J. Durst" <duerst@...>:

>> "Why don't we prepare gems.ruby-lang.org as the default and official
>> source of rubygems?  It provides `ruby semi-standard libraries'
>> under the following two rules:
>>
>> - only stable and well-selected gems are put there
>>
>> - the gems will be tested by the core team before releasing ruby"
>>
>> This will create more confusion.
>
> Not only that, it will also create more work for the core team. Several
> standard libraries had to be removed because we didn't find maintainers. If
> we can't keep standard libraries in good shape, then I'm not sure we can
> take on the work of taking care of (semi)official gems.

I expect work of the core team to be reduced because of two reasons.

First, separating official gems will make clear the scope of the
responsibilities.  The core team can focus on the core.  The gem
maintainers can focus on their gem.  This allows new maintainer
for each official gem to appear easily.

Second, the core team has to test the official gems after the core
is frozen, but is not obligated to fix their bugs.  Each maintainer
must fix them.  If there is no maintainer, anyone does not fix, or
if the fix misses the release, the gem will sadly drop out from the
official repository.  This rule ensures the reliability of the
official repository (the gems will work correctly as long as it
belongs to the official gems), but it may reduce the availability
(the gems will be available in the future).  So we should not use
the rule unless it is necessary.
(Of course, the core team may fix bugs of the gems even if they are
not obligated.)

--
Yusuke ENDOH <mame@...>