A Word on the Development Process
Eero Saynatkari
Tentative: please voice any issues with the arrangement:
There are a few changes being worked into the development
process that merit a mention to help everyone keep track
of and/or contribute to Waves. The code is still over at
Github.
0. All development takes place in waves/edge. The dyoder/
repositories are no longer in use.
1. Development is single-track, and continuous. Once, say,
1.0 has been completed, we will not move to a different
repository, start a new branch etc. we continue in the
same bat-repository, on the same bat-branch. Your local
branches are obviously fine, but as a rule there should
exist no long-lived branches in the main repo.
2. This means, obviously, that the HEAD of the waves/edge
repo may be broken at any given time and may not be
relied upon neither in production nor development. The
only people who actually work with HEAD are the ones
working on Waves itself.
3. What if someone wants to be "on the edge"? This term is
a bit outdated in a Git world (you can always use some
stable commit), but we need to map it to the one where
RubyGems are still in use. This is done by rampantly
tagging commits. Traditionally one may think of tags
as "0.8.2", "0.8.3" and so on, but we can extend this
to be "0.8.3.18423" etc. for arbitrary granularity.
At any time that the branch becomes stable (as in, it
does not break), a tag can be added. These tags, then,
can be relied upon--with the usual reservations--to be
suitable for use.
4. As a workaround for Github's lack of ability to create
gems from tags (or branches), the gem for waves/edge
will always be from a stable tag. Other gems can be
made available through the waves/stable repository and
as "published" Gems. Once Github improves, this will
be more sensible.
5. While not topical yet, bug- and security fixes can be
handled through forward branches. I will expand on this
in a later post, as it may require some room.
6. Speccing is to be done using Micronaut (RSpec-compat.)
The old bacon specs are still supported, but we need
to move to something a bit more featureful. I think
Mocha is the way to go for mocks.
Anyone wanting to hack on Waves:
0. The "free-flowing commit bit" is in use. If you create
a patch to Waves that is accepted, you are given commit
rights to the repository.
1. If you have a patch to Waves, the best way to get it in
is to use git-format-patch and send it to the ML here.
Github's pull requests are, ah, less desirable but will
be handled (although there may be a slight delay due to
the limited number of people who can access them.)
2. All patches, whether fixes or additions, must provide
specs for the behaviour (unless those specs already
exist.) A patch consisting of *just* specs is naturally
fine.
Ideas for stuff to do:
* 1.9 compatibility
* Reducing dependencies and especially eager loading of
dependencies.
* Improving and speccing sample/. Ideally we could run
specs for the sample apps automatically.
* Just plain adding specs.
Think that is it. Questions, comments etc.?
Eero (rue)
ab5tract
ever seen in the development of Waves so far lol.
And I don't mean that in a bad way! Genius, yes. Organized... not so
much ;)
I recently noticed that heroku has enabled all Rack applications. I
plan to start looking into this very soon. Which version of Ruby is
being used, predominantly? Is Waves MRI 1.8.7 compatible? I would
honestly like to be doing 1.9.1 (hoshi++) so perhaps I should just
blaze that path for us right now?
That is, tomorrow ;)
> 1. Development is single-track, and continuous. Once, say,
> 1.0 has been completed, we will not move to a different
> repository, start a new branch etc. we continue in the
> same bat-repository, on the same bat-branch. Your local
> branches are obviously fine, but as a rule there should
> exist no long-lived branches in the main repo.
> 6. Speccing is to be done using Micronaut (RSpec-compat.)
> The old bacon specs are still supported, but we need
> to move to something a bit more featureful. I think
> Mocha is the way to go for mocks.
http://technicalpickles.com/posts/ruby-stubbing-and-mocking-with-rr/
Not sure if it would play nicely with AutoCode, but I like the idea of
'spying' on objects. Plus, Waves' pedigree is clearly
'Edge' (capitalizing it means there is somthething New mean it
accomplished it), and efficient. While I can't speak for efficiency
atm it does seem to represent another ingression of a future-thinking
impulse. Looking forward to taking a look at Micronaut, but even more
just glad that we have an official spec framework to work with(in).
> 1. If you have a patch to Waves, the best way to get it in
> is to use git-format-patch and send it to the ML here.
> Github's pull requests are, ah, less desirable but will
> be handled (although there may be a slight delay due to
> the limited number of people who can access them.)
> 2. All patches, whether fixes or additions, must provide
> specs for the behaviour (unless those specs already
> exist.) A patch consisting of *just* specs is naturally
> fine.
> Ideas for stuff to do:
>
> * 1.9 compatibility
> * Reducing dependencies and especially eager loading of
> dependencies.
> * Improving and speccing sample/. Ideally we could run
> specs for the sample apps automatically.
> * Just plain adding specs.
Eero Saynatkari
> Is Waves MRI 1.8.7 compatible?
Insofar as I have exercised the lib, yes.
> Since we are still flexing for a mock, I'd like? to point out
> http://technicalpickles.com/posts/ruby-stubbing-and-mocking-with-rr/
Very nice, I had not seen this before (nor Micronaut before
yesterday for that matter.) I never liked Mocha much, but
there have been surprisingly few options.
RR is the mocking lib to use for now.
> > 1. If you have a patch to Waves, the best way to get it in
> > is to use git-format-patch and send it to the ML here.
> > Github's pull requests are, ah, less desirable but will
> > be handled (although there may be a slight delay due to
> > the limited number of people who can access them.)
>
> ++ (if it gets too busy we'll just build a trac ;)
Heh--although I should clarify: I do not expect the pull
request queue to be so packed that it causes a delay soon,
but there are only a couple people who can see and apply
a pull request which could be bad, say, over a weekend.
--
Magic is insufficiently advanced technology.
Daniel Yoder
> 0. All development takes place in waves/edge. The dyoder/
> repositories are no longer in use.
Yes.
> 1. Development is single-track, and continuous. Once, say,
> 1.0 has been completed, we will not move to a different
> repository, start a new branch etc. we continue in the
> same bat-repository, on the same bat-branch. Your local
> branches are obviously fine, but as a rule there should
> exist no long-lived branches in the main repo.
Yes, but see comments on #2.
> 2. This means, obviously, that the HEAD of the waves/edge
> repo may be broken at any given time and may not be
> relied upon neither in production nor development. The
> only people who actually work with HEAD are the ones
> working on Waves itself.
The value of branches and forks (mostly forks, so as not to confuse
things on the main repo) is to minimize instability of edge. That is,
the etiquette is like any other development effort. Don't check stuff
in that isn't tested. That will help make it possible for everyone to
run off edge without constant headaches. That said, obviously, if you
need guarantees, use stable not edge.
> 3. What if someone wants to be "on the edge"? This term is
> a bit outdated in a Git world (you can always use some
> stable commit), but we need to map it to the one where
> RubyGems are still in use. This is done by rampantly
> tagging commits. Traditionally one may think of tags
> as "0.8.2", "0.8.3" and so on, but we can extend this
> to be "0.8.3.18423" etc. for arbitrary granularity.
>
> At any time that the branch becomes stable (as in, it
> does not break), a tag can be added. These tags, then,
> can be relied upon--with the usual reservations--to be
> suitable for use.
Yes, although I would encourage us to do frequent pushes to stable
with the three-level version tags. That is, I don't see a big problem
with 0.8.13 or 0.8.25 if needed. We've been going too long without
pushing cool features into stable, an activity which also forces us to
be sure we've not gone too far off the deep end without adequate
testing.
> 4. As a workaround for Github's lack of ability to create
> gems from tags (or branches), the gem for waves/edge
> will always be from a stable tag. Other gems can be
> made available through the waves/stable repository and
> as "published" Gems. Once Github improves, this will
> be more sensible.
Do we really need edge gems? My feeling is that, in that case, you are
hacking on Waves, anyway, which means you're just pointing to your
version anyway. What's more, if we do reasonably frequent (every 2-4
weeks) pushes to stable, it isn't really necessary. What am I missing
here?
> 5. While not topical yet, bug- and security fixes can be
> handled through forward branches. I will expand on this
> in a later post, as it may require some room.
Looking forward to your thoughts on that. ;)
> 6. Speccing is to be done using Micronaut (RSpec-compat.)
> The old bacon specs are still supported, but we need
> to move to something a bit more featureful. I think
> Mocha is the way to go for mocks.
Fair enough, re: Bacon. But I am curious though about which features
you found lacking?
Same sort of interest in Mocha versus FlexMock. I am very interested
in the specifics.
Maybe a separate thread sharing your thoughts on these ... ?
> Anyone wanting to hack on Waves:
>
> 0. The "free-flowing commit bit" is in use. If you create
> a patch to Waves that is accepted, you are given commit
> rights to the repository.
Enthusiastic agreement. I understand the reservation SOME OF US might
have, since forking and sending patches or pull requests is so easy.
But there is some subtle psychology at work here, too. Giving commit
access is saying, you're part of the team. We're empowering our team
to do what they think is right. This is wonderfully risk free in git
because we can always revoke commit rights and easily back out
changes. But even if it wasn't, I think it is important to encourage
developers who've proven that (a) they are enthusiastic about what
we're doing and (b) talented enough to submit a reasonably interesting
patch to continue to be involved.
The only caveat is that I think it needs to be a "reasonably
interesting" patch, as opposed to just one that was accepted. That is,
if you change a version number or something, I'm not sure that
suggests that you should be hacking on the matching code. But I do
think we ought to be pretty liberal about this and see how it goes.
> 1. If you have a patch to Waves, the best way to get it in
> is to use git-format-patch and send it to the ML here.
> Github's pull requests are, ah, less desirable but will
> be handled (although there may be a slight delay due to
> the limited number of people who can access them.)
Yes.
> 2. All patches, whether fixes or additions, must provide
> specs for the behaviour (unless those specs already
> exist.) A patch consisting of *just* specs is naturally
> fine.
Yeah, that might cover my "reasonably interesting" criteria. If the
change doesn't require a spec, than it isn't really that big of a
deal. And writing specs for existing behavior gives you automatic
canonization.
> Ideas for stuff to do:
>
> * 1.9 compatibility
> * Reducing dependencies and especially eager loading of
> dependencies.
> * Improving and speccing sample/. Ideally we could run
> specs for the sample apps automatically.
> * Just plain adding specs.
>
>
> Think that is it. Questions, comments etc.?
Thanks again, Eero. Nicely done. Sorry for the delay in endorsing this.
Dan
Daniel Yoder
> ever seen in the development of Waves so far lol.
>
> And I don't mean that in a bad way! Genius, yes. Organized... not so
> much ;)
No worries. Agreed. And if it wasn't for automatthew ... ooph. Don't
even want to think about it.
> I recently noticed that heroku has enabled all Rack applications. I
> plan to start looking into this very soon. Which version of Ruby is
> being used, predominantly? Is Waves MRI 1.8.7 compatible? I would
> honestly like to be doing 1.9.1 (hoshi++) so perhaps I should just
> blaze that path for us right now?
The heroku guys actually got Waves running over there some time ago.
We are 1.8.7 so at least up until recently, so was Heroku.
However, we are targeting 1.9 support ...
Dan