Project structure revision
Indrajit Raychaudhuri
We have had discussion off and on regarding revision of the project
structure. I have been wondering for a while on this and thought of
taking a fresh look.
So how about splitting the monolithic git repository into:
- Framework [github.com/lift/framework]
Consisting of base, webkit and persistence. It's almost same as
what we have in framework currently with two key differences -- webkit
gets separated and lift-modules moves out. The meat of Lift stays here.
The revised grouping becomes:
- base = (common, json, util)
- webkit = webkit for now but good candidate for split [1][2]
- persistence = all that we have in persistence for now but
expect some shuffling around (defer that debate for now).
- Modules [github.com/lift/modules]
To start with, this repository would be same as what we have now.
However, the intent is to materialize the lift-modules discussion that
Peter started a while back [3]
Consider this to be *a place* for Lift modules -- a module can
mean plugin, theme, widget, gadget, tweaks, tacks whatever in your own
world so long as one complies with
the specification (and thus the definition) of a Lift module :)
- Examples [github.com/lift/examples]
Usual stuff we have, however, we need to do a bit of gardening
there. The main idea is to have two variants of examples:
- the *gold class* example project bundling most or all of the
Lift features (one stop shop to see how a feature participates in the
whole). We need better name for examples/example, however :)
- feature specific projects detailing on a particular feature
(e.g., squeryl, mongo, scalate etc.)
Apart from the obvious academic and showcasing purpose, these also
serve as one level validation of enhancements and fixes being applied in
framework (beyond the test cases).
- Template.g8 [github.com/lift/template.g8]
The giter8 [4] template than can eventually replace archetypes and
SBT project templates.
- Archetypes [github.com/lift/archetypes]
We know what this is, but would be nice to have this deprecated
and eventually removed making way for Template.g8 (via giter8) and/or
SBT template projects that we have.
- Site [github.com/lift/site]
- Facilities [github.com/lift/facilities]
Place for SBT plugins, build scripts etc. Again this needs better
name, suggestion?
- *App [github.com/lift/mega_app, github.com/lift/giga_app,
github.com/lift/gaga_app etc.]
Additional standalone projects that might come up under Lift
family. Just a placeholder keeping into consideration the app related
discussions we had on the list.
Thoughts, suggestions?
- Indrajit
[1]
http://groups.google.com/group/liftweb/browse_thread/thread/8942477669fd1318
[2] http://groups.google.com/group/liftweb/msg/cc90c4015d2fbecb
[3]
http://groups.google.com/group/liftweb/browse_thread/thread/19f56a83b8479980
[4] https://github.com/n8han/giter8
Derek Chen-Becker
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
Naftoli Gugenheim
David Pollak
I am reluctant to break framework/archetypes/examples up. I find a lot of errors before committing by compiling all the code and by running various example apps. I think that if the repo were split up, it would be harder to do a full build and committers may be less likely to do end to end builds. I'm also not sure of the practical value of having separate repos.
--
You received this message because you are subscribed to the Google Groups "Lift" group.
To post to this group, send email to lif...@googlegroups.com.
To unsubscribe from this group, send email to liftweb+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/liftweb?hl=en.
--
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im
Surf the harmonics
Indrajit Raychaudhuri
Derek Chen-Becker wrote:
> How would this fit in with the build process? Currently you can do a
> full build of absolutely everything as a test before committing. Would
> that still be possible?
Yes, it would be with a one time setup of either of the following:
1. SBT way: a separate skeleton project having something like:
class LiftFullBuild(info: ProjectInfo) extends LiftProject(info)
{
lazy val framework = project("lift/framework")
lazy val modules = project("lift/modules", framework)
lazy val examples = project("lift/examples", framework, modules)
lazy val template = project("lift/template.g8", framework, modules)
}
2. Shell script: a shell script having something like:
action = "update clean install"
for proj in $projects
do
cd $proj; sbt $action
done
Installation in either case could be something like:
curl -LfsS https://github/com/lift/<script_tarball> | tar xzv -C ~/bin
Of course, things have to be tightened all around for release time
activities like cleanup of stale artifacts in local repo, generate
vscaladoc site etc. These additional activities, if mandated, would
probably make #2 more convenient to use.
>
> On Thu, Jan 6, 2011 at 8:22 AM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>> wrote:
>
> Folks,
>
> We have had discussion off and on regarding revision of the project
> structure. I have been wondering for a while on this and thought of
> taking a fresh look.
>
> So how about splitting the monolithic git repository into:
>
> - Framework [github.com/lift/framework
> <http://github.com/lift/framework>]
> Consisting of base, webkit and persistence. It's almost same as
> what we have in framework currently with two key differences --
> webkit gets separated and lift-modules moves out. The meat of Lift
> stays here.
> The revised grouping becomes:
> - base = (common, json, util)
> - webkit = webkit for now but good candidate for split [1][2]
> - persistence = all that we have in persistence for now but
> expect some shuffling around (defer that debate for now).
>
> - Modules [github.com/lift/modules <http://github.com/lift/modules>]
> To start with, this repository would be same as what we have
> now. However, the intent is to materialize the lift-modules
> discussion that Peter started a while back [3]
> Consider this to be *a place* for Lift modules -- a module can
> mean plugin, theme, widget, gadget, tweaks, tacks whatever in your
> own world so long as one complies with
> the specification (and thus the definition) of a Lift module :)
>
> - Examples [github.com/lift/examples
> <http://github.com/lift/examples>]
> Usual stuff we have, however, we need to do a bit of gardening
> there. The main idea is to have two variants of examples:
> - the *gold class* example project bundling most or all of the
> Lift features (one stop shop to see how a feature participates in
> the whole). We need better name for examples/example, however :)
> - feature specific projects detailing on a particular feature
> (e.g., squeryl, mongo, scalate etc.)
> Apart from the obvious academic and showcasing purpose, these
> also serve as one level validation of enhancements and fixes being
> applied in framework (beyond the test cases).
>
> - Template.g8 [github.com/lift/template.g8
> <http://github.com/lift/template.g8>]
> The giter8 [4] template than can eventually replace archetypes
> and SBT project templates.
>
> - Archetypes [github.com/lift/archetypes
> <http://github.com/lift/archetypes>]
> We know what this is, but would be nice to have this deprecated
> and eventually removed making way for Template.g8 (via giter8)
> and/or SBT template projects that we have.
>
> - Site [github.com/lift/site <http://github.com/lift/site>]
>
> - Facilities [github.com/lift/facilities
> <http://github.com/lift/facilities>]
> Place for SBT plugins, build scripts etc. Again this needs
> better name, suggestion?
>
> - *App [github.com/lift/mega_app
> <http://github.com/lift/mega_app>, github.com/lift/giga_app
> <http://github.com/lift/giga_app>, github.com/lift/gaga_app
> <http://github.com/lift/gaga_app> etc.]
> Additional standalone projects that might come up under Lift
> family. Just a placeholder keeping into consideration the app
> related discussions we had on the list.
>
> Thoughts, suggestions?
>
> - Indrajit
>
> [1]
> http://groups.google.com/group/liftweb/browse_thread/thread/8942477669fd1318
> [2] http://groups.google.com/group/liftweb/msg/cc90c4015d2fbecb
> [3]
> http://groups.google.com/group/liftweb/browse_thread/thread/19f56a83b8479980
> [4] https://github.com/n8han/giter8
>
> --
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
Indrajit Raychaudhuri
Naftoli Gugenheim wrote:
> Maybe we need to also have a parent repository that has scripts to check
> out everything into child directories, and has the pom or sbt project to
> build everything in them.
Yes, sort of. With the difference that the parent repository doesn't
necessarily be a git repository. It can stay as a tarball in
github/assembla or as a gist.
>
>
> On Thu, Jan 6, 2011 at 3:32 PM, Derek Chen-Becker <dchen...@gmail.com
> <mailto:dchen...@gmail.com>> wrote:
>
> How would this fit in with the build process? Currently you can do a
> full build of absolutely everything as a test before committing.
> Would that still be possible?
>
>
> On Thu, Jan 6, 2011 at 8:22 AM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>> wrote:
>
> Folks,
>
> We have had discussion off and on regarding revision of the
> project structure. I have been wondering for a while on this and
> thought of taking a fresh look.
>
> So how about splitting the monolithic git repository into:
>
> - Framework [github.com/lift/framework
> <http://github.com/lift/framework>]
> Consisting of base, webkit and persistence. It's almost
> same as what we have in framework currently with two key
> differences -- webkit gets separated and lift-modules moves out.
> The meat of Lift stays here.
> The revised grouping becomes:
> - base = (common, json, util)
> - webkit = webkit for now but good candidate for split [1][2]
> - persistence = all that we have in persistence for now
> but expect some shuffling around (defer that debate for now).
>
> - Modules [github.com/lift/modules
> <http://github.com/lift/modules>]
> To start with, this repository would be same as what we
> have now. However, the intent is to materialize the lift-modules
> discussion that Peter started a while back [3]
> Consider this to be *a place* for Lift modules -- a module
> can mean plugin, theme, widget, gadget, tweaks, tacks whatever
> in your own world so long as one complies with
> the specification (and thus the definition) of a Lift module :)
>
> - Examples [github.com/lift/examples
> <http://github.com/lift/examples>]
> Usual stuff we have, however, we need to do a bit of
> gardening there. The main idea is to have two variants of examples:
> - the *gold class* example project bundling most or all of
> the Lift features (one stop shop to see how a feature
> participates in the whole). We need better name for
> examples/example, however :)
> - feature specific projects detailing on a particular
> feature (e.g., squeryl, mongo, scalate etc.)
> Apart from the obvious academic and showcasing purpose,
> these also serve as one level validation of enhancements and
> fixes being applied in framework (beyond the test cases).
>
> - Template.g8 [github.com/lift/template.g8
> <http://github.com/lift/template.g8>]
> The giter8 [4] template than can eventually replace
> archetypes and SBT project templates.
>
> - Archetypes [github.com/lift/archetypes
> <http://github.com/lift/archetypes>]
> We know what this is, but would be nice to have this
> deprecated and eventually removed making way for Template.g8
> (via giter8) and/or SBT template projects that we have.
>
> - Site [github.com/lift/site <http://github.com/lift/site>]
>
> - Facilities [github.com/lift/facilities
> <http://github.com/lift/facilities>]
> Place for SBT plugins, build scripts etc. Again this needs
> better name, suggestion?
>
> - *App [github.com/lift/mega_app
> <http://github.com/lift/mega_app>, github.com/lift/giga_app
> <http://github.com/lift/giga_app>, github.com/lift/gaga_app
> <http://github.com/lift/gaga_app> etc.]
> Additional standalone projects that might come up under
> Lift family. Just a placeholder keeping into consideration the
> app related discussions we had on the list.
>
> Thoughts, suggestions?
>
> - Indrajit
>
> [1]
> http://groups.google.com/group/liftweb/browse_thread/thread/8942477669fd1318
> [2] http://groups.google.com/group/liftweb/msg/cc90c4015d2fbecb
> [3]
> http://groups.google.com/group/liftweb/browse_thread/thread/19f56a83b8479980
> [4] https://github.com/n8han/giter8
>
> --
> You received this message because you are subscribed to the
> Google Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
David Bernard
Indrajit Raychaudhuri
David Pollak wrote:
>
>
> On Thu, Jan 6, 2011 at 7:22 AM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>> wrote:
>
> Folks,
>
> We have had discussion off and on regarding revision of the project
> structure. I have been wondering for a while on this and thought of
> taking a fresh look.
>
> So how about splitting the monolithic git repository into:
>
> - Framework [github.com/lift/framework
> <http://github.com/lift/framework>]
> Consisting of base, webkit and persistence. It's almost same as
> what we have in framework currently with two key differences --
> webkit gets separated and lift-modules moves out. The meat of Lift
> stays here.
> The revised grouping becomes:
> - base = (common, json, util)
> - webkit = webkit for now but good candidate for split [1][2]
> - persistence = all that we have in persistence for now but
> expect some shuffling around (defer that debate for now).
>
> - Modules [github.com/lift/modules <http://github.com/lift/modules>]
> To start with, this repository would be same as what we have
> now. However, the intent is to materialize the lift-modules
> discussion that Peter started a while back [3]
> Consider this to be *a place* for Lift modules -- a module can
> mean plugin, theme, widget, gadget, tweaks, tacks whatever in your
> own world so long as one complies with
> the specification (and thus the definition) of a Lift module :)
>
> - Examples [github.com/lift/examples
> <http://github.com/lift/examples>]
> Usual stuff we have, however, we need to do a bit of gardening
> there. The main idea is to have two variants of examples:
> - the *gold class* example project bundling most or all of the
> Lift features (one stop shop to see how a feature participates in
> the whole). We need better name for examples/example, however :)
> - feature specific projects detailing on a particular feature
> (e.g., squeryl, mongo, scalate etc.)
> Apart from the obvious academic and showcasing purpose, these
> also serve as one level validation of enhancements and fixes being
> applied in framework (beyond the test cases).
>
> - Template.g8 [github.com/lift/template.g8
> <http://github.com/lift/template.g8>]
> The giter8 [4] template than can eventually replace archetypes
> and SBT project templates.
>
> - Archetypes [github.com/lift/archetypes
> <http://github.com/lift/archetypes>]
> We know what this is, but would be nice to have this deprecated
> and eventually removed making way for Template.g8 (via giter8)
> and/or SBT template projects that we have.
>
> - Site [github.com/lift/site <http://github.com/lift/site>]
>
> - Facilities [github.com/lift/facilities
> <http://github.com/lift/facilities>]
> Place for SBT plugins, build scripts etc. Again this needs
> better name, suggestion?
>
> - *App [github.com/lift/mega_app
> <http://github.com/lift/mega_app>, github.com/lift/giga_app
> <http://github.com/lift/giga_app>, github.com/lift/gaga_app
> <http://github.com/lift/gaga_app> etc.]
> Additional standalone projects that might come up under Lift
> family. Just a placeholder keeping into consideration the app
> related discussions we had on the list.
>
> Thoughts, suggestions?
>
>
> I am reluctant to break framework/archetypes/examples up. I find a lot
> of errors before committing by compiling all the code and by running
> various example apps. I think that if the repo were split up, it would
> be harder to do a full build and committers may be less likely to do end
> to end builds.
I am hoping that won't happen if all committers agree to follow a
convention and set up a one time script (from a tarball or gist). That
script (shell gives maximum flexibility, but SBT should be fine too)
should be able to do full build in sequence. It should do all that "mvn
clean install" does and some more (hopefully ;))
> I'm also not sure of the practical value of having
> separate repos.
This was driven in my mind because of a mix of few things. We can
hopefully bring the 'projects as directory in a single git project' vs
'projects as separate git projects in Lift organization' to some
conclusion in course of the discussion.
1. Currently, we already have some repos separately, the intent is to
embrace that and streamline things via a higher order build script.
2. We have had related discussion(s) earlier on this. The most recent
that comes to my mind is in the context of Lift CMS [1]. Projects like
CMS, examples can have the best of both worlds. On one hand, their
master branches can always stay synced with framework master and
maintain build consistency and on the other hand have, say, LTS branches
which can be separately built as a '10 min activity' instead of a 110
min one ;)
Doing partial build is meant to be done with discretion and not a
general norm though, but you have the option at least.
3. The other advantage of having projects built in sequence is (a) you
can resume from when you left for failed build or (b) build a downstream
project separately without dealing with the whole of build starting from
lift-common. For example, doing a build for examples (for
demo.liftweb.net) shouldn't require a full build of all the
dependencies. This is more to do with structuring the build than
splitting the repo. But keeping them aligned might be convenient.
4. Related to above, trying out an example (from the examples project)
shouldn't require the whole of Lift framework to be downloaded and
built. Taking too long to build and arrive at the point of 'interest'
could be a little bit of niggle. One can argue that cd-ing to examples
and doing a 'clean install' should suffice. But that might not be
apparent to a SBT/Maven newbie. The revised message instead could be:
"Do a 'git clone' of examples, do 'sbt update jetty', play!"
4. Additionally, if we intend to support giter8, we need separate
project (giter8 looks for a separate one via github api). But this is a
trivial point.
5. Finally, archetypes don't seem to fit into the main project anymore
(more so with better alternatives around). Taking it out of main project
can be step 0 toward deprecation and eventual removal in the long term.
[1]
http://groups.google.com/group/liftweb/browse_thread/thread/826255e93c36fa2f/9c5a59cc232bc039
>
>
> - Indrajit
>
> [1]
> http://groups.google.com/group/liftweb/browse_thread/thread/8942477669fd1318
> [2] http://groups.google.com/group/liftweb/msg/cc90c4015d2fbecb
> [3]
> http://groups.google.com/group/liftweb/browse_thread/thread/19f56a83b8479980
> [4] https://github.com/n8han/giter8
>
> --
> You received this message because you are subscribed to the Google
> Groups "Lift" group.
> To post to this group, send email to lif...@googlegroups.com
> <mailto:lif...@googlegroups.com>.
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>.
Indrajit Raychaudhuri
David Bernard wrote:
> If you decide to split in multi repo, may be, using "git module" could
> be used to have a lift project/repo (like now) that aggregate all other
> and provide full build script.
>
> http://book.git-scm.com/5_submodules.html
>
> <http://book.git-scm.com/5_submodules.html>It will also allow smooth
> migration, eg extracting archetypes first, then exemples, instead of one
> big bang.
David, I am very keen and open to git submodule (Tim had suggested this
too) but the first time we tried going this route (in a separate project
at work) we had trouble figuring out the 'right way' in getting around
dealing with branches in the submodules. Further, people just forgot to
push a project but pushed the other project referring to that one. The
result was exact problem Scott Chacon mentioned in his book [1] ;-P
Since the previous experiment didn't work too well (in a team of < 10
committers) I thought being conservative in a team of > 30 committers
would be prudent. That said, I am all ears to advice/suggestion on a
clean git submodule workflow that works for Lift commit process.
- Indrajit
[1] http://progit.org/book/ch6-6.html
>
> Cheers,
>
> /davidB
>
> On Fri, Jan 7, 2011 at 06:33, Indrajit Raychaudhuri <indr...@gmail.com
> <mailto:indr...@gmail.com>> wrote:
>
>
>
> Naftoli Gugenheim wrote:
>
> Maybe we need to also have a parent repository that has scripts
> to check
> out everything into child directories, and has the pom or sbt
> project to
> build everything in them.
>
>
> Yes, sort of. With the difference that the parent repository doesn't
> necessarily be a git repository. It can stay as a tarball in
> github/assembla or as a gist.
>
>
>
> On Thu, Jan 6, 2011 at 3:32 PM, Derek Chen-Becker
> <dchen...@gmail.com <mailto:dchen...@gmail.com>
> <mailto:dchen...@gmail.com <mailto:dchen...@gmail.com>>>
> wrote:
>
> How would this fit in with the build process? Currently you
> can do a
> full build of absolutely everything as a test before committing.
> Would that still be possible?
>
>
> On Thu, Jan 6, 2011 at 8:22 AM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>
> <http://github.com/lift/site> <http://github.com/lift/site>]
> <mailto:lif...@googlegroups.com <mailto:lif...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>
> <mailto:liftweb%2Bunsu...@googlegroups.com
> <mailto:liftweb%252Buns...@googlegroups.com>>.
>
> For more options, visit this group at
> http://groups.google.com/group/liftweb?hl=en.
>
>
> --
> You received this message because you are subscribed to the
> Google
> Groups "Lift" group.
> To post to this group, send email to
> lif...@googlegroups.com <mailto:lif...@googlegroups.com>
> <mailto:lif...@googlegroups.com <mailto:lif...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>
> <mailto:liftweb%2Bunsu...@googlegroups.com
> <mailto:liftweb%252Buns...@googlegroups.com>>.
David Pollak
Indrajit Raychaudhuri
David Pollak wrote:
> Indrajit,
>
> You have a bunch of good reasons for splitting.
>
> There's one last issue for me: examples/example and new features.
>
> Often when I add a new feature (which is always done on a branch), I
> will add code to examples/example to demonstrate the feature.
>
> If I have to remember that I've got two branches that I have to merge
> and if the change set is not unified (so folks can see the use of the
> new feature on review board), it adds overhead.
This is a general con with this approach. It can happen not only for the
examples, but generally for any downstream artifact belonging to a
different repository (changes in webkit can affect a module as well as
an example). I am hoping we can deal with the RB part in two ways:
1. Using 'git diff' (via the ubiquitous script and posting all the diffs
together) doing something like:
for proj in $projects
do
cd $proj; git diff > $issueid
done
Caveat: current RB web interface doesn't allow adding multiple diff
together for review
2. Using gnu diffutil:
Instead of doing git diff/apply we use gnu diff/patch. It's available on
Linux, Mac and in Windows (via Cygwin - using Git on Windows imply it's
there :)).
Apart from the specific case of examples (it's an overhead there), using
separate workflow (branch > RB > merge) can add to the reliability on
the other hand.
Notes
a: Git submodule would have been a nice way to deal with this but I am
not too sure we can avoid things falling through the crack.
b: In some sense it exists currently too (lift_22_sbt), just that it
doesn't hurt yet because of the low overhead.
>
> On Thu, Jan 6, 2011 at 11:28 PM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>> wrote:
>
>
>
> David Pollak wrote:
>
>
>
> On Thu, Jan 6, 2011 at 7:22 AM, Indrajit Raychaudhuri
> <indr...@gmail.com <mailto:indr...@gmail.com>
> <http://github.com/lift/modules> <http://github.com/lift/modules>]
> <http://github.com/lift/site> <http://github.com/lift/site>]
> examples (for demo.liftweb.net <http://demo.liftweb.net>) shouldn't
> <mailto:lif...@googlegroups.com <mailto:lif...@googlegroups.com>>.
>
> To unsubscribe from this group, send email to
> liftweb+u...@googlegroups.com
> <mailto:liftweb%2Bunsu...@googlegroups.com>
> <mailto:liftweb%2Bunsu...@googlegroups.com
> <mailto:liftweb%252Buns...@googlegroups.com>>.
Derek Chen-Becker
Naftoli Gugenheim
Indrajit Raychaudhuri
Derek Chen-Becker wrote:
> AFAIK, any diff in RB has to be associated with a single repo, so unless
> we want to do multiple reviews per commit when including example code,
> etc...
Hmm, so this actually leads to multiple review. That's obviously more
overhead.
So how about making RB request for the feature commit (framework repo)
and posting the github diff url for examples change?
Something like:
1. Post RB request with the feature add/fix diff
2. Post github link to the changeset(s) or the specific feature branch
for examples in the description [github.com/lift/examples/comit/a1b1c1]
3. Post Assembla link
4. Request review
We do #1, #3, #4 the usual way - just add #2 as the only extra step.
>
> On Fri, Jan 7, 2011 at 11:02 AM, Indrajit Raychaudhuri
> <mailto:liftweb%2Bunsu...@googlegroups.com
> <mailto:liftweb%252Buns...@googlegroups.com>
> <mailto:liftweb%252Buns...@googlegroups.com
> <mailto:liftweb%25252Bun...@googlegroups.com>>>.
Indrajit Raychaudhuri
about repo here [2]. Yes, the intent is similar. However, I don't know
if it can fit our RB based workflow (instead of Gerrit based one)
without going thorough more than 'smallish hurdle'.
- Indrajit
[1] http://android.git.kernel.org/repo
[2] http://source.android.com/source/git-repo.html
Naftoli Gugenheim wrote:
> I wonder if any of the discussion here
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=257706#c128 is relevant,
> specifically about the 'repo' script android uses to manage multiple
> repositories.
>
>
> On Fri, Jan 7, 2011 at 3:23 PM, Derek Chen-Becker <dchen...@gmail.com
> <mailto:dchen...@gmail.com>> wrote:
>
> AFAIK, any diff in RB has to be associated with a single repo, so
> unless we want to do multiple reviews per commit when including
> example code, etc...
>
>
> On Fri, Jan 7, 2011 at 11:02 AM, Indrajit Raychaudhuri
> <mailto:liftweb%2Bunsu...@googlegroups.com
> <mailto:liftweb%252Buns...@googlegroups.com>
> <mailto:liftweb%252Buns...@googlegroups.com
> <mailto:liftweb%25252Bun...@googlegroups.com>>>.