You say "One of those is to be able to build releases for our community": do you mean that you are unhappy with the stated need to release from Apache and mark with "Incubating" (i.e. you want to release 1.x from SF)? Or if you were to bring the 1.x branches over to Apache, would you be prepared to swallow the bitter pill of 'incubator' markings on those releases?
I want 1.x to continue their lives inside apache. But I want, until graduation, the freedom to be able to release (at least the 1.2.x versions) on sf.net, without incubator string. The release is not made available through Apache hardware/infrastructure and not branded as such. I don't mind using the incubator label on 2.x or even possibly 1.3. I seriously *do* mind labeling the releases 1.2.x as incubator, and given the following reason, I think ASF would also: I know that we have (L)GPL code inside our Wicket-extensions project, which would prohibit any release of 1.2.x until that code has been replaced/removed. This is in my opinion unacceptable for a running project. We are in the process of replacing said code, but that does take time, and it is not likely to happen in the 1.2.x timeframe. So in order to provide support to our community we *need* the ability to perform releases. We do our best to remove all non-ASL compatible code for the things we want to be graduated. Until that happens we can't leave our users out in the cold. I know that for Apache folk the label 'incubator' doesn't qualify the project as 'bad', but in the world outside, that doesn't hold. I tend to stay away from any label other than the plain version number. Any other addition to that signifies 'not production ready'. I know a lot of developers that share this view. As we intend our stay inside the incubator to be transitional, I don't see a need to 'educate' all our users and the world outside about the view that incubator is merely a legal label. We don't intend to use the Apache brand outside the confined quarters of a graduated project, *other* than notifying people that we are moving towards Apache, and that all project related infrastructure such as mailinglists, bug tracker and code repository has moved to Apache (incubator) infrastructure. It is not only the label, but also the infrastructure. SF.net has for downloads a very good infrastructure available. When we want/need to release Wicket 1.x, we want it to be available through the best means available. This means that enough bandwidth is available for downloading the release.
As a side note, another issue I have noted regarding releases is that Incubator releases aren't allowed until all paperwork is in place. I would intend to have all paperwork in place before incubation begins, so that releases can be done soon in the incubation process.
Do you mean with that paperwork also that all code has to be ASL? Then there is no legal reason for a release to have the label 'incubating'. It is only a label to identify that the community is not yet mature enough for Apache standards. Martijn On 7/31/06, Upayavira <[EMAIL PROTECTED]> wrote:
Martijn Dashorst wrote: > Sorry for this lengthy response, but I got a negative vibe from > several reactions to this thread and I feel a need to vent my > concerns. > > First I am a big fan of Apache and the Apache community. I think that > the way Apache works is a great example of how a community effort can > produce great software. I think that the Wicket community is well on > its way to work in a similar fashion and would be a great addition to > the healthy community found at the ASF. I see several projects inside > ASF already working with Wicket and we always have shown interest in > working with Apache projects or using them. > > I saw a quote on the Wicket mailing list stating that 'SF.net is a > repository of open source projects and Apache is a community of people > working on open source projects' (sorry if I didn't quote this > correctly). This means IMO that PEOPLE are more important than > PROCESS. When Wicket is incubated, I fully intend to include as much > people from our community as possible. > > Someone suggested to fork the Wicket project into two: one at ASF for > Wicket 2.x and one at our current location (sf.net) for Wicket 1.x. A > forked community parted between 1.x and 2.x would be a disservice to > the Wicket community and I seriously frown upon such a suggestion. > This gives a message to those that they are not considered 'worthy' of > Apache. If the ASF is really concerned with building an open source > community, then the ASF should be working very hard to include > everyone. > > The knife cuts both ways: the Wicket community has to bite through > some hard bits, but so does the ASF imo. For us the hard bits will be > the loss of our total freedom to do whatever we want with our > framework (for instance, the possibility to incorporate any (L)GPL > code in our product), a (somewhat) more bureaucratic way of working, > and having to go through the incubation process which is uncertain and > will slow down the project. > > I am willing to bite through these bitter parts and join the ASF, but > only if ASF *also* is willing to accept some of Wicket's quirks. One > of those is to be able to build releases for our community, and make > them available at a convenient place with enough bandwidth and with > the quality people expect. > > Another is not having to rename all packages (in our 1.x branch) to > org.apache.wicket. Though this is a trivial thing to do, we strive to > keep API changes to a minimum between 1.y releases. Renaming *all* > packages doesn't add value for our users and only creates a major > inconvenience for them. Note that I don't have any problem with > renaming the packages for our 2.x branch to org.apache.wicket. Regards, Upayavira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Download Wicket 1.2.1 now! Embed Wicket components in your portals! -- http://wicketframework.org --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
