Rails core - Jun 2006 - Continuous integration - with the common plugins ?

Hi

I''m pretty new to rails-core so bear with me if this is an easy one
(I''ve
searched first!).

I''ve noticed the CI notifications on the list, they don''t seem
to include
the most used plugins outside of the core (I may be wrong).

Is there some CI setup to provide early detection of plugins breakages
(latest plugins, tested against edge rails for instance, something similar
to http://gump.apache.org maybe) ?

If all this already is available, I''ll be happy to use it. If not,
would
there be some interest in it ?

regards

Thibaut
--
LoGeek
[blog] http://www.dotnetguru2.org/tbarrere


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

On 2-jun-2006, at 9:10, Thibaut Barrère wrote:
> Hi
>
> I''m pretty new to rails-core so bear with me if this is an easy
one
> (I''ve searched first!).
>
> I''ve noticed the CI notifications on the list, they don''t
seem to
> include the most used plugins outside of the core (I may be wrong).
>
> Is there some CI setup to provide early detection of plugins  
> breakages (latest plugins, tested against edge rails for instance,  
> something similar to http://gump.apache.org maybe) ?
>
> If all this already is available, I''ll be happy to use it. If not,
> would there be some interest in it ?
>
This would be a little overzealous because plugins might require 3rd  
party libs. Besides, for example one of my plugin just bails out  
because of recent changes in Ferret - not "throws" but really _bails_
at some deep and dirty C level. The list would be flooded then.

--
Julian ''Julik'' Tarkhanov
please send all personal mail to
me at julik.nl

> This would be a little overzealous because plugins might require 3rd
> party libs. Besides, for example one of my plugin just bails out
> because of recent changes in Ferret - not "throws" but really
_bails_
> at some deep and dirty C level. The list would be flooded then.
Additionally, most plugin breakage is intentional. If a plugin depends
on implementational details, then it''ll naturally break when those
change. So it falls on the back of the plugin creator to continuously
update and verify his plugin against the latest Rails.

So I do encourage that plugin developers setup CI services, the
information is just only useful to them, not to the core team.
-- 
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

Hi,

The list would be flooded then.


Setting up CI doesn''t mean we should receive a mail for each and every
breakage (can be
some kind of digest, or a separate mailing list like on a couple of projects
around).


Additionally, most plugin breakage is intentional. If a plugin
depends
> on implementational details, then it''ll naturally break when those
> change. So it falls on the back of the plugin creator to continuously
> update and verify his plugin against the latest Rails.

The plugins ''ecosystem'' is still rather young. Not all the
plugins authors
can guaranty they''ll be able to maintain their work on the mid or long
term.

Even without explicitely depending on implementational details, breaking
changes can be introduced, subtile side effects can lead to breakages, etc.

Just being aware of which changes cause trouble in the plugins ecosystem
can ease the everyday life of a Rails user, and at the end of the road, help
gain
more traction to rails.

Anyway, thanks for your answers!

Thibaut


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

On 6/2/06, Thibaut Barrère <thibaut.barrere@gmail.com>
wrote:
> If all this already is available, I''ll be happy to use it. If not,
would
> there be some interest in it ?
Thibaut,

As a regular rails user, I''d certainly be happy if you were to pursue
this.  Would be a lot of work though, as you''d most likely want to
test each plugin individually against the new rails checkin (as some
plugins conflict with each other), many plugins require some manual
setup (creating new tables, adding columns to your other tables,
creating a set of models and controllers that can use the new
functionality, etc), and most plugins don''t already include tests to
check if they are working correctly, so these tests would need to be
written.  But even test coverage of some the plugins would be better
than no coverage.  =)  And if you created this framework for testing
the plugins, it might encourage the plugin authors to include test
apps for their plugins.

Your testing framework could get updated about new checkins by
subscribing to the rss feed off trac, so you wouldn''t need the core
team to do anything for you to get started with this.

If you do go forward with this, you might want to get in touch with
Benjamin Curtis of http://www.agilewebdevelopment.com/, as it seems
like this plugin directory would be a great place to update the status
of the tests of the plugins.  If plugins authors and users are
notified quickly that new rails code breaks their plugin (and exactly
what checkin breaks them), it should help to keep plugins up to date
with the current rails trunk.

You should propose this on the main rails list, or just go ahead and
do it and ANNOUNCE it on the main rails list.  =)

- Isaac

