On 01/13/2012 05:40 AM, Vít Ondruch wrote:
Next, it would be fine if you decide who would you like to support on
the first place, if general Ruby community or RPM based systems. You
cannot satisfy both I am afraid.
As you probably want to attract as many community developers as you
can, who are using different system, you should develop by Ruby
community standards and use Gemfile and Gemfile.lock without fear.
Since this is what works everywhere for Ruby developers. Developers
tends to use the newest Rubies, newest Rails, gems etc. and thats good
and that is how it should to be.
Bundler isn't the end of the story, there is rvm, and additional gem
dependency management tools. At the end of the day, the ruby community
has been very accommodating to a wide variety of platforms which is
fundamentally at a contrast to the single platform we want to be able to
support.
The more time that goes on, the more I'm convinced that it will take
both a community / cultural shift driven by marketing as well as an
improvement of the technologies and tooling at hand to drive the synergy
between communities. Both are necessary to accomplish our goals.
<snip>
Also, regarding development for Fedora, it would be nice if you could
develop just for Fedora Rawhide and follow the Rawhide release
schedule, i.e. push your project into Fedora before branch and later
push just bugfixes. No updates of Aeolus in older versions of Fedora
what so ever. This will allow you to have stable version of Aeolus on
each Fedora while focus on development on only one OS.
We are in the process of syncing a more regular / maintained Fedora
release schedule. We've divy'd up the components amongst their
respective subteams who are now responsible for maintaining their Fedora
package release cycle. This should lead to more incremental / fine tuned
updates in Fedora, and tighter integration between the Aeolus and Fedora
release cycles as a whole.
Dne 11.1.2012 22:03, Jason Guiditta napsal(a):
> This made me think, 'why not use this simple fact to make our dev
> setup work for both kinds of developers?'. There may be other or
> better ways to make that happen, but here is my proposal (finally):
> 1. Uncomment the source line in Gemfile so it points to
rubygems.org
> again, as is going to be expected by most ruby developers.
> 2. Update the lock file on a setup that has the _oldest supported
> versions of all dependencies_. This is a key point, as it will
> ensure a minimal baseline without forcing newer distros to hold back
> updating their packages.
Both of these make sense to me, though as far as #2 API
incompatibilities between versions of various gems may cause issues.
There really isn't any quick fix to this though, and not ruby / gem
specific, so we just need to be proactive about monitoring what we pull
into Aeolus and what it entails.
> 3. Add a rake task, for now I'll call it
'dev:rpm-only', hopefully
> the name makes it clear why. This task moves off Gemfile and
> Gemfile.lock to be something else, so they are not picked up for
> bundler use if you prefer to use rpm. If you are not using and
> rpm-only setup, and do not mind grabbing the specified versions from
> the lock file when running 'bundle install', then you can skip this
> step. Alternativwely we could go in the opposite direction, but as
> that would be less in keeping with the ruby standard practices, I
> would prefer not to do that (though I could certainly be conviced).
Seems a bit heavy handed to have a rake task to just rm those Gemfiles.
Could be solved through just documenting / making it known that the
Gemfiles should be removed to pull in dependencies installed locally via
RPM.
Either way works, just need to communicate our practices to the
community w/e way.
>
> The obvious downfall of this is:
> * If you are a developer working in rpm-only mode, it will be easy to
> add a new dependency and forget to add it to gemfile/lock. I think
> this will not be a large issue if we have a mix of development
> styles, as someone using the bundler style will notice pretty quickly
> in most cases that things dont seem to be working as expected. That
> said, a first step would to be to make it an expectation that any
> patch with a dependency change should also update the gemfiles (and
> vice versa if the patch comes from a bundler developer setup).
This would be a good idea for a git hook in the conductor repo.
> The
> next step could be another rake task you run whenever you change a
> dep, soemthing like 'rake dev:update-deps', which could write the
> changes to the given files for you.
There is a limit as to how far we'd be able to go with this due to API
incompatiblities. We'd be force to use the '>~' conditional in alot of
cases, as we'd be unsure if '>=' would break things. For example when we
were on rails 2.3.x, using a '>=' would've pulled in Rails 3.0.x which
would have broken things.
-Mo