Re: OASIS
Dirk-Willem van Gulik wrote: Within the ASF we have a number of projects which deal with formats and standards close to OASIS. random examples: docbook, uddi, relax ng. We've been approached by OASIS to see if it makes sense to join them. This is a call out to Community to see if that makes sense. Why does Oasis think it makes sense? Just because we implement some of their standards? Do you think it makes sense in light of all the objections you raised? Can you elaborate? - Any 'pay to play' is generally an issue for us on fundamental grounds. exactly. Looking at the current oasis setup, it seems its also pay more to play more, which I like even less. (This as opposed to an organisation like eclipse where its more pay as you can probably afford because we really do need some money.) But having said that - we've been able to resolve these issues in the past with some other similar organisations. right. I think most differences (like the preferred communication medium) are easy enough to resolve, as long as there is enough benefit. So - community - do we see enough benefit to start this conversation with Oasis? Uhm, no. But so far no-one has even tried to show any benefits and I'm pretty ignorant so that's not very surprising :-D Do we want to be close to some of their standards ? Me personally, nope. Generally, I think it is good for organisations like the ASF to have a say about technological standards. I think the JCP opened up significantly thanks to the ASF and if that's an exercise that we can repeat without any detrimental effect to the ASF...sure. If there's enough volunteers. I'm not particularly interested in most of the OASIS standards myself. from the peanut gallery, - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Subversion plugin for intellij idea 4.0.3
On linux: http://www.jroller.com/comments/lsd?anchor=howto_install_subversion_and_the On Mac OS X: http://kasparov.skife.org/blog/2004/05/20 Man is that a pain to figure out! cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache should join the open source java discussion
Something big is stirring in the java world. There's talks between Sun and IBM about releasing an open source version of java. There's talks between the linux desktop movers about adopting java as the glue that binds the major desktop projects together. Key ASF individuals are joining these discussions, on weblogs and various discussion forums. But the ASF as a whole is silent. Apache is one of the biggest open source communities, and the leader of the pack when it comes to open source java. I think the Apache community should work together on an open letter to Sun, IBM, and the rest of the open source community stating our shared position on the subject. Like Havoc Pennington writes (http://ometer.com/desktop-language.html), the Community Should Decide and It's time to start the discussion. WDYT? -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: planet aggregation doing some editing?
Thom May wrote: malicious users huh? Who would that be? -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: automatic nagging for board reports?
Leo Simons wrote: comments? Good idea? FWIW, I decided there was not enough interest to make me want to do the work :D -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Who decides who is 'worthy' for Planet Apache?
snip/ Thom and Ted, IIRC. I agreed with the decision. Several others did as well, apparently. I think if gump's postings were limited to a 1-or-2-paragraph message once a day, it might've been different. OTOH...reading a build failure just isn't as much fun as reading about someone's holiday. The former is work, the latter is a break away from work :D Hmmm. I guess a characterizing part of many weblogs is that they are a lot more personal than what is said on a mailing list (for example). The characteristic of the gump feed is that it's machine-generated. Which is not personal at all. It is useful (like bugzilla reports or jira reports or automated reports from other infrastructural services), but its not personal. Don't feel too bad about it (its nothing personal!). Just get yourself a human-written weblog and join that way ;) cheers! - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
automatic nagging for board reports?
(replies to community@ please) I believe many ASF projects are chronically late in sending in status reports in time for the board meeting. That's bad and they should be nagged about it. Since manual nagging is a chore, how about a small script in a crontab somewhere that automates sending out a timely reminder? I'll volunteer to set it up if such a thing is desireable. I just need the report schedule and some time. Or maybe we could (mis)use Jira? comments? Good idea? -- cheers, - Leo Simons --- Weblog -- http://leosimons.com/ IoC Component Glue -- http://jicarilla.org/ Articles Opinions -- http://articles.leosimons.com/ --- We started off trying to set up a small anarchist community, but people wouldn't obey the rules. -- Alan Bennett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Plant Apache is now online
Adam R. B. Jack wrote:
Leo, I hope this will reduce bandwidth utilization on your machine ('cos
folks won't poll your feed directly), but it might lead to more (as folks
follow through stories to get details.) I'll move this to gump.apache.com
(or whatever it is called) as soon as it available. Please let me know if
this is a problem.
bandwidth problem? Nah
Apparently, the machine has so far handled about a gig of http traffic
in january (all of december was 600mb). I think the campus usage policy
allows 10GB per week of outside-of-campus traffic. If it becomes an
issue, I'm sure that the network admins will cut me some slack. Given
the half a dozen tomcat instances and several dozen httpd instances that
run here at the university, I'll just go and thumb on some heads with a
big club if they don't :D
--
cheers,
- Leo Simons
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Policy for Jakarta Wiki(s)
Andrew C. Oliver wrote: That¹s fine, but the results aren't very useful see this: http://wiki.apache.org/general/FindPage?action=titlesearchvalue=FAQ This is what I mean (across wikis): http://nagoya.apache.org/wiki/apachewiki.cgi?search=FAQdosearch=1 The main issue I have with splitting things up are search nope, definately not the same. But I do suspect that within time, as the moin wiki actually sees usage (and a better pagerank), the google search will improve. I don't think it will be very difficult to add a cross-wiki fulltext search of our own, but I don't have time to do that atm. Maybe in a week or two. and linkage. I think this is more of a personal thing :D. I've always liked the Moin style of linking a lot better. Alsoa, its all about what links you mean, of course. For example, contrast http://wiki.apache.org/geronimo/FAQ (no, it doesn't exist yet, but it could) with http://nagoya.apache.org/wiki/apachewiki.cgi?ApacheJ2EE/FAQ I have no objections otherwise (supposing someone else has the headache of dealing with 100 different wiki configs). yep. Jason set up a nice little system for that. Its unfortunate no wiki supports namespaces of a sort. +1. No wiki is perfect, which is why there are so many, I guess. - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Clover license for the ASF?
Hi Conor, Brendan, everyone, Conor MacNeill wrote: On Tue, 11 Nov 2003 05:40 am, Leo Simons wrote: Hi gang, Has anyone requested an ASF-wide clover license yet, or discussed it with the clover people? Would that be a good idea to do? Does anyone have any contacts over at Cortex? i Leo, I work for Cortex. We are happy to give free licenses to individual open-source projects upon request. I know, and that's cool! What I'm hoping for is that Cortex would be willing to grant such a license to the ASF as a whole. After all, all of the ASF projects are public, community-developed open source projects, so it seems all those projects would be eligible for such a free license..an asf-wide license would make life for all those projects a little easier since it'd reduce administration overhead. Thoughts, anyone? cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Clover license for the ASF?
Hi gang, Clover is a cool tool for calculating unit test coverage of java software (http://www.thecortex.net/clover/). They make free copies available to open source projects (http://www.thecortex.net/clover/freelicense.jsp); some ASF projects already have received such licenses (http://www.thecortex.net/clover/testimonials.html). Has anyone requested an ASF-wide clover license yet, or discussed it with the clover people? Would that be a good idea to do? Does anyone have any contacts over at Cortex? cheers! - LSD - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Follow the example
Ceki Gülcü wrote: Avalon http://avalon.apache.org/ done. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Common documents across the ASF
Tim, you missed my point. Sander asked whether commit access is, or is seen as, a barrier. The answer is: yes. It is one of many barriers that we have. You're pointing out that those are in place for a reason. Well, yeah. For example, commit priviledge is something which is earned by individuals and given out by a community, hence facilitating a community feel. Someone who is granted committer status usually feels honoured to be asked to be part of the team. Works nicely. Now the catch: for some stuff, I happen to think some current barriers don't make sense. They result in lots of unneccessary duplication (of effort and material). general documentation is one of those areas. A low barrier to cross-project co-operation on stuff like that will help avoid pages like http://httpd.apache.org/dev/nt-cvs-ssh.txt IOW, this is not about technical difficulty or community dynamics, it is about managing the path of least resistance for a common cross-project concern which is completely orthogonal to the reason(s) for the existence of our barriers. cheers! - Leo Tim O'Brien wrote: rant-disclaimer/snip/stuff/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
news.apache.org (was: apache.org vs. mozilla.org)
Stefano Mazzocchi wrote: Now, I'm asking: what if the ASF provides its own news server that wraps around all our current mail lists setup and make them available to all news-archiving services and news-reading clients? +1 NNTP makes more sense than SMTP for group discussions. I read allmost all OSS mailing lists I participate in through gmane. It kicks major ass. - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Costin Manolache wrote:
On Tue, 25 Feb 2003, Leo Simons wrote:
files in /dist/java-repository besides perhaps HEADER.html and
README.htmls...
Few simple questions:
Should we use 2 different dirs for src and binary distribution ? Or maybe
3 dirs ( src, bin, doc ) ?
based on current practice at http://www.ibiblio.org/maven, the answer to
both is no. A quick
glance at the java projects @ http://www.apache.org/dist/ also seems to
result in a no. The
most standard practice seems to be to append -src or -bin, resulting in
filenames of
/dist/${project}/${subproject}/${version}/${package}-${version}-bin.${fomat}
/dist/${project}/${subproject}/${version}/${package}-${version}-src.${fomat}
where ${subproject} can be ., and the /${version} part in the path is
often ommitted.
Are milestone builds acceptable ? Should we get some weekly gump builds
from HEAD into the repository ?
That's up to each project to decide I think. My opinion is that once you
provide a distribution of
a file, you need to keep providing it at the same URL for a timespan
close to eternity. This seems a
good argument to not place milestones or weeklies here.
What policy should we use for removing older versions ( or we just keep
everything ) ?
my take: keep everything. Again, policy should be the same as for the
contents of /dist/. I dunno
if there is an asf-wide policy for that...looking at
http://www.apache.org/dist/httpd/old/, those guys
don't share my view :D
Since the versioned jar/unversioned dir format is used - I think various
PMCs should try to get the various projects to use the same format internally.
I would prefer the reverse ( versioned dirs / unversioned jars ) - but I
can live with the reverse if it does have a majority support.
Could we put at least this option to a vote, just to have a record that it
isn't just a random decision but what the committers really want ?
we could do that, but the big disadvantage with deviating from the
existing maven/centipede/ruper
practice is that it deviates from that practice, thus requiring work and
reducing compatibility. If you
feel like holding a vote, by all means feel free, I'll probably vote -1
for deviating from the existing
format (unless you've got a good argument rather than preference; I
share your preference but it
is just that ;)
cheers,
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Costin Manolache wrote: I see no problem if Ant, Gump, Centipede cooperate on the jar repository - and maven doesn't. uhm, I would like to see all of the above and the rest of us cooperate on this thing. The value of everyone's work on setting up and maintaining such a repo decreases rapidly with decrease of support in the actual tools used for interfacing with the repo. I for one don't feel like having to maintain multiple repos. But OTOH, I don't feel like spending more energy arguing than it would take to set up those multiple repos. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Costin Manolache wrote: What policy should we use for removing older versions ( or we just keep everything ) ? my take: keep everything. Again, policy should be the same as for the contents of /dist/. I dunno if there is an asf-wide policy for that...looking at http://www.apache.org/dist/httpd/old/, those guys don't share my view :D What about a at least 6 months and 2 versions back ? quoting yourself, how about: +1 for each project/PMC choosing what to publish/remove. And you and I can recommend to each project/PMC our respective preferred policy. If you feel like holding a vote, by all means feel free, I'll probably vote -1 for deviating from the existing format (unless you've got a good argument rather than preference; I share your preference but it is just that ;) There are few good arguments for both ways. yep. I think the best argument is common practice, and that's something which can be measured to a degree. If we host external packages - some licenses prohibit modifications of the binary distribution ( I read this as you can't rename jars). I think anyone who uses or accepts a license that dictates filenames is silly, but that could be just me :D It also seems to be a very common practice - almost all projects I know use unversioned jars. you and I work on different projects I guess! If anyone feels like it, one could do actual statistical analysis on http://cvs.apache.org/~leosimons/jars-in-cvs/ though one would have to compensate for the smart projects which don't keep binaries in CVS... I would say this beats the argument on the maven practice ( that ruper is also supporting ). I see no reason why a download tool can't accomodate both. me neither, but it sounds like more work again ;) On the other side - the practice on .so library supports the versioned jars, as well as the ability to have all .jars in a single dir and use the manifest to select the right version. not to mention apt, rpm, CPAN, PEAR (ie CPAN 4 PHP), OpenBSD, ... I think a vote would be necesary - I'll probably propose it in the projects I participate in. Probably a global jakarta vote would also make sense - at least to gather what's the majority things and recommend it. I say go for it (though I hope everyone shares my opinion :D) Since I don't think there is an absolute right - I obviously preffer a majority decision, that would justify some pushing and work to get it adopted. uhuh. There's that word again, work. A good scientist is a lazy scientist. Does that hold for programmers? (Are programmers scientists?) I say go for it though. Actually I just said it for the second time. Not lazy enough yet, me. cheers, - Leo, sometime-to-be-scientist, and planning to be a good one - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ant PMC Issue (was: RE: [proposal] daedalus jar repository)
Greg Stein wrote: The Board exists to help projects in their work. We exist to protect the ASF to ensure that it will continue to exist, to help projects. Our intent is to let projects do whatever they feel is right and correct, subject to the constraints of the operation of the ASF and to what we feel may be injurious to the overall health of the ASF. my opinion: the board peeps are doing pretty well. For sure, they've helped out avalon in an admirable way. Enough slamming the board already: you guys rock! Big well-deserved thank you. enough posts from me for the day. (I'm starting to compare myself to Andy :D) cheers! - Leo PS: sorry for all the warm fuzziness. I ate too much chocolate. PPS: the relevant dutch saying: Hoge bomen vangen veel wind. I'll leave it to Dirk to translate. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Noel J. Bergman wrote: As you have seen from some of our exchange and Costin's comments, there are differing views on how to make use of the repository. Costin and I seem to be of the option that a significant portion of the value of the repository comes from sharing and centralizing the managment of ASF-acceptable third party jars. you get an ok on that from the board and/or the infrastructure team, and consensus across the community, and I'll be absolutely 100% behind any such plan. And having an apache only repository is almost useless; even apache uses non-apache code. uhm...no. I need a location where I can put avalon jars and the distribution version of jars used by gump, and I would really like to have this location mirrored into the existing maven @ ibiblio repo, so that it becomes real easy to control what avalon jars are available that way. It's not useless at all! The current 'daedalus' repository seems to be duplicating what's already been done in maven. the difference is in control, location and community. I want to be able to modify the jars in the avalon part of such a repository (control), the ASF wants the asf hardware to be the primary distribution channel for asf software (location), and I want such a repository to be usable and the de-facto standard across ant,maven,centipede,whatever (community). Technically, I'm trying to exactly keep the difference to zero, and have exactly zero thought on how to do it, but just use the existing practices. FWIW, Dion indicates that you are wrong about the no regarding JUnit licensing. the no is with regard to whether apache wants to get into redistributing JUnit, not with regard to whether it is okay to link to or provide as part of an asf project, or anything like that. IANAL. Like I said the first time :D Licensing policy is quite tricky and lots of things need to be done before the ASF should even consider setting up a centralized easily user-accessible distribution [of third party jars] But that's the whole point, Leo. :-) Given the confusion and effort related to the approved use of third party jars, I see that as a primary benefit of the repository, not even a secondary one. Especially from the standpoint of the Board (and projects) being able to verify that all third party jars have clean license. I'm not sure if you have any idea of how many hours and hours Dion has invested in going through the Maven repository, and its licensing. sure. I know how much I've invested in it so far, and I have only very little knowledge and very little accomplishment in the matter, so he must have invested lots more :D. This is precisely why I'm doing next to no thinking on my own, and just following his lead! By using the repository as the authoritative statement of what is acceptable, projects have both a known authority and a known procedure for securing approval to use another jar. This provides further protection to the ASF by ensuring that not only does each PMC make a conscious decision to use a new jar, but that people who are familar with licensing on a regular basis also get a chance to vett new uses of third party code. you absolutely do not need a repository as an authoritative statement of what is acceptable. What you need for that is an authoritative statement. But yes, having a centralized repository of acceptable third party jars does add an extremely convenient procedure for securing approval of a particular jar. http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made into an authoritive source on www.apache.org that unambiguously answers yes or no And those would be the guiding principles used by the repository oversight committee to approve new contents. you mean not the guiding principles, but the authoritive statement. --- Look, I support the goal, but there's requirements to be satisfied. In order to place any non-asf created third-party jar on www.apache.org, I think we need at a minimum: 1) an ok from the board on providing redistribution of these third party jars* 2) authoritative** confirmation that the redistribution of any such jar under a specific license and/or copyright is in line with the ASL and the ASF licensing policy 3) authoritative** information on what requirements are placed on the redistribution of such a jar so that all relevant licenses and license policies are satisfied, 4) a mechanism for ensuring the satisfaction of these requirements 5) an ok (ie majority vote) from the community on this provision (though consensus would be nice) when (1)-(4) is satisfied you'll get my +1 on (5). I will also try and help out with satisfying (2)-(5) when (1) has been satisfied. I don't really care what process is used to get these requirments satisfied; a committee headed by Dion (sorry if I misspell here ;)) sounds just fine with me. But get (1) in place before spending too much energy on (2)-(5). Certainly, I'm not going to spend more time convincing anyone that
can Apache distribute third party libraries?
Dear board, there exists some confusion within the apache community about the redistribution of library sources and binaries by apache. The question I ask you is whether it is acceptable for the apache projects to do so, and what requirements are imposed on this redistribution. Specifically, would it be acceptable if the ASF were to create a centralized, publicly accessible repository of binary java libraries (so-called jars) from third parties, what requirements need to be satisfied in order for this repository to be acceptable, and what requirements need to be satisfied in order for any specific library to be acceptable for inclusion into this repository? I would like to point at some existing libraries the ASF redistributes in one form or another: http://cvs.apache.org/viewcvs.cgi/httpd-2.0/srclib/pcre/ Apache HTTP server distributes the PCRE library, licensed under the PCRE License, in source and binary forms. http://cvs.apache.org/~leosimons/jars-in-cvs/ - Various java-related projects distribute various jars. These are licensed under various terms; common ones including the IBM Public License and the BSD license. The above URL is a partial list of jars available through CVS. Many of these are also distributed as part of software releases available through http://www.apache.org/dist/. I would also like to point at the recent discussions in january and february on this topic held on the community@apache.org, general@jakarta.apache.org and dev@avalon.apache.org mailing lists as well as on other mailing lists, for the context in which these questions arose. thanks for your time and best regards, - Leo Simons - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Leo Simons wrote: you get an ok on that from the board and/or the infrastructure team, and consensus across the community, and I'll be absolutely 100% behind any such plan. scratch that, I'm in a Just Do It mood today. Just sent a message to the board (who are reading already anyway, but hey, some people like policy and procedure ;), watch for CC. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Sam Ruby wrote: - Leo (avalon pmc member acting sort-of on behalf of the java peeps using the lazy consensus model and the Just-Do-It-in-the-event-of-consensus mindset :D) I like that mindset. Note: the essence of lazy consensus is that such actions are immeditely rolled back if an issue is raised. I plan to do exactly that. heh. Me too :D cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Noel J. Bergman wrote:
Which PMC is going to oversee the repository?
all PMCs whose committers 'commit' to the repository should maintain
some oversight. I
don't think there's an official precedent wrt how this works @ apache.
It might be possible
to get the infrastructure peeps to take on the additional burden of
oversight, and maybe
some peeps will want to join the infrastructure team to that effect.
How are files going to be
committed?
anyone with an account on daedalus and part of the apcvs group can
place/modify the files
there using SCP/SSH. People who commit files will also have the option
to chmod those committed files so that they are editable by a smaller
group of people. Just
like with the existing distribution setup.
Who is going to ensure that the correct licenses are present and
honored?
IMO, the person who places a file in the repository should ensure the
presence of a license,
just as is currently the case with distributions (pattern emerging here
;). It is responsibility of
the ASF as a whole to make sure the rest of the world honours its
license. For the next few
weeks at least, I'll be monitoring the repository closely. I hope/expect
more people will step
up to help out.
once again, I'm not suggesting we place non-ASF jars online, which
simplifies license issues
rather by a large amount.
I also think it should be easy enough to automate this somewhat: for
each ${blah}.jar, check
there's a corresponding ${blah}.LICENSE*, and e-mail the owner of the
.jar if there isn't.
Should be easy enough; my plan basically consists of following the
maven+infrastructure lead
on stuff like that, as that's where the expertise is atm. (Looking at
http://www.ibiblio.org/maven/, they chose a pattern of
./${blah}/licenses/${blah}.license,
which is easily machine-parsable.)
I like the idea of a central repository. It would simplify the issue by
centralizing maintenance of jars and licenses. I just want to know how it
is going to operate. A joint operation between Ant and Maven?
Infrastructure?
A joint operation between all projects that want to have their jars in
the repo and all projects
interested in maintaining such a repo for other reasons, and the
infrastructure team. In effect,
_exactly_ the same de-facto guidelines that apply to
http://www.apache.org/dist/ apply to this
repo as well. We've not needed things set in stone wrt distribution
policy before (or do we? :D),
so I wonder whether we should start to do so now. Let's go with the
flow, shall we?
[I won't even get into the question of why those two can't be related
projects under a single PMC]
lets not :D
in summary, the answers to the questions you are posing should be the
same for
/dist/java-repository as for /dist/ as a whole. If those answers don't
exist for /dist/, well
if answers are needed they should be sought, but IMV that hasn't got too
much to do
with this specific repo and more with the general case. IE Is there
lack of policy with
regard to www.apache.org/dist/? is a different thread. And I guess Dirk
is the one to
give the answer to that one ;)
cheers,
- Leo
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [proposal] daedalus jar repository (was: primary distribution location)
Noel J. Bergman wrote: all PMCs whose committers 'commit' to the repository should maintain some oversight. Infrastructure hasn't considered that a good model for the Wiki, and I don't know that it would work any better for the repository. Someone needs to take responsibility for the oversight. they _have_ accepted this as a model for distribution management. The wiki is a very different topic. The www.apache.org/dist/ setup is something 'conventional', with a filesystem and permission management and SSH encryption and stuff. It is tried and tested, and perfectly secure (to the extend daedalus itself is secure). I'm not suggesting we place non-ASF jars online, which simplifies license issues rather by a large amount. Yes, that does. But I am expecting that people will want common things like JUnit, AIUI, there is currently a no on the ASF providing a redistribution point for things like JUnit in the style of a maven repository. At least not a definitive yes. which I understand to be acceptable so long as the IBM license is there. IANAL, but I understand the same thing ;) Once the binary distinction of ASF v non-ASF is dropped, then the simplicity of it being OK because it is all ASF-licensed code turns into the policing scenario that Maven is currently practicing, through Dion Gillard. yep. So don't drop the binary until you have a) policy, b) desire and c) an ok to make apache into a redistribution point of third-party software. Just b) doesn't cut it. But using the repository to hold third party jars for which the ASF has specifically ascertained appropriate license rights exist seems to be what gives us the most bang, because it is the third party libraries that are the most potentially time consuming and risky. Rather than each project have to deal with each third party jar, using the repository for that purpose would both share the burden of acquiring suitable license rights, and ensuring that they were acquired. www.apache.org/dist is the authoritive place for distribution of apache software. It is _not_ currently intended for redistribution, authoritive or not, of ASF-endorsed or ASF-acceptable software. Quite binary, yes (ant it is not something I made up, but what I took away from comments from Dirk or someone else entitled to make official statements). Changing this setup is something to be done only very cautiously after consulting with the projects that mirror our stuff and answering lots of other questions. I can see the argument as to why we would want to do such a thing, but I think it is best to hold this off for at least a month or two even if we were to decide to do it. Slow controlled evolution :D So, yes, the ASF-only distinction simplifies repository policing, but using it as the central location for authorized third party jars simplifies overall policing of third party license issues for the ASF as a whole. Licensing policy is quite tricky and lots of things need to be done before the ASF should even consider setting up a centralized easily user-accesible distribution point of materials not copyrighted by the ASF that can be called authoritive either by definition or default. For example, the docs started at http://nagoya.apache.org/wiki/apachewiki.cgi?Licensing should be made into an authoritive source on www.apache.org that unambiguously answers yes or no with regard to can we link to software under license X?, can we redistribute software under license X in source form and/or binary form?, how do we provide these licenses when we redistribute or link to software under license X?, what other steps doe we take when we redistribute or link to software under license X? and similar questions, so it is crystal clear what we can and cannot include and policy can be formulated and applied. Something like http://www.fsf.org/licenses/license-list.html#SoftwareLicenses for the ASL. Until these answers exist and are well-known throughout the community and relevant PMCs, we need to be as conservative as possible. Not sure if your project can distribute JUnit? Then don't, even if that makes life terribly inconvenient. Want to be sure? Ask the board to pour resources into getting answers. But we need to be sure before we act. I'm sure it is okay for the ASF to distribute jars from its own hardware based on its own sourcecode under its own license. Yes, binary, but it is the best first step and it solves a real need. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[proposal] daedalus jar repository (was: primary distribution location)
Hi all, (sorry for the massive crosspost up front, as this is a proposal that should in the end come from the various PMCs towards the infrastructure team I'm doing lots of CCing, just once) I've been giving this some thought. It has been pointed out that the primary distribution location for all apache projects should be an apache machine (board position, that is, and I guess mostly everyone agrees). It has also become evident that it makes sense to have the distribution repository structured in such a way that a software tool can understand it, and that it is very valuable for java-based projects to distribute jar files as well as zipped/tar+gzipped distributions (closest analogy is probably that it makes sense to ship an apache httpd msi in addition to a tar/gz). Finally, it is desirable to make use of the existing distribution mirroring setup already in place for apache to keep actual load on asf machines and the network as a whole as low as possible. Based on the above, I suggest we create such a machine-readable repository @ daedalus.apache.org:/www/www.apache.org/dist/java-repository using the de-facto common repository format pioneered by maven and supported in centipede, supported in Ant using RuperTask or a simple script (http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent), and easily supported in any software too that can do an HTTP GET and a sprintf(). The use of this repository is simply to contain symlinks to the various distributions in /www/www.apache.org/dist of the various projects. I am specifically _not_ suggesting that this repository should distribute other project distributions (like junit.jar). ASF is not in the mirroring business atm. Though I wouldn't have a problem if we were to change that, I doubt it'll increase the likelyhood of this proposal getting through and it would hence take more work :D As all java-based projects could benefit from having their software symlinked from this repository, it is probably useful if all committers with accounts on daedalus and that are part of the apcvs group (I think that's everyone by definition :D) gain access to the repository. Individual projects can then create dirs in the repository and tighten permissions, ie one would do something like cd /www/www.apache.org/ mkdir avalon-framework chown -Rf leosimons:avalon avalon-framework chmod -Rf 775 avalon-framework cd avalon-framework ln -s /www/www.apache.org/LICENSE.txt mkdir distributions mkdir jars cd distributions ln -s ../../../avalon/framework/latest/*.tar.gz ln -s ../../../avalon/framework/latest/*.zip # ... ln -s ../../../avalon/framework/v4.0/*.tar.gz ln -s ../../../avalon/framework/v4.0/*.zip ln -s /www/www.apache.org/LICENSE.txt cd ../jars ln -s ../../../avalon/framework/latest/avalon-framework-4.1.4.jar # ... ln -s ../../../avalon/framework/v4.0/avalon-framework-4.0.jar ln -s /www/www.apache.org/LICENSE.txt An alternative is of course to create an apjarrepo group consisting of perhaps a committer subset; I'd like to leave that choice up to the infrastructure team. If that is a better idea, please tell us so we can figure out a list of people who should be part of that group. Normally, I'd just ask the infrastructure peeps to umask 002 mkdir /www/www.apache.org/dist/java-repository chown :apcvs /www/www.apache.org/dist/java-repository and get things started, but given the unusual (well, maybe not ;) amount of controversy I think it makes sense to get noses in the right direction on this first. I would like to invite everyone to follow-up on this matter on community@apache.org, hold a (hopefully, brief productive) discussion, vote on a revised proposal (I'll happily volunteer for tallying things up), and format the results of that (assuming that my proposal gets through :D) as a request by all the involved java-related PMCs to have the infrastructure peeps do a 'mkdir java-repository'. Note the legal headache or impact caused by all this is zero: we are only providing convenience URLs for things apache already distributes. Also note the likely diskspace and bandwidth impact is also near zero: this repository would be automatically mirrored by the existing apache mirrors. Third, note the complete simplicity: it works out of the box with all existing build tools (that I know of), and the additional overhead impact on the infrastructure team is a single mkdir/chown. Finally, note the ease with which existing repositories like www.ibiblio.org/maven/ can be made to mirror this repository: rsync is already in place and available. so, thoughts? cheers all, - Leo Greg Stein pretty much summarized: I don't see why we need to do anything. Distribute from daedalus. Ibiblio can rsync it over. What more is needed? snip/ Andrew C. Oliver got the discussion started: I think the maven repository should be Apache's primary distribution of all Jakarta/XML projects. snip/
Re: Suggestion...
Noel J. Bergman wrote: David, I agree that there should be an e-mail. But it should be short, and consist of little more than a reference to the web site. All of this information should be available on the web site for review and update. As that content is enhanced, e-mail can go out to [EMAIL PROTECTED] agreed. http://www.apache.org/dev/ is a good place for all this information. It needs some work, and more exposure among existing committers. cheers! - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Hi all, I've just updated the setup mentioned below to do handle the licensing issue just a tiny bit better, up to the point where I think (IANAL!) it is no longer in violation of any license. http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.ent http://cvs.apache.org/viewcvs.cgi/avalon/check-targets.properties It might make sense for other projects that are also not moving to maven or centipede just yet to put in place a similar setup. cheers, - Leo What is more or less clear at this point is that the current setup I just put in place for avalon-framework where some Sun BCL code is downloaded from ibiblio is in breach of license (it won't work anymore either, as the problematic jars have been removed, so I guess it is already no longer in breach), whereas the setup we use in logkit (where the user must actively agree to the BCL license and download the code themselves) /seems/ to be acceptable. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: licensing issues and jars in Avalon
Sam Ruby wrote: Leo Simons wrote: recent board decree (saw it first on the infrastructure list) (paraphrasing): the ASF must not distribute software packages (in any form) licensed under LGPL, GPL or Sun Binary Code License in any way. Sun's Binary Code license permits bundling as part of your Programs. The short form of this: you can include such things in tars and zips for your release, but for individually download. In other words, users need not feel the pain, but developers do. So, in other words, it is okay if I as a developer download a BCL-licensed package, compile an ASF module against it, then build a distribution consisting of the compiled code and the BCL-licensed package? For example, is a JAMES distribution allowed to be compiled against the BCL-licensed package (after the developer making the distribution has agreed to the license) and ship with the BCL-licensed package? Is it also okay if my distribution instead contains the source code and the BCL-licensed package, and a build script for compiling the ASF module against the BCL-licensed package? Or is that not okay, but can I distribute the source code with my binary distribution? What about providing everything but the build script? I'm sorry, it's not too clear to me just yet. Personally, if there are open source alternatives, my recommendation is that they should be supported instead. +1. cheers, - Leo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Openness
VOTE 1: would you like to make it possible for non-committers to read this mail list thru a web archive? [X] +1 yes, let's make it readable [ ] 0 don't know/don't care [ ] -1 no, let's keep it private VOTE 2: would you like to make it possible for non-committers to fully subscribe to this mail list? [ ] +1 yes, let's open it to everyone [ ] 0 don't know/don't care [X] -1 no, let's keep it for committers only - Leo
Re: [VOTE] Open this list
View 1: Open the list completely, anyone can subscribe, post and read the archive View 2: Keep the list open only to committers, members and invitees (highly contributive developers and users) so far as posting goes, however allow anyone to read or view the archive (and include an archive such as MARC, etc. View 3: Close the list to all except members and committers. View 1: +1 Sam, Steven Noles +0 View 2: +1 Andy +1 View 3: +1 Ken -0 Please state your view and vote your conscience. - Leo Simons
