Re: Proposal for STDCXX

[Branko Čibej]

On May 13, 2005, at 5:27 PM, Heidi Buelow wrote:
Proposal for an Apache-run version of the C++ Standard Library

+1
The proposal says that this library has a "complete locale 
implementation". I'm wondering about the possibilities for code reuse 
when/if we start on a second generation of apr-iconv.

-- Brane
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Package naming for several languages

[Branko Čibej]

On 30.01.2014 21:16, Kowalski, Francois-Xavier wrote:
> My $0.1: stick with the language rather than with the platform:

Because it's well-known that API implementations are never
platform-specific. :)


> *-js/
> *-objc/
> *-cs/
>
>
> —FiX
>
> -Original Message-
> From: Lewis John Mcgibbney 
> Reply-To: "general@incubator.apache.org" 
> Date: Thursday 30 January 2014 19:46
> To: "general@incubator.apache.org" 
> Subject: Package naming for several languages
>
>> Hi Folks,
>> Currently we are working on getting correct package naming implemented
>> within Apache Usergrid (incubating).
>> The Usergrid codebase contains SDK's in several languages... no biggie,
>> however what I am unsure about is how package naming should be implemented
>> in dotnet [0], html5-javascript[1], ios[2], etc packages?
>> Any direction would be very handy.
>> Thanks in advance
>> Lewis
>>
>> [0] https://github.com/usergrid/usergrid/tree/master/sdks/dotnet
>> [1] https://github.com/usergrid/usergrid/tree/master/sdks/html5-javascript
>> [2] https://github.com/usergrid/usergrid/tree/master/sdks/ios
>>
>> -- 
>> *Lewis*
>
> -
> 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

Re: Websites, WebApps, and Release Policy

[Branko Čibej]

On 26.08.2014 00:24, Justin Mclean wrote:
> Hi,
>
>> This strikes me very similar to providing access to daily SNAPSHOT binary
>> artifacts. I would argue that labeling it appropriately is all you
>> need.
> Except that is this case the intended audience of the application is users.

Bloodhound has maintained two VMs that host publicly available
development snapshots since it was a podling, and still does today, more
than a year after it graduated. The situation is exactly the same; the
snapshots are clearly marked as "development work in progress", the
sources of the running instances are freely available from SVN to anyone
with a web browser. There has never been any confusion as to whether
these snapshots are an ASF Release or not.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating)

[Branko Čibej]

On 02.09.2014 15:51, Dave wrote:
> On Tue, Sep 2, 2014 at 9:43 AM, John D. Ament 
> wrote:
>
>> So... do you have a 1.0 artifact staged somewhere? I get that it's a
>> rebuild of RC4, but I don't see that release referenced anywhere on your
>> site.
>>
> The release files are here: http://people.apache.org/~snoopdave/usergrid/

Release bits have to be in SVN, not in some random location on some
random server. In your case:

https://dist.apache.org/repos/dist/dev/incubator/usergrid

before it's released and in

https://dist.apache.org/repos/dist/release/incubator/usergrid

after the release vote has passed and usually 24 hours before the
release is announced. Neither of these directories exist.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION

[Branko Čibej]

On 03.09.2014 05:03, Jake Farrell wrote:
> Hi John
> I requested that Dave add the RC tag to better keep track of multiple
> release candidates and make it easier for testing and not mixing any
> previous version up accidentally. This is very common and currently done in
> many TLP's including Thrift, Mesos, and Cassandra to name a few.

Agreed. And it is (or should be) normal process to start a new vote for
every new set of release bits. Even if 1.0.0 is just a repackaging of
1.0.0-rc4, there may be bugs in the packaging process itself (such as
we've seen in this thread, when files that were not intended to be
released were bundled in the release artefacts), so the PPMC should test
and vote again.

The vote should always refer to a particular release package (taken from
dist/dev), not to some tag in the repository.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release RC4 as Apache Usergrid 1.0 (incubating) - CORRECTION

[Branko Čibej]

On 02.09.2014 23:06, Dave wrote:
> Rats. That directory should not have been included in the release. It
> is created as part of the build process and the contents are fetched
> by Bower (similar to how Maven pulls in jars). Thanks for your
> attention to detail. I will have a new set of release files shortly
> and will restart the vote.

Please don't forget to cancel this vote by replying to the vote thread
and adding a [CANCEL] or [CANCELLED] tag before the [VOTE] tag in the
subject. Otherwise the vote tracker will not know that the vote has been
closed and will keep tracking it forever.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Grill as new Incubator project

[Branko Čibej]

On 23.09.2014 14:37, Jean-Baptiste Onofré wrote:
> I like Lens indeed.

Sooo ... I suppose the PMC chair will be called the Grey Lensman then? :)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Silk as new Incubator project

[Branko Čibej]

On 27.09.2014 05:38, Konstantin Boudnik wrote:
> Hi David.
>
> I believe it will be needing a usual place to publish releases

Release tarballs go here before the release vote starts:

https://dist.apache.org/repos/dist/dev/incubator/ignite

After the vote passes, they should be moved here:

https://dist.apache.org/repos/dist/release/incubator/ignite

Feel free to create the "ignite" directories as necessary.


Note that .../release/... is distributed to mirrors; over at Subversion,
we wait 24 hours between moving release bits to .../release/... and
announcing the release, to make sure that all mirrors have caught up.
Only the latest reelase should be there, any older versions must be
deleted. They should have been automagically moved to

http://archive.apache.org/dist/incubator/ignite

fairly soon after they appear on dist.apache.org; if they don't, nudge
Infra.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Ignite into the Apache Incubator

[Branko Čibej]

On 28.09.2014 02:58, Konstantin Boudnik wrote:
> I would like to call a vote for accepting "Apache Ignite" for Apache 
> Incubator.
> The full proposal is available below. We ask the IPMC to sponsor it, with cos
> as Champion, and stack, rvs, cos, hsaputra and brane volunteering to be 
> Mentors.
>
> Please cast your vote:
>
> [ ] +1, bring Iginite into Incubator
> [ ] +0, I don't care either way,
> [ ] -1, do not bring Iginite into Incubator, because...

+1 (binding)

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Code Donations and Committer Righs

[Branko Čibej]

On 26.09.2014 20:03, jan i wrote:
> On 26 September 2014 19:23, Roman Shaposhnik  wrote:
>
>> Just like Ross, the following constitutes my personal opinion
>> (that has been formed over the years of maintaining complex
>> code bases written "before my time"):
>>
>> On Fri, Sep 26, 2014 at 10:04 AM, Ross Gardler (MS OPEN TECH)
>>  wrote:
>>> OK. I will give you my personal opinion since you are seeking to drive
>> consensus...
>>> I would say that if the code is of sufficient quality and relevance for
>> the project to want
>>> to accept it then contributors should be given commit rights.
>> I would even go further than this: to me a brand new code donation
>> without anybody donating that code willing to sign up to maintain
>> it (at least for as long as it takes for others to ramp up) spells orphaned
>> code.
>>
>> IOW, for sizable brand new contribution the commit rights of somebody
>> familiar with the code shouldn't be a question, but more of a prerequisite
>> to actually accepting that contribution in the first place.
>>
> my personal opion is a big +1 to not accepting bigger contributions if the
> programmers (or at least part of them) comes along. Getting new code
> without people that understand it deeply, is really asking for trouble.

I tend to agree. However, there's more than one aspect to the issue:
your typical ASF committer does not only contribute and maintain code;
she also participates in the process of managing the project and
community. The more so on projects that do not make a difference between
committer and PMC member.

It may not always be the case that someone who makes a software grant is
also aware of how the project and community work. On the other hand, one
would expect that the existing community members are able to help such
new contributors over the initial hurdles of adapting to the (drumroll)
Apache Way.

So ... it's essentially a toss-up, but personally I'd prefer
inclusiveness over control-freakness.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Committer Voting and Vetos

[Branko Čibej]

On 01.10.2014 05:41, Greg Stein wrote:
> On Tue, Sep 30, 2014 at 10:28 AM, Ted Dunning  wrote:
>
>> On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein  wrote:
>>
>>> To the concrete question, the Subversion project never calls a strict
>>> [VOTE] for new committers or PMC members. We discuss first, and that sets
>>> the direction. People throw out +1 messages, but that is "sure, make it
>> so"
>>> rather than a true vote. Whenever somebody says "wait a minute", then we
>>> do. We don't have formal rules around this stuff, since a general goal of
>>> consensus is so ingrained into the community.
>>>
>> The nice thing about the vote is that there is a [RESULT] message to link
>> to.  What does the Subversion project link to in the account request?
>>
> We don't provide a link. There is no reason for Infrastructure to
> second-guess account requests from Officers or ASF Members, so that link is
> optional. *Should* a question ever arise, then it is easy enough to provide
> background information.

Yup. I see the link field there as being mainly for the benefit of the
Incubator and podlings.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: svn commit: r1631099 - /incubator/public/trunk/content/projects/ignite.xml

[Branko Čibej]

On 12.10.2014 14:24, sebb wrote:
> On 11 October 2014 20:15,   wrote:
>> Author: cos
>> Date: Sat Oct 11 19:15:17 2014
>> New Revision: 1631099
>>
>> URL: http://svn.apache.org/r1631099
>> Log:
>> Updating Ignite website with initial INFRA task dates
>>
>> Modified:
>> incubator/public/trunk/content/projects/ignite.xml
>>
>> Modified: incubator/public/trunk/content/projects/ignite.xml
>> URL: 
>> http://svn.apache.org/viewvc/incubator/public/trunk/content/projects/ignite.xml?rev=1631099&r1=1631098&r2=1631099&view=diff
>> ==
>> --- incubator/public/trunk/content/projects/ignite.xml [utf-8] (original)
>> +++ incubator/public/trunk/content/projects/ignite.xml [utf-8] Sat Oct 11 
>> 19:15:17 2014
>> @@ -91,12 +91,6 @@
>>.
>>.
>>  
>> -Branko Čibej
>> -Konstantin Boudnik
>> -Henry Saputra
>> -Roman Shaposhnik
>> -Michael Stack
>> -
> Why were the mentor names dropped?


They weren't dropped; these were duplicates in the wrong place. All five
are still listed as mentors on this page.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Branko Čibej]

On 13.10.2014 16:14, Julian Hyde wrote:
> For many projects, especially "library" projects, the "convenient binaries" 
> that matter most these days are the jars (source, binary, and javadoc) that 
> are deployed to the maven repo. Calcite releases in fact do not currently 
> include a binary tar ball, only a source tar ball and maven jars. 
>
> Are these jars subjected to due diligence during the release vote? It seems 
> to me that each of those jars is a de facto binary release.

If it contains sources, it's not a binary release. Binary JARs are
definitely a binary release. I haven't a clue what Javadocs are, but
since they're derived from the sources, I'd prefer to put them in the
"binary" category for simplicity.

But that's beside the point. "Convenience binaries" are anything that
was created from the properly voted-on and released source that did not
go through the same formal release proces as the source release. If the
PMC did not vote on the binary JARs, they are not an Apache Release and
therefore none of our guarantees (or liabilities) can apply to them.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Convenience Binary Policy

[Branko Čibej]

On 21.10.2014 06:34, Alex Harui wrote:
> What is the piece I’m missing that says we have to vote to update the
> binary package?

Apparently the Flex community believes that convenience binaries need
votes. They don't, but aside from that, if you guys are already voting
on binary packages, it makes perfect sense to vote for your fixed
version, if only to keep people happy.


-- Brane

P.S.: Why anyone would think voting on binaries makes any kind of sense
around here is, of course, a different question. I can't even begin to
count the number of times it's been pointed out that binaries are not
Apache releases.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Convenience Binary Policy

[Branko Čibej]

On 21.10.2014 15:55, Harbs wrote:
> The one thing I see missing from the proposed text is dependencies and 
> installers.
>
> Particularly this section:
> ### Compiled packages ### {#compiled-packages}
>
> The Apache Software Foundation produces open source software. All releases
> are in the form of the source materials needed to make changes to the
> software being released.
>
> As a convenience to users that might not have the appropriate tools to build a
> compiled version of the source, binary/bytecode packages MAY be distributed
> alongside official Apache releases.  In all such cases, the
> binary/bytecode package MUST have the same version number as the source
> release and MUST only add binary/bytecode files that are the result of
> compiling that version of the source code release.
> ---
> How do binary dependencies fit in?

Binary dependencies are, by definition, not released by the ASF; because
we release source code. Also, software that has dependencies that are
only available in binary form is not open-source, in my book.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] [PROPOSAL] HTrace for Apache Incubator

[Branko Čibej]

On 03.11.2014 16:49, Stack wrote:
> On Sun, Nov 2, 2014 at 6:19 PM, Naresh Agarwal 
> wrote:
>
>> Just curious if HTrace is aimed only for Hadoop infrastructure/Hadoop based
>> applications or it can be used in any Java based systems?
>>
>>
> HTrace's provenance is Hadoop but the only hadoop 'taint' in HTrace is the
> leading 'H' in its name; it should be fit for any java distributed systems.
>
> Lets make this more plain in the proposal.

Would it hurt to remove the H from the project name, then?

(I won't propose replacing it with "D", that would be really confusing.)

-- Brane

P.S.: Ooh ... "Distributed Tracing" -> Distress, which happens to be
what an admin feels when her distributed app goes wonkers ...

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] [PROPOSAL] HTrace for Apache Incubator

[Branko Čibej]

