+1 to Adam's careful reasoning.
It looks like only the website location / names would be changing.
As part of this, it would be good to clean up the initial upload for this
which won't be used anymore (site-publish).
I'd like to see something get done here, so we can start incrementally
improvi
On 11/10/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
/common<<< the shared top node
/trunk
/uima-website
/uima-docbook
I think that things should be grouped under a trunk only if they are
likely to be branched/tagged together. I don't think
Marshall Schor wrote:
/uimaj
/trunk
/uimaj-x <<< the Java framework. Java examples, build
scripts, Eclipse tooling etc.
So if we organize all uimaj stuff like this, can we drop the uimaj-
prefix for the project names this time? I don't have a very strong
preference, I just t
Michael Baessler wrote:
But if I'm honest after this long discussion I do not remember all the
details of each of the
suggestions. I would like to have a summary of the two suggestions and
than start a vote for it.
Many projects save votes for those times where there is not a clear
consensus.
Marshall Schor wrote:
I think the bottom line is that both approaches can be argued for -
I don't have strong preference, except I do like to (in general)
split up things into more manageable-sized chunks. So, I think I would
come down on the side of having separate top-level projects for the
ui
Adam Lally wrote:
Even if there's no technical barrier (seeing as svn realizes branches
and tags as copies anyway), to me it's a more natural mental model if
branches/tags actually correspond to a single artifact that will be /
has been released together.
I think the bottom line is that both ap
On 11/9/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
> So branching and tagging aren't very straightforward in that scenario.
I'm not sure this is true. Yes, creating a branch or tag is copying the
whole project, but it is a lazy copy. So, yes, it would "collect a bunch of
things that didn't
Adam Lally wrote:
On 11/9/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
I like having more synchronization (as an option, not as a
requirement:-)
If we have, say, the C# framework under uima-sdk, and it has an
unsynchronized release schedule - would that be a problem or not?
It might be. I
On 11/9/06, Marshall Schor <[EMAIL PROTECTED]> wrote:
I like having more synchronization (as an option, not as a requirement:-)
If we have, say, the C# framework under uima-sdk, and it has an
unsynchronized release schedule - would that be a problem or not?
It might be. If we wanted to create
Adam Lally wrote:
I agree with that meaning of SDK, but seem to have come to the
opposite conclusion. :) What I was proposing as uima-sdk does break
down into uimaj-core, uimaj-tools and uimaj-examples, among other
things. It really does capture the whole SDK.
OK, I see your point. The uima-s
To me, the "SDK" has a meaning of adding tools, examples, etc. to a core
thing. Using it as a top-level collection name for the various
framework implementations seems a bit "off".
I agree with that meaning of SDK, but seem to have come to the
opposite conclusion. :) What I was proposing as ui
To me, the "SDK" has a meaning of adding tools, examples, etc. to a core
thing. Using it as a top-level collection name for the various
framework implementations seems a bit "off".
I think our big code bases (Java, C++, maybe others in the future - e.g.
C#, javaScript) could go into their own
How should we organize svn?
We can have one trunk/branch/tag and under it a bunch of "projects".
We can have multiple top-level things, each having (optionally)
trunk/branch/tag and under those a bunch of projects.
I say optionally, because I see projects that have "sandbox" as one of
the top
Our SVN structure is currently something like this:
site/
site_publish/
** the html files for our website are currently here
uimaj/
trunk/
uima-website/
** website sources are here
uima-docbooks/
** documentation is here
uimaj-/
** code is here
I like the idea
The initial import was to
.../incubator/uima/xxx/trunk/
The idea about xx was for "future" expansion. One of the x
might be sandbox, for instance.
Our initial software contribution is for the uima - java framework, so
for this, we set up xx = uimaj (j for Java).
This might b
15 matches
Mail list logo
