--96YOpH+ONegL0A3E
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Sep 09, 2010 at 12:45:50PM +0900, Yusuke ENDOH wrote:
> Hi,
> 
> 2010/9/9 Aaron Patterson <aaron / tenderlovemaking.com>:
> >>  pros:
> >>   1) advantage for users: they can use "gem update" if stdlib has
> >>      an update.  Users can also use "gem remove".
> >
> > I hope this this advantage is not understated.  When stdlib has a bug,
> > we have to *live with that bug* until the next release of Ruby.  To work
> > around, people are forced to monkey patch stdlib.
> >
> > Even worse is the disadvantage to people who are stuck with a particular
> > Ruby version in production.  Many people can update gems at will, but
> > not Ruby versions.  Those unfortunate people have to live with the bug
> > _even longer_ than Ruby's release cycle.
> 
> I can't understand your point.

People who use Ruby on managed environments.  For example, I pay for a
shared server, but I am not allowed to upgrade Ruby.  I am allowed to
install as many gems as I want, but not allowed to upgrade Ruby.

Now, I find a bug in stdlib.  What do I do?  I can't upgrade Ruby.  I
must look for alternative hosting, or find a gem that replaces the
function stdlib provides.

> When a stdlib has a fatal bug (which causes security issue), we've
> released security package.  Users can rebuild and use it.
> If stdlib is also distributed as a gem, users have easier way: "gem
> update".  This is the advantage I mentioned.
> 
> If a user is using ruby installed via system-dependent packaging
> system (such as apt or SUSE's), the user should not use "gem update",
> but wait the distributor to update ruby package.

On a shared environment, you are at the mercy of the providers.  You
have no control.  Packaging stdlib as gems would give you control.

> Anyway, users don't have to live with that bug, I think.
> 
> 
> >>  cons:
> >>   1) disadvantage for the core team: developping style will get
> >>      complex.  The core team must care multiple entities: Ruby
> >>      package and stdlib gems.
> >
> > I don't think this con is true.  Development of these gems could stay in
> > the Ruby svn repository.  There is no reason to keep them in separate
> > repositories.  Gem releases could be made from the Ruby source itself.
> > Gem releases would only happen with the ruby-core member in charge of
> > that stdlib gem deems appropriate.
> 
> I agree.  Almost all developers will not be affected by this change,
> except release managers :-)

How would release managers be affected?  If I only use ruby svn for
managing my "stdlib-gem", ruby svn *always* has the most up-to-date
version of the code,  chkbuild will always run my tests, life would
continue the same (I think).

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

--96YOpH+ONegL0A3E
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iQEcBAEBAgAGBQJMiGCEAAoJEJUxcLy0/6/GidsIAJntQZxI2F1c5aafXVghN5i8
Gekpc+pArVjF7c3Yxvtf9GTseisKBVqEJzWsdAooTUqFXYtGp9fJqOkfmoKfm5pr
5I4ElmztT8b9V9ldZtwcPDtyx1D9O+7hkcIspFqrZvuPd+BsuqB24GfRBQY0/0Mc
9Fi6j7XL6qcmX06PLRcO74i/NSdSatlT1hQTILZ9jwtaqx/QXBCUuEz7zwcf+iUF
BcmvXlL/DS4J91PqC1bGPIGc/thKcrk2vKmtCi3WsEr8bMTZlZIPiP0EPA273EL8
NaZUkEvywPdNaePU6nJXzNrVjtyInoxyYwZhnKvbUJV6miWzQKuE/hfHfWUxz/cf
-----END PGP SIGNATURE-----

--96YOpH+ONegL0A3E--