On 03.11.2014 19:12, Stack wrote:
> On Mon, Nov 3, 2014 at 8:01 AM, Branko Čibej  wrote:
>
>> On 03.11.2014 16:49, Stack wrote:
>>> On Sun, Nov 2, 2014 at 6:19 PM, Naresh Agarwal <
>> naresh.agar...@inmobi.com>
>>> wrote:
>>>
>>>> Just curious if HTrace is aimed only for Hadoop infrastructure/Hadoop
>> based
>>>> applications or it can be used in any Java based systems?
>>>>
>>>>
>>> HTrace's provenance is Hadoop but the only hadoop 'taint' in HTrace is
>> the
>>> leading 'H' in its name; it should be fit for any java distributed
>> systems.
>>> Lets make this more plain in the proposal.
>> Would it hurt to remove the H from the project name, then?
>>
>> (I won't propose replacing it with "D", that would be really confusing.)
>>
>> -- Brane
>>
>> P.S.: Ooh ... "Distributed Tracing" -> Distress, which happens to be
>> what an admin feels when her distributed app goes wonkers ...
>>
> HTrace is 'fairly' generic and the github project is what comes up when you
> search. That said, I think your suggestion pretty great, funny. Its
> probably a bad name for a software project though? (Distrace?)

If Subversion and Git are OK, then Distress fits right in, wouldn't you
say? :)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduation of Apache Falcon from the Incubator

[Branko Čibej]

On 05.11.2014 16:05, Srikanth Sundarrajan wrote:
> Hi Jan,
> Venkatesh Seetharam is extremely active on the project, but couldn't vote 
> on this thread,

Why not? Are you guys by any chance treating project committers and PPMC
members differently?

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

[Branko Čibej]

On 21.08.2012 12:52, sebb wrote:
> I think the NOTICE problems are serious enough to warrant a respin.

This is an unreasonable request. The IPMC voted on the 3.4.0 release.
The notice file has not changed between 3.4.0 and 3.4.1. How then do you
justify this new requirement?

It is not fair to the podling if the IPMC invents new requirements and
reverses its own decisions for no apparent reason. This NOTICE issue
certainly shouldn't be ground for vetoing a release.

By the way, the same holds for binaries being included in the releases.
The 3.4.0 release, with binaries, was approved. If the podling did not
change its release procedures and policies and artefacts in the
meantime, it's not reasonable to hold up what amounts to a security
release solely based on the IPMC having screwed up the previous release
vote.

It is fair to require changes for the next release. It's not fair to use
different criteria for two successive, essentially identical releases.
(N.B.: I use the term "essentially identical" in the sense that, whilst
some of the sources have changed, the overall structure of the release
artefacts has not.)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

[Branko Čibej]

On 21.08.2012 17:29, Greg Stein wrote:
> On Tue, Aug 21, 2012 at 11:26 AM, Greg Stein  wrote:
>> On Tue, Aug 21, 2012 at 8:53 AM, Thilo Goetz  wrote:
>>> On 21/08/12 13:59, Branko Čibej wrote:
>>>> On 21.08.2012 12:52, sebb wrote:
>>>>> I think the NOTICE problems are serious enough to warrant a respin.
>>>> This is an unreasonable request. The IPMC voted on the 3.4.0 release.
>>>> The notice file has not changed between 3.4.0 and 3.4.1. How then do you
>>>> justify this new requirement?
>>> Let me offer some advice from somebody who has been where you
>>> are now.
>> To be clear: Branko is an IPMC mentor, and not part of the AOO community.
> Oops. I meant IPMC *member*. (and an ASF Member for a couple years)
>
>> And I do happen to agree with Benson (else-thread) that any NOTICE
>> problems here do not require a respin.
>>

(nod) I should've emphasized that I'm spamming ex-cathedra as an
uninterested observer. :)

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Branko Čibej]

On 26.08.2012 13:15, Tim Williams wrote:
> Marvin gave the link earlier in this thread. 4th para is the relevant bit.
>
> http://www.apache.org/dev/release.html#what

The relevant part is in the last paragraph. However, that says
"convenience" and defines version numbering requirements, but it does
/not/ state that the binaries are not sanctioned by the ASF and are not
part of the official ASF release.

It would be very useful if that paragraph were amended to say so
explicitly. I've had no end of trouble trying to explain to managers and
customers that any binaries that come from the ASF are not "official".
Regardless of the policy stated numerous times in this thread and on
this list, this is not clear anywhere in the bylaws or other online
documentation (that I can find).

-- Brane

P.S.: I asked this same question on legal-discuss a week ago. My post
has not even been moderated through as of today, so referring people to
that list doesn't appear to be too helpful.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Branko Čibej]

On 26.08.2012 16:46, Joe Schaefer wrote:
> The point most people seem to make out of "sanctioned"
> or "official" builds revolves around indemnifying volunteers
> involved in the production of the release.
>
>
> I'm tired of rehashing release.html for the umpteenth time
> simply because Brane or you or some other newb lacks the
> experience to know the context behind the document, but
> as they say patches welcome (on site-...@apache.org).  Every
> committer can alter the wording on that page and do something
> more productive than make clueless arguments on this
> ever devolving thread.

That's very helpful, thanks. So if someone asks me about ASF releases
and binaries I should refer them to the legal-discuss archives, or these
general@ archives, or simply tell them to find a founding member to
condescendingly explain the obvious. Because I sure can't give 'em a
link to some page on our web site.

I'll refrain from spelling out the epithets that come to mind.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache OpenOffice Community Graduation Vote

[Branko Čibej]

On 26.08.2012 17:04, Joe Schaefer wrote:
> Waah Brane- obviously you're not as community-oriented
> as you'd like to think.  release.html is the byproduct
> of several years of writing oriented towards the lowest
> common denominator of the org, but if you think you know
> how to improve it you have all the requisite karma already.
>
> All that's missing is a clue.

Joe, I know very well (and you know that I know) that I can edit most of
the things that appear on our web site. But if community-oriented means
that anyone should just edit those docs to scratch an itch and to hell
with consensus and the consequences, then you're right, I'm definitely a
misfit here.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

[Branko Čibej]

On 08.10.2012 13:44, Franklin, Matthew B. wrote:
>> -Original Message-
>> From: Marvin Humphrey [mailto:mar...@rectangular.com]
>> Sent: Friday, October 05, 2012 8:54 PM
>> To: general@incubator.apache.org
>> Subject: Re: key signing
>>
>> On Fri, Oct 5, 2012 at 8:55 AM, Jukka Zitting  
>> wrote:
>>> It's good to recommend people to get their keys signed by someone in
>>> the Apache web of trust and I think we could do more in that area,
>> Maybe if we didn't insist on face-to-face meetings we'd get better adoption
>> rates.
>>
>> Apache dev docs:
>>
>>http://www.apache.org/dev/openpgp.html#wot-link-in
>>
>>How To Link Into A Public Web Of Trust
>>
>>In short, expect that:
>>
>>*   this will involve a face-to-face meeting
>>
>> GnuPG docs:
>>
>>http://www.gnupg.org/gph/en/manual.html#AEN84
>>
>>A key's fingerprint is verified with the key's owner.  This may be done in
>>person or over the phone or through any other means as long as you can
>>guarantee that you are communicating with the key's true owner.
> +1.  I think with technologies like Skype & Google Hangout, we can get the 
> same level of assurance of a person's identity as a physical key signing 
> party.

What guarantee do you have that a particular Skype ID is whoever you
think it is? None at all, unless the person involved looked at your
Skype contact list and said, yeah, that's me. Likewise for Google
Hangout. As long as they're doing that, they might as well verify the
signature fingerprint in your PGP keyring.

In this respect e-mail is just as secure, so why don't we all just sign
keys because someone claiming to be from from Chad sent us a mail asking
us for a signature?

Really.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

[Branko Čibej]

On 08.10.2012 17:43, Marvin Humphrey wrote:
> On Mon, Oct 8, 2012 at 7:36 AM, Branko Čibej  wrote:
>> What guarantee do you have that a particular Skype ID is whoever you
>> think it is? None at all, unless the person involved looked at your
>> Skype contact list and said, yeah, that's me. Likewise for Google
>> Hangout. As long as they're doing that, they might as well verify the
>> signature fingerprint in your PGP keyring.
>>
>> In this respect e-mail is just as secure, so why don't we all just sign
>> keys because someone claiming to be from from Chad sent us a mail asking
>> us for a signature?
>>
>> Really.
> Is it your position that this excerpt from the GnuPG docs is wrong?
>
> This may be done in person or over the phone or through any other
> means as long as you can guarantee that you are communicating with
> the key's true owner.

It says clearly, "as long as you can guarantee that you are
communicating with the key's true owner." Which was exactly my point.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: key signing

[Branko Čibej]

On 10.10.2012 00:01, Marvin Humphrey wrote:
> While this protocol does not rely heavily on validating
> government-issued IDs, the Debian guidelines quoted above point out
> that some people object to giving such IDs too much creedence:

So instead of giving too much credence to government-issued IDs, you'd
prefer to give credence to a service provided "for free" by a commercial
entity with a conceivable interest in inserting backdoors in software or
subverting trust in certain keys (a.k.a. Google), with the whole thing
being archived in as system controlled by another commercial entity
(a.k.a. YouTube, incidentally a.k.a. Google), with no public oversight
of those archives.

I'm sure you'd sue Google and win if they fake the archive.

-- Brane


-
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.2 (incubating)

[Branko Čibej]

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.

-
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.2 (incubating)

[Branko Čibej]

On 08.11.2012 19:08, Joachim Dreimann wrote:
> Marvin: Thank you for the helpful feedback. I will discuss this with the
> other devs and raise tickets for us as appropriate. I believe Hyrum has not
> yet voted to my knowledge, only Brane. So we still need two votes at this
> point.

Hyrum voted +1. You need one more IPMC vote to release.

-- Brane


-
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.2 (incubating)

[Branko Čibej]

On 10.11.2012 14:39, Franklin, Matthew B. wrote:
> Apologies for the delay, the conference wifi was taken down before I could
> send the e-mail.
>
> Unfortunately, when I ran a license header check, the report came back
> with some minified css & js files in the source release.  As far as I am
> aware, minified files are not considered source and therefore should not
> be in the distribution.

Hm, then why doesn't that show up here:

http://ci.apache.org/builders/bloodhound-trunk-rat-report


Regarding the minified files you found: I agree that minification
should, in future, be part of the installation process. However, once
can hardly claim that minified files are "not source". They are souce,
not even compressed. IMO the point of having source releases is
auditability. Minification makes it harder, but doesn't take it away
(as, for example, compilation does).

I propose this is not a release blocker. We should however recommend
that the project stops shipping minified sources in some (near) future
release.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Apache Marmotta

[Branko Čibej]

On 19.11.2012 13:15, Benson Margulies wrote:
> On Mon, Nov 19, 2012 at 6:32 AM, Andy Seaborne  wrote:
>> On 19/11/12 11:20, Sebastian Schaffert wrote:
>>> Hi all,
>>>
>>> we have had a brainstorming round and came up with the suggestion "Apache
>>> Marmotta" as a new name. We looked a bit and the name seems not to be taken
>>> yet, so there would probably no legal issues with the name.
> A big +1. The small furry logo opportunities rival a certain famous elephant.

And it helps (?) that it's easy to associate with gopher. You know, that
internet search thing? Incidentally also a furry rodent ...

-- Brane


-
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.3 (incubating)

[Branko Čibej]

On 26.11.2012 16:59, Joachim Dreimann wrote:
> Hi,
>
> I would like to request the beginning of the vote for the third 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/owksv6lbcs6zq7th
>
> 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/tags/0.3-incubating/
>   (r1412891)
>
> Issues identified to be fixed for the next release are listed here:
>   https://issues.apache.org/bloodhound/ticket/273
>   https://issues.apache.org/bloodhound/ticket/274
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Release this package as Apache Bloodhound 0.3
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)

+1 (binding)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Invoke silent consensus rule for podling releases (was: [VOTE] Release Apache Bloodhound 0.3 (incubating))

[Branko Čibej]

It's quite frustrating that people find time to write hundreds of mails
about points of procedure, but can't take time to review a release
tarball from a podling.

Activity on Bloodhound is picking up, and the project wants to release
every couple weeks; yet the 0.2 vote thread sat in general@ for longer
than that.

It's worse for these mails to go unanswered than if the release had been
vetoed. I hereby propose we extend the silent consensus rule to podling
release votes.

-- Brane

On 26.11.2012 16:59, Joachim Dreimann wrote:
> Hi,
>
> I would like to request the beginning of the vote for the third 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/owksv6lbcs6zq7th
>
> 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/tags/0.3-incubating/
>   (r1412891)
>
> Issues identified to be fixed for the next release are listed here:
>   https://issues.apache.org/bloodhound/ticket/273
>   https://issues.apache.org/bloodhound/ticket/274
>
> The vote will be open for at least 72 hours.
>
> [ ] +1 Release this package as Apache Bloodhound 0.3
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)
>
> Cheers,
> Joe
>


-
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.3 (incubating)

[Branko Čibej]

On 01.12.2012 08:37, Luciano Resende wrote:
> On Mon, Nov 26, 2012 at 7:59 AM, Joachim Dreimann <
> joachim.dreim...@wandisco.com> wrote:
>
>> Hi,
>>
>> I would like to request the beginning of the vote for the third 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/owksv6lbcs6zq7th
>>
>> 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/tags/0.3-incubating/
>>   (r1412891)
>>
>> Issues identified to be fixed for the next release are listed here:
>>   https://issues.apache.org/bloodhound/ticket/273
>>   https://issues.apache.org/bloodhound/ticket/274
>>
>> The vote will be open for at least 72 hours.
>>
>> [ ] +1 Release this package as Apache Bloodhound 0.3
>> [ ] +0 Don't care
>> [ ] -1 Do not release this package (please explain)
>>
>> Cheers,
>> Joe
>>
>> --
>> Joe Dreimann
>> UX Designer | WANdisco 
>>
>
> License and notice seems fine and couple of the issues found during the
> vote on the dev list dosen't seem blocking.
>
> +1 binding.