On Jun 4, 2006, at 10:43 AM, Isaac Reuben wrote:
> On 6/2/06, Thibaut Barrère <thibaut.barrere@gmail.com> wrote:
>> If all this already is available, I''ll be happy to use it. If
not,
>> would
>> there be some interest in it ?
>
> Thibaut,
>
> As a regular rails user, I''d certainly be happy if you were to
pursue
> this.  Would be a lot of work though, as you''d most likely want to
> test each plugin individually against the new rails checkin (as some
> plugins conflict with each other), many plugins require some manual
> setup (creating new tables, adding columns to your other tables,
> creating a set of models and controllers that can use the new
> functionality, etc), and most plugins don''t already include tests
to
> check if they are working correctly, so these tests would need to be
> written.  But even test coverage of some the plugins would be better
> than no coverage.  =)  And if you created this framework for testing
> the plugins, it might encourage the plugin authors to include test
> apps for their plugins.
>
> Your testing framework could get updated about new checkins by
> subscribing to the rss feed off trac, so you wouldn''t need the
core
> team to do anything for you to get started with this.
>
> If you do go forward with this, you might want to get in touch with
> Benjamin Curtis of http://www.agilewebdevelopment.com/, as it seems
> like this plugin directory would be a great place to update the status
> of the tests of the plugins.  If plugins authors and users are
> notified quickly that new rails code breaks their plugin (and exactly
> what checkin breaks them), it should help to keep plugins up to date
> with the current rails trunk.
>
> You should propose this on the main rails list, or just go ahead and
> do it and ANNOUNCE it on the main rails list.  =)
>
> - Isaac
I''d be happy to help out with this, either by making an update feed  
for the plugins, or by hosting a plugin testbed, or whatever. :)

--
Benjamin Curtis
http://www.bencurtis.com/
http://www.tesly.com/ -- Collaborative test case management
http://www.agilewebdevelopment.com/ -- Resources for the Rails community

Hi

thanks for the feedback. The first idea I''m thinking about is simply to
run
the tests of each plugin in isolation, against the latest rails. I''ll
try to
think about it and see if I can come out with something easy to host and
maintain.

cheers

Thibaut


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

Bitten, the CI plugin for trac is a master/slave build server that
might work really well here. We''ve been using it on my current Rails
project because the master is on our team server out on the internet
and the actual build has to happen behind a corporate firewall.

I''m suggesting the Rails core team could run Bitten master on the main
rails trac instance and (so inclined) authors of widely-used plugins
could register and maintain Bitten slaves that reported back build
results for their project.

Obie

CC: Michael Schubert, who knows way more about Bitten than I do

On 6/5/06, Thibaut Barrère <thibaut.barrere@gmail.com>
wrote:
> Hi
>
> thanks for the feedback. The first idea I''m thinking about is
simply to run
> the tests of each plugin in isolation, against the latest rails.
I''ll try to
> think about it and see if I can come out with something easy to host and
> maintain.
>
> cheers
>
> Thibaut
>
>
>
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>
>
>

I''m not entirely sure of the merits of having widely used plugins
report breakages back to the rails-core team.  Some plugins are
notorious for fiddling with the internals of rails.   Breakage there
is inevitable unless we freeze the codebase entirely.

Rails itself definitely needs some CI love, but as for plugins,
they''re the author''s responsibility.   In the event we break
some
plugin, the author can let us know if it''s something we didn''t
mean to
do.  If it breaks because it relies on the internals of rails, then
they can release a new version.


-- 
Cheers

Koz

> Rails itself definitely needs some CI love, but as for plugins,
> they''re the author''s responsibility.   In the event we
break some
> plugin, the author can let us know if it''s something we
didn''t mean to
> do.  If it breaks because it relies on the internals of rails, then
> they can release a new version.
The idea is not to fallback on the core team for each and every detail.

Well this post is out of the scope of the tiny CI stuff we''ve been
discussing, but here''s my opinion:

Given the dynamic nature of ruby, it''s essentially more likely
(compared to
other platforms) to have some code which fiddles with the internals or
externals of the core, even when you take care of not fiddling.

Although the plugin author makes effort by packaging and releasing his stuff
to the community, not every plugin author will be able to support and
maintain his work on the mid or long term. As everyone here knows, the
coding part is only a slice in the lifetime of a piece of code, a tiner
slice than maintenance part.

If releasing a plugin costs too much to the author, we''ll get less
plugins
(read: less long-living plugins which we can rely on, or advise to a
customer for instance).

Any way to ease the lives of the plugins maintainers will bring love to the
users. The users need to be able to trusts those plugins (not only today,
but at least in a couple of months).

I think the community will get more benefits if we think a bit more
"global"
- plugins are a (big) part of rails, not finding a way to bring love to them
is bad for rails itself.


Just some thoughts - I really love working on Rails apps, I just want to
keep it that way :)


cheers

Thibaut
--
[blog] www.dotnetguru2.org/tbarrere


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> Although the plugin author makes effort by packaging and releasing his
stuff
> to the community, not every plugin author will be able to support and
> maintain his work on the mid or long term. As everyone here knows, the
> coding part is only a slice in the lifetime of a piece of code, a tiner
> slice than maintenance part.
Releasing a piece of open source software is a commitment to its
users,   if you''re unable to support and maintain your plugin, then
don''t release it in the first place.  No amount of CI magic beans can
substitute for a plugin author who actually looks after his plugin,
> I think the community will get more benefits if we think a bit more
"global"
> - plugins are a (big) part of rails, not finding a way to bring love to
them
> is bad for rails itself.
I think that the best option will be for one of the plugin directories
to offer CI for plugin authors.

-- 
Cheers

Koz

> I think that the best option will be for one of the plugin directories
> to offer CI for plugin authors.
I do agree.


_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core