Re: [VOTE] Release Apache Bloodhound 0.2 (incubating)
On Thu, Nov 1, 2012 at 8:24 AM, Branko Čibej br...@apache.org wrote: On 29.10.2012 15:22, Joachim Dreimann wrote: Hi, I would like to request the beginning of the vote for the second release of Apache Bloodhound in the incubator following the successful vote by the Bloodhound PPMC. The result of the vote is summarised here: http://markmail.org/thread/zrgkleendiqvanzs The artefacts for the release including the source distribution and KEYS can be found here: https://dist.apache.org/repos/dist/dev/incubator/bloodhound/ The release itself is created from: https://svn.apache.org/repos/asf/incubator/bloodhound/branches/0.2 (r1394550) Issues identified to be fixed for the next release are listed here: https://issues.apache.org/bloodhound/ticket/246 https://issues.apache.org/bloodhound/ticket/245 The vote will be open for at least 72 hours. [ ] +1 Release this package as Apache Bloodhound 0.2 [ ] +0 Don't care [ ] -1 Do not release this package (please explain) +1 to release Apparently my vote got mislaid on the other list. +1 to release. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache Bloodhound 0.1.0 (incubating)
On Mon, Aug 6, 2012 at 9:37 PM, Greg Stein gst...@gmail.com wrote: On Aug 6, 2012 7:07 PM, Gary Martin gary.mar...@wandisco.com wrote: ... The vote will be open for at least 72 hours and therefore ends after 11pm UTC on Thursday 9th August. [ ] +1 Release this package as Apache Bloodhound 0.1.0 [ ] +0 Don't care [ ] -1 Do not release this package (please explain) Repeating my prior IPMC binding vote: +1 to release Same. +1 (binding) -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: -1 on this months board report (was: Small but otherwise happy podlings)
On Wed, Jan 11, 2012 at 4:49 PM, Sam Ruby ru...@intertwingly.net wrote: On Wed, Jan 11, 2012 at 4:19 PM, Benson Margulies bimargul...@gmail.com wrote: And here we return to a thread of some weeks ago. One chair can't review all those reports and push the bounce buttons. Some other people have to step up to help. This Board member reads each and every one of them every month. So it is no change in workload to me to push this work down. Instead of talking about this abstractly, -1 on forwarding to the board the following reports. I'll start with the most egregious one: ... -1 on forwarding on the following reports as they are Missing: Bloodhound I'll take responsibility for this one. As a first-time mentor, I completely spaced the reporting requirement; particularly since the deluge of Bloodhound-related discussion induced a sort of fatigue on that topic. I'll ensure it happens next month. (That, and I haven't yet learned how to wade through the fire hose that is general@incubator to spot potential reminders.) -Hyrum Callback/Cordova HISE JSPWiki Openmeetings -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Q. Forks without concensus?; A. anytime / depends / never without agreement
On Sat, Jan 7, 2012 at 4:10 PM, Roy T. Fielding field...@gbiv.com wrote: On Jan 7, 2012, at 1:49 PM, Greg Stein wrote: On Jan 7, 2012 4:24 PM, Roy T. Fielding field...@gbiv.com wrote: ... The original developers are not ambivalent to this fork. Untrue. Christian and Remy are, and always have been, supportive. They were the ones to suggest the fork, rather than trying to make the changes in trunk. I read the trac-dev mailing list. To say that they are supportive is a huge stretch of the imagination. They are sadly resigned to see a potential contributor decide to fork the code instead of working with them directly. And the rest of the community (which is far larger than the core) thinks the idea stinks. If you read trac-dev, you will also notice that the discussion about the so-called fork has more responses than all other threads in the last three months *combined*. Lots of navel gazing, not much work. (Though surprisingly, discussion *has* picked up in the past couple of weeks, so maybe this is a Good Thing all around.) What you have is a vocal minority that disagree. Ethan is not even a core committer, as far as I can tell. Edgewall, the copyright holder, is a defunct shell. That is a primary reason WANdisco wanted to move to the ASF: a home with actual backing and longevity. Then we should be able to convince Christian and Remy to join the initial committers list and bring the rest of the TRAC community with them. Why has that not been done? It has been. They have essentially said we've moved on, best of luck. WANdisco has definite problems in how they approach and work with open source communities. They discussed this stuff with the Trac principals privately, rather than with the broader community. But my read is that the Trac leads are supportive of Bloodhound. They are supportive of people doing work on Trac. They did not support a fork at the ASF. What they told WANdisco was that, rather than come to some artificial agreement on how they should work together before WANdisco had contributed anything, that WANdisco should fork the code and start by making contributions. That's it. The only reason that Christian has not directly opposed Bloodhound is because he believes the BSD license gives permission to fork the code. My interest here is seeing Trac revitalized, improved, and delivered as an awesome open source issue tracker. I'm tired of Bugzilla and (non-OSS) Jira. I like the Google Code tracker, but I'm biased there :-P There is no evidence to suggest that cannot be done on trac-dev. I'm not sure I agree with this statement. Trac has a singular and well-defined philosophy built around a small core and an environment of plugins. This isn't the place to debate the merits of that architecture, but suffice it to say that such a system can often require a lot of work to get to a usable state. The goals of Bloodhound are separate from that: create a full-featured issue tracker which is easy to deploy and use for end users and administrators both. Honestly, Trac is a good product, and is an excellent choice as the core for Bloodhound, but the community goals differ. Significantly. Bloodhound won't happen on trac-dev because the Trac community is philosophically opposed to the direction the nascent Bloodhound community wants to take. That's okay: people are allowed to have different goals. And the great part about open source is we all don't have to reinvent the wheel to implement those different views of the world. Bloodhound can be a derivative of Trac with its own community and goals [1]. There's room enough in the world for them both. I think the Trac community sees this as a zero-sum game: if people are contributing to Bloodhound, they *aren't* contributing to Trac. Instead, we should try to convince the Bloodhound people that our philosophy is best, and they should just come over here. Resolving such philosophical differences and technical goals is difficult at best, and I don't see it happening soon. But that's okay, there isn't a globally optimal solution to issue tracking, and we can agree to experiment with different paths. But I've probably said too much already. There isn't much more I can add here, and the last think I want to do at this point is prolong the agony of this discussion. -Hyrum [1] Indeed, I know of at least one private proprietary derivative of Trac, but since it's proprietary, nobody knows about it and nobody complains. It's the fact that Bloodhound is proposed as open source which is causing the hullaballoo in the first place. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
Agreed: we don't (and shouldn't) encourage hostile forks at the ASF. This isn't a hostile fork. From the beginning, the intention of Bloodhound has been to be to use the existing Trac system as much as possible and to improve upon it. After many private (and some public) conversations with several of the Trac principals, it was agreed that the existing community had a different set of goals than the Bloodhound supporters, and that a separate community and derivative codebase was probably in the best interests of all. The Incubator proposal was publicized and discussed on trac-dev *simultaneously* with the discussion on general@incubator, and the reception was generally indifferent (as Greg mentioned earlier)[1]. While I don't discount Ethan's feelings out-of-hand, it certainly is a bit late in the game to be re-raising these issues. Basically, I just don't understanding the concerns that a very vocal minority appear to have. Is it a problem with the license? Fracturing of the community? Technical issues? Or just don't take my code? As for discussion about the technical and other project direction, I'd encourage interested parties to bring up their concerns and suggestions on bloodhound-...@incubator.apache.org. (Note: that list is only a few days old, so it may take a little while for folks to get subscribed.) Since one of the main goals of Bloodhound (and the Incubator) is building community, and we should try as hard as possible to get Bloodhound-related discussion on the bloodhound-dev@ list. All that being said, if people are looking for any kind of closure on this issue, they will probably have to wait a bit. The next few days are holidays for a large part of the world, so any discussion will likely attract a very vocal minority, biasing the resulting discussion. -Hyrum [1] It interesting to note that the single thread on trac-dev discussing Bloodhound has more posts than all other threads to trac-dev during the last three months *combined*. On Sat, Dec 31, 2011 at 9:57 AM, Ralph Goers ralph.go...@dslextreme.com wrote: I find this post disturbing. Had it been posted before the vote closed I most certainly would have voted -1 as we don't encourage hostile forks at the ASF. Ralph On Dec 30, 2011, at 12:30 PM, Ethan Jucovy wrote: -1 The Bloodhound proposal is to build an issue tracker by first importing the Trac core code into the Apache Subversion repository. As currently planned, this project has potential to be detrimental to the existing Trac brand and community, and it seems that the Bloodhound project's goals could equally be achieved without taking the heavy-handed first step of forking the Trac codebase. I hope that the Bloodhound team will consider building Bloodhound as a set of plugins and configurations and an installer that distributes them with an upstream Trac version, rather than forking Trac as a first resort. My concerns fall into three categories: a) The Bloodhound proposal contains substantial allegations about the health of the Trac community and the competence of its maintainers, as motivating factors for the fork and rebuild community approach proposed. No documented evidence has been provided to support these claims, and many of the claims are directly contradicted by the publicly available records in the Trac community's issue tracker, mailing list archives and commit logs. b) Neither the Bloodhound proposal nor the ensuing discussions have demonstrated any compelling legal, procedural, technical or strategic reason why Bloodhound should be based on a fork of Trac rather than an upstream distribution of Trac. c) Although the people involved have been friendly and expressed a desire to keep the two projects in cooperation, the actions taken so far and the intentions announced are characteristic of a hostile fork. -- (a) The Bloodhound proposal contains substantial allegations, without evidence, about the health of the Trac community and the competence of its maintainers. These allegations are largely contradicted by publicly available records of the Trac community. * The Bloodhound proposal claims, Private efforts to engage the existing developers in implementing features have been negatively received[1]. (a.1) I was not involved, and all conversations between WANdisco and the Trac developers were private and off-record, so it is impossible to verify the actual sequence of events. But, per [2], it seems that what is referred to here is the following: WANdisco’s developers asked for commit access to the Trac core, and/or proposed migrating the Trac core to the Apache Foundation’s infrastructure and governance, with no prior history of engagement with the Trac community and no prior contributions (see a.2 below). If this is the case, characterizing it as an offer to implement features which was negatively received by the Trac developers is significantly misleading. (a.2) Five out of Bloodhound's six
Re: [VOTE] Bloodhound to join the Incubator
On Tue, Dec 27, 2011 at 2:55 AM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] Sent: Friday, 23 December 2011 6:58 PM To: general@incubator.apache.org Subject: Re: [VOTE] Bloodhound to join the Incubator Hi, On Fri, Dec 23, 2011 at 12:29 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: ...I don't know what the proper procedure for vote counting is... Usually you just change the subject to [RESULT][VOTE]... to make it more obvious that you're tallying the vote, and we often list the names of whoever cast binding votes. No need to redo it for this vote IMO. I'll make a start at requesting some resources, like mailing lists and stuff. Thanks! I'll help with migrating code and other stuffs over, but probably not until after the first of the year. We can discuss on the new mailing lists when they get set up. -Hyrum -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com/ - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Bloodhound to join the Incubator
On Mon, Dec 19, 2011 at 12:55 PM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: It seems discussion on Bloodhound has died down, so it's time to call a VOTE. Please vote on the acceptance of Bloodhound into the Apache Incubator. The proposal is available at [1] and its content is also included below for your convenience. Please vote: [X] +1 Accept Bloodhound for incubation [ ] +0 Don't care [ ] -1 Don't accept Bloodhound for incubation (please explain) Looking forward to seeing this in the Incubator. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
[VOTE] Bloodhound to join the Incubator
[[http://www.apache.org/legal/resolved.html#category-a|approved]] by the Apache Legal team for use in Apache-distributed products. In fact, existing projects at the ASF have been doing so for a number of years. Potential concerns about patents embodied in the Trac code at best, and a change of license or software grant would not defray them. (See [[http://mail-archives.apache.org/mod_mbox/incubator-general/201112.mbox/%3CCABD8fLXs%2BCz3qQkR20bS2%2BSAW0N3yiTGkTH7iTxGwTUUwTADSQ%40mail.gmail.com%3E|this mail]] for a better explanation.) == External Dependencies == The bulk of the initial code will be from the Trac project, which is licensed under the BSD license. Bloodhound also relies upon BSD-licensed subcomponents for HTML templating. = Required Resources = == Mailing lists == The initial set of mailing lists will be: * bloodhound-private (with moderated subscriptions) * bloodhound-dev * bloodhound-commits * bloodhound-user == Subversion Directory == https://svn.apache.org/repos/asf/incubator/bloodhound == Issue Tracking == Bloodhound would like to self-host its issue tracking, see below. == Other Resources == In the interests of eating our own dogfood, Bloodhound would like to self-host the issue tracker and related tools. The team will work with Infrastructure to define and manage this configuration. == Initial Committers == * Mat Booth (mat.booth at wandisco dot com) * Mark Poole (mark at wandisco.com) * Hyrum Wright (hyrum.wright at wandisco dot com) * John Chambers (john.chambers at wandisco.com) * Gary Martin (gary.martin at wandisco.com * Gavin McDonald (gavin at 16degrees.com.au) == Affiliations == * Mat Booth, WANdisco * Mark Poole, WANdisco * Hyrum Wright, WANdisco * John Chambers, WANdisco * Gary Martin, WANdisco * Gavin McDonald, Independent = Sponsors = == Champion == Hyrum K. Wright == Nominated Mentors == * Hyrum K. Wright * Greg Stein == Sponsoring Entity == The Apache Incubator - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Bloodhound
On Thu, Dec 15, 2011 at 3:35 AM, Gavin McDonald ga...@16degrees.com.au wrote: -Original Message- From: Greg Stein [mailto:gst...@gmail.com] Sent: Thursday, 15 December 2011 1:30 PM To: Hyrum K Wright Cc: general@incubator.apache.org; Ian Wild Subject: Re: [PROPOSAL] Apache Bloodhound The discussion has been minimal, and has ramped down. Time to move to a vote? (I had hoped to see some people volunteer...) My py fu isn't great but maybe I can help in some way and be a chance to learn some more, so I'll put my name down as committer if you think I'll be useful. Added to the proposal. Feel free to update your information (including affiliation). While you may or may not feel comfortable hacking the code initially, having somebody to help admin a local instance will be very useful. Thanks for volunteering. :) -Hyrum On Dec 2, 2011 10:53 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation's reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed
Re: [PROPOSAL] Apache Bloodhound
On Mon, Dec 12, 2011 at 2:41 AM, Greg Stein gst...@gmail.com wrote: On Dec 12, 2011 3:12 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Fri, Dec 2, 2011 at 4:53 PM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. Do you have pointers to public discussions about this? Without a well-documented history of attempts and failure to engage with the existing developers this could easily be seen as a hostile fork. I've seen some offlist discussions with the principals behind Trac. This has not caught them unaware. One of those devs even created a wiki page at Edgewall for Bloodhound: http://trac.edgewall.org/wiki/BloodHound?action=diffversion=1 My impression of their view is ambivalence. Most notably, has the idea of bringing Trac itself to the ASF been presented to Edgewall? What was their response? Hyrum has seen more of the discussion and could answer better, but my read is that ambivalence again. They aren't going to put in an effort themselves to move Trac itself. I seem to recall a couple of the devs are interested in the move, and want to see how it goes. That pretty much captures it. The complete discussion on the trac-dev mailing list is here: http://groups.google.com/group/trac-dev/browse_thread/thread/14268355c6e1d494 -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL] Apache Bloodhound
On Mon, Dec 5, 2011 at 10:22 PM, Dennis E. Hamilton dennis.hamil...@acm.org wrote: Uh, here's the TRAC License: http://trac.edgewall.org/wiki/TracLicense. You have to do what it says. The language is very simple. So is the Copyright notice. If this is the codebase that you propose to be the foundation of Bloodhound development, I suspect that an SGA (Software Grant Agreement) from Edgewall Software is preferred in order to have it be licensable by Apache under the ALv2. If an SGA is possible, it would deal with the patent issue that has been raised on this thread. See http://www.apache.org/licenses/#grants. preferred or required? I'll also note that small bits of the Trac test suite are already being distributed in ASF releases of Subversion and hosted in our public repo. See: http://svn.apache.org/repos/asf/subversion/trunk/NOTICE and http://svn.apache.org/repos/asf/subversion/trunk/subversion/bindings/swig/python/tests/trac/test.py Subversion still maintains the required attribution per the Trac License, but also adds the ALv2. This was a point of discussion during the Subversion incubation, but was vetted and approved and has been the status quo for over 2 years. I have no idea how much the SGA is a requirement for the incubator proposal moving forward. Your champion or proposed mentors should know. I recommend that be figured out ASAP. How that will be handled might need to be added to the incubator proposal, also. What specific questions would you like to see addressed in the proposal? - Dennis If you end up needing a plan B, it might be appropriate to move where further development under the BSD license is possible. SourceForge might be an useful choice. SourceForge offers Trac as an available feature for projects, and it also supports SVN as one of its repository services. (I only mention that because I was looking into the SourceForge 2.0 beta recently and I have some small projects there.) -Original Message- From: Niclas Hedhman [mailto:nic...@hedhman.org] Sent: Monday, December 05, 2011 18:38 To: general@incubator.apache.org Cc: Mark Struberg; Ian Wild; Greg Stein Subject: Re: [PROPOSAL] Apache Bloodhound I suggest legal-discuss@ is involved to answer it. Although it is Cat A license, I don't think it is fully kosher, as we promise that the original contributor hasn't submarined any patents, but BSD doesn't state this. Maybe it is a tiny point, but more eyes from legal-discuss@ won't hurt... It would surprise me if this question isn't already answered. In fact, it is: http://www.apache.org/legal/resolved.html#category-a I humbly submit that reopening the question with legal-discuss@ would be disrespectful of their time. -Hyrum On Tue, Dec 6, 2011 at 6:26 AM, Hyrum K Wright hyrum.wri...@wandisco.com wrote: I don't know the proper answer to the licensing and patent questions. My understanding (standard caveats apply) is that the BSD is a Category A license, and as software distributed under it may be included in ASF software such as Bloodhound. I'm unsure what the concern about BSD notices in source file is, nor do I know if such concern is well-founded. -Hyrum On Fri, Dec 2, 2011 at 8:22 PM, Niclas Hedhman nic...@hedhman.org wrote: SO, IIUIC, the first step is to import TRAC, and we will have primarily a BSD codebase as the main body of code? Does this mean that all BSD notices in source files must live in ASF repository for all eternity, assuming that we are allowed to sublicense into ALv2 (which I think is no problem)? And what about the lack of patent license that we offer downstream, but have not received from upstream? Cheers Niclas On Sat, Dec 3, 2011 at 12:14 AM, Mark Struberg strub...@yahoo.de wrote: so this is basically Trac ++ and a fork of Trac ? Or is it a completely rewritten new approach? just curious :) LieGrue, strub - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase
Re: [PROPOSAL] Apache Bloodhound
I don't know the proper answer to the licensing and patent questions. My understanding (standard caveats apply) is that the BSD is a Category A license, and as software distributed under it may be included in ASF software such as Bloodhound. I'm unsure what the concern about BSD notices in source file is, nor do I know if such concern is well-founded. -Hyrum On Fri, Dec 2, 2011 at 8:22 PM, Niclas Hedhman nic...@hedhman.org wrote: SO, IIUIC, the first step is to import TRAC, and we will have primarily a BSD codebase as the main body of code? Does this mean that all BSD notices in source files must live in ASF repository for all eternity, assuming that we are allowed to sublicense into ALv2 (which I think is no problem)? And what about the lack of patent license that we offer downstream, but have not received from upstream? Cheers Niclas On Sat, Dec 3, 2011 at 12:14 AM, Mark Struberg strub...@yahoo.de wrote: so this is basically Trac ++ and a fork of Trac ? Or is it a completely rewritten new approach? just curious :) LieGrue, strub - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas
[PROPOSAL] Apache Bloodhound
Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration of Bloodhound becomes dead simple. = Current Status = == Meritocracy == Although initially corporate-sponsored, any interested developers would be granted commit access. Even developers employed by the sponsoring companies would be required to demonstrate competency to gain commit privileges. Individuals with corporate affiliations would understandably be known within the community, but would not have bearing on the granting of commit privileges. == Community == One of the primary purposes of this proposal is to develop a strong developer community around the Trac code base. The current developers and supporting institution have moved on to other things, and this has caused stagnation in the existing community. We want to use the experience of the Incubator PMC, and the incubation process, to reboot the developer community, while at the same time incorporating oft-requested features into the existing product. Building
Re: [PROPOSAL] Apache Bloodhound
On Fri, Dec 2, 2011 at 10:14 AM, Mark Struberg strub...@yahoo.de wrote: so this is basically Trac ++ and a fork of Trac ? Pretty much. It's Trac plus a number of commonly used plugins plus additional functionality. There's been some discussion about this with the principles on the Trac project, as well as on trac-dev, and so far there hasn't been any discord. Or is it a completely rewritten new approach? Bloodhound may eventually diverge from Trac, but that's up to the communities involved. -Hyrum - Original Message - From: Hyrum K Wright hyrum.wri...@wandisco.com To: general@incubator.apache.org Cc: Ian Wild ian.w...@wandisco.com; Greg Stein gst...@gmail.com Sent: Friday, December 2, 2011 4:53 PM Subject: [PROPOSAL] Apache Bloodhound Hello Incubator! WANdisco would like to propose the inclusion of a new project, Apache Bloodhound, to the Incubator. The proposal has been posted to the wiki[1], and is also included below. We've privately discussed this project with a number of individuals, but would now like to get the discussion rolling here. Bloodhound is new effort, based on Trac[2], to provide issue tracking and collaboration tools for developers. We realize the proposal is a work-in-progress, and as such look forward to feedback and discussion. We hope to attract mentors and other interested parties through the incubation proposal process, and further diversify the community as we move through incubation. In particular, this project is an opportunity to build a new community around the codebase, and we look forward to doing so at the ASF. -Hyrum [1] http://wiki.apache.org/incubator/BloodhoundProposal [2] http://trac.edgewall.org/ = Bloodhound - Collaborative development tools based on Trac = == Abstract == Bloodhound will be a software development collaboration tool, including issue tracking, wiki and repository browsing. Essentially an improved distribution of the well-known Trac project, Bloodhound will include the common and useful plugins to enable a more complete distribution than a typical Trac installation. == Proposal == Bloodhound will be a software development collaboration tool, based on the existing Trac project, which will include a repository browser, wiki, and defect tracker. In addition to the standard Trac installation, Bloodhound will incorporate a number of popular modules into the core distribution, and include additional improvements developed (as [[http://trac-hacks.org/|plugins]]) outside the Trac project. == Background == The [[http://trac.edgewall.org/|Trac project]] is a BSD-licensed collaboration tool used to assist in software development. It has a wide user base, a pluggable infrastructure, and is generally considered stable. By it's own recognition, however, the development community surrounding Trac has largely dissipated, with little mailing list traffic, and very few commits to the source code repository (see [2]). Private efforts to engage the existing developers in implementing features have been negatively received. At the same time, other individuals and companies, such as [[http://www.wandisco.com|WANdisco]], have expressed interest in helping continue to develop Trac. These entities would prefer this effort to be at a vendor-neutral location, with the clear process for intellectual property management that comes from the Foundation. As such, the Apache Software Foundation feels like the best fit for this new project based on Trac. == Rationale == As discussed earlier, the current Trac development community is small and reluctant to accept outside contributions. Given the Foundation’s reputation for building and maintaining communities, we feel a new project, based on Trac but incubated under the Apache umbrella, would help re-build the developer community, jump started by developer time donated by WANdisco. Additionally, as a developer tool, Bloodhound is a good fit with other, similarly-focused developer tools at the ASF. Private discussions have shown there is some interest by third-parties to release internal improvements to Trac, and Bloodhound gives them an additional venue to do so. == Initial Goals == The initial goals for Bloodhound primarily revolve around migrating the existing code base and integrating external features to make the project easy to deploy. Additional ideas will of course follow, but the following goals are sufficiently difficult to be considered early milestones. Some of the initial goals include: * Migrate the existing BSD-licensed Trac code base to the ASF. * Attract developer and user interest in the new Bloodhound project. * Incorporate externally developed features into the core Bloodhound project. * Package the most popular plugins into the core project, so installations and administration of Bloodhound becomes dead simple. = Current Status = == Meritocracy == Although initially corporate-sponsored
Re: KEYS and releases
On Mon, Jun 27, 2011 at 4:59 PM, Mattmann, Chris A (388J) chris.a.mattm...@jpl.nasa.gov wrote: Yep, makes sense. Like I told Benson, I wasn't exactly sure if the mirroring system were read only downstream of the Apache root sources (IOW, I thought we had more control then in reality we did). BTW, if someone could point me to a document where this is described, that would certainly help me refer it to others in the future. Several projects reference the httpd document entitled Verifying Apache HTTP Server Releases, which includes good commentary on why it's important to download the signatures directly from Apache hardware, and keys from the public keyrings. You can find it here: http://httpd.apache.org/dev/verification.html I also found several other documents about making releases and signing them, but these mostly addressed the process from a release manager's perspective, and not an end users. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Future of RAT
On Tue, Aug 10, 2010 at 9:43 PM, Philip M. Gollucci pgollu...@p6m7g8.com wrote: On 8/10/2010 10:39 PM, Justin Erenkrantz wrote: On Tue, Aug 10, 2010 at 12:50 PM, Greg Steingst...@gmail.com wrote: It is *very* true that Infra, Legal, and (all?) ASF PMCs will be clients/users of the tool. But are they interested in its development? If it goes under infra (as some are pushing for), then Joe gets to rewrite it in Perl. Hey, that's not a bad idea! =P -- justin It already *is* being rewritten in Python. :) -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Subversion is now an official ASF project!
Please note, though, that that does not reflect any official pronouncement of the Subversion development community. However, a number of the corporate sponsors are working toward making a summer release a reality, and we welcome whatever help folks want to give. Getting the ASF migration out of the way can/will certainly open up more resources for hacking. -Hyrum On Feb 26, 2010, at 3:58 AM, James Bailey wrote: Summer :) http://subversion.wandisco.com/component/content/article/1/44.html On Fri, Feb 26, 2010 at 9:41 AM, Johan Compagner jcompag...@gmail.comwrote: congrats! do we now get a 1.7 release asap? ;) I really like the features that where proposed! On Wed, Feb 17, 2010 at 22:16, Greg Stein gst...@gmail.com wrote: Hi all, The ASF Board just voted to approve the graduation of Subversion from the Incubator. We are now an official project of the Apache Software Foundation! Go forth! Be merry! Cheers, -g - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org -- Kind Regards, James Bailey Community Site Engineer Subversion Community Site: http://subversion.wandisco.com - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Missing reports due NOW
On Jan 18, 2010, at 2:20 PM, Justin Erenkrantz wrote: On Mon, Jan 18, 2010 at 5:28 AM, Noel J. Bergman n...@devtech.com wrote: Missing: Subversion Hmm. Something went wrong with the automated notifier as this ball got dropped, I guess. Subversion should have something submitted by this evening. -- justin The automated notifier (Marvin?) sent it's notification on Jan. 1, and it was promptly missed in all the post-holiday revelry. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Publishing api docs for Subversion
On Dec 3, 2009, at 2:14 PM, Paul Querna wrote: On Thu, Dec 3, 2009 at 9:31 AM, Doug Cutting cutt...@apache.org wrote: Paul Querna wrote: httpd and apr have published doxygen of their trunks periodically, they aren't based on any release. Were these published these on the official public website or in the dev/ section? I was under the impression that released documentation should be treated similarly to released code. The convention I've used is that stuff that's in trunk, stuff that's intended to be included in releases, is only published after release. Other pages on the website that are not included in releases, e.g., the project's home page, are clearly published without a release vote. http://httpd.apache.org/docs/trunk/ Which is linked from the sidebar everywhere, and on the docs page: http://httpd.apache.org/docs/ Back the original question: What's the best/typical way of generating and providing these documents? Subversion is using svnwcsub to publish subvesion.apache.org, but I don't think it's reasonable to check in a copy of the API documentation. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: JavaHL package namespace / migration / compatability
On Nov 17, 2009, at 3:11 AM, Branko Čibej wrote: Ralph Goers wrote: In general, Java code at Apache should reside under a package of org.apache. In this case, I would expect org.apache.subversion.javahl. Of course, this will create compatibility problems. I don't know if it is completely possible to create a separate jar containing the necessary glue code to map the org.tigris classes to org.apache - or if is even worth the effort. I don't quite understand the point of this. Here we are with a Java wrapper library for the Subversion APIs. The versioning rules that apply to it are the same as for the rest of Subversion -- in other words, we *must* keep the same package names in the JavaHL public API. Is there a specific reason for doing a bunch of extra work that does not add any value to JavaHL but only adds a layer of indirection for /all/ users of the library? Subversion's versioning guidelines say that the old APIs (and implicitly the package names) need to stay stable in future 1.x releases. That does not, however, preclude us from creating an up-to-date interface in the org.apache namespace, and only adding new and future features to that interface, effectively deprecating the old one. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: svn status update (was: svn commit: r880911 [1/13] - in /subversion/trunk: ./ build/ build/generator/ build/win32/ notes/obliterate/ packages/python-windows/ packages/windows-WiX/BuildSubversion
On Nov 16, 2009, at 1:27 PM, Greg Stein wrote: fyi, Subversion has been migrated into the ASF repository. About 30+ committers have access and are beginning work within the ASF repo. Below, you can see the big change to switch the licensing over to the ASF (we were already on ALv2, so this is merely a name change). Also, note the mailing lists are active. I declared flag day as 00:01 UTC Wednesday Nov 18 to switch to the subversion.apache.org lists (lazy consensus seems to approve). Please sign up as you will (all lists are open-subscription, but for private). Buildbot migration is now in-progress. I also expect some nightly builds to begin soon. At that point, we'll have tarballs if anybody would like to perform an audit. Hyrum has already fed some patches back to RAT to ease running RAT on release tarballs. Nightlies are currently here: http://orac.ece.utexas.edu/pub/svn/nightly/ I just manually reran my scripts to generate the tarballs based upon the code in the ASF repository, so folks can take a look at their leisure. Feel free to review source control. I'll send a notification when we have a handy tarball for review. Note that the software grant was recorded over the weekend. With that in hand, and a license/legal audit TBD, then subversion should be about ready to go(*). Cheers, -g (*) looks like we'll migrate to bugzilla. the issue and mailing list migration should not be a blocker for graduation (per ASF lax rules on location of such), but we'll have mailing lists done in the next couple weeks. issue tracker is TBD cuz of complicated data migration planning to do. -- Forwarded message -- From: hwri...@apache.org Date: Mon, Nov 16, 2009 at 14:07 Subject: svn commit: r880911 [1/13] - in /subversion/trunk: ./ build/ build/generator/ build/win32/ notes/obliterate/ packages/python-windows/ packages/windows-WiX/BuildSubversion/ packages/windows-WiX/BuildSubversion/WixDialog/ packages/windows-WiX/BuildSubver... To: comm...@subversion.apache.org Author: hwright Date: Mon Nov 16 19:07:17 2009 New Revision: 880911 URL: http://svn.apache.org/viewvc?rev=880911view=rev Log: Test out my new and fancy ASF commit priviledges by changing the copyright wording in our license headers to reflect ownership by the ASF. * NOTICE: Change terminology to ASF, and update a link. * subversion/libsvn_subr/opt.c (svn_opt__print_version_info): Note that the product as a whole is copyrighted by the ASF, and update the project website. * everywhere: Change license text to reflect ASF ownership. Modified: ... - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education
On Nov 12, 2009, at 9:05 PM, Jukka Zitting wrote: Hi, On Wed, Nov 11, 2009 at 4:11 PM, Greg Stein gst...@gmail.com wrote: Plan: raise an issue, and we fix it. Not sure what else you're looking for. I was just pointing out that if you want to do the release review based on an existing 1.6.x release, I wouldn't expect it to be fully compliant with Apache policies (license headers, etc.) and would accept a plan on how those issues will be (or already are being) resolved in the first Apache release of Subversion (1.7.0?). To me that would satisfy the release-related exit criteria we have. FWIW, the Subversion nightly server is back online: http://orac.ece.utexas.edu/pub/svn/nightly/ The cron job used to generate those tarballs uses the exact same rolling scripts we use to generate standard releases, so those tarballs could be used to test whatever non-process-related qualifications for release people want to see. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 9:16 AM, Mark Phippard wrote: On Tue, Nov 10, 2009 at 10:10 AM, Greg Stein gst...@gmail.com wrote: On Tue, Nov 10, 2009 at 09:59, C. Michael Pilato cmpil...@collab.net wrote: ... I certainly understand why license issues would be a concern. But I could use an education about why this particular case matters. We currently ship Neon in a separate tarball from Subversion's core code for the convenience of our users, but if that's a problem, we can stop doing so. Subversion doesn't require Neon. Or Serf. You can have a perfectly valid, working, Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. So users and package maintainers are free to assemble Subversion with the optional bits they care to provide for their consumers. Igor, is there a particular concern that you can elaborate on here if only for my education? If the Apache software is *non-functional* without the LGPL software, then you are effectively requiring downstream users to link themselves into the LGPL licensing. Since Subversion does not require any LGPL to function, then we should be just fine. I plan to run this past legal-discuss for verification (along with our optional GNOME, KDE, and BDB dependencies). I seem to recall from the legal web pages there is no specific mention of our case, so wanted to double-check and then possible add our use-case to those pages. Regarding serf and Neon, I think that serf will be just fine to have as a default. It has been totally functional for many of us (cmpilato is a serf skeptic :-P) He is not the only one :) That said, I think the point is why should the default matter? We can either optionally use Neon or we cannot. Even if Neon is the default, if someone builds with only Serf then it becomes the default. As Mike says, we do not provide binaries so we will not be asking to distribute any of these libraries. We will need to find out if it is OK to still supply our dependencies tarball for convenience. And if we can't ship the deps tarballs, you won't find me (the current release manager) shedding any tears. I don't have any statistics to back it up, but I tend to thinks the deps tarball is pretty underutilized. I don't think it would have a negative impact on our users or release process. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [PROPOSAL][VOTE] Subversion
On Nov 10, 2009, at 10:29 AM, Jochen Wiedmann wrote: On Tue, Nov 10, 2009 at 3:59 PM, C. Michael Pilato cmpil...@collab.net wrote: Subversion client and server that doesn't use a DAV layer at all. The Subversion community has never released binaries -- ever -- not do we plan to. That would a completely new philosophy for an Apache project, which always aimed very heavily on distributions. It might either enforce to look at legal aspects in a different view - or lead to changing your philosophy. :-) Personally, I don't see any reason why things like creation of Windows binaries should be left to outsiders. (Apart from CollabNets business interests, which I wouldn't like to count.) Just recently, we had a very active discussion regarding Maven where the emphasis was laid very heavily on the distributable archives (binary and source) as the endorsed result of the release/vote process. The reason we (Subversion) do not ship binaries is simple: we don't have the resources to meet the request, and most of our users use Subversion as part of a third-party tool, which most often *does* ship as a binary. We've supported community efforts to create binaries, even going so far as to host selected variants on our downloads page, but they are still not considered official artifacts of the project. -Hyrum - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Insanity. Apache Incubator should be about education
contrib/ has been removed from the packaging scripts, and won't ship with 1.7. In other news, the box that builds the nightly tarballs is back online, albeit with a new disk, so it'll take me a day or two to get it back up. When it does, I'll point people there, and you can see what a typical tarball would look like (with the caveat that a nightly is untested, not a true release, and could cause a black hole that swallows the Earth). -Hyrum On Nov 10, 2009, at 4:04 PM, Greg Stein wrote: Dims: Exactly. The svn devs have been talking off/on what to do about contrib/ for nearly a year. Various options: simply toss it and wait for people to cry and do something to fix it; somehow get it all relicensed (one of the contributors already said no); etc etc. Current consensus seems to be that we'll simply not package the contrib/ section into our 1.7 release. Cheers, -g On Tue, Nov 10, 2009 at 16:53, Davanum Srinivas dava...@gmail.com wrote: Jukka, Not so sure... because that dist may contain code that we may not allow. Greg, Is there any code in there that is not Apache compatible? i see some in the contrib section... http://svn.collab.net/repos/svn/trunk/contrib/client-side/svn-clean thanks, dims On 11/10/2009 04:25 PM, Jukka Zitting wrote: Hi, On Tue, Nov 10, 2009 at 8:28 PM, Greg Steingst...@gmail.com wrote: Unfortunately, some documentation needs to be brought in sync. See: http://incubator.apache.org/guides/graduation.html#checklist I'm nitpicking, but even there we only ask the podlings to demonstrate ability to create Apache releases. Per Joe, I think it makes sense to run podlings through a release to teach them the ropes, rather than lump that onto Infrastructure. But I also believe we should provide waivers when appropriate. Fair enough. As an alternative, how about submitting http://subversion.tigris.org/downloads/subversion-1.6.6.tar.bz2 for IPMC review? That should require no extra work from and no special waivers for Subversion. BR, Jukka Zitting - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