Thank you, Luciano. We now have two binding IPMC votes, one from a
mentor, and one from another IPMC member who was kind enough to be
provoked into action by said mentor's troll.

Any other takers? :)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Invoke silent consensus rule for podling releases

[Branko Čibej]

On 01.12.2012 15:06, Marvin Humphrey wrote:
> On Fri, Nov 30, 2012 at 9:08 PM, Branko Čibej  wrote:
>> It's quite frustrating that people find time to write hundreds of mails
>> about points of procedure, but can't take time to review a release
>> tarball from a podling.
> Reviewing a release when you are not directly involved as a developer is
> **really hard**.
>
> As an IPMC member yourself, have you ever reviewed a release for podling you
> were not involved with?

Yes. In fact, I spent time reviewing AOO incubator releases. Don't
recall if I actually voted on one; probably not, since there were so
many other active IPMC members all over that.

> I hereby propose we extend the silent consensus rule to podling
> release votes.
> -1
>
> That's at odds with basic, ASF-wide rules for voting on releases.

I know; but it got everyone's attention, didn't it. :)

What I'd more seriously like to propose is that we come up with a tool
that slurps the general@ archives and pings the list once a week with a
reminder about outstanding votes. I'll happily invest my copious free
time towards that, if the IPMC agrees such a tool would be useful.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Invoke silent consensus rule for podling releases

[Branko Čibej]

On 01.12.2012 16:00, Daniel Shahaf wrote:
> Make every vote a bugzilla issue, and use the existing script that mails
> an issue summary once a week?

That's certainly one thing I considered.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: "Obfuscating' 3rd party jars

[Branko Čibej]

On 04.12.2012 06:35, Michael MacFadden wrote:
> Benson,
>
> I agree.  There was some progress in mavenizing the build.  I suspect that
> that solution will take some time.  The build process is somewhat
> complicated at the moment, if this is the long term solution, we may need
> to do something simpler to start off with.

The "something simpler" is called an INSTALL(.txt) file, in which you
write that the project depends on Junit and emma, which can be
downloaded from so-and-so and placed over-there in the source tree.

> In the case of Junit, we should probably be able to remove it from a
> binary release.  There is no reason to include it in my mind since it's
> only used during the build.  Not sure on emma.

I notice that Junit and emma are both category-B per

http://www.apache.org/legal/resolved.html

so you can use them (given the restrictions in that resolution), but if
you're worried about obfuscation then do not include them in your
release tarball.

>   Regardless a temporary
> work around would be to remove them and simply required the users to
> download them.  We could even provide a simple script to do that.

Or that, yes.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Wiki karma

[Branko Čibej]

I find myself unable, as a Bloodhound mentor, to sign off their report
for December.  Can I please get karma to edit the Incubator wiki? My
wiki username is "brane".

Thanks,

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Bloodhound status (Was: Shepherd assignments, December 2012, first pass)

[Branko Čibej]

On 11.12.2012 23:21, Jukka Zitting wrote:
> Hi,
>
> On Tue, Dec 4, 2012 at 2:20 AM, Benson Margulies  
> wrote:
>> Jukka Zitting: Bloodhound
> The report looks pretty good - they've added a few new committers and
> cut some releases after their previous report. The report, like the
> previous one, notes community diversity as the top issue, but with the
> new committers in place and looking at the nicely growing commit and
> list activity it seems to me as if the project is already on a good
> track towards graduation.

New committers are not the same as community diversity, unfortunately.
The overwhelming majority of contributors to the project are sponsored,
in one way or another, by a single commercial entity. As things
currently stand, if that entity looses interest, the project dies.

The intent is that, with announcements about frequent releases going to
(amongst other places) trac-hacks, interest will eventually bring new
blood to the project.

> In fact based on my brief review I don't see any notable reasons to
> vote against graduation should a vote come up tomorrow, so I've
> categorized the project as ready to graduate as soon as they feel
> they're up to it. Mentors, please correct if needed.

I agree, apart from the community diversity issue.

> PS. It would be interesting to see a summary of how the relationship
> with the Trac project played out in practice. I remember this being a
> source of quite a bit of concern when Bloodhound was being proposed,
> but it looks like everything has worked out fairly well. This might be
> a useful example to keep in mind when similar cases come up in the
> future.

I'm not actively involved in liaison with Trac, but I do know that the
Bloodhound community is being very careful about not stepping on any
toes, and stressing that BH is an enhancement of Trac, not a fork. For
now, I don't detect any friction between the two projects.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Bloodhound status (Was: Shepherd assignments, December 2012, first pass)

[Branko Čibej]

On 12.12.2012 03:22, Kalle Korhonen wrote:
> Also - there's a fairly new startup in San Francisco area going by the same
> name Bloodhound (see http://bloodhound.com/). I'm not associated with them,
> just happened to hear about them. It's obviously not in the same business
> but given how Apache projects have traditionally been rather cautious with
> branding and trademark conflicts, name change is perhaps something the
> project may want to consider.

This is actually ridiculous, both the name and the logo look like a
ripoff. I'm sure that site wasn't up even a few months ago; I certainly
did a bit of searching around for the use of "bloodhound" an found only
a range of blood testing medical equipment.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Onami Parent 1 RC2

[Branko Čibej]

On 27.12.2012 08:41, Marcel Offermans wrote:
> Hello Christian,
>
> On Dec 26, 2012, at 11:05 AM, Christian Grobmeier  wrote:
>
>> Hi Marcel,
>>
>> On Wed, Dec 26, 2012 at 10:22 AM, Marcel Offermans
>>  wrote:
>>> -1 Because: The release now is a ZIP file, and contains the NOTICE and 
>>> LICENSE files, but they must be located at the root of the archive [1], and 
>>> not in a subfolder like they are now.
>> For me they are in the root folder. It looks exactly as the Apache Parent:
>> https://repository.apache.org/content/repositories/releases/org/apache/apache/12/
>>
>> My package opens like this:
>>
>> $ tree .
>> .
>> ├── DEPENDENCIES
>> ├── DISCLAIMER
>> ├── LICENSE
>> ├── NOTICE
>> ├── pom.xml
>> └── src
>>└── site
>>└── site.xml
>>
>> Can you please tell me what you are seeing? I really don't get what you mean.
> This is what I am seeing:
>
> Marcels-MacBook-Pro:Downloads marcel$ unzip -l 
> org.apache.onami.parent-1-incubating-source-release.zip 
> Archive:  org.apache.onami.parent-1-incubating-source-release.zip
>   Length Date   TimeName
>     
> 0  12-21-12 05:29   org.apache.onami.parent-1-incubating/
> 0  12-21-12 05:29   org.apache.onami.parent-1-incubating/src/
> 0  12-21-12 05:29   org.apache.onami.parent-1-incubating/src/site/
>   531  12-21-12 05:29   org.apache.onami.parent-1-incubating/DISCLAIMER
> 11357  12-21-12 05:29   org.apache.onami.parent-1-incubating/LICENSE
>   208  12-21-12 05:29   org.apache.onami.parent-1-incubating/NOTICE
> 29715  12-21-12 05:29   org.apache.onami.parent-1-incubating/pom.xml
>  4193  12-21-12 05:29   
> org.apache.onami.parent-1-incubating/src/site/site.xml
>   262  12-21-12 05:29   org.apache.onami.parent-1-incubating/DEPENDENCIES
>     ---
> 46266   9 files

This is clearly per spec. LICENSE, NOTICE, etc. are all at the root of
the source tree. Congrats to the packagers for making a ZIP file that
unpacks into a new subdirectory, instead of the all-to-common braindead
practice of unpacking into the current directory.


Marcel, I suppose you expected LICENSE and NOTICE to appear in ./ not
org.apache.onami.parent-1-incubating/, and that's what caused confusion?

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: DOAP

[Branko Čibej]

On 02.01.2013 01:09, Benson Margulies wrote:
> Hi there.
>
> In the process of cleaning up photark, I noticed that very few
> incubating projects have DOAP files.

At the risk of appearing a total idiot (as if I usually don't), I have
to ask: what is a DOAP file and what is it good for?

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[ANNOUNCE] Apache Bloodhound relaxes access control to its source tree

[Branko Čibej]

Following the discussions on members@ and comdev, the Apache Bloodhound
developers have decided[1] to relax the ACL governing access to the
Bloodhound code so that as of now, any ASF committer has commit access.

Of course this does not waive potential contributors' duty to engage
with the Bloodhound community before making changes.

The process will (eventually) be described at

http://issues.apache.org/bloodhound/wiki/BloodhoundContributing

-- Brane

[1] http://goo.gl/bDC0U

-
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.4 (incubating)

[Branko Čibej]

On 17.01.2013 23:47, Ryan Ollos wrote:
> ...
> Please vote:
> [ ] +1 Release this package as Apache Bloodhound 0.4
> [ ] +0 Don't care
> [ ] -1 Do not release this package (please explain)

+1 (binding)


-- 
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com


-
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.4 (incubating)

[Branko Čibej]

On 18.01.2013 11:39, sebb wrote:
> On 17 January 2013 22:47, Ryan Ollos  wrote:
>> Hi everyone,
>>
>> I would like to initiate the vote for releasing Apache Bloodhound 0.4
>> (incubating)
>> in the incubator following the successful vote of the Bloodhound PPMC.
>>
>> The vote PPMC vote thread:
>> http://markmail.org/message/d2yvz2tx5pj57ru4
>>
>> Please find the change log for this proposed release below:
>>
>>  * Replaces ticket edit form with a new 'in-place' edit and workflow control
>>  * Added white-labeling for error messages and basic branding
>>  * Improvements to the quick ticket creation form including ability to
>> specify the select fields and their order
>>  * Various bug fixes
>>
>>  * Not fixed for this release:
>>* No major outstanding issues
>>
>> The release candidate artifacts consist of source release as a tar.gz
>> archive along with the associated MD5 and GPG signature.
>> These can be found at:
>> https://dist.apache.org/repos/dist/dev/incubator/bloodhound/
>>
>> The archive is based on the tag:
>> http://svn.apache.org/viewvc/incubator/bloodhound/tags/0.4-incubating
> The LICENSE file looks good.
>
> However I'm not sure that the NOTICE file is correct.
>
> Are all the entries in NOTICE required?

Bloodhound builds upon Trac and uses Bootstrap and JQuery -- and
includes all of them in the source release, so yes, I believe all the
entries are required.

> If they are required, are they correct, i.e. is the correct
> attribution included?

As far as I can see, it's all correct. Which one(s) do you find incomplete?

(FWIW, neither the NOTICE file nor the used external modules have
changed since the previous release.)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: How to make votes more visible?

[Branko Čibej]

On 23.01.2013 18:42, Gary Martin wrote:
> Regarding the original suggestion, a web based tool would only seem to
> be useful if the problem is associated with IPMC members not noticing
> rather than not feeling that they have time to do proper reviews.

That's a fair point. Still, I've decided to have a go at generating a
web status page anyway. Should have a prototype ready soon.

> Has this been determined yet? Are there any other possible reasons?

I suppose it's not just time, but lack of interest, too. I admit that I
seldom look at releases from podlings I'm not mentoring.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Incubator voting status page

[Branko Čibej]

A while ago I proposed we should have a status page showing current
pending votes.

To this end I've begun writing a simple script that parses the
general@incubator Atom feed from Markmail and creates a static web page
with information gleaned from there (it keeps longer-term data in a
SQLite database).

The script is here:

https://svn.apache.org/repos/asf/incubator/public/trunk/incuvoter

and the current results are here:

http://people.apache.org/~brane/incubator-votes.html

That page (should) get updated every 4 hours. It will also list closed
votes up to 30 days old.

There are currently no links to the actual vote threads. Also I'm having
a bit of trouble with the feed from mod_mbox, as it's quite short-term
and doesn't seem to be at all complete; that's why I switched to using
the current month's worth of data from Markmail.

Eventually I'd like to integrate this into the incubator pages, and add
logic to the scripts so they'd yell at general@incubator if votes are
overdue.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 24.01.2013 06:16, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Jan 24, 2013 at 05:05:42 +0100:
>> There are currently no links to the actual vote threads. Also I'm having
>> a bit of trouble with the feed from mod_mbox, as it's quite short-term
>> and doesn't seem to be at all complete; that's why I switched to using
>> the current month's worth of data from Markmail.
>>
> ~apmail/public-arch/incubator.apache.org/general/

Thanks, Daniel!

I don't really want to parse mbox files, but it just might turn out to
be better than the alternatives -- especially bandwidth-wise. :)

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 24.01.2013 13:25, Gary Martin wrote:
> We all seem to want a bit of feature creep. I would probably include a
> last update time for the page.

Guys, you're committers, the code is in Subversion, go wild :)

> Interestingly, the form that Ryan announced the results means that it
> looks like the Bloodhound vote is still open. I'll guess that markmail
> doesn't take cc's as being on the list or something.

In the meantime I changed the thing to parse the mbox archives directly.
Apparently that vote result is not in the current mbox file, either.
Don't ask me why. But we do seem to have problems with our mail archives.

-- Brane

>
> Cheers,
> Gary
>
> On 24/01/13 11:50, Joachim Dreimann wrote:
>> Good work Brane. Just one feature suggestion: Could you display the
>> relative time (ie '3 days ago') in the table, and the absolute time in
>> tooltips?
>> That would make it much easier to read I reckon.
>>
>> Cheers,
>> Joe
>>
>>
>> On 24 January 2013 04:05, Branko Čibej  wrote:
>>
>>> A while ago I proposed we should have a status page showing current
>>> pending votes.
>>>
>>> To this end I've begun writing a simple script that parses the
>>> general@incubator Atom feed from Markmail and creates a static web page
>>> with information gleaned from there (it keeps longer-term data in a
>>> SQLite database).
>>>
>>> The script is here:
>>>
>>> https://svn.apache.org/repos/asf/incubator/public/trunk/incuvoter
>>>
>>> and the current results are here:
>>>
>>> http://people.apache.org/~brane/incubator-votes.html
>>>
>>> That page (should) get updated every 4 hours. It will also list closed
>>> votes up to 30 days old.
>>>
>>> There are currently no links to the actual vote threads. Also I'm
>>> having
>>> a bit of trouble with the feed from mod_mbox, as it's quite short-term
>>> and doesn't seem to be at all complete; that's why I switched to using
>>> the current month's worth of data from Markmail.
>>>
>>> Eventually I'd like to integrate this into the incubator pages, and add
>>> logic to the scripts so they'd yell at general@incubator if votes are
>>> overdue.
>>>
>>> -- Brane
>>>
>>> -
>>> 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

Re: Incubator voting status page

[Branko Čibej]

On 24.01.2013 17:19, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Jan 24, 2013 at 13:40:29 +0100:
>> On 24.01.2013 13:25, Gary Martin wrote:
>>> Interestingly, the form that Ryan announced the results means that it
>>> looks like the Bloodhound vote is still open. I'll guess that markmail
>>> doesn't take cc's as being on the list or something.
>> In the meantime I changed the thing to parse the mbox archives directly.
>> Apparently that vote result is not in the current mbox file, either.
>> Don't ask me why. But we do seem to have problems with our mail archives.
> The mbox files on minotaur should be up-to-date at all times.  (The ones
> on mail-archives are only updated hourly.)  Was it CCed to general@ ?

It was. And it ended up in the bloodhound-dev archive, but not in the
general archive.

I've noticed before that our archives seem to be incomplete, and indeed
it appears that the mbox files contain only messages To: a list,
everything that actually gets delivered to subscribers by the list server.

-- Brane

P.S.: Incidentally, I noticed that I need more smarts in the subject
parser: it doesn't understand [CANCELLED][VOTE] or [DISCUSS][VOTE]. :)

> grep ^Subject: ~apmail/public-arch/incubator.apache.org/general/201301 | 
> fgrep -i '[vote]' | sed -e 's/^Subject: *[Rr][Ee]: */Subject: /' | sort -u
Subject: Getting IPMC members to vote Re: [VOTE] Release Apache Bloodhound
Subject: [CANCELLED][VOTE] Apache cTAKES 3.0.0-incubating RC4 release
Subject: [DISCUSS][VOTE] Streams Master 0.1-incubating Release
Subject: [RESULT] [VOTE] Release Onami Parent 1 RC2
Subject: [RESULT][VOTE] Apache Oltu (formerly Apache Amber) graduation
Subject: [RESULT][VOTE] Apache Oltu (formerly Apache Amber) graduation 
resolution
Subject: [RESULT][VOTE] Streams Master 0.1-incubating Release
Subject: [RESULT][VOTE] release Apache Onami Parent 2-incubating
Subject: [VOTE] - Apache Clerezza Graduation Resolution
Subject: [VOTE] Apache Kalumet 0.6-incubating release (2nd try)
Subject: [VOTE] Apache cTAKES 3.0.0-incubating RC4 release
Subject: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release
Subject: [VOTE] Release Apache Bloodhound 0.4 (incubating)
Subject: [VOTE] Release Apache Onami-Logging 3.4.0-incubating
Subject: [VOTE] Release Apache Onami-Test 1.4.0-incubating
Subject: [VOTE] Release Onami Parent 1 RC2
Subject: [VOTE] Streams Master 0.1-incubating Release
Subject: [VOTE] release Apache Onami Parent 2-incubating

> grep ^Subject: ~apmail/public-arch/incubator.apache.org/bloodhound-dev/201301 
> | fgrep -i '[vote]' | sed -e 's/^Subject: *[Rr][Ee]: */Subject: /' | sort -u
Subject: Getting IPMC members to vote Re: [VOTE] Release Apache Bloodhound
Subject: Getting IPMC members to vote Re: [VOTE] Release Apache Bloodhound 0.4 
(incubating)
Subject: Installation documentation. Was: [VOTE] Release Apache Bloodhound
Subject: [RESULT] [VOTE] Release Apache Bloodhound 0.4 (incubating)
Subject: [VOTE] Release Apache Bloodhound 0.4 (incubating)
Subject: new KEYS scheme? (Was: Re: [VOTE] Release Apache Bloodhound 0.4
Subject: new KEYS scheme? (Was: Re: [VOTE] Release Apache Bloodhound 0.4 
(incubating))



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 24.01.2013 22:01, Branko Čibej wrote:
> I've noticed before that our archives seem to be incomplete, and
> indeed it appears that the mbox files contain only messages To: a
> list, everything that actually gets delivered to subscribers by the
> list server.

I meant to say, /not/ everything that actually gets delivered ...

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release

[Branko Čibej]

On 21.01.2013 21:08, Benson Margulies wrote:
> On Mon, Jan 21, 2013 at 2:10 PM, Matt Franklin  
> wrote:
>> On Monday, January 21, 2013, Benson Margulies wrote:
>>
>>> Matt, can you reference the policy that category A deps can't be
>>> sitting in svn in binary? Of course, these folks can learn to use ivy,
>>> maven, or maven-ant-tasks to reduce the need for this, but I'd like to
>>> be clear on whether this is required behavior or not. I thought that a
>>> source package could incorporate binaries of at least 'A'
>>> dependencies, but I am happy to be corrected. And svn is yet another
>>> question.
>>
>> I am referring to this discussion  http://s.apache.org/MUZ
> Well, that clear enough, even if it is a typical example of how our
> founders yell at us but we have no mechanism to channel those yells
> into concise, unambiguous, documentation.

Per haps off-topic ... but I fail to see how "source release" is
ambiguous or not concise.

Unless the Java world has a different definition of "source code" than
us stuck-in-the-mud plodders, and it's only considered binary once it's
been JIT-compiled. :)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache cTAKES 3.0.0-incubating RC5 release

[Branko Čibej]

On 25.01.2013 01:50, Ted Dunning wrote:
> On Fri, Jan 25, 2013 at 7:37 AM, Branko Čibej  wrote:
>
>> On 21.01.2013 21:08, Benson Margulies wrote:
>> ...>>
>>>> I am referring to this discussion  http://s.apache.org/MUZ
>>> Well, that clear enough, even if it is a typical example of how our
>>> founders yell at us but we have no mechanism to channel those yells
>>> into concise, unambiguous, documentation.
>> Per haps off-topic ... but I fail to see how "source release" is
>> ambiguous or not concise.
>>
>> Unless the Java world has a different definition of "source code" than
>> us stuck-in-the-mud plodders, and it's only considered binary once it's
>> been JIT-compiled. :)
>>
>
> It isn't necessarily ambiguous when applied to code, but there is a
> different case when applied to models  or parameter settings.
>
> For instance, commons match has polynomial coefficients embedded in code
> that approximate certain functions.  These are the results of computations
> done using other systems and the source code and the data used in those
> other computations are not included in the released code, only the
> parameter values are.
>
> This same sort of thing applies here except that the model in question has
> a much larger set of values and is being packaged in a binary, inspectable
> format.  Would your opinion change if the model were expressed in a textual
> model?  Would it matter that the textual model is too large and obtuse to
> usefully inspect?

