A pretty long answer, so please bear with me.
On Mon, Apr 2, 2012 at 7:03 PM, Igor Vaynberg <[email protected]> wrote:
> from a couple of replies to this thread i am a little confused. are we
> talking about keeping experimental things in different modules on
> master or different branches?
Master.
> obviously the big problem is that not everyone has access to the
> apache git repo, so projects will still pop up on github, etc, if they
> require collaboration from non-committers.
Then make them committers. The bar for becoming a Wicket committer is
neigh impossible to reach. The whole idea is to grow our community,
not stifle it. Doing development at Apache is the whole point. We
became an Apache community when we joined the incubator and graduated.
This means IMO that we should develop at Apache, not develop elsewhere
and patch when convenient.
> if, this is directed at committers, there are a couple of issues that
> need to be discussed.
It is directed at committers.
> 1) sometimes its not possible to release the code, ie wicket-cdi which
> lacks necessary maven dependencies in central. what do we do in those
> cases?
First of all we need to get on the same page of what constitutes a
release. What you and I regarded as releases from Apache is apparently
false. Recent discussions that have surfaced at the incubator show
that we do our releases wrong from an ASF policy standpoint [1].
The gist of the discussion is (I paraphrase):
This is what we should vote on:
* An Apache Release consists only of source code.
* Nothing more, no binaries.
* What we vote on is just the source tar ball
* Without any binary build artifacts (i.e. class files, jars) inside
or alongside
Additionally:
* we can provide for end users convenience jar files, and other
binary distributions of our code.
So instead of a zip/tar.gz file with source and binaries we should
just vote on and release a signed archive of a git tag without any
binary build artifacts. Next we can additionally provide our jar files
into the maven repository.
PS. I think this makes testing the releases a lot easier: no need to
configure a repository to download the artifacts, but just download
the tar ball and run mvn install inside. Then you have the binary
artifacts in your local repo to play with, without having it shared in
the company repository. When everything is dandy, you can nuke the
local artifacts, vote +1 and wait until the release manager promotes
the convenience artifacts to maven central.
So to get back at your question 1): what do we do with projects that
can't be released until dependencies are in Maven central?
If the code is working, but the dependencies are unavailable from
Maven central we can either publish the code as part of our tar ball,
and not push the modules to Maven central (which is the real
objection), or not publish the code as part of our tar ball (e.g. two
folders in our repository: releasable/ and experimental/)
> 2) sometimes a project is just an idea to play with. once we release
> it as a 0.1 module we have to at least somewhat maintain it. and what
> if the idea doesnt pan out, is it ok to just drop the module?
Yes. We can decide to drop the module. Read the ASL section 7 [2] that
covers our releases:
7. Disclaimer of Warranty. Unless required by applicable law or
agreed to in writing, Licensor provides the Work (and each
Contributor provides its Contributions) on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
implied, including, without limitation, any warranties or conditions
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
PARTICULAR PURPOSE. You are solely responsible for determining the
appropriateness of using or redistributing the Work and assume any
risks associated with Your exercise of permissions under this License.
Even for Wicket 1.5.5 we don't claim that it works for any particular
use case. It might just work for building web applications, but there
is no warranty that Wicket actually works for that purpose. Go figure
what this means for a 0.1 version of a module.
> what happens with the dropped code if someone outside wicket wants to work
> on it, does it move back to github?
That is also an option. Move the code to wicket stuff, or github or
google code or whatever. This is also covered by section 2 of our
license [2]:
2. Grant of Copyright License. Subject to the terms and conditions of
this License, each Contributor hereby grants to You a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
copyright license to reproduce, prepare Derivative Works of,
publicly display, publicly perform, sublicense, and distribute the
Work and such Derivative Works in Source or Object form.
When we decided to use semver [3], we obtained the option to release
code with a version < 1.0 where there are no guarantees of stability
or future support. [even for wicket-core we don't guarantee any
support, see the Apache License]. AFAIC we develop experimental code
at Apache, ship it with our main releases, but with a different
version number. If things don't work out, we move it to github (but if
it doesn't work, why would it be workable on github?), or drop it.
Anyone is free to take the work and put it on their personal github
space. The only thing is that package names and the Maven coordinates
(GAV) should be renamed.
In short, we should:
- modify our release process to vote just on the source tar ball
- provide additional binaries for convenience to our users at apache
(doesn't require a vote)
- start working on experimental stuff, new modules at Apache
- release those with versions < 1.0 until mature enough to be
included in proper, then version with proper
[ - use an experimental/ sub folder in our project structure for these modules]
Martijn
[1] http://markmail.org/message/a4kbf33vn57dkz2j
[2] http://www.apache.org/licenses/LICENSE-2.0.txt
[3] http://semver.org
