And the other ones will be kept in the separate repo.
> --
> You received this message because you are subscribed to the Google
> Groups "rapidsms" group.
> To post to this group, send email to rapi...@googlegroups.com.
> To unsubscribe from this group, send email to
> rapidsms+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rapidsms?hl=en.
Maybe we should have a clear separation between "official" contrib apps,
from the dev team. Apps that are not required, but that most of the
users will use (like auth in Django). They could lie in the repo.
And the other ones will be kept in the separate repo.
I am strongly in favor of keeping them separate. I think that any
features that require synchronous changes to both will continue to be
rare and we should be strengthening the division between app-land and
core-land rather than encouraging the lack of separation that has
plagued the project in the past (perhaps because everything was in a
single repository?).
I agree that developing with submodules is very annoying. Personally,
I find it easier to clone the repositories separately (you can clone
one within the other or symlink them side-by-side) and only deal with
submodules periodically.
evan
I am strongly in favor of keeping them separate. I think that any
features that require synchronous changes to both will continue to be
rare and we should be strengthening the division between app-land and
core-land rather than encouraging the lack of separation that has
plagued the project in the past (perhaps because everything was in a
single repository?).
In the past, we've had a silly proliferation of rapidsms forks. Part
of the reason is that in order to make a change to something like
locations templates or the old reporters app -- you had to fork the
entire repository (core code, app code and all). Since you've already
forked the whole thing and you are in the field hacking on a
deployment, it was very easy to hack on other apps and hack on the
core. Apps are no longer treated as separate pieces of functionality
that work together -- they become a large interconnected stew. Very
little is reusable. Afterwards, many useful little changes may be
bundled with deployment-specific hackery in large commits and never
get shared. Now, one only needs to fork the contrib repository and can
avoid the temptation of mucking things up.
Even though its a subtle and in some ways meaningless separation, as
you point out, the repository division helps promote thinking about
the rapidsms framework and its app ecosystem as different things --
not just a big hot mess called rapidsms. Hopefully this will subtly
encourage us to focus on making apps that are not unnecessarily
dependent on other apps so that they might be reusable.
Finally, the annoyance of separate repositories only affects a small
portion of the community. The pip installer is a single step whether
it downloads one repository or two behind the scenes. Most rapidsms
app developers will be authoring and maintaining their own apps in
their own repositories. Some may contribute improvements to the
contrib apps. Fewer still will work on core framework code. Each of
these constituent groups (app developers, contrib developers, core
developers) have a different interests and, if the community continues
to grow, each will have its own champions and contributors independent
of the others.
Best,
Evan
In the past, we've had a silly proliferation of rapidsms forks. Partof the reason is that in order to make a change to something like
locations templates or the old reporters app -- you had to fork the
entire repository (core code, app code and all). Since you've already
forked the whole thing and you are in the field hacking on a
deployment, it was very easy to hack on other apps and hack on the
core. Apps are no longer treated as separate pieces of functionality
that work together -- they become a large interconnected stew. Very
little is reusable. Afterwards, many useful little changes may be
bundled with deployment-specific hackery in large commits and never
get shared. Now, one only needs to fork the contrib repository and can
avoid the temptation of mucking things up.
Even though its a subtle and in some ways meaningless separation, as
you point out, the repository division helps promote thinking about
the rapidsms framework and its app ecosystem as different things --
not just a big hot mess called rapidsms. Hopefully this will subtly
encourage us to focus on making apps that are not unnecessarily
dependent on other apps so that they might be reusable.
Finally, the annoyance of separate repositories only affects a small
portion of the community. The pip installer is a single step whether
it downloads one repository or two behind the scenes. Most rapidsms
app developers will be authoring and maintaining their own apps in
their own repositories. Some may contribute improvements to the
contrib apps. Fewer still will work on core framework code. Each of
these constituent groups (app developers, contrib developers, core
developers) have a different interests and, if the community continues
to grow, each will have its own champions and contributors independent
of the others.
It affects a huge portion of the people working on RapidSMS itself, and I think anything we can do to make volunteers' time better spent will go a long way to ensuring a cohesive product that people enjoy contributing to.
What do others think? In general, I'm still of the opinion that the contrib submodule adds little value to the project at the expense of a lot of pain for both developers and patch reviewers. If avoiding a "big hot mess" is what we need, I think that falls more on the core devs (and the rest of the community) to do in-depth code reviews, rather than any particular method of slicing up the code.
Yours,Tobias
> I agree, I believe that the core/contrib separation actually makes it harder
> to work on a patch. At least, I find that I have to jump through more hoops
> to actually test and submit the changes. I tried to record the method I used
> to submit my last patch here:
> http://docs.rapidsms.org/Development/Contributing/Example
I'm in agreement here too. Over the last two years we core dev's
failed at preventing a "big hot mess."
Adam and I had a nice talk about this the other night and I think that
the lack of extensibility in the old architecture had a lot to do with
this.
Colin, thanks for taking the time to write up your example. The
process is indeed ridiculous.
> There are a lot of steps and, possibly due to my unfamiliarity with git,
> changes to submodules can easily be lost or put you in a weird state unless
> you do everything correctly the first time. I don't know if this is the best
> method, but I figured I'd document it as a possible set of steps to submit a
> patch via GitHub. What does everyone else do? For me, the separation makes
> it harder to follow trunk (unless I want to introduce git submodules into my
> project dependency list), which is fairly easy with Django [1].
Yes it is very easy to get things very screwy and weird with git.
I'm thinking that whatever questionable value there is in using
submodules will never be worth the tradeoff of raising the barrier to
entry by requiring so much monkeying around with git.
> Further, the Hudson build server won't pick up contrib changes until a core
> dev updates the submodules, right? So contrib may receive several breaking
> pushes (from core or non-core devs), but the build server wont see the break
> until a core dev updates the reference in rapidsms-core-dev. Then the build
> breaks and emails core devs about failures introduced not in the most recent
> core commit, but rather commits made a while back in contrib.
> Regards,
> Colin
> [1] http://docs.djangoproject.com/en/dev/topics/install/?#installing-the-development-version
Another great point. A functional build server will probably be a
better way to help us prevent a hot mess.
Looking at the contrib apps:
ajax, djangoadmin, export, httptester, messagelog, registration,
search, default, echo, handlers, locations, messaging, scheduler,
training
I'm comfortable with all of them going into the main repository with
the exception of search and training. The training app, while awesome,
isn't designed for ongoing use during production -- and is a great
example of how app authors can modify rapidsms' core routing system
from the comfort of a discrete app. As for search, I think that we
should have some kind of search API offered to app authors, but until
this implementation is more widely used I believe it should live with
the community apps.
Color me convinced. I say we move ajax, djangoadmin, export,
httptester, messagelog, registration, default, echo, handlers,
locations, messaging, and scheduler into the main repository, and move
search and training into the community repository.
I think that timing these changes with the shifting of
rapidsms/rapidsms-core-dev code into rapidsms/rapidsms is a perfect
opportunity to do so.
Cheers,
Evan
+1 on that. let's merge contrib back into core.
</adam>
> I agree, I believe that the core/contrib separation actually makes it harder
> to work on a patch. At least, I find that I have to jump through more hoops
> to actually test and submit the changes. I tried to record the method I used
> to submit my last patch here:
> http://docs.rapidsms.org/Development/Contributing/Example
Colin, thanks for taking the time to write up your example. The
process is indeed ridiculous.
Looking at the contrib apps:ajax, djangoadmin, export, httptester, messagelog, registration,
search, default, echo, handlers, locations, messaging, scheduler,
training
I'm comfortable with all of them going into the main repository with
the exception of search and training. The training app, while awesome,
isn't designed for ongoing use during production -- and is a great
example of how app authors can modify rapidsms' core routing system
from the comfort of a discrete app. As for search, I think that we
should have some kind of search API offered to app authors, but until
this implementation is more widely used I believe it should live with
the community apps.
Color me convinced. I say we move ajax, djangoadmin, export,
httptester, messagelog, registration, default, echo, handlers,
locations, messaging, and scheduler into the main repository, and move
search and training into the community repository.
I think that timing these changes with the shifting of
rapidsms/rapidsms-core-dev code into rapidsms/rapidsms is a perfect
opportunity to do so.
I think that timing these changes with the shifting of
rapidsms/rapidsms-core-dev code into rapidsms/rapidsms is a perfect
opportunity to do so.+1