In cases like this one, it would seem reasonable for the source code to
refer to those models and computations, which presumably anyone can then
reproduce to their own satisfaction. This is unlike compiled code in
that compilation results are notoriously hard to reproduce exactly,
because they depend on many factors that are usually hard to document,
let alone reproduce. I'd expect a mathematical model, no matter how
large, does not suffer from such ambiguities (and shut up, Gödel).

However, that's beside the point, because ...

> What about a hypothetical case where the model is derived from the
> explosion of a nuclear bomb?  Would the release of the numbers require the
> inclusion of a suitable bomb design so that everybody could replicate the
> derivation?

... the issue is not about the exposing all the knowledge that goes into
writing the code, but to expose the code itself so that it can be
reviewed for, e.g., back-doors and other security issues. Neither of
your examples is relevant.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

I think I've managed to work around the fact that our mbox archives only
contain mails that were addressed To: a list, not Cc: that list.

I changed the vote counting script so that it parses /all/ the incubator
list archives, not just general@, for vote threads addressed to
general@. This solved the case where, e.g., the Bloodhound vote
resolution was not noticed.

Other minor changes:

  * Changed the colour scheme to match Clutch
  * Added an age column to the current votes table
  * Shows the last recorded change (based on mbox file mtimes)
  * Removed the ability to parse Atom feeds

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 25.01.2013 16:12, Marvin Humphrey wrote:
> On Fri, Jan 25, 2013 at 6:27 AM, Branko Čibej  wrote:
>> I think I've managed to work around the fact that our mbox archives only
>> contain mails that were addressed To: a list, not Cc: that list.
> I'll bet that Ryan isn't subscribed to general@incubator and that his message
> wasn't moderated through right away.
>
> It's now in the general@incubator archives as well.
>
> http://mail-archives.apache.org/mod_mbox/incubator-general/201301.mbox/%3CCAPt9QwRMDCcp_JWwAJeL-rH3YnPJDNEjq0tgcQvUHUKrpv-y%2BA%40mail.gmail.com%3E

I did see the message on general@ days ago, when it still was not in the
archives. But even if my interpretation of the fact is wrong, parsing
all the archives isn't that expensive, so I'll leave it in.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 25.01.2013 18:26, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Jan 25, 2013 at 15:27:25 +0100:
>> I changed the vote counting script so that it parses /all/ the incubator
>> list archives, not just general@, for vote threads addressed to
> Do you also parse the d...@helix.incubator.apache.org archives, which are in
> ~apmail/public-arch/helix.apache.org/dev/ ?

No, as I wasn't aware of them. I can add them to the list.

>> general@. This solved the case where, e.g., the Bloodhound vote
>> resolution was not noticed.
>>
>  251 N   Jan 24 Ryan Ollos  (  96) [RESULT] [VOTE] Release Apache 
> Bloodhound
> appears in the general@incubator archives.

It didn't yesterday, even though I saw it in my inbox as coming from the
mailing list. I don't understand what's happening (and don't really want
to :).

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 26.01.2013 00:16, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Jan 25, 2013 at 18:40:18 +0100:
>> On 25.01.2013 18:26, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Fri, Jan 25, 2013 at 15:27:25 +0100:
>>>> I changed the vote counting script so that it parses /all/ the incubator
>>>> list archives, not just general@, for vote threads addressed to
>>> Do you also parse the d...@helix.incubator.apache.org archives, which are in
>>> ~apmail/public-arch/helix.apache.org/dev/ ?
>> No, as I wasn't aware of them. I can add them to the list.
> All new podlings use that scheme.  Helix was just the first one to use
> it, there are already 3 others (and all podlings created from this point
> on, too).

I see. Can you suggest a way to find which archives belong to podlings,
then, without having to parse /all/ the archives and/or manually add
them to the archive list? I can probably find the info in the incubator
status, if there's no easier way to notice what's a podling and what isn't.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 26.01.2013 14:27, Benson Margulies wrote:
> Brane, are you currently using the pickled clutch metadata? If we just
> need to add a field to it we can.

Nope, I'm currently walking the incubator archive tree. The clutch
metadata is in general good enough, since if clutch can generate
target/current.ent, I can certainly get the information I need from
that. The only question is the conversion from
l...@podling.incubator.apache.org (which clutch knows about) to
archive/podling.apache.org/list (which is where the podling mail
archives will be in future) is consistent.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 27.01.2013 16:17, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Jan 26, 2013 at 15:30:04 +0100:
>> On 26.01.2013 14:27, Benson Margulies wrote:
>>> Brane, are you currently using the pickled clutch metadata? If we just
>>> need to add a field to it we can.
>> Nope, I'm currently walking the incubator archive tree. The clutch
>> metadata is in general good enough, since if clutch can generate
>> target/current.ent, I can certainly get the information I need from
>> that. The only question is the conversion from
>> l...@podling.incubator.apache.org (which clutch knows about) to
>> archive/podling.apache.org/list (which is where the podling mail
>> archives will be in future) is consistent.
>>
> Yes, it is, for all *@p.i.a.o lists.

Well, I've found an inconsistency while changing the scripts to parse
the content/podlings.xml and content/projects/.xml.
Onami's dev list is the old-style:

onami-...@incubator.apache.org

but its archive is new-style:

onami.incubator.apache.org/dev

I don't want to special-case the script for this; can we make the
archive consistent with the mailing list address?

