Paul Querna wrote:
What must be done is to cleary distinguish it from an Apache release.
Then it should be completely re-branded, ie, instead of 'Apache Foo'
it needs to be labeled 'Bar'.
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
AFAIU, we cannot label stuff in the lab as "Apache something", sometimes
I use "the 'Magma' Apache Lab", as a shortcut for "the thing called
'Magma' inside Apache Labs", but a lab should NOT be referred to as
"Apache something", because apart from being hosted on an Apache server
it is not an Apache project (apache is not the publisher, no IP
clearance, no community review or consensus, etc..), and should not use
the brand.
I'm not that good at legal stuff, and tried to understand how things
work, and came up with what follows. Please mind that this is my
understanding after reading around both the Labs documents and the
foundation documents, and I'm in no way in the position to state rules,
so please tell me where I'm wrong!
- A Lab is not an Apache project, so it should avoid any kind of Apache
branding, including the name. "Apache Labs" is anyway an Apache project,
so "my Apache Lab", "The Apache Lab named This", "The Apache Lab I'm PI"
or "The 'This' Apache Lab" maybe are ok.
... One "exception" to this is seems to be the package name. While it
could be considered branding, in practice it's quite common in similar
systems (like SourceForge, java.net etc..) to let individuals use the
namespace in packages. In fact the package name is used to prevent
name-clash and to denote where the source of the class is "coming from",
in a broad sense, so org.apache.mylabname should be ok, maybe he rule of
using org.apache.labs.something would be even better.
- Anyone on the internet can take any stuff in Apache svn (or anything
with an Apache license for that matter), eventually modify it (or not),
build it, package it, distribute it. So the PI (or anyone else) can take
the source or a Lab, build it, put it on the internet, either as source
or compiled artifact. Obviously, it must be crystal clear that this is
not an Apache release, and has been done without any of the steps
required by the "Apache way", so no community behind it, no IP
clearance, no safety net etc.. basically, it should in no way be
possible for the average user to think it is an Apache branded product.
Up to now this is left to the common sense of the PI, no explicit rule
has been established.
... I don't know if the artifacts can be published in the private http
committer space on Apache servers, I've seen these spaces being used to
"release" non official Apache (and non Apache) stuff before, but I would
personally avoid it.
... Publishing it on your own server, or deploying it using maven to a
repo hosted on a server of yours, printing the source code and
distributing it to customers of your local grocery store, should be fine.
- Branches and tags are development tools, not release tools. While it
is common practice to create a tag or a branch when a release is made,
tagging or branching (which in SVN is the same) has a broader semantic.
See the SVN manual, or all the advantages of using GIT, for description
of various scenarios where branching is used independently from a
release cycle.
... Agile development dictate the use of short cycles, so we should
expect a lab to have more than one cycle before getting to a state where
it can be promoted to incubator or to a hosting TLP. In this sense,
creating a branch/tag for a completed cycle should be ok, whether or not
in the same day you package the code, zip it, and put it on your blog as
"Finally something is working on my XXX effort on Apache Lab, this is a
zip with sources".
... That's also why I created the "current" and "next" versions in Jira,
to track cycles.
... So, yes, you can branch.
... I think you can use numeric names for your branches/tags, or dates,
or whatever, so you can branch for each progressive development cycle or
experimental fork. I would not use "RELEASE-1.0" as a branch name, cause
that could be interpreted by the ignorant as "The release 1.0 of a
trustworthy Apache product", but "1", "A", "0.1", "march-2009-1",
"20090316", could be fine, unless someone in the position to do it
establishes a rule for it.
I hope I'm guessing it right, and this is useful to other PIs.
Simone
--
Simone Gianni CEO Semeru s.r.l. Apache Committer
http://www.simonegianni.it/
---------------------------------------------------------------------
To unsubscribe, e-mail: labs-unsubscr...@labs.apache.org
For additional commands, e-mail: labs-h...@labs.apache.org