I also found two other problems: flex and photark removed the
'id="mail-dev"' attributes from their status XML files, and also
replaced the list address with the web archive address, so there's no
machine-readable way to find their mailing list address. I think it
would be a good idea to require that the .xml files are
machine-readable in the sense that all relevant information about a
podling can be extracted from them without special-casing scripts.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 28.01.2013 08:58, Daniel Shahaf wrote:
> Branko Čibej wrote on Mon, Jan 28, 2013 at 08:22:42 +0100:
>> On 27.01.2013 16:17, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sat, Jan 26, 2013 at 15:30:04 +0100:
>>>> On 26.01.2013 14:27, Benson Margulies wrote:
>>>>> Brane, are you currently using the pickled clutch metadata? If we just
>>>>> need to add a field to it we can.
>>>> Nope, I'm currently walking the incubator archive tree. The clutch
>>>> metadata is in general good enough, since if clutch can generate
>>>> target/current.ent, I can certainly get the information I need from
>>>> that. The only question is the conversion from
>>>> l...@podling.incubator.apache.org (which clutch knows about) to
>>>> archive/podling.apache.org/list (which is where the podling mail
>>>> archives will be in future) is consistent.
>>>>
>>> Yes, it is, for all *@p.i.a.o lists.
>> Well, I've found an inconsistency while changing the scripts to parse
>> the content/podlings.xml and content/projects/.xml.
>> Onami's dev list is the old-style:
>>
>> onami-...@incubator.apache.org
>>
>> but its archive is new-style:
>>
>> onami.incubator.apache.org/dev
>>
>> I don't want to special-case the script for this; can we make the
>> archive consistent with the mailing list address?
>>
> They seem consistent with the other "new-style" podlings:
>
> minotaur,9:~apmail/public-arch% find . -maxdepth 2 -name \*onami\* 
> ./onami.apache.org
> minotaur,9:~apmail/public-arch% grep -h List-Id onami.apache.org/*/* | uniq
> List-Id: 
> List-Id: 
> List-Id: 

Ah, could it be then that content/projects/onami.xml is just wrong and
needs to be updated? It says:

onami-dev@incubator.apache.org



-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 28.01.2013 10:01, Simone Tripodi wrote:
> Hi Branko!
>
> On Mon, Jan 28, 2013 at 9:57 AM, Branko Čibej  wrote:
>> Ah, could it be then that content/projects/onami.xml is just wrong and
>> needs to be updated?
> yes, we published the status page before we got the MLs addresses and
> noticed they are in the new pattern :P could one of the mentor please
> update it?

I can do that. And have done it. Please review:

svn diff -c1439308 http://svn.apache.org/repos/asf/incubator



-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 29.01.2013 09:53, Daniel Shahaf wrote:
> David Crossley wrote on Tue, Jan 29, 2013 at 16:12:34 +1100:
>> You are striking the same type of problems that Clutch has
>> needed to deal with over the years. In general, the state of
>> podling metadata is not reliable. That is something that we
>> need to get podling developers interested with.
>>
> I have a current example.  Flex and Wink haven't updated their
> podlings.xml entries to
> status="graduated"
> , therefore certain infra scripts still consider them podlings rather
> than PMCs.

Nor had PhotArk updated its entry to "retired" until I did that
yesterday to get rid of one of the warnings.

I'm not actually all that worried. The worst that can happen in the case
of the voter script is that some votes don't get recorded, or are
recorded later than expected. The script does emit warnings if it sees
strangeness; I /could/ teach it to send the warnings to the podling's
dev list (if known), cc: general@. But I'd rather not open the spam
floodgates unless people really want me to.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [CANCEL][VOTE] Apache Kalumet 0.6-incubating release (2nd try)

[Branko Čibej]

On 29.01.2013 17:11, Christian Grobmeier wrote:
> Hello,
>
> could you send the usual [CANCELED] mail?
> It would help the script to put it to the right side:
> http://people.apache.org/~brane/incubator-votes.html

Ha, you should read the script before posting. :)

It understands [CANCEL], [CANCELED] (wrong) and [CANCELLED] (correct).
It's just that the page gets updated once every 4 hours, and the
cancellation mail arrived about half an hour after the trigger.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 29.01.2013 17:23, sebb wrote:
> On 29 January 2013 14:17, Branko Čibej  wrote:
>> On 29.01.2013 09:53, Daniel Shahaf wrote:
>>> David Crossley wrote on Tue, Jan 29, 2013 at 16:12:34 +1100:
>>>> You are striking the same type of problems that Clutch has
>>>> needed to deal with over the years. In general, the state of
>>>> podling metadata is not reliable. That is something that we
>>>> need to get podling developers interested with.
>>>>
>>> I have a current example.  Flex and Wink haven't updated their
>>> podlings.xml entries to
>>> status="graduated"
>>> , therefore certain infra scripts still consider them podlings rather
>>> than PMCs.
>> Nor had PhotArk updated its entry to "retired" until I did that
>> yesterday to get rid of one of the warnings.
>>
>> I'm not actually all that worried. The worst that can happen in the case
>> of the voter script is that some votes don't get recorded, or are
>> recorded later than expected. The script does emit warnings if it sees
>> strangeness; I /could/ teach it to send the warnings to the podling's
>> dev list (if known), cc: general@. But I'd rather not open the spam
>> floodgates unless people really want me to.
> Why not append the errors to the end of the report?

Good idea, I'll do that.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [CANCEL][VOTE] Apache Kalumet 0.6-incubating release (2nd try)

[Branko Čibej]

On 29.01.2013 21:18, Christian Grobmeier wrote:
> On Tue, Jan 29, 2013 at 9:11 PM, Branko Čibej  wrote:
>
>> It understands [CANCEL], [CANCELED] (wrong) and [CANCELLED] (correct).
> I thought CANCELED is wrong myself, but then I read:
> http://www.reference.com/motif/language/cancelled-vs-canceled

All I can say is: never trust Americans when it comes to English grammar
-- they're not native speakers. :D

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

There is now an embedded version of the voting status page available for
preview at

http://people.apache.org/~brane/fakeubator/votes.html

By "embedded" I mean, integrated into (a copy of) the Incubator site.
The page is updated every 4 hours.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 10:59, Christian Grobmeier wrote:
> On Thu, Jan 31, 2013 at 8:55 AM, Branko Čibej  wrote:
>> There is now an embedded version of the voting status page available for
>> preview at
>>
>> http://people.apache.org/~brane/fakeubator/votes.html
>>
>> By "embedded" I mean, integrated into (a copy of) the Incubator site.
>> The page is updated every 4 hours.
> It looks very cool.
>
> What if whimsy would generate the html and we would "include" it with
> a small javascript snipped? I can provide such a snippet, if wanted

Personally I'd rather have whatever process is updating the regular
Incubator site create the vote status page in-place. I added a separate
target to the Ant build file specifically for that purpose -- so that
only that page can be updated without affecting the rest of the site,
and therefore this can be done more often than once a day.

That way you don't have to keep track of stylesheet changes, etc.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 15:12, Christian Grobmeier wrote:
> On Thu, Jan 31, 2013 at 2:30 PM, Branko Čibej  wrote:
>> On 31.01.2013 10:59, Christian Grobmeier wrote:
>>> On Thu, Jan 31, 2013 at 8:55 AM, Branko Čibej  wrote:
>>>> There is now an embedded version of the voting status page available for
>>>> preview at
>>>>
>>>> http://people.apache.org/~brane/fakeubator/votes.html
>>>>
>>>> By "embedded" I mean, integrated into (a copy of) the Incubator site.
>>>> The page is updated every 4 hours.
>>> It looks very cool.
>>>
>>> What if whimsy would generate the html and we would "include" it with
>>> a small javascript snipped? I can provide such a snippet, if wanted
>> Personally I'd rather have whatever process is updating the regular
>> Incubator site create the vote status page in-place. I added a separate
>> target to the Ant build file specifically for that purpose -- so that
>> only that page can be updated without affecting the rest of the site,
>> and therefore this can be done more often than once a day.
> So you would commit this page all four hours automatically?

Not at all. Notice that the embedded example is /not/ the real incubator
site but a copy in my homedir on minotaur. The idea is obviously to not
commit either the generated XML template, nor the even-more-generated
HTML file.

>> That way you don't have to keep track of stylesheet changes, etc.
> The same is true for including a HTML snipped. I am speaking of
> including the raw table only and leave the formatting to the main
> incubator page.
> however, if you like to do it otherwise go for it. Every saved minute
> is good for me :-)

Most of the rest of the site is nice and static. It'd be a shame not to
keep it so.

I guess it's best if I ping infra and ask about getting this done (or
probably file an INFRA ticket). Infra are also in the best position to
know if we can have the page regenerated more often, e.g., once an hour.


-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 16:51, Daniel Shahaf wrote:
> Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
>> I guess it's best if I ping infra and ask about getting this done (or
>> probably file an INFRA ticket). Infra are also in the best position to
>> know if we can have the page regenerated more often, e.g., once an hour.
> The first issue I see is that your script assumes it has local access to
> the public-arch tree, so it can only run on minotaur (or on the
> mail-archives.a.o box).

Ah, that's a good enough point for doing the dynamic-include thing.
Initially I thought I'd be downloading the mboxes from mail-archives,
but ... local access is soo much faster and easier.

I'll make it work as Christian suggested then.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Ambari (incubating) 1.2.0 Release Candidate RC0.

[Branko Čibej]

On 01.02.2013 08:56, Mahadev Konar wrote:
> Closing the vote since its past 72 hours.
>
> The vote passes with 4 IPMC +1's. Will do the needful to push the release out.

The first needful is to send a proper [RESOLVED][VOTE] mail :)

-- Brane, quite touchy on the subject after writing the votes parser


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 17:18, Branko Čibej wrote:
> On 31.01.2013 16:51, Daniel Shahaf wrote:
>> Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
>>> I guess it's best if I ping infra and ask about getting this done (or
>>> probably file an INFRA ticket). Infra are also in the best position to
>>> know if we can have the page regenerated more often, e.g., once an hour.
>> The first issue I see is that your script assumes it has local access to
>> the public-arch tree, so it can only run on minotaur (or on the
>> mail-archives.a.o box).
> Ah, that's a good enough point for doing the dynamic-include thing.
> Initially I thought I'd be downloading the mboxes from mail-archives,
> but ... local access is soo much faster and easier.
>
> I'll make it work as Christian suggested then.

And it's done. An embedded status page is created on minotaur and
dynamically embedded into the new vote status page. There are only two
issues:

  * It'll take a while for this to show up, since the incubator site
refreshes once a day (?); in the meantime, the embedded status link
will be dead.
  * The embedded content gets loaded from people.apache.org, not
incubator.apache.org; AIUI that'll cause browsers to portend
disaster and in some cases refuse to load the vote status. This
should be fixed, suggestions welcome.

In the meantime I managed to speed up mbox parsing by several orders of
magnitude, so I now update the status page once every hour.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 14:13, Branko Čibej wrote:
> On 31.01.2013 11:02, sebb wrote:
>> On 31 January 2013 07:55, Branko Čibej  wrote:
>>> There is now an embedded version of the voting status page available for
>>> preview at
>>>
>>> http://people.apache.org/~brane/fakeubator/votes.html
>>>
>>> By "embedded" I mean, integrated into (a copy of) the Incubator site.
>>> The page is updated every 4 hours.
>> Looks good, but I think the "Ignoring crud ... Subscribe" warnings
>> should be fixed.
>>
>> The way those podlings have added the Subscribe links seems perfectly
>> reasonable to me.
> I can easily remove those warnings -- I added them on purpose when I
> changed the page status generator to display warnings.
>
> On the other hand -- nothing ever stopped anyone from enclosing the mail
> address in a link anchor, where scripts can ignore them; or adding
> another column to the table for the links.

I updated the Bloodhound status page to give an example for adding extra
links to the table without confusing parsers. It'll be visible next time
the Incubator site updates. Given that it's not at all hard, I'm leaning
towards leaving those warnings in.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: svn commit: r1441429 - /incubator/public/trunk/content/projects/bloodhound.xml

[Branko Čibej]

Thanks for the reminder.

On 01.02.2013 16:42, sebb wrote:
> Please remember to publish the site after committing updates.
>
>
>
> On 1 February 2013 12:49,   wrote:
>> Author: brane
>> Date: Fri Feb  1 12:49:29 2013
>> New Revision: 1441429
>>
>> URL: http://svn.apache.org/viewvc?rev=1441429&view=rev
>> Log:
>> Replace silly dots with   entities.
>> Add archive links to public lists.
>>


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 31.01.2013 11:02, sebb wrote:
> On 31 January 2013 07:55, Branko Čibej  wrote:
>> There is now an embedded version of the voting status page available for
>> preview at
>>
>> http://people.apache.org/~brane/fakeubator/votes.html
>>
>> By "embedded" I mean, integrated into (a copy of) the Incubator site.
>> The page is updated every 4 hours.
> Looks good, but I think the "Ignoring crud ... Subscribe" warnings
> should be fixed.
>
> The way those podlings have added the Subscribe links seems perfectly
> reasonable to me.

I can easily remove those warnings -- I added them on purpose when I
changed the page status generator to display warnings.

On the other hand -- nothing ever stopped anyone from enclosing the mail
address in a link anchor, where scripts can ignore them; or adding
another column to the table for the links.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 01.02.2013 17:01, sebb wrote:
> On 1 February 2013 10:29, Branko Čibej  wrote:
>> On 31.01.2013 17:18, Branko Čibej wrote:
>>> On 31.01.2013 16:51, Daniel Shahaf wrote:
>>>> Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
>>>>> I guess it's best if I ping infra and ask about getting this done (or
>>>>> probably file an INFRA ticket). Infra are also in the best position to
>>>>> know if we can have the page regenerated more often, e.g., once an hour.
>>>> The first issue I see is that your script assumes it has local access to
>>>> the public-arch tree, so it can only run on minotaur (or on the
>>>> mail-archives.a.o box).
>>> Ah, that's a good enough point for doing the dynamic-include thing.
>>> Initially I thought I'd be downloading the mboxes from mail-archives,
>>> but ... local access is soo much faster and easier.
>>>
>>> I'll make it work as Christian suggested then.
>> And it's done. An embedded status page is created on minotaur and
>> dynamically embedded into the new vote status page. There are only two
>> issues:
>>
>>   * It'll take a while for this to show up, since the incubator site
>> refreshes once a day (?); in the meantime, the embedded status link
>> will be dead.
> It updates immediately, provided that you publish any changes.
>
>>   * The embedded content gets loaded from people.apache.org, not
>> incubator.apache.org; AIUI that'll cause browsers to portend
>> disaster and in some cases refuse to load the vote status. This
>> should be fixed, suggestions welcome.
> The use of target=_blank causes a new window to created each time the
> link is clicked; that seems wrong.

Yes, I just noticed that; copy-paste bug from the standalone page link,
will fix.

> Also, it does not work in Firefox. Or Chrome. Or Opera. Or IE.

That's caused by the the access control constraints, as I point out in
the text you quoted. I tried circumventing that in .htaccess, but the
incubator site config doesn't load mod_headers, so that won't help.

We'll either have to change the httpd config for that site -- load
mod_headers, or set up a proxy to the real status page --or come up with
a way to copy the updated status page directly from minotaur to the live
site.

I think updating the httpd config is the more realistic option, since it
doesn't presume a ssh tunnel between minotaur and the site server.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 01.02.2013 20:48, sebb wrote:
> On 1 February 2013 16:29, Branko Čibej  wrote:
>> On 01.02.2013 17:01, sebb wrote:
>>> On 1 February 2013 10:29, Branko Čibej  wrote:
>>>> On 31.01.2013 17:18, Branko Čibej wrote:
>>>>> On 31.01.2013 16:51, Daniel Shahaf wrote:
>>>>>> Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
>>>>>>> I guess it's best if I ping infra and ask about getting this done (or
>>>>>>> probably file an INFRA ticket). Infra are also in the best position to
>>>>>>> know if we can have the page regenerated more often, e.g., once an hour.
>>>>>> The first issue I see is that your script assumes it has local access to
>>>>>> the public-arch tree, so it can only run on minotaur (or on the
>>>>>> mail-archives.a.o box).
>>>>> Ah, that's a good enough point for doing the dynamic-include thing.
>>>>> Initially I thought I'd be downloading the mboxes from mail-archives,
>>>>> but ... local access is soo much faster and easier.
>>>>>
>>>>> I'll make it work as Christian suggested then.
>>>> And it's done. An embedded status page is created on minotaur and
>>>> dynamically embedded into the new vote status page. There are only two
>>>> issues:
>>>>
>>>>   * It'll take a while for this to show up, since the incubator site
>>>> refreshes once a day (?); in the meantime, the embedded status link
>>>> will be dead.
>>> It updates immediately, provided that you publish any changes.
>>>
>>>>   * The embedded content gets loaded from people.apache.org, not
>>>> incubator.apache.org; AIUI that'll cause browsers to portend
>>>> disaster and in some cases refuse to load the vote status. This
>>>> should be fixed, suggestions welcome.
>>> The use of target=_blank causes a new window to created each time the
>>> link is clicked; that seems wrong.
>> Yes, I just noticed that; copy-paste bug from the standalone page link,
>> will fix.
>>
>>> Also, it does not work in Firefox. Or Chrome. Or Opera. Or IE.
>> That's caused by the the access control constraints, as I point out in
>> the text you quoted. I tried circumventing that in .htaccess, but the
>> incubator site config doesn't load mod_headers, so that won't help.
> However, in that case surely it ought to display an error message?
>
> There is some code that looks as though it tries to report the error:
>
> if (fragment_loader.status != 200)
> html = "Content is not available";
> else {
> container = document.getElementById("voter").parentNode;
> container.innerHTML = fragment_loader.responseText;
> }
>
> That looks wrong - why is the error written to a different variable?

Meh, another bug. Thanks for catching it and fixing it.

(Apparently I'm not at my best these days ... only this morning I
started wondering why that error message wasn't showing up. Sigh.)

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 01.02.2013 18:05, Daniel Shahaf wrote:
> Branko Čibej wrote on Fri, Feb 01, 2013 at 17:29:45 +0100:
>> I think updating the httpd config is the more realistic option, since it
>> doesn't presume a ssh tunnel between minotaur and the site server.
> The only supported way to get content to the web servers is to commit it
> to svn and have svnpubsub pull it to them.
>
> So, just have a cronjob on minotaur commit the changes.  You can get
> a username+password for that by asking.

Surely it doesn't make sense to commit this transient table. If I wanted
that, I'd be generating (and committing) all of content/votes.xml
instead. But I really think the voting status page should be updated
more often than once a day, hence the current architecture that doesn't
depend on incubator site updated.

I'm all for moving this from minotaur to whimsy, and do suggest we
change the incubator.a.o server config so that the votes table can be
fetched from there.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 02.02.2013 16:29, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Feb 02, 2013 at 11:01:42 +0100:
>> I'm all for moving this from minotaur to whimsy, and do suggest we
> whimsy doesn't have the public-arch tree locally.

Thanks for reminding me again ... silly me.

>> change the incubator.a.o server config so that the votes table can be
>> fetched from there.
>>
> Not specific enough to comment on.  (Change how?)

Either:

LoadModule headers_module /.../mod_headers.so

I've already put the following in the .htaccess file:


# Allow remote content from people.apache.org in order to fetch vote status
Header set Access-Control-Allow-Origin "http://people.apache.org";


Or:

ProxyPass /remote/embedded-votes.html 
http://people.apache.org/~brane/incubator/embedded-votes.html

and I'll change the URL of the generated table in votes.xml.

A simple redirect will of course not work, as it triggers the same
access restriction. The proxy solution doesn't open the door as wide,
but I expect it's slightly more expensive than adding a header to the
response. Either way should work.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Incubator voting status page

[Branko Čibej]

On 02.02.2013 19:05, Daniel Shahaf wrote:
> Branko Čibej wrote on Sat, Feb 02, 2013 at 18:06:11 +0100:
>> On 02.02.2013 16:29, Daniel Shahaf wrote:
>>> Branko Čibej wrote on Sat, Feb 02, 2013 at 11:01:42 +0100:
>>>> I'm all for moving this from minotaur to whimsy, and do suggest we
>>> whimsy doesn't have the public-arch tree locally.
>> Thanks for reminding me again ... silly me.
>>
>>>> change the incubator.a.o server config so that the votes table can be
>>>> fetched from there.
>>>>
>>> Not specific enough to comment on.  (Change how?)
>> Either:
>>
>> LoadModule headers_module /.../mod_headers.so
>>
>> I've already put the following in the .htaccess file:
>>
>> 
>> # Allow remote content from people.apache.org in order to fetch vote 
>> status
>> Header set Access-Control-Allow-Origin "http://people.apache.org";
>> 
>>
>> Or:
>>
>> ProxyPass /remote/embedded-votes.html 
>> http://people.apache.org/~brane/incubator/embedded-votes.html
>>
>> and I'll change the URL of the generated table in votes.xml.
>>
>> A simple redirect will of course not work, as it triggers the same
>> access restriction. The proxy solution doesn't open the door as wide,
>> but I expect it's slightly more expensive than adding a header to the
>> response. Either way should work.
> Thanks for the config snippets, but my opinion is unchanged: if this is
> to be available via http://incubator.apache.org/, it should get
> committed somewhere.  (This will be consistent with how every docroot on
> the www box works)  For your use-case it would be ok have a cron'd
> buildbot job that commits directly to the production tree --- that's how
> the twitter feed on www.apache.org gets updated.
>
> The alternative would be to leave the code on people.a.o or add some
> "rsync minotaur:public-arch/ ./" calls and move it to whimsy.
>
> Or feel free to ask site-dev@ or infra@ for other opinions.

I solved it by removing the embedded page and leaving only the
standalone one. I've spent too much time on this as it is. If anyone
wants to pick it up, they can

svn merge  -c-1441791 ^/incubator/public/trunk

and take it from there.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 23.01.2013 14:48, Simone Tripodi wrote:
> SVN source tag
> https://svn.apache.org/repos/asf/incubator/onami/tags/org.apache.onami.logging.parent-3.4.0-incubating/
>
> Staging repo:
> https://repository.apache.org/content/repositories/orgapacheonami-150/

Since when do source packages not have to be on dist.apache.org?

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 02.02.2013 21:36, Branko Čibej wrote:
> On 23.01.2013 14:48, Simone Tripodi wrote:
>> SVN source tag
>> https://svn.apache.org/repos/asf/incubator/onami/tags/org.apache.onami.logging.parent-3.4.0-incubating/
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/orgapacheonami-150/
> Since when do source packages not have to be on dist.apache.org?

Just to be clear, in the case of Onami Logging, reviewers are  asked to
find the right package amongst 8 different source packages in 8
different directories.

Initially I thought that the logging-parent.zip would be enough to
verify the release; but the notice files in the various module-specific
source jar files aren't identical to the one in the repository. At that
point I stopped looking.

In other words, the reason you're not getting votes from the IPMC is
that it's well-nigh impossible for an outsider to verify the release
artefacts.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Onami-Test 1.4.0-incubating

[Branko Čibej]

On 23.01.2013 14:51, Simone Tripodi wrote:
> [ ] +1, let's get it rmblee!!!
> [ ] +/-0, fine, but consider to fix few issues before...
> [ ] -1, nope, because... (and please explain why)
>
> So IPMCs please cast your votes!

+1

I still wish the source package was easier to find.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 03.02.2013 21:26, Christian Grobmeier wrote:
>> Just to be clear, in the case of Onami Logging, reviewers are  asked to
>> find the right package amongst 8 different source packages in 8
>> different directories.
> What do you mean with "right"? They all are "right", because they
> contain different sources and we want to release them all.

In the end I realized that only the -parent.zip contained all the
sources and was comparable to the contents of the release tag in SVN.
This should, IMO, be better communicated in the vote announcement.

The fact that the NOTICE files in the other source .jars are not
identical to the one in the source .zip, or in the release tag, is
(putting it mildly) confusing.

> Impossible? I have to disagree. One can:
>
> wget -r -l 1 -np -nH -nd -nv -e robots=off --wait 10
> --no-check-certificate
> https://repository.apache.org/content/repositories/orgapacheonami-150/
>
> and easily gets all files.

Yes. I'm not interested in checking a lot of binaries. They're not part
of the release, right?

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Onami-Logging 3.4.0-incubating

[Branko Čibej]

On 04.02.2013 01:05, Mohammad Nour El-Din wrote:
> Hi Branko...
>
>
> On Sun, Feb 3, 2013 at 10:31 PM, Branko Čibej  wrote:
>
>> On 03.02.2013 21:26, Christian Grobmeier wrote:
>>>> Just to be clear, in the case of Onami Logging, reviewers are  asked to
>>>> find the right package amongst 8 different source packages in 8
>>>> different directories.
>>> What do you mean with "right"? They all are "right", because they
>>> contain different sources and we want to release them all.
>> In the end I realized that only the -parent.zip contained all the
>> sources and was comparable to the contents of the release tag in SVN.
>> This should, IMO, be better communicated in the vote announcement.
>>
> I agree this might be a helpful detail but not a mandatory or necessary one
> as it can be deduced from the structure of the project

Only if you happen to be familiar with Maven.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Bloodhound from Incubator

[Branko Čibej]

> [X] +1 Graduate Apache Bloodhound podling from Apache Incubator

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Bloodhound from Incubator

[Branko Čibej]

On 11.03.2013 05:04, Kalle Korhonen wrote:
> Was the potential trademark conflict discussed somewhere? See
> http://mail-archives.apache.org/mod_mbox/incubator-general/201212.mbox/%3c50ca29ad.6000...@apache.org%3E-
> if so, just linking to the discussion is fine.

It was discussed on trademarks@; the thread starts with
201302.mbox/<51259463.4030...@wandisco.com>

That thread overlaps another in bloodhound-private@, which starts with
201302.mbox/<5125124d.8060...@wandisco.com>

Both messages are from Gary. Note that I'm not going to post links to
the private archives, I'm sure these breadcrumbs and
mail-search.apache.org will help you find the discussions.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT][VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Branko Čibej]

Just tagging the [RESULT] onto the subject so that the vote status gets
updated.

On 24.02.2013 04:36, Devaraj Das wrote:
> Hi folks,
> With 10 binding +1 votes, this vote has passed.  Thanks to everyone who
> voted.
> Devaraj.
>  +1 (binding)
>
> On Feb 15, 2013, at 11:22 AM, Devaraj Das wrote:
>
>> Hi Folks,
>>
>> Thanks for participating in the discussion. I'd like to call a VOTE
>> for acceptance of Apache Knox Hadoop Gateway Project into the
>> Incubator. The vote will close on Feb 22 at 6:00 p.m.
>>
>> [ ]  +1 Accept Apache Knox Hadoop Gateway Project into the Incubator
>> [ ]  +0 Don't care.
>> [ ]  -1 Don't accept Apache Knox Hadoop Gateway Project into the
>> Incubator because...
>>
>> Full proposal is pasted at the bottom of this email, and the
>> corresponding wiki is http://wiki.apache.org/incubator/knox. Only
>> VOTEs from Incubator PMC members are binding.
>>
>> Here's my +1 (binding).
>>
>> Thanks,
>> Devaraj.
>>
>> -
>>
>> Knox Gateway Proposal
>>
>> Abstract
>>
>> Knox Gateway is a system that provides a single point of secure access
>> for Apache Hadoop clusters.
>>
>> Proposal
>>
>> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
>> single point of authentication and access for Apache Hadoop services
>> in a cluster. The goal is to simplify Hadoop security for both users
>> (i.e. who access the cluster data and execute jobs) and operators
>> (i.e. who control access and manage the cluster). The Gateway runs as
>> a server (or cluster of servers) that serve one or more Hadoop
>> clusters.
>>
>> Provide perimeter security to make Hadoop security setup easier
>> Support authentication and token verification security scenarios
>> Deliver users a single cluster end-point that aggregates capabilities
>> for data and jobs
>> Enable integration with enterprise and cloud identity management
> environments
>> Background
>>
>> An Apache Hadoop cluster is presented to consumers as a loose
>> collection of independent services. This makes it difficult for users
>> to interact with Hadoop since each service maintains it’s own method
>> of access and security. As well, for operators, configuration and
>> administration of a secure Hadoop cluster is a complex and many Hadoop
>> clusters are insecure as a result.
>>
>> The goal of the project is to provide coverage for all existing Hadoop
>> ecosystem projects. In addition, the project will be extensible to
>> allow for new and/or proprietary Hadoop components without requiring
>> changes to the gateway source code. The gateway is expected to run in
>> a DMZ environment where it will provide controlled access to these
>> Hadoop services. In this way Hadoop clusters can be protected by a
>> firewall and only limited access provided through the firewall for the
>> gateway. The authentication components of the gateway will be modular
>> and extensible such that it can be integrated with existing security
>> infrastructure.
>>
>> Rationale
>>
>> Organizations that are struggling with Hadoop cluster security result
>> in a) running Hadoop without security or b) slowing adoption of
>> Hadoop. The Gateway aims to provide perimeter security that integrates
>> more easily into existing organizations’ security infrastructure.
>> Doing so will simplify security for these organizations and benefit
>> all Hadoop stakeholders (i.e. users and operators). Additionally,
>> making a dedicated perimeter security project part of the Apache
>> Hadoop ecosystem will prevent fragmentation in this area and further
>> increase the value of Hadoop as a data platform.
>>
>> Current Status
>>
>> Prototype available, developed by the list of initial committers.
>>
>> Meritocracy
>>
>> We desire to build a diverse developer community around Gateway
>> following the Apache Way. We want to make the project open source and
>> will encourage contributors from multiple organizations following the
>> Apache meritocracy model.
>>
>> Community
>>
>> We hope to extend the user and developer base in the future and build
>> a solid open source community around Gateway. Apache Hadoop has a
>> large ecosystem of open source projects, each with a strong community
>> of contributors. All project communities in this ecosystem have an
>> opportunity to participate in the advancement of the Gateway project
>> because ultimately, Gateway will enable the security capabilities of
>> their project to be more enterprise friendly.
>>
>> Core Developers
>>
>> Gateway is currently being developed by several engineers from
>> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
>> and Sumit Mohanty. All the engineers have deep expertise in
>> middleware, security & identity systems and are quite familiar with
>> the Hadoop ecosystem.
>>
>> Alignment
>>
>> The ASF is a natural host for Gateway given that it is already the
>> home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data
>> software projects. Gateway is designed to solve the security
>> cha

[RESULT][VOTE] Accept Tez into Incubator

[Branko Čibej]

On 25.02.2013 05:44, Arun C Murthy wrote:
> Thanks to all who voted. Obviously, I'm +1 (binding) on the proposal.
>
> With 14 +1s (10 binding) the vote passes.
>
> I'll start the work to get the podling started.
>
> thanks,
> Arun
>
> On Feb 19, 2013, at 8:26 PM, Arun C Murthy wrote:
>
>> Hi Folks,
>>
>> Thanks for participating in the discussion. I'd like to call a VOTE for 
>> acceptance of Apache Tez into the Incubator. I'll let the vote run till into 
>> this weekend (Sun 2/24 6pm PST).
>>
>> [ ]  +1 Accept Apache Tez into the Incubator
>> [ ]  +0 Don't care.
>> [ ]  -1 Don't accept Apache Tez into the Incubator because...
>>
>> Full proposal is pasted at the bottom of this email, and the corresponding 
>> wiki is http://wiki.apache.org/incubator/TezProposal. 
>>
>> Only VOTEs from Incubator PMC members are binding, but all are welcome to 
>> express their thoughts.
>>
>> Here's my +1 (binding).
>>
>> thanks,
>> Arun
>>
>> PS: From the initial discussion, the only changes are that I've added one 
>> new mentor and 2 new committers. All the new additions come from the 
>> non-major employer while we continue to strive to further diversify during 
>> the incubation. Thanks.
>>
>> 
>>
>> = Tez =
>>
>> == Abstract ==
>> Tez is an effort to develop a generic application framework which can be used
>> to process arbitrarily complex data-processing tasks and also a re-usable set
>> of data-processing primitives which can be used by other projects.
>>
>> == Proposal ==
>> Tez is a proposal to develop a generic application which can be used to
>> process complex data-processing task DAGs and runs natively on Apache Hadoop 
>> YARN. YARN is a generic resource-management system on which currently 
>> applications like MapReduce already exist. MapReduce is a specific, and
>> constrained, DAG - which is not optimal for several frameworks like Apache 
>> Hive
>> and Apache Pig. Furthermore, we propose to develop a re-usable set of
>> libraries of data-processing primitives such as sorting, merging,
>> data-shuffling, intermediate data management etc. which are necessary for 
>> Tez 
>> which we envision can be used directly by other projects. 
>>
>> == Background ==
>> Apache Hadoop MapReduce has emerged as the assembly-language on which other
>> frameworks like Apache Pig and Apache Hive have been built. However, it has
>> been well accepted that MapReduce produces very constrained task DAGs for 
>> each
>> job which results in Apache Pig and Apache Hive requiring multiple MapReduce
>> jobs for several queries. By providing a more expressive DAG of tasks for a
>> job, Tez attempts to provide significantly enhanced data-processing
>> capabilities for projects like Apache Pig, Apache Hive, Cascading etc.
>>
>> == Rationale ==
>> There is an important gap that Tez fulfills in the Apache Hadoop ecosystem of
>> allowing for more expressive task DAGs for data-processing applications such
>> as Apache Pig, Apache Hive, Cascading etc.
>>
>> With emergence of Apache Hadoop YARN, there is a strong need for a
>> common DAG application which can then be shared by Apache Pig, Apache Hive,
>> Cascading etc.
>>
>> == Initial Goals ==
>> The initial goals for this project are to specify the detailed requirements
>> and architecture, and then develop the initial implementation including the
>> DAG ApplicationMaster to run natively inside Apache Hadoop YARN. 
>>
>> == Current Status ==
>> Significant work has been completed to identify the initial requirements and
>> define the overall system architecture. There is a patch available in the
>> internal Hortonworks git repository which can act as the initial seed. 
>>
>> === Meritocracy ===
>> We plan to invest in supporting a meritocracy. We will discuss the 
>> requirements 
>> in an open forum. Several companies have already expressed interest in this 
>> project, and we intend to invite additional developers to participate. 
>> We will encourage and monitor community participation so that privileges can 
>> be 
>> extended to those that contribute. 
>>
>> === Community ===
>> The need for a generic DAG application for data processing in the open 
>> source is 
>> tremendous, so there is a potential for a very large community. We believe
>> that Tez's extensible architecture will further encourage community 
>> participation. 
>> Also, related Apache projects (eg, Pig, Hive) have very large and active 
>> communities, and we expect that over time Tez will also attract a large 
>> community.
>>
>> === Core Developers ===
>> The developers on the initial committers list include people very experienced
>> in the Apache Hadoop ecosystem:
>>
>>  * Alan Gates 
>>  * Arun C Murthy 
>>  * Ashutosh Chauhan 
>>  * Bikas Saha 
>>  * Chris Douglas 
>>  * Daryn Sharp 
>>  * Devaraj Das 
>>  * Gopal Vijayaraghavan 
>>  * Gunther Hagleitner 
>>  * Hitesh Shah 
>>  * Jason Lowe 
>>  * Jean Xu 
>>  * Jitendra Pandey 
>>  * Julien Le Dem 
>>  * Kevin Wilfong 
>>  * Mike Liddell 
>>  * Namit Jain

[RESULT][VOTE] Accept Provisionr into the Apache Incubator

[Branko Čibej]

On 07.03.2013 08:54, Andrei Savu wrote:
> Thanks to all who voted! With 18 +1s (10 binding) the vote passes.
>
> I'll start the work to get the podling started.
>
> Thanks,
> Andrei
>
> On Mon, Mar 4, 2013 at 9:31 PM, Henry Saputra wrote:
>
>> +1 non-binding
>>
>> Good luck
>>
>>
>> On Sat, Mar 2, 2013 at 3:35 PM, Andrei Savu  wrote:
>>
>>> Hi Guys,
>>>
>>> I'd like to call a VOTE for acceptance of Provisionr into the Apache
>>> Incubator.
>>>
>>> The vote will close on March 8.
>>>
>>> [] +1 Accept Provisionr into the Apache incubator
>>> [] +0 Don't care.
>>> [] -1 Don't accept Provisionr into the incubator because...
>>>
>>> Full proposal is pasted at the bottom on this email, and the
>> corresponding
>>> wiki is http://wiki.apache.org/incubator/ProvisionrProposal
>>>
>>> Only VOTEs from Incubator PMC members are binding, but all are welcome to
>>> express their thoughts.
>>>
>>> Thanks,
>>> Andrei Savu
>>>
>>> --
>>> Provisionr Proposal
>>>
>>> == Abstract ==
>>>
>>> Provisionr is an effort to develop a service that can be used to create
>> and
>>> manage pools of virtual machines on multiple clouds. Our focus is on
>>> semi-automated workflows and cloud portability.
>>>
>>> == Proposal ==
>>>
>>> Provisionr solves the problem of cloud portability by hiding completely
>> the
>>> APIs and only focusing on building a cluster that matches the same set of
>>> assumptions on all clouds, assumptions like: running a specific operating
>>> system (e.g. Ubuntu 12.04 LTS), having the same set of pre-installed
>>> packages and binaries, sane dns settings (forward & reverse ip
>> resolution -
>>> as needed for Hadoop), ntp settings, networking settings, firewall, ssh
>>> admin access, vpn access etc.
>>>
>>> As a secondary goal Provisionr should also provide primitives for
>> building
>>> automatic or semi-automatic workflows for configuring services, workflows
>>> that assume that all the machines share a common set of characteristics
>> as
>>> described above.
>>>
>>> == Background ==
>>>
>>> Creating clusters on cloud infrastructure is non-trivial because careful
>>> orchestration is required. To make it easy to deploy services we need to
>>> start from a foundation that matches a common set of assumptions on
>>> multiple providers.
>>>
>>> == Rationale ==
>>>
>>> This project started as a re-write of the core of Apache Whirr but has a
>>> different target being more focused on semi-automated workflows and cloud
>>> portability.
>>>
>>> == Initial Goals ==
>>>
>>>  * Build a community
>>>  * Provide an excellent user experience for semi-automatic workflows
>> (e.g.
>>> using Rundeck)
>>>  * Implement a REST service and a Web Console
>>>  * Add support for more providers
>>>
>>> == Current Status ==
>>>
>>> Provisionr had four releases on [[
>>> https://github.com/axemblr/axemblr-provisionr/wiki|GitHub]] and it's
>> used
>>> to deploy Hadoop clusters on-demand at Axemblr and infrastructure for
>>> testing / QA.
>>>
>>> === Meritocracy ===
>>>
>>> We plan to invest in supporting a meritocracy. We will discuss the
>>> requirements in an open forum. Several companies have already expressed
>>> interest in this project, and we intend to invite additional developers
>> to
>>> participate. We will encourage and monitor community participation so
>> that
>>> privileges can be extended to those that contribute.
>>>
>>> === Community ===
>>>
>>> The community interested in cloud service infrastructure is currently
>>> spread across many smaller projects, and one of the main goals of this
>>> project is to build a vibrant community to share best practices and build
>>> common infrastructure.
>>>
>>> === Core developers ===
>>>
>>> Core developers are very experienced in the Apache ecosystem. To achieve
>>> more diversity of developers, we will be eager to recruit developers from
>>> diverse companies.
>>>
>>>  * Andrei Savu - asavu at apache dot org  (Apache Whirr PMC)
>>>  * Ioan Eugen Stan - ieugen at apache dot org (Apache James PMC)
>>>  * Alex Ciminian -  alex.ciminian at gmail dot org
>>>
>>> === Alignment ===
>>>
>>> Provisionr complements Apache Whirr and later on it should provide a
>> robust
>>> foundation for more advanced functionalities.
>>>
>>> == Known Risks ==
>>>
>>> === Orphaned products ===
>>>
>>> The contributors have significant open source experience and the project
>> is
>>> being used as part of a commercial product, so the risk of being orphaned
>>> is relatively low. We plan to mitigate this risk by recruiting additional
>>> committers.
>>>
>>> === Inexperience with Open Source ===
>>>
>>> Most of the initial committers have experience working on open source
>>> projects. Andrei Savu and Ioan Eugen Stan have experience as committers
>> and
>>> PMC members on other Apache projects.
>>>
>>> === Homogenous Developers ===
>>>
>>> We are committed to recruiting additional committers from other companies
>>> based on their contributions to the project.
>>>
>>> === Reliance on Salaried Develope

Re: [VOTE] Apache Onami to become an ASF TLD

[Branko Čibej]

On 18.03.2013 11:25, Bertrand Delacretaz wrote:
> Hi,
>
> On Mon, Mar 18, 2013 at 8:01 AM, Christian Grobmeier
>  wrote:
>> ...in the previous discussions were no objections against the graduation
>> of Apache Onami...
> Was there a community vote indicating a desire to graduate?

This is the community vote. It's a bit confusing that it's also cc:'d to
general@.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Onami to become an ASF TLD

[Branko Čibej]

On 18.03.2013 11:35, Mohammad Nour El-Din wrote:
> Hi
>
>Last time I checked the rules it state that, for such votes, the IPMC
> should be *notified* through general@

This VOTE is not a requirement but is recommended. It is unlikely
that IPMC members will vote to approve graduation unless the Mentors
and community positively express their readiness for graduation. It
is wise to copy the incubator general list when the vote is proposed.


I see no requirement to notify. And I still maintain it's confusing, as
evidenced by this very case.

It would make more sense if general@ were notified after the fact of the
vote result, e.g., as an addendum to the graduation vote proposal.
There's absolutely no call for the IPMC to poke our fingers into what
are obviously optional, internal podling procedures. That's almost as
bad as doing code reviews for them.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] - Java OffHeap Memory Pool

[Branko Čibej]

Is code for this available for review anywhere?

-- Brane

On 16.04.2013 19:46, serkan özal wrote:
> Project Name: Jillegal
>
>
> 1. Abstract:
> GC is one of the time taken operations in Java. GC run anytime, marks, swaps 
> and compacts objects at memory. If there are so many live objects, managing 
> them by GC leads to overhead. If objects can be allocated outside of GC, 
> there will be no overhead for the application. The session will go through 
> the new method of creating and using object off-heap with no additional 
> serialization/deserialization or any other overheads. 
>
>
> 2. Proposal:
> For off-heap memory, I propose a solution that objects are allocated and 
> initialized at off-heap instead of heap. Not only object attributes are 
> allocated at off-heap, but also object header and metadata are allocated at 
> off-heap. So while a reference to this object at off-heap is being 
> interpreted, JVM knows which class this object references to. You can get 
> your off-heap object from an object pool instead of with "new" operator. This 
> object pool allocates a fixed size memory region from off-heap and create 
> empty objects with given class on there. These empty objects can be created 
> as lazy or eager. Another advantage off this technique is that objects in 
> pool are layout in memory as sequential. While accessing an object, its 
> neighbour objects are also fetched to CPU cache, so CPU cache hit rate for 
> sequential object accesses are increased. On the other hand, freeing unused 
> objects is responsibility of developer by calling "free" method of object 
> pool which means there is no dead object detection mechanism like GC. 
> Therefore, getting all objects from off-heap for whole application is 
> dangerous and not recommended. Because, this will cause memory leaks. In 
> addition, this technique can be combined with "Java Instrumentation API". 
> With "@FromOffHeap" annotation, developer can sign classes these must be 
> allocated from off-heap instead of heap. With "Java Instrumentation API", all 
> "new" operators for signed classes with "@FromOffHeap" annotation can ben 
> transformed to code that allocates objects of signed class from off-heap via 
> object pool. So developer doesn't change all "new" keywords for getting from 
> object pool in code. Instread of this, just sign class with "@FromOffHeap" 
> annotation and all "new" keywords transformed for getting from object pool at 
> class load time. This technique was used at a real time CDR processing system 
> for Turk Telekom. There were billions of objects were used. Managing these 
> objects by GC caused to performance overhead. For some most used classes, we 
> allocated these objects from off-heap instead of "new" keyword. After some 
> processings on them (takes 4-5 hours), we release these allocated memory 
> regions to operating system by freeing them. Allocating objects from off-heap 
> pool helps us to gain significant execution time performance.
>
>
> 3. Rationale:
> In general, off-heap pool implementations are implemented by 
> serialization/deserialization to allocated off-heap memory region via 
> "ByteBuffer" class. But this technique leads to extra execution overhead. 
> Because while reading from an object, the target object must be created by 
> deserializing all primitive fields eagerly or only required fields on demand 
> and while writing to an object, the attribute has been set by application, 
> must be deserialized to allocated off-heap memory region. In addition, 
> objects itself is created at heap, so GC knows and tracks it. With my 
> solution, all of these overheads are overcomed.
>
>
> 4. Initial Goals:
>  * Allocating objects from off-heap and using them as normal on-heap 
> Java object. * Allocating arrays for object types from off-heap and 
> using them as normal on-heap Java object arrays. * Allocating arrays 
> for primitive types from off-heap and using them as normal on-heap Java 
> primitive type arrays. * Allocating strings from off-heap and using 
> them as normal on-heap strings. * Implementing auto expandable 
> off-heap pool that expands when its delegated off-heap pool implementation is 
> full. * All features must be supported for 32 bit and 64 bit JVM. 
> * All features must be supported for Sun HotSpot JVM, Oracle JRockit, IBM 
> J9.
>
> 5. Currently Implemented Features:
>
>  * Allocating objects from off-heap and using them as normal on-heap 
> Java object * Allocating arrays for object types from off-heap and 
> using them as normal on-heap Java object array * Allocating arrays 
> for primitive types from off-heap and using them as normal on-heap Java 
> primitive type arrays * Implementing auto expandable off-heap pool 
> that expands when its delegated off-heap pool implementation is full. 
> * All features are supported for 32 bit and 64 bit JVM. * All 
> features 

Please remember to post [CANCEL] notes for cancelled votes

[Branko Čibej]

The voting status script relies on them to update its tables. Currently
there are a number of votes flagged as out of date:

http://people.apache.org/~brane/incubator/votes.html

however, many (if not most) of them were actually cancelled, in some
cases replaced by another (successful) voting thread.

I originally wrote that script because it was often quite hard to figure
from the mail archives which votes were current. If vote proposers don't
make the effort to manage the voting threads, the script ends up being
useless.

Thanks,

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL][VOTE] Subversion

[Branko Čibej]

Leo Simons wrote:
> I have no idea what might be going on in your head, but from where I
> sit, it seems like you might be overreacting just a _bit_ to a
> tongue-in-cheek e-mail post script. Have some green tea.
>   

There were also some suggestions about us making a release for the sake
of making a release, never mind that it would be broken and useless. But
Greg already ranted about that, and he rants a lot better than I do when
he puts his mind to it. :)

All in all, I think we know how to make releases, and moreover we know
hot to *not* make releases. Right, Leo? :)

-- Brane

-
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 (was: [PROPOSAL][VOTE] Subversion)

[Branko Čibej]

Martijn Dashorst wrote:
> Yes, *AND* ensuring legal dots are put on the i's and j's. This is
> done through checking the release and ensuring that it is in adherence
> to our policies which you and others have crafted. *All* podlings have
> to ensure they have the correct licensing headers, notices and other
> bits in place before they can graduate.
>
> AFAIK releases done by podlings are legally more sound than
> established projects at Apache. Do you consider that a bad thing?
> What strikes me is that because the SVN project has many old boys
> network guys on board, somehow the policy to what all podlings are
> subjected to is no longer valid?
>   

I don't disagree to checking the legal bits and pieces. But what I read
up to now, in the other thread, was more to the tune of checking release
quality and procedures. I got stuck on the "quality" part; I for one
will not sign off a Subversion release if I know it's broken, and
apparently the legal bits can be verified in other ways.

Clearly it's up to the Incubator PMC and/or Mentors to decide what does
or does not make sense here. If "make a proper release" is indeed the
verdict, then Subversion will remain incubating for several months at
least. That's not necessarily a bad thing, but it does leave a strange
taste in the mouth, especially given how much effort we've already put
in running our project according to ASF standards.

Oh and by the way, ranting about old-boys networks was pretty much the
last thing I expected to read on this list. Is the meritocracy blues all
nonsense then? Just askin' ...

-- Brane, not an ASF member


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL][VOTE] Subversion

[Branko Čibej]

Igor Burilo wrote:
> C. Michael Pilato 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?
>>>   
>
> Michael, sure Neon and Serf are optional and it’s absolutely correct from
> the legal point of view. But in this case SVN should work without DAV
> support, which is important for end-users.
>
> When we talk about licensing issues we mean problem with entire SVN
> acceptance and distribution. In particular, it’s a big problem for Eclipse
> community and companies that stay behind this community. To accept SVN they
> require a legally clean pre-built solution. It means that at least JavaHL
> client should be EPL (Apache 2.0) compatible. Now it doesn’t because of
> Neon. Sure, someone can tell – build distribution yourself with Serf, but we
> understand that result isn’t guaranteed at the current moment, so this
> solution will not be accepted. Another approach to allow users build library
> by themselves will not work, because require knowledge and experience from
> end-users.
>   

I don't quite understand what you're getting at, but you appear to be
mixing up the concepts of "releasing" and "packaging". If the Eclipse
community requires a pre-built solution, then tough luck, they won't get
it from the Subversion project because we never have and never will
release anything but source code. If some package maintainer volunteers
to build binaries specifically for Eclipse, then said maintainer can do
it without including Neon or BDB or a few other optional bits and
pieces, and will end up with a functional Subversion client.

> At the current moment SVN client can’t pass legal review on Eclipse

(something I don't really care about, but) see above; we do not release
any code with an incompatible license.

>  and it
> means that SVN loosing its huge potential there. It’s a perfect example when
> nice technology is blocked by legal tricks. So the perfect solution will be
> to replace Neon by Serf, because it will resolve a lot of issues described
> above with SVN acceptance.
>   

Frankly I've heard so many interesting things about the Eclipse process
from various sources that it appears to me that they're tripping
themselves up on imaginary technicalities. The statements you made about
Subversion's incompatibility with Eclipse seem bogus; since, as I said
above, all the potentially conflicting parts are completely optional and
do not have to be part of any binary package.

What am I missing?

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL][VOTE] Subversion

[Branko Čibej]

William A. Rowe Jr. wrote:
> Mark Phippard wrote:
>   
>> I gave counsel to the Eclipse Foundation and explained that they could
>> provide a fully functioning JavaHL library to users with only EPL
>> compatible code.  Basically, you just need to build without Neon, BDB
>> and libintl support.  Of the three, the only thing an Eclipse client
>> user needs is Neon, and Serf serves as a viable replacement.  I do not
>> know why they never chose to release a binary built this way.  I can
>> only assume that Igor and Polarion did not want to make these
>> binaries.
>> 
>
> I suspect IBM's ICU lib could be substituted for libintl, and as there is
> some traction on the idea of dumping apr-iconv, this would be a sensible
> thing (since ICU is the heir apparent for non-iconv based platforms).
>
> I keep reading "The project doesn't release binaries".  Who will, Tigris?
> Collab?  Yo momma?  One of the greatest advantages is that committers who
> wish to package binaries can do so under the ASF umbrella, something that
> in this litigious society I would never consider doing now.
>
> So is the "project doesn't release binaries" mantra a statement about the
> past practices, a tacit or explicit contract in bringing this to the ASF,
> or just the posters' personal preference?
>   

Wait a minute. Are you implying that the "project" *should* release
binaries? Wouldn't such a requirement apply to, say, APR, to keep this
close to home?

Certainly any volunteer with proper karma can build binaries from the
release tarballs, and if those binaries happen to pass muster wrt
ASF-mandated legalities, then from my understanding it should be OK to
host such binaries on ASF's infrastructure. But that's not the same as
the project releasing those binaries -- lack of digital sigs on them is
a dead giveaway.

How many APR and/or httpd commiters sign your Windows binary packages?

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Two other issues to discuss for Subversion

[Branko Čibej]

Martijn Dashorst wrote:
> On Tue, Nov 10, 2009 at 8:43 PM, Greg Stein  wrote:
>   
>> LOL
>>
>> Well... the problem is that an "svn mv" from /incubator/subversion/ to
>> /subversion/ introduces an artificial breakage in the history. It is
>> actually quite disruptive for tracking history (which is very
>> important to us).
>> 
>
> Sounds like an excellent task to solve for subversion 1.7. :-)
>   

Heh. It's the sort of task-to-solve I've been ranting about^W^Whoping
for on and off for ... what, nine years or so? :)

But now that we're joining the ASF, I'll magically have more time on my
hands to do it.

-- Brane

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

OT: Subverting Eclipse (subject line changed to protect the guilty)

[Branko Čibej]

Igor Burilo wrote:
> Mark Phippard-3 wrote:
>   
>>> I gave counsel to the Eclipse Foundation and explained that they could
>>> provide a fully functioning JavaHL library to users with only EPL
>>> compatible code.  Basically, you just need to build without Neon, BDB
>>> and libintl support.  Of the three, the only thing an Eclipse client
>>> user needs is Neon, and Serf serves as a viable replacement.  I do not
>>> know why they never chose to release a binary built this way.  I can
>>> only assume that Igor and Polarion did not want to make these
>>> binaries.
>>>   
>
> Mark, it’s not a problem to build JavaHL. But as you said, to make it EPL
> compatible Eclipse should replace Neon by Serf or remove DAV libraries
> completely. It’s not a solution. In the first case proper functionality
> isn’t guaranteed (you and Michael Pilato are sceptic regarding Serf). Nobody
> would like to use SVN client, which is “different” and migh have problems.
>   

Sorry, but I have to say it: FUD, FUD, FUD! The *only* difference
between Serf and Neon that I'm aware of, in terms of functionality of
course, is that Neon (used to) have support for some authorization
models that Serf (used not to) have.

What you are saying is that Eclipse would only accept a Subversion
client with Neon in it ("proper functionality" FUD), but can't because
it has Neon in it so the license is wrong. That's just nitpicking for
the fun of it, and it assumes that Eclipse is itself the epitome of
perfection and should not be sullied by imperfect code. Bit of a paradox
there.

Which causes me to wonder how come you happen to trust Polarions
Java-only reimplementation of Subversion protocols -- that were never
seen, let alone certified as correct, by the Subversion community -- to
guarantee "proper functionality".

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Review-Then-Commit

[Branko Čibej]

Eric Evans wrote:
> Sure, but the IPMC is in a position of power, and can impose it's will
> upon the project (including CTR vs. RTC), right?
>   

I have no clue whether the IPMC can impose such a decision. But I'm
very, very certain that it should not even consider trying. It's better
to ask the podling's PMC to address concerns and let them work it out,
than simply telling them that "we see this problem, and here's how you
will fix it." That would be rather counterproductive, the idea is to
ensure the project can live independently once it has graduated.

-- Brane

-
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

[Branko Čibej]

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?

This suggestion is equivalent to requiring that all C APIs that come
from this community be prefixed with ap_ ... so "it's completely
possible to create a separate set of headers with the necessary glue
that map svn_ to ap_svn_."

Sorry about being a bit sarcastic there.

-- Brane


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org