RE: [DISCUSS] Apache NetBeans Incubator Proposal

[Dennis E. Hamilton]

> -Original Message-
> From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
> Sent: Monday, September 19, 2016 13:05
> To: general@incubator.apache.org
> Subject: RE: [DISCUSS] Apache NetBeans Incubator Proposal
> 
> There is a big difference between Apache OpenOffice and NetBeans.
> NetBeans, even with the NetBeans Platform, is a developer-facing
> project.  I presume that the cycle of learning and improvement out
> through the adopters and community for NetBeans is operating
> successfully and will thrive at Apache.  The "eating-your-own-dogfood"
> principle seems to be well in hand [;<).
> 
> There does need to be attention to infrastructure requirements.
> 
> The initial committer list for Apache OpenOffice to enter incubation was
> entirely and publicly self-selected.  That means it includes, to this
> day, individuals who do not commit to the code but contribute, when
> still active, in other ways.  There are acute divisions between those
> who cannot and will not build the code, those who manage to build and
> run the code, and those who can do anything significant with the code
> and test their results.  That division is a tremendous challenge in the
> sustainability of Apache OpenOffice.
[orcmid] 

I should be clear that the acute division is with respect to capacity and 
capabilities and also will.  I did not mean divison as some sort of dispute.

> 
> Although the size of OpenOffice is daunting, that in itself is not a
> challenge to the ASF infrastructure.  The files in the Apache OpenOffice
> 4.1.2 source release consist of
> 
>1.43 GB (1,541,226,333 bytes) of text in
>  60,955 files, in
>   6,429 folders.
> 
>  - Dennis
> 
[ ... ]


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

RE: [DISCUSS] Apache NetBeans Incubator Proposal

[Dennis E. Hamilton]

There is a big difference between Apache OpenOffice and NetBeans.  NetBeans, 
even with the NetBeans Platform, is a developer-facing project.  I presume that 
the cycle of learning and improvement out through the adopters and community 
for NetBeans is operating successfully and will thrive at Apache.  The 
"eating-your-own-dogfood" principle seems to be well in hand [;<).

There does need to be attention to infrastructure requirements.  

The initial committer list for Apache OpenOffice to enter incubation was 
entirely and publicly self-selected.  That means it includes, to this day, 
individuals who do not commit to the code but contribute, when still active, in 
other ways.  There are acute divisions between those who cannot and will not 
build the code, those who manage to build and run the code, and those who can 
do anything significant with the code and test their results.  That division is 
a tremendous challenge in the sustainability of Apache OpenOffice.

Although the size of OpenOffice is daunting, that in itself is not a challenge 
to the ASF infrastructure.  The files in the Apache OpenOffice 4.1.2 source 
release consist of

   1.43 GB (1,541,226,333 bytes) of text in
 60,955 files, in
  6,429 folders.

 - Dennis   

> -Original Message-
> From: Raphael Bircher [mailto:rbircherapa...@gmail.com]
> Sent: Monday, September 19, 2016 04:10
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Apache NetBeans Incubator Proposal
> 
> Hi Geertjan
> 
> I'm registred at NetBeams now, to get a closer look at the project. I
> was a bit shocked about the similarities with the formar
> OpenOffice.org project. The structure of the Project, the workflow
> etc. are so close to the OpenOffice.org project, much closer as I
> expected. My biggest fear for the incubation is not the technical
> aspect. For infrastructure we will find solutions, and for many
> problems exist already blueprints from the OpenOffice Project. My
> biggest fear ist the community. As I saw on the NetBeans ML, the
> decision to join the ASF was made by Oracle. Well a load of the
> community members welcome this step, but there are also fears. This
> fears has to be addressed, this is very very important.
> 
> One Mail also complained about the Initial Committer list. Are all
> active committers who did commit in the last 6 month (or so) on the
> initial committer list. forgotten people can create bad blood and
> disappointment. The committers are the most value part of a project.
> 
> This are at the moment my biggest concerns.
> 
> Regards Raphael
> 
[ ... ]


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

RE: [DISCUSS] Apache NetBeans Incubator Proposal

[Dennis E. Hamilton]

+1

> -Original Message-
> From: Greg Stein [mailto:gst...@gmail.com]
> Sent: Sunday, September 18, 2016 00:46
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Apache NetBeans Incubator Proposal
> 
> On Sat, Sep 17, 2016 at 9:54 AM, Geertjan Wielenga <
> geertjan.wiele...@googlemail.com> wrote:
> 
> > Hi all,
> >
> > Can we be specific about what info is needed, or what further details
> > specifically, before going into a vote for acceptance of the proposal?
> My
> > concern is that each question we answer is answered by further
> questions to
> > answer. Maybe we could do a phone conference with the NetBeans
> > infrastructure side together with the Apache infrastructure side.
> Maybe we
> > can work through the infrastructure challenges during incubation.
> >
> 
> Generally speaking, Apache would prefer to slow things down and use a
> mailing list, rather than to have a phone conference. The email is
> documented for everybody to review, to participate, and to record for
> future examination. A phone conference probably wouldn't resolve many
> questions/concerns anyway, simply because much of that comes from
> considered thought. A phone call is "THINK NOW. RESPOND. OOPS. MISSED
> YOUR
> CHANCE." ... Mailing lists give people time to think.
> 
> There is no rush, no dates, no deadlines at the ASF. It may take longer
> via
> mailing lists, but it means that the larger community can be involved,
> can
> review, and can be archived.
> 
> If one question turns into three ... well, that is deliberation. As
> David
> noted else-thread, we rarely get such a large, well-established
> community
> arriving at the Incubator. That necessitates a bit more inquiry than
> most
> other entrants receive. Layers of the onion get peeled, and new
> questions
> arrive. More layers unpeeled ...
> 
> And to point to the elephant in the room: I bet there are people
> concerned
> given the recent misadventures of AOO [and Oracle's donations of these
> two
> projects]. Personally, I think it is hogwash, and don't believe any
> concern
> applies here, as the communities and the userbase are very different.
> BUT,
> temporally, there is a conflation of the donations of these two
> projects. I
> suspect that will cause a few people to slow down and ask more
> questions.
> 
> Cheers,
> -g


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

RE: Ease of release process and exit criteria

[Dennis E. Hamilton]

+1 to this, including the posts from Mark and Bertrand.

I know of a project where this would have made a serious difference for 
graduation and subsequent sustainability.

 - Dennis

> -Original Message-
> From: Shane Curcuru [mailto:a...@shanecurcuru.org]
> Sent: Friday, August 19, 2016 07:08
> To: general@incubator.apache.org
> Subject: Re: Ease of release process and exit criteria
> 
> Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
> > Hi Mark,
> >
> > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 
> wrote:
> >> ...I'm thinking of a graduation criteria long the lines of:
> >> "Is the release process clearly documented to the point that someone
> new
> >> to the project could produce a release build?"...
> 
> +1, this is a critical point to include.  We continue to see projects
> struggling with releases when early volunteers leave and no-one else
> really understands releases.
> 
> ...snip...
> > How about also adding an RE50 item to
> > https://community.apache.org/apache-way/apache-project-maturity-
> model.html
> > about a repeatable release process? That's a discussion for
> > community.a.o but what's your opinion?
> 
> +1, this is both important to include philosophically as well as
> practically.  I.e. it's an important reminder that project technical
> procedures need to be understandable by the *whole* community, not just
> the first few developers who created the project.
> 
> - Shane
> 
> -
> 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: Ease of release process and exit criteria

[Dennis E. Hamilton]

> -Original Message-
> From: Mark Struberg [mailto:strub...@yahoo.de.INVALID]
> Sent: Friday, August 19, 2016 03:19
> To: general@incubator.apache.org
> Subject: Re: Ease of release process and exit criteria
> 
> Good links.
> 
> I’d like to add some information for projects who use GIT with maven:
[ ... ]
> Note that in most projects we do _not_ push the release candidate
> directly to the ASF repo but e.g. to the release managers private github
> account.
> Reason is that we cannot easily get rid of it from the cannonical ASF
> repo if the VOTE fails.
> (ASF repos get mirrored downstream in seconds, and while we could
> technically remove it from our own repo we have no control over all the
> clones).
[orcmid] 

The ASF SVN supports a staging process by which projects have a place to put 
dev-only builds that are for testing and consideration as release candidates.  
How that would tie into GIT-only projects and Maven as used is a different 
matter and distinguishing between non-released developer artifacts, release 
candidates, and releases seems to be much trickier.  

Using AOO as an example, the place where artifacts for dev-only use and 
handling as release candidates are at 

 .  Release candidates on 
which deliberation fails to achieve release approval can be deleted from there.

When a release candidate is identified and approved as a release, it is copied 
or moved to 

  along with the 
signatures and hashes that were with the candidate in the dev area.  (Using 
SVN, this is a cheap copy.)

That is the staging point for a general, public distribution.  
Within something like 24-48 hours, the content of that release area is 
automatically mirrored to

 

And THAT is the official public availability point (with whatever mirroring and 
other downstream distribution there happens to be).  That is where the 
indelible KEYS, hashes, signatures, etc. are to be accessed and the material is 
preserved in perpetuity. 

Deletions at dist.apache.org do not have any effect on the archive.apache.org 
artifacts, so one can clean-up by removing those.  This is SVN so the artifacts 
are not completely gone, but they are not available for mistaken download by 
direct access to those locations.

> 
> This is kind of symetrical to the maven repo staging aproach.
> And the sha1 is the same anyway if we merge the buid-branch to master
> and push it to the ASF repo later (when the VOTE did pass).
> 
> Something very old I wrote up for DeltaSpike a few years ago where I
> described the steps:
> http://mail-archives.apache.org/mod_mbox/deltaspike-
> dev/201309.mbox/%3c1378906506.82251.yahoomail...@web28902.mail.ir2.yahoo
> .com%3E
> 
> hth.
> 
> LieGrue,
> strub
> 
> 
> > Am 19.08.2016 um 11:57 schrieb Bertrand Delacretaz
> :
> >
> > Hi Mark,
> >
> > On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas 
> wrote:
> >> ...I'm thinking of a graduation criteria long the lines of:
> >> "Is the release process clearly documented to the point that someone
> new
> >> to the project could produce a release build?"...
> >
> > I like this - as another example we have
> > http://sling.apache.org/documentation/development/release-
> management.html
> > in Sling, and as someone who does releases in bursts that's very
> > useful.
> >
> >> ...If there is general consensus on this, I'm happy to draft
> something to
> >> add to http://incubator.apache.org/guides/graduation.html#releases
> ...
> >
> > +1 and it's good to add links such as the ones you mentioned and the
> > above if you think they are good examples.
> >
> > How about also adding an RE50 item to
> > https://community.apache.org/apache-way/apache-project-maturity-
> model.html
> > about a repeatable release process? That's a discussion for
> > community.a.o but what's your opinion?
> >
> > -Bertrand
> >
> > -
> > 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: Code signing and WOT for releases

[Dennis E. Hamilton]

> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Thursday, July 28, 2016 05:13
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
> 
> 4) how to find a public key certificate matching the ID in the signature
> and how to check that the private key is asserted to be in the
> possession of the person controlling orc...@apache.org[orcmid]  if you are 
> *not*
> using assertions how would this be accomplished?
[orcmid] 

That's correct, there is no technical assertion mechanism in OpenPGP.  I should 
not have used that term.

What constitutes the equivalent of an *attestation* in WOT is the 
counter-signing of a public key by another.  That is taken as an attestation 
that an identified individual claimed authority over the private key by virtue 
of the fingerprint, the User ID, and in-person confirmation of identification.

In the case of controlling orcmid@ apache.org, the evidence is that the person 
having control of that account (Apache Committer ID orcmid) placed the 
fingerprint in his private account record and the system retrieved the key with 
that fingerprint and placed it at 
.  That is retrieval from 
Internet key servers periodically and will reflect any counter-signing by 
others as well as any revocation.

There's more to be said about that particular certificate, and other 
attestations that apply to it, but we can stop here unless you are curious 
about that.

 - Dennis

> 
> Regards
> Martin
> __
> 
> 
> 
> > From: dennis.hamil...@acm.org
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> > Date: Wed, 27 Jul 2016 10:01:59 -0700
> >
> >
> > > -Original Message-
> > > From: Martin Gainty [mailto:mgai...@hotmail.com]
> > > Sent: Wednesday, July 27, 2016 08:06
> > > To: general@incubator.apache.org
> > > Subject: RE: Code signing and WOT for releases
> > >
> > >
> > >
> > > > From: dennis.hamil...@acm.org
> > > > To: general@incubator.apache.org
> > > > Subject: RE: Code signing and WOT for releases
> > > > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > > > [ ... ] Yesterday, I received an email from one of the users who
> > > received a security advisory message that I signed.  The user's mail
> > > reader reported that the signature was untrusted (no surprise) and
> that
> > > the signature was BAD.  Since the mail reader shows the stripped
> > > message, and it looks perfectly fine, there is no way to help
> analyze
> > > that from my end.
> > > >
> > > > What I did do was (1) verify the message that was sent to me from
> the
> > > list and (2) verify the message in the list archive.  I then (3)
> advised
> > > the recipient what I did and also (4) how to find a public key
> > > certificate matching the ID in the signature and how to check that
> the
> > > private key is asserted to be in the possession of the person
> > > controlling orc...@apache.org and how the individual having control
> of
> > > that email address is associated with the ASF.
> > >
> > > MG>can we assume the key was converted to PKCS8 before asserting the
> > > key?
> > > http://stackoverflow.com/questions/5230942/how-to-read-a-private-
> key-
> > > for-use-with-opensaml
> > >
> > > MG>and then built new SignatureBuilder().buildObject() Signature
> with
> > > key locations before assigning
> > > assertion.setSignature(___)?http://www.programcreek.com/java-api-
> > > examples/index.php?api=org.opensaml.xml.signature.Signature
> > >
> > > MG>/thanks dennis/
> > [orcmid]
> >
> > This signing had nothing to do with MIME-signatures or SSL.  It is a
> plaintext message that has a "clearsign" OpenPGP signed section in-line
> in the message body.  (The signed part was created first and then pasted
> into the plaintext email.)  You can see the archived form at
> >  announce/201607.mbox/browser> where it is the only message there. At the
> bottom of the HTML-formatted display of the message, select the "Unnamed
> text/plain" link to see a cleaner plaintext.
> >
> > This is not unlike the .asc files that can be made as external PGP
> signatures of code, except it is inline instead of external to the file
> being signed.
> >
> > > >
> > > > (I made another check of the archived message too.  The raw form
> of
> > > the message fails to verify when downloaded and that appears to be
> on
> > > account of some encoding features that have to be processed properly
> for
> > > the original text to be reconstituted properly. That might or might
> not
> > > be relevant to how that recipient's email reader handles PGP
> > > > signatures.)
> > [orcmid]
> >
> > (If you look at the raw version on the archive, you will see a pile of
> =20 line endings that make the raw form unverifiable.  And because the
> signature block has a line ending in =, there is an appended raw "3D"
> that 

RE: Code signing and WOT for releases

[Dennis E. Hamilton]

> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Wednesday, July 27, 2016 08:06
> To: general@incubator.apache.org
> Subject: RE: Code signing and WOT for releases
> 
> 
> 
> > From: dennis.hamil...@acm.org
> > To: general@incubator.apache.org
> > Subject: RE: Code signing and WOT for releases
> > Date: Tue, 26 Jul 2016 10:33:13 -0700
> > [ ... ] Yesterday, I received an email from one of the users who
> received a security advisory message that I signed.  The user's mail
> reader reported that the signature was untrusted (no surprise) and that
> the signature was BAD.  Since the mail reader shows the stripped
> message, and it looks perfectly fine, there is no way to help analyze
> that from my end.
> >
> > What I did do was (1) verify the message that was sent to me from the
> list and (2) verify the message in the list archive.  I then (3) advised
> the recipient what I did and also (4) how to find a public key
> certificate matching the ID in the signature and how to check that the
> private key is asserted to be in the possession of the person
> controlling orc...@apache.org and how the individual having control of
> that email address is associated with the ASF.
> 
> MG>can we assume the key was converted to PKCS8 before asserting the
> key?
> http://stackoverflow.com/questions/5230942/how-to-read-a-private-key-
> for-use-with-opensaml
> 
> MG>and then built new SignatureBuilder().buildObject() Signature with
> key locations before assigning
> assertion.setSignature(___)?http://www.programcreek.com/java-api-
> examples/index.php?api=org.opensaml.xml.signature.Signature
> 
> MG>/thanks dennis/
[orcmid] 

This signing had nothing to do with MIME-signatures or SSL.  It is a plaintext 
message that has a "clearsign" OpenPGP signed section in-line in the message 
body.  (The signed part was created first and then pasted into the plaintext 
email.)  You can see the archived form at

 where it is the only message there. At the bottom of the HTML-formatted 
display of the message, select the "Unnamed text/plain" link to see a cleaner 
plaintext.  

This is not unlike the .asc files that can be made as external PGP signatures 
of code, except it is inline instead of external to the file being signed.

> >
> > (I made another check of the archived message too.  The raw form of
> the message fails to verify when downloaded and that appears to be on
> account of some encoding features that have to be processed properly for
> the original text to be reconstituted properly. That might or might not
> be relevant to how that recipient's email reader handles PGP
> > signatures.)
[orcmid] 

(If you look at the raw version on the archive, you will see a pile of =20 line 
endings that make the raw form unverifiable.  And because the signature block 
has a line ending in =, there is an appended raw "3D" that breaks the whole 
thing. A client that does not restore the plaintext before checking the 
signature will claim that the signature is "BAD".)

PS: I sent the same message to a colleague who has a PGP-aware email client, 
and the message verified automatically and was presented without the boundaries 
and the signature block.  Instead, there was a marker that indicated the part 
of the message that was signed.  So it would appear that the person who 
reported to me encountered an interoperability failure.
> >
[ ... ]


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

RE: Code signing and WOT for releases

[Dennis E. Hamilton]

> -Original Message-
> From: Nick Kew [mailto:n...@apache.org]
> Sent: Tuesday, July 26, 2016 02:25
> To: general@incubator.apache.org
> Subject: Re: Code signing and WOT for releases
> 
> On Tue, 2016-07-26 at 09:19 +0200, Thorsten Schöning wrote:
> > Hi all,
> >
> > the docs about release management for incubating projects make clear
> > that the release needs to be signed[1] and in the end associated with
> > the project AND the WOT of Apache in general[2].
> 
> I don't like that term "the WOT of Apache in general", with its
> implied suggestion that an Apache WoT might differ from AN Other.
> Even if a private Apache WoT were a reality, how would that help
> our users verify our releases?  Surely the WoT we should be
> concerned with is the Strong Set that unifies Geekdom at large.
[orcmid] 

I think that is perhaps relevant to how the WoT is viewed, but it does not 
necessarily consider the audience of the signed material.  

For example, Apache OpenOffice distributes binaries on behalf of end-users.  
They are unlikely to know anyone in the WoT of a signer and, while there may be 
an effect in numbers, it is not clear how one can be satisfied abut the 
identity and veracity of the signer.

Also, there are two aspects that seem to be muddled in discussion of the WoT.  
There is how much one trusts that the private key is in the exclusive control 
of the user identified in the public key certificate and that the 
identification is accurate, and the not-quite-the-same question of how much one 
trusts the possessor of that private key to be careful in the counter-signing 
of the public keys of others.  

> Yes, also the project's KEYS and id.apache.org, but that's
> a separate issue to the WoT!
[orcmid] 

Right.  Yesterday, I received an email from one of the users who received a 
security advisory message that I signed.  The user's mail reader reported that 
the signature was untrusted (no surprise) and that the signature was BAD.  
Since the mail reader shows the stripped message, and it looks perfectly fine, 
there is no way to help analyze that from my end.

What I did do was (1) verify the message that was sent to me from the list and 
(2) verify the message in the list archive.  I then (3) advised the recipient 
what I did and also (4) how to find a public key certificate matching the ID in 
the signature and how to check that the private key is asserted to be in the 
possession of the person controlling orc...@apache.org and how the individual 
having control of that email address is associated with the ASF.

(I made another check of the archived message too.  The raw form of the message 
fails to verify when downloaded and that appears to be on account of some 
encoding features that have to be processed properly for the original text to 
be reconstituted properly. That might or might not be relevant to how that 
recipient's email reader handles PGP
signatures.)

> 
> In terms of instructions I can't improve on Mark's reply.
> I would add that it's not entirely unprecedented to sign a
> release with a key that can't be verified in the Strong Set,
> but you should make all efforts to avoid that.  A key that
> can't be verified adds no more security than an MD5 checksum.
> 
> --
> Nick Kew
> 
> 
> -
> 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: Notes on branding

[Dennis E. Hamilton]

On the other hand, it would be great were the Apache Incubator image linked to 
something better than http://trafodion.apache.org [;<).

As a general observation, the fine print mentioning of Incubator would also 
serve folks better if there was a link as part of the Incubator mention.

http://incubator.apache.org in both cases seems good enough.

No voting required.

 - Dennis

> -Original Message-
> From: Ted Dunning [mailto:ted.dunn...@gmail.com]
> Sent: Sunday, July 3, 2016 00:05
> To: general@incubator.apache.org
> Subject: Re: Notes on branding
> 
> On Fri, Jul 1, 2016 at 8:55 PM, Gunnar Tapper 
> wrote:
> 
> > FYI, "Apache Trafodion" is part of the logo. I'm not putting the
> project
> > through another round of voting on that one. :)
> >
> 
> Wouldn't suggest that either.
> 
> What I was noting was that the text above the log and the text in the
> logo
> were kind of redundant.
> 
> I sympathize with not wanting to make low priority changes. This was
> just a
> note.


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

RE: [DISCUSS] Juneau Incubation Proposal

[Dennis E. Hamilton]

> -Original Message-
> From: James Bognar [mailto:james.bog...@salesforce.com]
> Sent: Thursday, June 16, 2016 12:51
> To: general@incubator.apache.org; dennis.hamil...@acm.org
> Subject: Re: [DISCUSS] Juneau Incubation Proposal
> 
> The list of POJOs supported is listed here:
> 
> http://jamesbognar.github.io/juneau-docs/doc/overview-
> summary.html#Core.PojoCategories
[orcmid] 

Nice.  Thanks for that and the other links.

 - Dennis
> 
> On Thu, Jun 16, 2016 at 11:26 AM, James Bognar
> 
> wrote:
> 
[ ... ]
> > The javadocs are currently being hosted on GitHub and are accessible
> here:
> > http://jamesbognar.github.io/juneau-docs/doc/index.html
> >
> > The main documentation is located in the overview document
> > http://jamesbognar.github.io/juneau-docs/doc/overview-summary.html#TOP
> >
> >
[ ... ]


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

RE: [DISCUSS] Juneau Incubation Proposal

[Dennis E. Hamilton]

It appears that POJO = Plain-Old Java Object.

There does not seem to be consensus on what qualifies as a POJO.  There is at 
least one definition that suggests absence of a need for a class path (?! 
whatever that means, perhaps being about dependencies?).  Is there some 
technical, definitive definition of what qualifies as a POJO for Juneau?

On attempting download from page 
https://sites.google.com/site/apachejuneau/downloads my Internet browser 
identified Juneau-6.0.0.zip as containing a virus and the download was deleted 
:(.  The detected item is identified as Trojan:Win32/Spursint.A!cl and is 
considered dangerous, executing commands from an attacker.  The offender 
appears to be 

   juneau-6.0.0.zip->samples/juneau-samples-6.0.0.war
 ->WEB-INF/lib/wink-server-1.2.1-incubating.jar
 ->HtmlDefaultRepresentation/js/CollapseExpand.js

The detection is from Windows Defender using Internet Explorer 11 on Microsoft 
Windows 10 Pro x64.

It would be helpful, perhaps, if the JavaDocs were accessible via HTTP directly.

Having said all of that, this is certainly an interesting prospect.

 - Dennis


> -Original Message-
> From: James Bognar [mailto:james.bog...@salesforce.com]
> Sent: Thursday, June 16, 2016 10:09
> To: general@incubator.apache.org
> Subject: Re: [DISCUSS] Juneau Incubation Proposal
> 
> FYIhere's the content of the proposal.
> 
> = Juneau Toolkit =
> 
> == Abstract ==
> 
> Apache Juneau is a toolkit for marshalling POJOs to a wide variety of
> content types using a common framework, and for creating sophisticated
> self-documenting REST interfaces and microservices using VERY little
> code.
> 
> == Proposal ==
> 
> An external website has been set up to point to existing libraries and
> documentation:
> https://sites.google.com/site/apachejuneau/
> 
[ ... ]


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

RE: [ALL] Volunteers for a Math PPMC?

[Dennis E. Hamilton]

I see, by being allergic to cross-posting, that I have created the mess I hoped 
to avoid.  There are matters here for keeping the Commons Math folk involved so 
I won't say much here.  This needs to be addressed at dev-commons.

A couple of comments in-line, 

> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Sunday, June 12, 2016 04:31
> To: general@incubator.apache.org; dennis.hamil...@acm.org
> Subject: Re: [ALL] Volunteers for a Math PPMC?
> 
> On Sat, Jun 11, 2016 at 12:11 PM Dennis E. Hamilton
> <dennis.hamil...@acm.org>
> wrote:
> 
> > Interesting.  Does this mean migrating Commons Math to a math PPMC
> (not
> > IPMC)?
> >
> > Would the scope be the same?
> >
> >
> I do not know if the scope for Math would change necessarily, but I
> would
> imagine you'd see some new innovations coming from it, such as
> distributed/parallel computing versions of some algorithms.  I would
> leave
> that up to the new PPMC (thanks for the correction) or PMC.   I do know
> that the main person working on it right now, Gilles Sadowski, has some
> plans to split it up into multiple, independent modules so that they can
> have their own release cycles, etc.  This was something suggested by the
> other contributors before they forked (https://hipparchus.org/) the
> project
> and did that very thing.
[orcmid] 

I asked because there are those who propose retiring portions of Commons Math 
that no one is maintaining (with some confusion between "stable" and 
"unmaintainable") The current collection of packages seems to include some that 
are more than "small easily-integrated components [without] complex 
dependencies and configurations."  That appraisal is definitely superficial on 
my part, though.  This is not an expert assessment.

> 
> 
> Would Commons Math go to the Attic?
> >
> >
> This is what I am trying to prevent.  I think Math has a future here at
> the
> ASF and it would be a shame for it to "die" at this time.  My hope is to
> take it to a TLP by way of the Incubator in order to help it gain a
> larger
> community around it.  It really hasn't ever had a large, sustained
> community of contributors (other than us folks in the peanut gallery
> from
> the Commons PMC that aren't math experts like the core group).
> 
> Is there some problem that this is meant to solve?  How is it a
> solution?
> >
> >
> Math has always been an odd bird in Commons, IMHO.  FWIW, here is the
> discussion thread we had about moving it to TLP (the subsequent VOTE
> passed, btw):
> 
> http://markmail.org/message/bi7tg4ssuiqljiby
> 
> 
> >  - Dennis
> >
> > PS: I have labored through the dev-commons thread on [Math] Commons
> Math
> > (r)evolution, and a few other of the June math-related posts.  I think
> > going through the effort to create an Incubation proposal would be
> useful.
> > You will have to come to grips, and clarity, on whether and to what
> extent
> > this is effectively an ASF-internal fork.  Not that there is anything
> wrong
> > with that.  It is leaving it unresolved that strikes me as solving
> nothing.
> >
> >
> This is *not* a fork!  We (with the blessing of the Commons PMC) would
> be
> moving the code a TLP, but we (maybe just "I" at this point, I don't
> know)
> would like for it to spend a bit of time in the Incubator in order to
> build
> a more diverse community around it and make sure it can stand on its
> own.
> I don't think there is precedent for this, but that doesn't mean it's a
> bad
> idea.  Commons Math's community wasn't large enough to sustain this
> exodus
> (5 people) and it is a pretty bad spot right now, with only one regular
> contributor left over.  I'm not going to go into what caused this
> situation.  We are where we are.  We just need to try to do what's best
> for
> Math and let it move forward.
[orcmid] 

About attic and forking.  I meant whether the code base that is at Commons Math 
would be frozen and in the attic although available for use, just not 
maintained there.  Folks could be advised that there is continued development 
downstream from there in an Apache (podling) project and, if it graduates, a 
different TLP.  

Do not assume that graduation of a Podling is a slam dunk.  

"Fork" is not a toxic notion at the ASF, although I understand that the current 
existence of non-ASF Commons Math fork is bothersome to those who have put 
their hearts into Commons Math and have not defected.

There are a number of technicalities in moving that need to be identified and 
prepared for.  Those need to be comprehe

RE: [ALL] Volunteers for a Math IPMC?

[Dennis E. Hamilton]

Interesting.  Does this mean migrating Commons Math to a math PPMC (not IPMC)? 

Would the scope be the same?

Would Commons Math go to the Attic?  

Is there some problem that this is meant to solve?  How is it a solution?

 - Dennis 

PS: I have labored through the dev-commons thread on [Math] Commons Math 
(r)evolution, and a few other of the June math-related posts.  I think going 
through the effort to create an Incubation proposal would be useful.  You will 
have to come to grips, and clarity, on whether and to what extent this is 
effectively an ASF-internal fork.  Not that there is anything wrong with that.  
It is leaving it unresolved that strikes me as solving nothing.

PPS: Not cross-posting.  The interested parties may need to come to 
general-incubator to begin appreciating for themselves what is involved.

> -Original Message-
> From: James Carman [mailto:ja...@carmanconsulting.com]
> Sent: Saturday, June 11, 2016 03:26
> To: Commons Developers List ;
> general@incubator.apache.org
> Subject: [ALL] Volunteers for a Math IPMC?
> 
> We (the Commons PMC) have not decided yet what to do, but I just wanted
> to
> gauge the interest in joining the math IPMC if we choose to go TLP by
> way
> of the incubator. The idea would be that math (whatever its name may
> be),
> would go through the incubator in order to enrich its community prior to
> becoming a TLP. Do we have any folks willing to throw their hat in the
> ring?
> 
> p.s. I've cross-posted to the incubator list as there are folks there
> who
> are very good at this stuff and could perhaps lend us some advice.


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

ODF Toolkit Podling (was RE: 54 podlings - too many?)

[Dennis E. Hamilton]

Since I came to OpenOffice and Apache via my work on ODF at OASIS, I have some 
interest in this topic.  

I share Sam Ruby's bafflement.  Sustainability of a single committer curating 
the code base is certainly a concern.  In November 2015, mentor Nick Burch 
challenged the podling with the thread starting at 
.
  The thread died out without any resolution other than to work on JIRA issues 
and their patches.

 - Dennis

OBSERVATIONS (THE TL;DR)

 1. There has been a fork of the significant ODFDOM portion of the ODF Toolkit 
and the fork is unwilling to contribute back to the ODF Toolkit, where new 
feature development seems to be dormant.

 2. There seems some confusion about what going to the attic means.  It does 
not mean that the codebase disappears, the expressed fear.  It does mean that 
the code is frozen.  That would eliminate the maintenance that is the prominent 
current activity.

 3. The ODF Toolkit and the level of SDK support in AOO are fundamentally 
different, despite any similarity of function.  There could be advantageous use 
of ODF Toolkit availability by the Apache OpenOffice project for utility, 
testing, and forensic activities on the project.  That opportunity has not been 
taken and, based on that, I don't foresee it.  

 4. Blending into AOO would doubtless dilute the dedicated attention the ODF 
Toolkit now receives, especially from users and devs, without any benefit of 
AOO developer attention.  (Merging the issue trackers would not be a plus 
either.)

 5. It seems that ODF Toolkit is in a maintenance mode that does not lead to 
releases.  That is evidently adequate for the current community.  Since July 
2014 all commits have been by two developers and since December 2014 only one 
of them.  Many of the recent commits are application of patches provided by 
others on the Apache JIRA ODFTOOLKIT project, and working via JIRA seems to go 
well.  In a brief exploration, I did not find any thrust toward expansion of 
ODF feature coverage.

MORE BACKGROUND

The ODF Toolkit came to the ASF after the Oracle licensing of OpenOffice.org to 
the ASF and the creation of the Apache OpenOffice podling.

The ODF Toolkit is essentially a pure Java project (not a bad thing) and always 
had a small development community when it existed outside of Apache.  It was 
convenient that the original ODF Toolkit project, sponsored by Oracle and IBM 
(whose copyright notices appear on files), was already licensed under ALv2.

The ODF Toolkit shares with Apache POI the provision of APIs and low-level 
functions, in this case for manipulation of ODF-format documents.  The ODF 
Toolkit does not deal with GUI or other types of user-facing functionality.  It 
is mainly a stack for developer usage in ODF processing tools and utilities.

The ODF Validator component of the project is user-operable when deployed.  I 
do not know the state of coverage of the ODF 1.2 format or the quality of 
semantic validation beyond the schema level.  I do not know the extent to which 
the profiles of ODF support by products like Microsoft Office and Apache 
OpenOffice are recognized.  (That also applies with respect to feature coverage 
of the ODF Toolkit generally.)

The ODF Toolkit is very different from SDK provided in Apache OpenOffice 
releases.  The AOO SDK provides APIs into running instances of Apache 
OpenOffice and supports such things as headless operation, injection of 
extensions, etc.  The ODF Toolkit is free-standing and lacks the complexity of 
the AOO SDK and the tight dependency on a full Apache OpenOffice instance.  
This is not a bad thing.  

There are also utility functions within the Apache OpenOffice code base and SDK 
that are usable apart from AOO.  These are the AOO UNO tools, unique to AOO, 
along with additional source to make them operable independently with reliance 
on the AOO UNO library alone.  The ODF Toolkit does not depend on UNO at all, 
providing greater fit into a Java-centric effort.




> -Original Message-
> From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby
> Sent: Monday, March 28, 2016 05:48
> To: general@incubator.apache.org
> Subject: Re: 54 podlings - too many?
> 
> On Mon, Mar 28, 2016 at 8:37 AM, Harbs  wrote:
> > What about recommending that it be adopted by OpenOffice?
> >
> > IIUC, ODF Toolkit predates OpenOffice becoming an Apache Project. It
> seems (to an outsider like me) like the OpenOffice community would be a
> good home for a related toolkit.
> 
> It was proposed as a separate project from the beginning by a member
> of the Open Office community.
> 
> - Sam Ruby
> 
> > Harbs
> >
> > On Mar 28, 2016, at 2:33 PM, Sam Ruby  wrote:
> >
> >> On Mon, Mar 28, 2016 at 6:44 AM, John D. Ament
>  wrote:
> >>> Both great ideas.  Thanksfully, 

RE: Copyright sign offs

[Dennis E. Hamilton]

> -Original Message-
> From: Henri Yandell [mailto:bay...@apache.org]
> Sent: Monday, February 29, 2016 18:43
> To: general@incubator.apache.org
> Cc: Dennis Hamilton <dennis.hamil...@acm.org>
> Subject: Re: Copyright sign offs
> 
> Is 'it was already under Apache 2.0' typically taken to cover:
> 
>   "Check and make sure that the papers that transfer rights to the ASF
> been
> received. It is only necessary to transfer rights for the package, the
> core
> code, and any new code produced by the project."
> 
> ?
[orcmid] 

No, I don't take it to cover that.  I think it is more like speaking of 
third-party code that bears ALv2 license notices already.

[Also "rights" and "transfer" are rather vague and potentially over-broad.  I 
have no interest in haggling about that.  All I am suggesting is that the 
original files do not appear to be transposed to having the form of notice 
preferred by the ASF.  Having not been on the PPMC, I have no idea what grants 
were received in any form.] 

> 
> Hen
> 
> 
> 
> On Mon, Feb 29, 2016 at 4:17 PM, John D. Ament <johndam...@apache.org>
> wrote:
> 
> > Dennis,
> >
> > For some reason, Oliver Rau added you in this commit
> >
> >
> https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/od
> ftoolkit.xml?r1=1296007=1531246
> > If you don't belong, you should be able to remove yourself.
> >
> > John
> >
> > On Mon, Feb 29, 2016 at 6:30 PM Dennis E. Hamilton <
> > dennis.hamil...@acm.org>
> > wrote:
> >
> > > Henri,
> > >
> > > I did a quick look at the odftoolkit repository and the podling
> page.
> > >
> > > The odftoolkit project was originally under ALv2.  The code still
> carries
> > > Copyright notices on the individual files and the ALv2 license
> statement
> > > has not been updated/replaced by the current one mentioning
> contribution
> > to
> > > the ASF, etc.
> > >
> > > In passing, I notice a peculiarity of the incubator page,
> > > <http://incubator.apache.org/projects/odftoolkit.html>.  I'm certain
> I
> > > was never on the PPMC and I don't think I was a committer either,
> unless
> > it
> > > is transitive via incubator (a change since 2012?).  My impression
> was
> > that
> > > the PPMC was rather small.  I have no idea what its current
> membership
> > is.
> > >
> > > There has been recent maintenance on the source code, some working
> > against
> > > JIRA issues, as reported in the February 2016 Incubator Report.
> > >
> > >  - Dennis
> > >
> > >
> > > > -Original Message-
> > > > From: Henri Yandell [mailto:bay...@apache.org]
> > > > Sent: Friday, February 26, 2016 17:28
> > > > To: general@incubator.apache.org
> > > > Subject: Copyright sign offs
> > > >
> > > > Haven't done this in a while :)
> > > >
> > > > Thought I'd share that the following podlings have not yet signed
> off
> > on
> > > > their Copyright sections in their status reports. I mention this
> > because
> > > > I
> > > > believe it's one of the first elements that should be signed off
> on the
> > > > status report and it's a worry if projects have not done so:
> > > >
> > > >   cmda
> > > >   datafu
> > > >   horn
> > > >   johnzon
> > > >   odftoolkit
> > > [ ... ]
> > > >
> > > > I'd be interested to hear about any reasons why the above aren't
> able
> > to
> > > > sign that element of their status file off.
> > > [ ... ]
> > >
> > >
> > > 
> -
> > > 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: Copyright sign offs

[Dennis E. Hamilton]

Henri,

I did a quick look at the odftoolkit repository and the podling page.

The odftoolkit project was originally under ALv2.  The code still carries 
Copyright notices on the individual files and the ALv2 license statement has 
not been updated/replaced by the current one mentioning contribution to the 
ASF, etc.

In passing, I notice a peculiarity of the incubator page, 
.  I'm certain I was 
never on the PPMC and I don't think I was a committer either, unless it is 
transitive via incubator (a change since 2012?).  My impression was that the 
PPMC was rather small.  I have no idea what its current membership is.

There has been recent maintenance on the source code, some working against JIRA 
issues, as reported in the February 2016 Incubator Report.

 - Dennis

 
> -Original Message-
> From: Henri Yandell [mailto:bay...@apache.org]
> Sent: Friday, February 26, 2016 17:28
> To: general@incubator.apache.org
> Subject: Copyright sign offs
> 
> Haven't done this in a while :)
> 
> Thought I'd share that the following podlings have not yet signed off on
> their Copyright sections in their status reports. I mention this because
> I
> believe it's one of the first elements that should be signed off on the
> status report and it's a worry if projects have not done so:
> 
>   cmda
>   datafu
>   horn
>   johnzon
>   odftoolkit
[ ... ]
> 
> I'd be interested to hear about any reasons why the above aren't able to
> sign that element of their status file off.
[ ... ]


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

RE: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)

[Dennis E. Hamilton]

Not to put too much of a fine point on it, but that license provision strikes 
me as only half of the deal in the case of a submission to an ASF Project.  The 
other key aspect has to do with the explicit assertion by the pull-requester 
that they have the right to make the contribution, which is to say that the 
commit contents not already in the code base are the original (in Copyright 
sense) work of the submitter and not constrained by a condition of employment, 
etc.  Considering that there are varying degrees of understanding and 
casualness around this in the world of software developers, additional ceremony 
(whether involving a CLA or not) seems valuable as part of the ASF preservation 
of IP provenance by having the contributor be mindful of the assurance they are 
explicitly claiming in making a contribution. 

More complicated is staging for a committer to vet the contribution and 
determine whether and how to accept it, preserve history, etc.  (There is a 
great Google Talk by Linus on how that is organized for the Linux kernel, with 
a hierarchy of lieutenants.)  That is also a factor around pull requests, 
although I don't think it came up at Corinthia.  I believe ASF approaches for 
this situation, along with the preservation of history back to the contributor, 
have only recently (post-Corinthia) been worked up; I haven't followed the 
details, being on an SVN-harbored project.

For Git-harbored ASF projects (as the Corinthia podling was), the ability for 
committers to simply synchronize a clone is very nice and straightforward under 
a CTR regime.  

 - Dennis

PS: I think I created confusion about accepting DIFs (patches) versus pull 
requests myself, in a dev@ message very early in the setup for Corinthia 
(December 2014).  That aside on a larger topic was never discussed though.  I 
don't think there was ever a non-committer pull-request to deal with.  Later, 
there was a time when one contributor's submissions became substantial enough 
to request an iCLA, and that contributor was invited to become a committer+PPMC 
almost concurrently.  I think that happened every time and I don't recall 
complaint on those occasions.  There was expressed concern that ceremonial 
requirements, process, etc., would discourage participation and that is where 
ideas about community may have collided.

> -Original Message-
> From: Rob Vesse [mailto:rve...@dotnetrdf.org]
> Sent: Monday, January 18, 2016 01:30
> To: general@incubator.apache.org
> Subject: Re: Post mortem request for the handling of the Corinthia
> podling (was Re: FYI, I have subscribed to this list and to your private
> list)
> 
> Just wanted to reply to one specific point:
> 
> On 15/01/2016 14:55, "Peter Kelly"  wrote:
> 
> >I felt were unreasonable - the inability to accept pull requests from
> >anyone without first asking them to sign a CLA
> 
> Who in particular told you this?  I occasionally see communities
> operating
> under this misguided assumption and it frustrates me and I try and
> correct
> it whenever I see this
> 
> The Apache License contains Clause 5 (Submission of Contributions) which
> says the following:
> 
> "Unless You explicitly state otherwise, any Contribution intentionally
> submitted for inclusion in the Work by You to the Licensor shall be
> under
> the terms and conditions of this License, without any additional terms
> or
> conditions. Notwithstanding the above, nothing herein shall supersede or
> modify the terms of any separate license agreement you may have executed
> with Licensor regarding such Contributions."
> 
> 
> So basically anything anyone that intentionally submits something to
> your
> project for inclusion (and it's pretty clear that a pull request is an
> intentional submission) then it is fair game for inclusion in an Apache
> Licensed project without the need for any separate agreement.
> 
> Now for large contributions (where large is arbitrarily defined by the
> accepting community) there may be a desire to always get a CLA but it is
> a
> fallacy to say that a ICLA is always required.
> 
> As a corollary if someone is making large contributions they should be a
> candidate for committer and/or PMC status and if they were to be granted
> committer status then the ASF requires they have a ICLA on file
> 
> Rob
> 
> 
> 
> 
> 
> -
> 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: Post mortem request for the handling of the Corinthia podling (was Re: FYI, I have subscribed to this list and to your private list)

[Dennis E. Hamilton]

I have declined to participate in any post-mortem activity.  

There are some relevant matters to clarify in the bringing of this thread to 
general@ incubator.a.o, however.

Comments in-line.

> -Original Message-
> From: Alex Harui [mailto:aha...@adobe.com]
> Sent: Friday, January 15, 2016 09:32
> To: general@incubator.apache.org; d...@corinthia.incubator.apache.org
> Subject: Re: Post mortem request for the handling of the Corinthia
> podling (was Re: FYI, I have subscribed to this list and to your private
> list)
> 
> Probably too late, but some comments in-line.
[ ... ]
> It appears that Qt is no longer under LGPL and now just GPL? [1]  That
> could limit the number of commercial users which is one reason why the
> ASF
> has the CategoryX restriction.
[orcmid] 

Not exactly.  What has been removed is LGPL 2.1.  LGPL3 remains an option, 
along with GPL2, GPL3, and a separate commercial license.

> 
[ ... ]
> I don't know how Qt is packaged, but AIUI, the CategoryX restriction
> does
> not apply to build tools and runtimes.  But whether you package it or
> download it, if using it places restrictions on your customers than
> that's
> a problem.
> 
[orcmid] 

There was a contortion of the optional dependency case for ASF releases.  The 
proposed workaround was to make optional *substitutability* for the Qt 
dependency.  But no substitute with equivalent functionality was proposed or on 
offer.

A concern posted on the dev@ list gave cautionary warning the project might hit 
a wall with regard to this reversal of how optional dependency becomes 
acceptable, i.e. .

Inability to use Qt as the core framework for portable GUI clients became a 
technical deal-breaker for the podling, as Peter Kelly has already reported.


[ ... ]
> 
> [1]
> http://www.qt.io/qt-news/qt-open-source-licensing-changed-product-structure-updated-strengthen-community-extend-adoption/



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

RE: Help for the Log4cxx podling

[Dennis E. Hamilton]

[not cross-posting]

If there is a read-only GitHub mirror of the in-attic SVN repository subtree, 
will that provide enough history for you?

Or would you actually require a (compressed) dump of the read-only SVN 
repository subtree (not the entire ASF subversion), assuming Apache Infra could 
provide that without creating any unacceptable SVN lock-out duration?

[I am operating on the assumption that the repository in the attic has the 
entire history of the project's repository tree at the time of movement to the 
attic.  It is simply read-only forever.]

 - Dennis


[ ... ]
> And that's fine, but that doesn't necessary mean that you need to "lock
> away" the history. But I may completely wrong and it wouldn't be
> allowed to even fork a dead Apache log4cxx on GitHub to keep working
> on it with the history, even privately?
> 
> Mit freundlichen Grüßen,
> 
> Thorsten Schöning
[ ... ]


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

RE: Help for the Log4cxx podling

[Dennis E. Hamilton]

Aside to John:

No particular reason other than I find it confusing whether I am subscribed to 
both lists or not.

I just wanted to understand the technical objection.  Greg's response settled 
the only concern I could see.

 - Dennis

> -Original Message-
> From: John D. Ament [mailto:johndam...@apache.org]
> Sent: Friday, January 8, 2016 17:14
> To: general@incubator.apache.org; dennis.hamil...@acm.org;
> tschoen...@am-soft.de
> Subject: Re: Help for the Log4cxx podling
> 
> On Fri, Jan 8, 2016 at 6:06 PM Dennis E. Hamilton
> <dennis.hamil...@acm.org>
> wrote:
> 
> > [not cross-posting]
> >
> 
> Just curious - but why? The hope is to collaborate between the two
> groups
> to get a consensus.
> 
> 
> >
> > If there is a read-only GitHub mirror of the in-attic SVN repository
> > subtree, will that provide enough history for you?
> >
> > Or would you actually require a (compressed) dump of the read-only SVN
> > repository subtree (not the entire ASF subversion), assuming Apache
> Infra
> > could provide that without creating any unacceptable SVN lock-out
> duration?
> >
> > [I am operating on the assumption that the repository in the attic has
> the
> > entire history of the project's repository tree at the time of
> movement to
> > the attic.  It is simply read-only forever.]
> >
> >  - Dennis
> >
> >
> > [ ... ]
> > > And that's fine, but that doesn't necessary mean that you need to
> "lock
> > > away" the history. But I may completely wrong and it wouldn't be
> > > allowed to even fork a dead Apache log4cxx on GitHub to keep working
> > > on it with the history, even privately?
> > >
> > > Mit freundlichen Grüßen,
> > >
> > > Thorsten Schöning
> > [ ... ]
> >
> >
> > -
> > 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: Help for the Log4cxx podling

[Dennis E. Hamilton]

[Not cross-posted]

This is not about the governance issues raised in the discussion.

Technically, I do not understand what is difficult about creating working 
copies of a project's portion of the ASF SVN repository.  It is done all of the 
time, for presumably much larger projects.  If you mean a full backup with all 
history, that is a different matter.  An attic SVN would still have all of that 
though.

In any case, projects now have the option of creating a read-only Git mirror of 
their SVN, and there are a number of those hosted on GitHub, cloned, forked, 
etc.  That could clearly be done for a project with its SVN in the attic.  (I 
have no idea whether the history is as complete as what abides in the SVN.)  
These are not Gits of the entire ASF repo.  The Git mirror has just the 
project's slice.

What is not part of the current use of Git mirrors (whether on an ASF SVN or 
Git) is a way to accept Git push requests at the mirror in a manner that 
sustains ASF requirements for provenance and auditability of contributions, 
with assurance that IP matters are dealt with in accord with policy.  My 
impression is that there is work underway to address that.  However, this 
relates to ASF project governance policies and practices and that may not be 
helpful in how log4xx might be sustained.  It would not apply to a project in 
the attic regardless.  


> -Original Message-
> From: Thorsten Schöning [mailto:tschoen...@am-soft.de]
> Sent: Friday, January 8, 2016 08:20
> To: general@incubator.apache.org
> Cc: log4cxx-...@logging.apache.org
> Subject: Re: Help for the Log4cxx podling
> 
[ ... ]
> The problem and difference to GitHub I see now with the Attic is, that
> you have a huge, centralized SVN repo, which is very hard to clone for
> interested persons like me for technically reasons. When I tried some
> years ago, you actively blocked me just because I fetched revisions a
> week or so... :-) So if you decide that the project is dead, with the
> same decision you might prevent people access to the very valuable
> history of the project simply for practical reasons, because we are
> not allowed to clone it 2 weeks or the amount of data is just to huge
> with all those empty revisions or whatever.
> 
> If the project is additionally hosted on GitHub and not only in Attic,
> it would be simpler for still interested people to fork and make use
> of it. I see that as somewhat special to Apache's Attic concept, and
> maybe even the use of SVN, though I like SVN a lot: To me it looks
> like that hosting all Attic projects on a platform enabling easier
> forking of the entire project history would be a great idea.
[ ... ]


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

RE: RTC vs CTR (was: Concerning Sentry...)

[Dennis E. Hamilton]

> -Original Message-
> From: r...@databricks.com [mailto:r...@databricks.com] On Behalf Of
> Reynold Xin
> Sent: Sunday, November 22, 2015 22:33
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
[ ... ]
[orcmid] 
> Committers are required to use JIRA, github, and follow many other
> processes that "drive-by" should follow. I don't see why "code review"
> is
> different from filing JIRA tickets. In most RTC projects, committers do
> have more rights -- a committer can review somebody else's patch and
> commit
> it.
[ ... ]
[orcmid] 
Caught my eye.  

In the one place where I see RTC, when it is a committer who proposes RTC, it 
is that committer who will ultimately make any commit.  

Admittedly, this is in a case where C[TR] is available.  

Even on a project where RTC is the norm, why would not the original committer 
be allowed to commit, based on whatever adjustments review requires?  (I am not 
equating this with lazy consensus, although that might be an individual case.)

A formal RTC arrangement as I see described strikes me as similar to situations 
where (senior) professional engineers are responsible for reviewing and 
approving the work of others.  I can understand the commitment to quality and 
accountability that represents, along with the premiums for malpractice 
insurance that go with it.  (I assume that pair-programming is not so formal 
and the original committer is as likely to do the commit as the buddy.)

I can see the code being produced being under an open-source license too. I am 
failing to grasp how formal RTC can fit with the ASF drive for flat, 
non-authoritarian structures, though.  I suppose I don't have to understand it, 
it being unlikely that I would ever be involved in such an arrangement at the 
ASF.


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

RE: Incubator mail archives lagging badly

[Dennis E. Hamilton]

I see 253 messages from incubator-geode for November, with the last dated today.

I followed the below-supplied URL, switched to date view, and then went to the 
last available page (3 in this case).

Is this not reproducible?

 - Dennis

> -Original Message-
> From: Gregory Chase [mailto:gch...@pivotal.io]
> Sent: Wednesday, November 18, 2015 11:02
> To: general@incubator.apache.org
> Subject: Re: Incubator mail archives lagging badly
> 
> http://mail-archives.apache.org/mod_mbox/incubator-geode-
> dev/201511.mbox/browser
> 
> As one example.
[ ... ]


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

RE: RTC vs CTR (was: Concerning Sentry...)

[Dennis E. Hamilton]

+1

Although an individual taking the RTC route is a bit different than there being 
a local policy that requires it.  This has been addressed subsequently on this 
thread, but I am struck by Bertrand's simple statement.  It inspired a 
different way of looking at RTC vs CTR.  

It is a community strength, and even related to having committer karma at all, 
that folks are considered trustworthy to make changes (C[TR]) in repositories 
where they are competent and careful, and that they are trusted to know the 
difference where RTC is called for when they are not so confident and consider 
determination/review as a way of avoiding unintended consequences.  

There is also the safeguard that review is always possible and, indeed, we are 
presumably talking about the one place where vetos count.

That does not mean mistakes do not happen, that no one is ever hasty, 
bull-headed, etc., etc.  We're all human and these projects are human 
enterprises.  The idea is that mutual trust based on a shared commitment 
prevails as a guiding force through the hurly-burly of all that.  And out of 
that, a trustworthy (not some abstractly perfect) outcome is achieved.  By 
trustworthy, to be clear, I mean that the result shows care for the ultimate 
recipients of the work and when there are breakdowns, they are resolved in a 
manner that demonstrates that care.

It seems then, that having some sort of blanket policy one way or the other is 
about some magical view of a perfection where there is none to be found, only 
folks stumbling along doing their best.  We want to honor that, and the guiding 
principle is that community is where it arises.

 - Dennis 

PS: From another context, but one that might be useful here: To be trustworthy, 
one must first be willing to trust.  (From this, you could surmise why I 
personally find ALv2 preferable to GPL in the work that I do and why I find 
ASF's approach to serving the public good so harmonious.)

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Monday, November 16, 2015 23:53
> To: Incubator General 
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
> 
> On Tue, Nov 17, 2015 at 5:25 AM, Ted Dunning 
> wrote:
> > ...RTC can be framed as "I don't trust you to do things right"...
> 
> Or also "I don't trust myself 100% to do things right here and would
> like systematic reviews of my commits".
> 
> Like all sharp tools I think RTC has its place, but shouldn't be
> abused. It's perfectly possible to have some parts of a project's code
> under RTC and others under CTR.
> 
> -Bertrand
> 
> -
> 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: Concerning Sentry: A disagreement over the Apache Way and graduation

[Dennis E. Hamilton]

I think the Maturity Model, relied on as some guidelines for assessing a 
project, needs to be applied for that purpose in terms of identifying the 
striving-fors.  Is there evidence that particular areas are being strived for.  
Is there evidence of an anti-pattern.  How do these net out in the considered 
judgment of the person making that assessment, what facts are indicators, 
warning-signs, etc.  

It is my understanding that this is not a pure pass/fail thing.  A graduation 
could be accompanied by a charge to develop/diminish/whatever in the activities 
of the newly-established PMC and having that accounted for.

Isn't this an always "on balance" determination, where in some cases, 
demonstration of remedy is required before graduation and other times not?  
(With some items being show-stoppers, I suppose, such as careless handling of 
IP clearance.)

 - Dennis



> -Original Message-
> From: justin.erenkra...@gmail.com [mailto:justin.erenkra...@gmail.com]
> On Behalf Of Justin Erenkrantz
> Sent: Sunday, November 15, 2015 07:14
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> On Saturday, November 14, 2015, Rich Bowen  wrote:
> 
> > No. I can use whatever criteria I like to justify my vote on a
> podlings
> > graduation, if it's in line with asf philosophy. This document is,
> and
> > accurately reflects the criteria I use when voting on a graduation.
> That
> > is, the document reflects me, not vice versa, as I said above.
> >
> > It's very akin to the docs that circulate around member election time.
> They
> > are useful guidelines but nobody is compelled to adhere to any
> particular
> > one of them.
> >
> 
> The difference is that member elections are majority-based - graduation
> votes are essentially subject to veto.
> 
> There's a huge difference there.  If you are subjecting all of your
> votes
> to that checklist and will actively block podlings that do not meet your
> personal guidelines, you are making everyone else subject to it.  --
> justin


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

RE: Concerning Sentry: A disagreement over the Apache Way and graduation

[Dennis E. Hamilton]

> -Original Message-
> From: Branko Čibej [mailto:br...@apache.org]
> Sent: Saturday, November 7, 2015 09:29
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> On 03.11.2015 09:48, Bertrand Delacretaz wrote:
[ ... ]
> > Based on the information provided in this thread It looks to me like
> > Sentry isn't operating according to items CO20, CO40, CS20 and CS50 of
> > our maturity model [1].
> 

[ ... ]
> Can we please stop calling someone's pet paperwork "our maturity model?"
> I'm fed up to the gills with the assumption that it has any relevance
> for anything or anyone in the foundation, including the Incubator and
> Podlings.
> 
> -- Brane

[orcmid] 

Huh?  The development of this document, 



was carried out on the dev community list over a significant period of time.  
It even provides an account for that development and where related materials 
can be found.  It is a work in progress, as is the ASF itself.  As far as I can 
tell, being a tender-foot in these parts, this is a distillation of a great 
deal of thinking and consideration based on serious consideration by 
contributors with substantial experience.  

I find the dismissing of that effort to be very peculiar as part of a 
discussion about The Apache Way.

It is easy to find evidence that this is relevant to several someones in the 
foundation, including in the Incubator and Podlings.  Apparently, some other 
someones have not been paying attention or simply haven't taken it seriously.  
That happens.

I do agree that a list of codes without any context is probably not a very 
gentle application of it as part of an assessment of a podling's readiness to 
graduate.  

> 
> 
> -
> 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: Concerning Sentry: A disagreement over the Apache Way and graduation

[Dennis E. Hamilton]

If the mentor brought the considerations to a podling for them to reconcile
and record, that would be great.  If that were guidance to mentors, that
would be great also.

What concerns me is that podlings of newly-arrived initial committers may
tend to see whatever the practice that is suggested to them as being gospel
and this is carried from one PPMC to another.

I have seen too much customization too early and there is then not even some
sort of common practice that can be used even as training wheels.  It is
like trying to improvise jazz when you take your first instrument out of the
box.  

Bothers me.  YMMV [;<).

> -Original Message-
> From: Ross Gardler [mailto:ross.gard...@microsoft.com]
> Sent: Saturday, November 7, 2015 12:58
> To: general@incubator.apache.org; dennis.hamil...@acm.org
> Subject: RE: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> There should be no recommendation for podlings. Mentors should guide the
> podling to making the right decision for their community by discussing
> the pros and cons of each model.
> 
> The idea of a mentor bringing their preference, or worse the IPMC having
> a "default" is problematic.
> 
> Sent from my Windows Phone
> 
> From: Dennis E. Hamilton<mailto:dennis.hamil...@acm.org>
> Sent: ‎11/‎6/‎2015 9:35 AM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: RE: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> I think there is a difference between what TLPs do and what the
> recommended approach for Podlings is.
> 
> My impression, based on limited podling experience, is that the default
> tends to be PPMC == committer.
> 
> Thanks for raising the notion of looking at why committers are *not*
> moved to the PMC of a TLP after some period of time, though.  My
> question, as a PMC member, would be whether or not we are holding the
> reins too tight at the expense of both community and sustainability.  An
> useful danger sign, that.
> 
>  - Dennis
> 
> > -Original Message-
> > From: Greg Reddin [mailto:gred...@gmail.com]
> > Sent: Friday, November 6, 2015 06:22
> > To: general@incubator.apache.org
> > Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> > graduation
> >
> > On Fri, Nov 6, 2015 at 7:58 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
> > > On 11/05/2015 12:02 AM, Joe Schaefer wrote:
> > >> Committership is the right to do work on the project. PMC
> membership
> > is the
> > >> right to participate in governance.  People left in the nebulous
> > state
> > >> between
> > >> committership and PMC membership for long periods of time more than
> > likely
> > >> will give up in frustration for not being trusted enough to govern
> > their
> > >> own work.
> > >
> > >
> > > Most of the older projects at the Foundation do not have PMC ==
> > > Committer. Notably, httpd. The notion that committers are
> > automatically
> > > PMC is a fairly new innovation. As it happens, it's an innovation
> that
> > I
> > > wholeheartedly support and recommend, but it's a minority of
> projects
> > > that have this policy. If you follow board reports, you'll notice
> that
> > > PMC additions and Committer additions are seldom coincident.
> >
> > In further support of Joe's point, for most of the projects I've been
> > involved with, the PMC promotion was almost automatic and occurred
> > within about 6 months of committership. The committer-only period was
> > just a probationary period to make sure a person was not going to
> > abuse his/her privileges. An invite to committership comes with an
> > unspoken assumption that we want you to help govern the project, but
> > let's start with giving you access. I don't know that I ever saw
> > anyone stay as committer-only for an extended period of time.
> >
> > Greg
> >
> > -
> > 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: Concerning Sentry: A disagreement over the Apache Way and graduation

[Dennis E. Hamilton]

I think there is a difference between what TLPs do and what the recommended 
approach for Podlings is.

My impression, based on limited podling experience, is that the default tends 
to be PPMC == committer.

Thanks for raising the notion of looking at why committers are *not* moved to 
the PMC of a TLP after some period of time, though.  My question, as a PMC 
member, would be whether or not we are holding the reins too tight at the 
expense of both community and sustainability.  An useful danger sign, that.

 - Dennis

> -Original Message-
> From: Greg Reddin [mailto:gred...@gmail.com]
> Sent: Friday, November 6, 2015 06:22
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
> On Fri, Nov 6, 2015 at 7:58 AM, Rich Bowen  wrote:
> > On 11/05/2015 12:02 AM, Joe Schaefer wrote:
> >> Committership is the right to do work on the project. PMC membership
> is the
> >> right to participate in governance.  People left in the nebulous
> state
> >> between
> >> committership and PMC membership for long periods of time more than
> likely
> >> will give up in frustration for not being trusted enough to govern
> their
> >> own work.
> >
> >
> > Most of the older projects at the Foundation do not have PMC ==
> > Committer. Notably, httpd. The notion that committers are
> automatically
> > PMC is a fairly new innovation. As it happens, it's an innovation that
> I
> > wholeheartedly support and recommend, but it's a minority of projects
> > that have this policy. If you follow board reports, you'll notice that
> > PMC additions and Committer additions are seldom coincident.
> 
> In further support of Joe's point, for most of the projects I've been
> involved with, the PMC promotion was almost automatic and occurred
> within about 6 months of committership. The committer-only period was
> just a probationary period to make sure a person was not going to
> abuse his/her privileges. An invite to committership comes with an
> unspoken assumption that we want you to help govern the project, but
> let's start with giving you access. I don't know that I ever saw
> anyone stay as committer-only for an extended period of time.
> 
> Greg
> 
> -
> 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: Concerning Sentry: A disagreement over the Apache Way and graduation

[Dennis E. Hamilton]

For me, the key, nay brilliant, terms in the Maturity Model are about 
"striving."  

The question is always, is there demonstrable striving toward the elements 
identified in the maturity model.

If that's not apparent, then one has to wonder, whatever the level of 
achievement, whether that's what one expects to see in an Apache Project, 
whatever its tenure.  It's about the journey the Project (or Podling) is on, 
not a fixed destination.

 - Dennis

> -Original Message-
> From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of
> Roman Shaposhnik
> Sent: Wednesday, November 4, 2015 09:50
> To: general@incubator.apache.org
> Subject: Re: Concerning Sentry: A disagreement over the Apache Way and
> graduation
> 
[ ... ]

> Think of it as when you are asking somebody to review your code. If you
> don't make it easy for reviewers -- don't expect them to bend over
> backwards
> to make sense out of what you submitted. Doesn't mean you'll get a -1,
> but
> don't expect a quick +1 either. Same deal with a maturity model: when
> the time
> comes for a graduation vote, if you make it easy(er) for "reviewers"
> to start forming
> an opinion on whether the community is ready or not -- you will spend
> less time arguing.
> 
> Personally I find maturity model template to be just that kind of a tool
> for me.
> 
> On the flip side -- not filling it out is not a blocker. It just
> means, for example,
> that *I* personally will have very little incentive to dig into the guts
> of a
> community I don't know well to really find out all the same details that
> mentors
> or community members could have communicated to me filling out the
> maturity model template.
> 
> Thanks,
> Roman.
> 
> -
> 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: Starting from the other end

[Dennis E. Hamilton]

+1 from me too.

I did some wordsmithing but not certain how that works properly in Google Docs 
in terms of how changes are made evident for review, etc.

 - Dennis

PS: When I go back and review, I see that I needed to leave more highlights or 
comments to indicate places where I made adjustments.  (Maybe a wiki would be 
better, so there is a modification history?)

> -Original Message-
> From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
> Sent: Monday, October 19, 2015 01:29
> To: Incubator General 
> Subject: Re: Starting from the other end
> 
> Hi,
> 
> On Thu, Oct 15, 2015 at 8:55 PM, Ted Dunning 
> wrote:
> > ...The first step (What Apache Incubator Does) can be edited at
> >
> https://docs.google.com/document/d/1dxUVHGWcj83wIVnskYL7iM7PiiScLLNS4HjG
> Ha6LsgA/edit?usp=sharing ...
> 
> I like that.
> 
> Combined with a set of commented links that point to good examples of
> the various phases and transitions (proposal, acceptance, etc.) I
> think this could replace a large part of the Incubator documentation.
> 
> I don't have any specific changes to request at this point, I think
> the current draft is good enough to move to our wiki or website.
> 
> -Bertrand
> 
> -
> 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: structural reform- division of labor

[Dennis E. Hamilton]

+1

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Thursday, October 15, 2015 00:39
To: Incubator General ; Joe Schaefer 

Subject: Re: structural reform- division of labor

On Thu, Oct 15, 2015 at 5:05 AM, Joe Schaefer
 wrote:
> ...Formally, that's all a working group needs to be- yet another mailing 
> list

I'm not in favor of more mailing lists, I think [tags] in subject
lines can pretty much do the same thing without splitting the
community (as per Stefano Mazzocchi's busy lists pattern [1]).

So maybe just define a set of such tags like [graduation], [proposal]
[release] etc. but stay here.

-Bertrand

[1] http://grep.codeconsult.ch/2011/12/06/stefanos-mazzocchis-busy-list-pattern/

-
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: Permissive UI Libraries

[Dennis E. Hamilton]

An after-thought.

These days, a critical provision of GUI support involves adaptability for form 
factors and methods of interaction (e.g., tablets, touch, and audio controls) 
as well as provisions for internationalization and assistive technologies 
including text to speech, audio context and position announcement, speech to 
text and speech control as well as interoperability and customization with 
assistive technologies.

That would be very important in a roadmap for permissively-licensed UI 
frameworks/libraries and a powerful contribution in the context of public good.

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Tuesday, September 8, 2015 08:12
To: general@incubator.apache.org
Subject: Permissive UI Libraries (was RE: [NOTICE] corinthia ...)

Designing a cross-platform UI library is not a trivial task and I am certain 
the false starts far outnumber the few notable successes.

Although the idea does make my heart pound, that also reminds me I may not have 
the youthful vigor and developer chops that would make such an undertaking 
realistic on my part.  On the other hand, being in on one from the beginning 
would be an exciting experience.

There is also a cautionary issue.  When it comes to lean development and a 
startup project, the obvious teething approach is via HTML5 and the JavaScript 
route.  Maybe client-side is under node.js, etc.

At some point there is a moment of truth that suggests models can be handled 
well in portable code, but views and their controllers tend to be best adjusted 
to the platform and context of use, not just for performance but to satisfy 
scaling and lifecyle concerns on the platform and always confirming what users 
already know in their comfort zone.  

So, even with a common, permissive view, there must be a way to rely on 
platform resources in a manner that provides UX familiarity and critical GUI 
performance.

'Lo and Behold!

There are permissive UI libraries, and they are part of an *Apache* project.  
And some of the work on platform adaptability has been done.  It is a major 
part of Apache OpenOffice.

There are two layers.  

 - UNO is plumbing used throughout Apache OpenOffice.  While it is 
object-oriented and C++ in the main, it is a COM-alike layer and that makes it 
amenable to extraction and reuse/interop with Java, Python, certain EcmaScript 
implementations, etc.  There is much experience with this layer.  There would 
probably need to be more work done to free this layer more (and have 
binary-compatibility with COM).

 - VCL the Visual Control Library, is designed to operate above platforms such 
as Windows and OS X using native provisions.  It also has a plug-in mechanism, 
used on *nix distributions, to map to other GUI frameworks, including GTK and 
KDE.  It is thought to be workable with Qt as well, and more/other (adapter) 
plugins are possible.  The plug-in mechanism may need to be extended for 
multi-platform employment, especially with regard to platform and GUI discovery.

Freeing these as separate libraries would be a project in itself.  I am certain 
that both UNO and VCL would morph, and it would be useful to see how well 
interface versioning could work in any such progression, preserving legacy use 
from substantial products, such as Apache OpenOffice.

It is not a short-term activity, and it would have to be grown from some small 
core and expanded through carefully-developed feature-set levels.  I think this 
could be a worthy effort.  To have tested, confirmed development for use 
outside of the current host application would be valuable in both directions.

OpenOffice is much bigger than this, even though it provides a worked, 
archetypical case.  It would be overpowering to attempt this from within the 
project along with everything else there is to deal with.  But a parallel 
effort on the side could have a synergistic outcome.

This is not high on *my* bucket list; it is not entirely off that list either.  
It is not on the "real-soon-now" list either.

I suggest this is worthy of investigation by those who are keen about GUI 
interfaces.

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Monday, September 7, 2015 02:38
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

On Sep 7, 2015 4:12 PM, "Jochen Theodorou" <blackd...@gmx.org> wrote:
>...
> I am not sure that approach is realistic. I mean, if you say it must be
optional and not required, then there must be an existing alternative. And
that alternative must be not LGPL. If there is such a toolkit, then why not
go with that right away? The project has to manage its resources well.

Exactly. Without an alternative, then you have a pile of code that doesn't
meet any user expectations.

If it can be released as a library, for downstream users to produce an
edi

RE: Permissive UI Libraries

[Dennis E. Hamilton]

And let us not forget Tk, <https://en.wikipedia.org/wiki/Tk_(software)>.

 - [;<).

-Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Tuesday, September 8, 2015 08:12
To: general@incubator.apache.org
Subject: Permissive UI Libraries (was RE: [NOTICE] corinthia ...)

[ ... ]

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Monday, September 7, 2015 02:38
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

[ ... ]
Given the UI landscape, and its licensing, I can see why Corinthia would
like to host elsewhere. One day, we'll see some permissive UI libraries

Cheers,
-g


-
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

Permissive UI Libraries (was RE: [NOTICE] corinthia ...)

[Dennis E. Hamilton]

Designing a cross-platform UI library is not a trivial task and I am certain 
the false starts far outnumber the few notable successes.

Although the idea does make my heart pound, that also reminds me I may not have 
the youthful vigor and developer chops that would make such an undertaking 
realistic on my part.  On the other hand, being in on one from the beginning 
would be an exciting experience.

There is also a cautionary issue.  When it comes to lean development and a 
startup project, the obvious teething approach is via HTML5 and the JavaScript 
route.  Maybe client-side is under node.js, etc.

At some point there is a moment of truth that suggests models can be handled 
well in portable code, but views and their controllers tend to be best adjusted 
to the platform and context of use, not just for performance but to satisfy 
scaling and lifecyle concerns on the platform and always confirming what users 
already know in their comfort zone.  

So, even with a common, permissive view, there must be a way to rely on 
platform resources in a manner that provides UX familiarity and critical GUI 
performance.

'Lo and Behold!

There are permissive UI libraries, and they are part of an *Apache* project.  
And some of the work on platform adaptability has been done.  It is a major 
part of Apache OpenOffice.

There are two layers.  

 - UNO is plumbing used throughout Apache OpenOffice.  While it is 
object-oriented and C++ in the main, it is a COM-alike layer and that makes it 
amenable to extraction and reuse/interop with Java, Python, certain EcmaScript 
implementations, etc.  There is much experience with this layer.  There would 
probably need to be more work done to free this layer more (and have 
binary-compatibility with COM).

 - VCL the Visual Control Library, is designed to operate above platforms such 
as Windows and OS X using native provisions.  It also has a plug-in mechanism, 
used on *nix distributions, to map to other GUI frameworks, including GTK and 
KDE.  It is thought to be workable with Qt as well, and more/other (adapter) 
plugins are possible.  The plug-in mechanism may need to be extended for 
multi-platform employment, especially with regard to platform and GUI discovery.

Freeing these as separate libraries would be a project in itself.  I am certain 
that both UNO and VCL would morph, and it would be useful to see how well 
interface versioning could work in any such progression, preserving legacy use 
from substantial products, such as Apache OpenOffice.

It is not a short-term activity, and it would have to be grown from some small 
core and expanded through carefully-developed feature-set levels.  I think this 
could be a worthy effort.  To have tested, confirmed development for use 
outside of the current host application would be valuable in both directions.

OpenOffice is much bigger than this, even though it provides a worked, 
archetypical case.  It would be overpowering to attempt this from within the 
project along with everything else there is to deal with.  But a parallel 
effort on the side could have a synergistic outcome.

This is not high on *my* bucket list; it is not entirely off that list either.  
It is not on the "real-soon-now" list either.

I suggest this is worthy of investigation by those who are keen about GUI 
interfaces.

 - Dennis

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Monday, September 7, 2015 02:38
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

On Sep 7, 2015 4:12 PM, "Jochen Theodorou"  wrote:
>...
> I am not sure that approach is realistic. I mean, if you say it must be
optional and not required, then there must be an existing alternative. And
that alternative must be not LGPL. If there is such a toolkit, then why not
go with that right away? The project has to manage its resources well.

Exactly. Without an alternative, then you have a pile of code that doesn't
meet any user expectations.

If it can be released as a library, for downstream users to produce an
editor, then okay. But an releasing an editor with no UI is kind of a
non-starter. :-(

Given the UI landscape, and its licensing, I can see why Corinthia would
like to host elsewhere. One day, we'll see some permissive UI libraries

Cheers,
-g


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

RE: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Dennis E. Hamilton]

I can speak to the specific case.

The desire is to adopt Qt as the best-choice, most-cross-platform GUI framework 
for Corinthia on the desktop.  The non-commercial, open-source license for Qt 
is LGPL/GPL.  See .

As I understand it, a second-thought alternative to full-up dependence on Qt is 
to make an experimental implementation that employs a wrapper API under which a 
Qt-specific integration layer is introduced.  The Qt integration layer is meant 
to be optionally replaceable by an alternative one and corresponding framework 
under the wrapper API.  The wrapper API and integration layer for any 
functionally-equivalent integration/replacement is TBD.  A cautionary concern 
was raised about the prudence of having an optional-replacement of an LGPL 
dependence rather than an optionally-employable LGPL dependence.  

No specific proposal or request for any sort of exception is at legal-discuss 
or the LEGAL JIRA.

 - Dennis

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Sunday, September 6, 2015 09:23
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

Am 06.09.2015 04:22, schrieb Dave Fisher:
[...]
> Also Apache needs a release policy for binaries that would allow the best 
> UX/UI API for the platform to be used even if it is GPL. If you have 
> subscribed to legal-discuss the last few months you know why that discussion 
> was impossible. If that can be worked out then at least it would help other 
> projects.

can you explain the case a bit? Do you link statically? What is the license?

bye blackdrag

-- 
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
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: ODF Toolkit may need help

[Dennis E. Hamilton]

Ian,

I recall prospects for some cooperation with POI back when the ODF Toolkit came 
over for incubation.  POI is also Java based and deals with Zip-carried 
document formats and maybe some conversions, at least within the Microsoft 
Office document models.

 - Dennis

-Original Message-
From: Ian C [mailto:i...@apache.org] 
Sent: Wednesday, September 2, 2015 18:52
To: general@incubator.apache.org
Subject: Re: ODF Toolkit may need help

Hi All,

I wrote the last none mentor signed off report for the ODF Toolit.

It has been, is, very quiet, but I believe there are a number of users
out there.
I'm not sure on the numbers or the details. It would be a shame to
alienate them.
Whatever we do let's try to make sure they understand what is happening.

As for moving the code under the Corinthia banner (I am a committer on
Corinthia - not on ODF toolkit) whilst I think they have common ground
they are quite different beasts.
And, as Jan pointed out, based on different language technologies.

I don't know how to inject life into it. I have raised the issue a few
time with little or no response.
There are some technical things I can see that would be good to do and
a list of JIRA items to be addressed.
But we need people on board to address them.

Before moving it to the attic is there anything that can be done to
publicise the need for people and try to attract them?
I would love to see it continue.


On Wed, Sep 2, 2015 at 11:17 PM, jan i  wrote:
> On 2 September 2015 at 17:11, Louis Suárez-Potts  wrote:
>
>>
>> > On 02 Sep 15, at 10:28, toki  wrote:
>> >
>> >
>> >
>> > On 02/09/15 10:25, John D. Ament wrote:
>> >
>> >> I'd like to bring to your attention the ODF Toolkit podling.
>> >
>> > This project has been torn between going to the attic, or becoming a
>> > sub-project of another project, since at least January 2014.
>> >
>> > IMNSHO, it should go to the attic, with Apache Corinthia picking up
>> > whatever code ODF Toolkit created that it (Corinthia) can use.
>>
>> I’d agree. Far as I can tell, the only substantial difference for ODF
>> Toolkit would be that no one would have to not write non-reports nor would
>> anyone have to agonise over what has not been done.
>>
>> Plus, Corinthia could benefit by attracting more interest among those
>> interested in ODF.
>>
> As far as I can see ODF Toolkit is written in Java, so it is not that easy
> to use the code.
>
> The philosophy of ODF Toolkit also seems quite different than the
> filters/lenses of Corinthia.
>
> But of course corinthia need all the positive attention it can get.
>
> rgds
> jan i
>
>>
>> -louis
>> >
>> > jonathon
>> >
>> > -
>> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> > For additional commands, e-mail: general-h...@incubator.apache.org
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

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


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

RE: apache binary distributions

[Dennis E. Hamilton]

[Not cross-posting to a private list.]

Dave,

I don't exactly understand what it is expected that trademarks@ would be doing 
or clarifying with regard to your specific Foo Manchu case.

Please explain what you mean by a percentage.

 - Dennis

PS: How do you see a case where the Manchu project makes nothing more than 
nominative mentions of Foo and Foo is not used at all in the naming of the 
Manchu product?  Are specific instances of the use of Foo in a manner that 
would confuse Manchu with Foo what you have in mind for bringing to an Apache 
Foo PMC?

PPS: I assume we are talking about something other than how third parties use 
and attribute ALv2 licensed code one way or another.  I'm not certain how 
trademark enters there.  There is related discussion on legal-discuss, however.

-Original Message-
From: Dave Fisher [mailto:dave2w...@comcast.net] 
Sent: Friday, August 28, 2015 14:35
To: general@incubator.apache.org
Cc: tradema...@apache.org; stephen.alan.conno...@gmail.com
Subject: Re: apache binary distributions

Again mixed. Let's substitute a real case.

Sent from my iPhone

 On Aug 28, 2015, at 6:21 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 
 (Please note mixed private/public lists)
 
 On 8/25/15 5:17 PM, Stephen Connolly wrote:
[ ... ]
 
 package-name: foo
 description: The Manchu team's packaging based on Apache Foo.
  Apache Foo is a framework for doing bar.
  Apache, Apache Foo and Foo are trademarks of the Apache Software
 Foundation.

Foo = OpenOffice
Manchu = LibreOffice

This is the reality in Linuxland without the attribution. This has been going 
on for sometime. I think since prior to Oracle's grant.

Rolling that back should be a goal for the PMC.

Maybe we diff the codebases and accept a percentage. This standard might the 
encourage upstream contribution.

I would like to formulate this idea for the AOO dev list. The above has really 
helped me crystallize what I've been kicking around in my mind for months and 
months.

Thoughts before I take it there?

I know I'm not following Shane's thoughts below. OpenOffice is uniquely 
problematic.

Regards,
Dave

[ ... ]


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

RE: IP clearance template - tweak sanity check

[Dennis E. Hamilton]

The template is very handy and good to know about.

Simple observations:

A. Process section 3, first bullet, should also have and/or *an* ASF officer 
as in the second bullet.

B. Process section 5, concerning checksum and detached signature.  This has 
come up recently, so is fresh in my mind.  The format for the checksum file is 
apparently not as widely-known as one might tacitly assume.  We need a 
reference and a place for how one identifies the file, the format in the file, 
and typically how the checksum (digest) is verified.  For the detached 
signature, there needs to be a way to know how to find a proper public key to 
use.  I recommend that there be a KEY file that contains the public key(s) of 
the signer(s) with each having a UID that is an Apache ID, so there is an 
auditable tie to https://people.apache.org/keys/committer/.  I suppose this 
belongs elsewhere and could be linked from this template.

C. Filling the Form, make a snapshot of the source code is a little vague.  
This is not in an incubation area so more information is needed.  Also, is 
there a difference if Process section 5 (about checksums in grant documents) is 
not exercised or is that a good place to put the snapshot either way?

D. Verify Distribution Rights section.  The two remarks about active 
committers is strange, because of confusion with existing ASF Committers and 
non-ASF committers to the incoming code base.  This would seem to be different 
depending on whether there is a CCLA applicable to the code base or not.  Am I 
understanding this correctly?

E. Verify distribution Rights last table item. depended upon by the project 
*are* covered

F. Verify distribution Rights last paragraph.  The sentence about result of 
checking off these items seems odd.  Is it that the criteria for checking off 
these items is there being a Software Grant, ...  The for ASF licensed code 
is not needed, or maybe to the Apache Software Foundation?  The which have 
no dependencies is about the code, not the granting, yes?

I apologize for not being a doer on suggestions for this.  I trust it is 
helpful just the same.

Thanks for doing this,

 - Dennis



-Original Message-
From: Nick Burch [mailto:n...@apache.org] 
Sent: Saturday, August 22, 2015 00:53
To: general@incubator.apache.org
Subject: IP clearance template - tweak sanity check

Hi All

I hit a snag when trying to fill out the IP clearance template, in the 
Identify name recorded for software grant section, as it used to only 
refer to grants.txt. Based on advice from Craig wearing his secretary hat, 
I've updated that to handle grants given as part of a CCLA, as well as 
giving some guidance on what to write there.

The new text is now about twice as long, but hopefully clearer on how to 
fill it out. A sanity check from others would be good though!

It's at http://incubator.apache.org/ip-clearance/ip-clearance-template.html
then scroll to the Copyright section

Thanks
Nick

-
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: What is the legal basis for enforcing release policies at ASF?

[Dennis E. Hamilton]

[Failing at dealing with this cross-posted and variously-branched discussion on 
two lists, so I am doing it too.  Also OT with respect to Ross's declaration, 
but it has to do with the fact that release is not so well distinguished as 
one might hope.]

Minor nit? #1: 

Generally, because of what is seen in the repository in terms of LICENSE and 
NOTICE placement, it appears to apply to everything at and below that point in 
the repository.  A casual observer cannot tell that there is an important 
ceremonial distinction with regard to using the archived packaging of an 
approved Apache Release.

Not-so-minor nit? #2: 

Licensed to the Apache Software Foundation (ASF) 
under one or more contributor license agreements. 
See the NOTICE file **distributed** with this work
for additional information regarding copyright 
ownership.  The ASF licenses this file to you under 
the Apache License, Version 2.0 (the 'License') at 
the very top of many individual files in typical ASF 
Project repositories.

Techno-legal nit? #3: 

From http://www.apache.org/licenses/icla.txt:

You hereby grant to the Foundation and to recipients 
of software **distributed** by the Foundation a perpetual,
worldwide, non-exclusive, no-charge, royalty-free, 
irrevocable copyright license to reproduce, prepare 
derivative works of, publicly display, publicly perform, 
sublicense, and distribute Your Contributions and such 
derivative works.

 ** emphasis mine in both places

Avoiding the nit-pickers by picking more nit? #4

A while back, because I was concerned that some user of a contribution of mine 
might be trapped in a hair splitting between distribution, non-distribution, 
and released I made a supplemental declaration.  I provided a copy to the 
Secretary of the Foundation on 2013-03-08.

This broader statement grants to **all parties obtaining** any past or future 
ASF **contribution** of mine effectively the same copyright license granted 
under the iCLA without the condition that it be distributed by the Foundation.  
You can see it in all of its glory at 
http://mail-archives.apache.org/mod_mbox/openoffice-dev/201303.mbox/%3c008801ce1c21$0deb3560$29c1a020$@apache.org%3e.
  This is not the same as an ALv2 license, but it basically gives to all of 
those parties the same terms as provided to the ASF under the iCLA (technically 
not an ALv2 license either).

I have made a comparable declaration by any contribution I might make to 
LibreOffice.  I have *not* provided LibreOffice with the dual MPL-LGPL license 
declaration they tend to request. (The receipt of that declaration has not been 
acknowledged, but I stand behind it.)  

(Le sigh)

 - Dennis  



-Original Message-
From: Ross Gardler [mailto:ross.gard...@microsoft.com] 
Sent: Friday, August 21, 2015 09:14
To: general@incubator.apache.org; ComDev d...@community.apache.org
Subject: RE: What is the legal basis for enforcing release policies at ASF?

[ ... ]

Our policy is that the combined works are RELEASED under ALv2. That combined 
work is only licensed as  such when the foundation formally approves it. This 
happens when the PMC members indicate that, to the best of their knowledge, a 
specified combined work (a source package) conforms with the legal and policy 
expectations of ask source code included (both ours and upstream).

Individual contributions in our source repository are under ALv2. These are 
approved as such, through a best effort analysis, at the point of contribution. 
[ ... ]


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

RE: apache binary distributions

[Dennis E. Hamilton]

A side matter that has not been raised here.

One reason for protecting a mark is to avoid losing it.

I have worked at two corporations that were necessarily aggressive in 
protecting the use of their marks: Univac in various incarnations and Xerox 
Corporation.

While Google might be happy to see the verbing of its mark, other trademark 
holders worry about the inappropriate use of their mark by others.  This is 
related to the confusion issue but it is about the mark *becoming* generic and 
no longer protected.

The famous case of this is apparently aspirin.  I suspect the makers of 
Kleenex tissues have similar concerns but can't do much about what the general 
public does.  

There are some hyper-active approaches that we know of, especially if your 
surname is McDonald, but nevertheless there are two reasons for careful use of 
a mark and requiring others to use it carefully: protecting the distinctiveness 
and protecting against confusion.

I have no information on recent cases and how the US Patent and Trademark folk 
rule on these things nowadays.

I suspect the guidelines that go with protecting an ASF-held mark to this 
degree is over the line on the fussiness side.  At the OSCON Apache Software 
Foundation booth, I repeatedly heard that I use Apache or I love Apache and 
it is easy to confirm that they mean the Apache HTTPD software (or whatever the 
fussy designation would be).  I don't see any guidance on how Apache project 
participants should employ the marks in their writing and speaking. 

The matter of harmful confusion, as gone into at length on this thread, is of 
course a judgment call as it would be if a claim of confusion were put before a 
judge [;), and it is all grey in the wide middle.

I think an useful case here would be whether users of Joe's Maven found that 
the Apache Maven project would not accept their incident reports and there no 
other recourse, users being led to believe that the Apache Maven project is 
responsible for the code that they are using.  If that is a pattern, that seems 
like a good trigger for having a heart-to-heart with the producer of Joe's 
Maven about clearing up the confusion.

 - Dennis


-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Wednesday, August 19, 2015 06:27
To: Incubator General general@incubator.apache.org
Subject: Re: apache binary distributions

On Wed, Aug 19, 2015 at 10:46 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 ...Well I actually have concerns about the maven that debian is publishing.
 There are some quite significant - in my view - deviations from our Maven.

 For me, the majority of the concerns could be addressed if they fix the
 *Description* to clarify that it is a modified distribution of Apache Maven
 *and* they add an ACK to the trademarks in the description of the package...

I agree that this would be a reasonable request.

OTOH I'm not sure about requesting a package name change, if I'm
getting maven from a Debian package library it's reasonable to
expect that that package has been built and assembled by Debian, as
it's their core business. But that would be a question for our
trademarks folks.

-Bertrand

-
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: apache binary distributions

[Dennis E. Hamilton]

Marvin's comprehensive response is very helpful.

However, the first described case is about a third-party distribution of 
binaries, even though some or all of the third parties are participants on the 
project.  (I assume the executable was not produced by the project in a manner 
that constitutes distribution and it is not authenticated by the project, 
especially a release manager.)

Off the top of my head, the trademark policy comes into play, because these are 
not folks acting with their Apache Project hats on.  It seems that the first 
responsibility about this is for the PMC of the (hypothetical) project.

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Tuesday, August 18, 2015 09:46
To: general@incubator.apache.org
Subject: Re: apache binary distributions

On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen

 So what if a project (members) does not vote but unofficially
 releases binary executable packages, perhaps along with source to some
 other location than /dist/? Clearly, it's not an official release by Apache
 policy but there the bits are in the wild anyway.

At Apache, software that is published beyond the group that develops it must
be assembled, vetted and voted in accordance with Release Policy and
distributed in accordance with Release Distribution Policy.

  http://www.apache.org/dev/release
  http://www.apache.org/dev/release-distribution

Apache is deliberately decentralized in that technical decisions are
officially delegated to a PMC, but projects are still obligated to follow
Foundation policy with regards to project governance, IP diligence, etc.  A
primary function of the Incubator is to prepare projects to self-govern in
accordance with Apache policy and traditions.

As a last resort, policy violations eventually escalate to the Board of
Directors, which has the authority to take actions including termination of
the project.  But a healthy project self-governs and does not require Board
intervention -- individual contributors on the ground like you and me are
expected to address problems before they become severe.

 I'm asking since at least
 for many of the Java/Maven based projects it's very easy and inexpensive to
 distribute software through Maven Central. NPM also happily uses Github as
 their central repository so you could technically make lots and lots of
 convenience artifacts available without ever officially releasing
 anything.

Apache software does get (re)published to Maven Central, NPM, and any number
of other downstream distribution channels -- it just has to be released in
accordance with Apache release policy first.

Apache's release policy is deeply enmeshed with our governance institutions,
our IP controls, and the legal structure of the Foundation.  For example,
holding release votes helps ensure that small contributors are not run over
and that power is not consolidated in the hands of the few, jeopardizing
project independence.  It also helps to ensure that our projects actually make
pure open source releases, something that is really worth fighting for in this
era of privacy violations and aggressive three-letter agencies.

I've focused more on how policy is administered than the why policy is the
way it is in this email, because we're deep in a thread and this email is
long enough.  For those who are interested, I suggest reading the the Release
Policy page, as it captures some of the rationales, sometimes eloquently.

HTH,

Marvin Humphrey

-
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: apache binary distributions

[Dennis E. Hamilton]

On dev-community, you mentioned something that caught my eye.  Although it is a 
bit OT, maybe not, Roman's observation on this thread (abridged below).

Indulge me in borrowing the key bit for me:

I get so worked up when 'general public'
in our release policy gets [mis]interpreted 
as mostly related to 'end users'.
But that's a pet peeve for a different thread ;-)

I think that the general public becomes involved in multiple ways.  

First and foremost has to do with the next-in-line adopter of an Apache Project 
release.  That can be two-fold when there are convenience binaries that have 
quite different next-in-line adopters, as for Apache OpenOffice.

Although take-up of the AOO source for packaging in Linux distributions is not 
a significant factor (LibreOffice having that distribution case pretty well 
nailed down), there are next-in-line integrators and customizers.

For AOO a key consideration is that the software is for end-user purposes and 
somewhere end-users and the general public touch it massively.  And that 
software and those users come back to the project with their Bugzilla issues, 
mailing list reports, forum searches, etc.  They are certainly and clearly in 
the cycle of learning-and-improvement and their adoption of the software, 
however binaries reach them, is a big deal.  

This may be an aberration with respect to the ASF prototypical case, but it is 
not so much with respect to open-source itself.  And authenticity and 
protection of the brand/trade-mark are serious.  I suspect similar 
considerations arise for software that has end-user importance, whether for 
productivity, web browsing, social connections, or tools for media and image 
creation.  

The key point is that knowing the *variety* of next-in-line adopters is 
important, including is the ultimate end-points where usability, reliability, 
and other continuation-influencing factors feed back to the project very 
directly.  

Just sayin'

 - Dennis


-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Monday, August 17, 2015 21:11
To: general@incubator.apache.org
Subject: Re: apache binary distributions

On Sun, Aug 16, 2015 at 1:02 PM, Marvin Humphrey mar...@rectangular.com wrote:
[ ... ]
 This thread is long and bendy. What is it that you want to achieve?

Three things:
[ ... ]

3. Have Shane (as VP of Brand) and a few active PMC members
(like Stephen Connolly) express their view points on how ASF
brands are being used by downstream Linux packagers, since this
is the prototypical relationship between the Foundation and *any*
downstream.

Based on #3 I feel like I might have a few potential suggestions to clarify
our written policy, but I'd like to see the feedback first.

Thanks,
Roman.

P.S. Thanks to all who chimed in with very good feedback!

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---BeginMessage---
On Mon, Aug 17, 2015 at 8:48 AM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 8/16/15 4:25 PM, Roman Shaposhnik wrote:
 On Fri, Aug 14, 2015 at 3:59 PM, Shane Curcuru a...@shanecurcuru.org wrote:
 On 8/7/15 7:53 AM, Niclas Hedhman wrote:
 Bill,
 So I can release Niclas Hadoop platform, based on Apache Hadoop ?? I
 thought the discussion a few years ago was that this was misleading...

 No, you cannot.  See our actual trademark policy:

   https://www.apache.org/foundation/marks/faq/#products

 Our release policy, as Roman originally asked about, applies only to ASF
 projects, and has no bearing on third parties.  However our trademark
 policy, and trademark law, prevents third parties from publicly
 providing software using our trademarks.

 Our operational policies only apply to our projects, just like any other
 corporation.  Some policies, like our license itself and our formal
 trademark policy, inform the rest of the world how they are allowed to
 use our websites, software code, and brands.

 Make sense?

 It does, but our relationships with downstream Linux vendors
 (just to take the most obvious example) set a very confusing
 precedent.

 Shane, if would be super helpful if you took a look at:
http://pkgs.org/search/hadoop
http://pkgs.org/search/maven
http://pkgs.org/search/subversion
 and pubished your narrative of how the ASF branding
 policies apply in both cases.

 The 3 projects I'm picking represent a pretty diverse
 set of cases of how PMCs are conducting themselves.

 OK, that will take some time.  It would help if we can setup a call or
 get someone to writeup a description of what those pages mean from the
 larger perspective:

Understood. And perhaps this could be considered
important enough so that we start a dedicated thread.

Let me know if you'd also suggest moving to a more appropriate
mailing list.

 

[DISCUSS] [VOTE] Graduate Apache Usergrid from the Incubator

[Dennis E. Hamilton]

I also assume that only PPMC votes are binding is also a mistake, since this 
[VOTE] is on the general-incubator list.

I presume that this means only IPMC votes are binding and that appears to be 
what the binding votes are.

 - Dennis

-Original Message-
From: Daniel Gruno [mailto:humbed...@apache.org] 
Sent: Monday, August 10, 2015 09:48
To: general@incubator.apache.org
Subject: Re: [VOTE] Graduate Apache Usergrid from the Incubator

There's a typo in the resolution: should be jfarr...@apache.org, not 
jfarr...@apachge.org ;)

With regards,
Daniel.

On 2015-08-10 18:15, Dave wrote:
 The Usergrid project has made three releases from the Incubator (1.0.0,
 1.0.1 and 1.0.2), has added multiple and diverse committers, and the
 project has completed all required items on the graduation check-list [1].
 Consensus appears to be ([2] and [3]) that the project is ready to graduate
 and so I'm calling this vote and sharing the Usergrid Top Level Project
 Resolution (see below).

 The vote will run for 72 hours, ending 3pm EST Thursday Aug 13, 2015.
 Everyone in the Usergrid and Incubator communities is invited and
 encouraged to vote, although only PPMC votes are binding

 [ ] +1 Graduate Apache Usergrid from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache Usergrid from the Incubator because ...

 Here's my binding vote: +1.

 Thanks,
 Dave

 [1] http://incubator.apache.org/projects/usergrid.html
 [2] Dev list discussion:
 http://mail-archives.apache.org/mod_mbox/incubator-usergrid-dev/201507.mbox/%3CCAF1aazBvhYD3ZM_nKDDbrwO%3D4y6d%2BR1nH1M-2FWc9GZNuPtAjw%40mail.gmail.com%3E
 [3] Incubator discussion:
 http://mail-archives.apache.org/mod_mbox/incubator-general/201508.mbox/%3CCAF1aazCBCKNNYGT42%2BuGo%3DAdMb9uLkBrEm04rWj2tPe5LG%2BE9A%40mail.gmail.com%3E


 Apache Usergrid top-level project resolution:

 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the
 Foundation's purpose to establish a Project Management
 Committee charged with the creation and maintenance of
 open-source software related to the Usergrid BaaS software,
 for distribution at no charge to the public.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache Usergrid Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache Usergrid Project be and hereby is
 responsible for the creation and maintenance of open-source
 software related to the Usergrid BaaS software; and be it further

 RESOLVED, that the office of Vice President, Usergrid be and
 hereby is created, the person holding such office to serve at
 the direction of the Board of Directors as the chair of the
 Apache Usergrid Project, and to have primary responsibility for
 management of the projects within the scope of responsibility
 of the Apache Usegrid Project; and be it further

 RESOLVED, that the persons listed immediately below be and
 hereby are appointed to serve as the initial members of the
 Apache Usegrid Project:

 * Tim Anglade  timangl...@apache.org
 * Askhat Asanaliev aasanal...@apache.org
 * John D. Amentjohndam...@apache.org
 * Ed Anuff edan...@apache.org
 * Furkan Bıçak fbi...@apache.org
 * Ryan Bridges ry...@apache.org
 * Jake Farrell jfarr...@apachge.org
 * Scott Ganyo  scottga...@apache.org
 * Sungju Jin   sun...@apache.org
 * Dave Johnson snoopd...@apache.org
 * Alex Karasuluakaras...@apache.org
 * Salih Kardan skar...@apache.org
 * Jim Jagielskij...@apache.org
 * Shaozhuang Liu   st...@apache.org
 * Nate McCall  zzn...@apache.org
 * John Mcgibbney   lewi...@apache.org
 * Alex Muramotoamuram...@apache.org
 * Todd Ninetoddn...@apache.org
 * Luciano Resende  lrese...@apache.org
 * Yiğit Şaplı  yig...@apache.org
 * Rod Simpson  rockers...@apache.org
 * Jeff Westjeffreyaw...@apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Todd Nine
 be appointed to the office of Vice President, Usergrid, to serve
 in accordance with and subject to the direction of the Board of
 Directors and the Bylaws of the Foundation until death,
 resignation, retirement, removal or disqualification, or until
 a successor is appointed; and be it further

 RESOLVED, that the initial Apache Usergrid Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator Usegrid podling; 

RE: apache binary distributions

[Dennis E. Hamilton]

I think there is a bright-line distinction between Apache binary distributions 
and distributions made by third parties.  In particular, I don't think that 
taking builds off of a buildbot or any other developer or overnight builds will 
count, although release candidates come close.

I think it has to do with authenticity. (I am agreeing with Roman, but include 
verifiable provenance here.) When an Apache Project makes convenience binaries 
from a specific source code release and declares them authentic via 
release-manager control (even though not a source code release), via code 
signing via Apache committer signatures, including the release manager's, using 
and arranging publication of appropriately named files for download in some 
manner while housing the integrity hashes and signatures on secure Apache 
infrastructure, I would say that is an Apache [Convenience] Binary 
Distribution.  Any release notes and support information about those identified 
binary distributions are about those and not anything else.  There is clear 
provenance that such distributions are specifically provided for public use by 
the Apache Project and that the Apache Project will stand behind them in an 
appropriate manner.  (Take bug reports against the binaries, deal with security 
vulnerabilities, no matter their origin in the Apache source code, etc.)

 - Dennis

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Thursday, August 6, 2015 17:51
To: general@incubator.apache.org
Subject: Re: apache binary distributions

On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote:
[ ... ]
 if PMC produced a release then binary convenience
artifacts are easy: anything that corresponds to that release *could*
be considered an official binary convenience artifact for the release
(see my point above on 3d part vs. PMCs actually producing these
binaries).

IOW, what makes a binary convenience artifact an official ASF
artifact is not whether it got designated as such, but whether it
corresponds to an official source release produced by the PMC.

 Same for links for example to docker image distribution servers...
 or let's say a link to an ubuntu package. On the other hand you
 can put disclaimers on the pages stating they are not official...

But they are. If they correspond to an official release.

 Then again nightly builds should be ok, if they will have the
 same disclaimer?

No. Nightly builds are special precisely because they don't
correspond to an official source release.

 Or is it ok if the nightly build comes from
 non-apache?

It is ok, but at that point it becomes 3d party artifact and as
such can't be promoted as part of ASF project.

 If that is ok, then why does the release document
 not say this and is instead very strict about not promoting anything
 even beyond the dev-list? It does not make sense for me and I
 am going in circles here.

Perhaps the source of confusion is that ironically PMCs are *more*
constrained in what they can do compared to 3dparty. They do get
the Apache Branding rights in return for those constraints, though.

 Of course a third person would be someone unrelated to the project.

Or related. Could even be one of the PMC members. The point
is: it is NOT PMC.

[ ... ]


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

RE: third party tooling.

[Dennis E. Hamilton]

I want to come back to the question about the dependency of a source release on 
third-party tooling to be built.

There is some sort of principle involved when it comes to how others can build 
the source easily, even if only to confirm that it builds and operates.  

I would not want to see an Apache release that provides building on a 
significant explicitly-targeted platform exclusively via expensive commercial 
tools as the only means for directly confirming builds by an user of the 
release, a volunteer tester, some-one verifying the build, etc. 

I don't believe that is necessary for any project that I am aware of.  In the 
odd case of Visual Studio, mentioned in the original question, I think the 
danger is that the developers will use a Professional or more-expensive version 
and not confirm that a free version is readily available and can be sufficient 
to accomplish all of the builds by limiting their development to use of the 
free version or at least confirming that the free version will build it.  

I would think that this is in the spirit of maturity-model clause CD30's 
widely available standard tools. I would question any unnecessary dependence 
on tools that are a barrier to use by casual users and volunteer developers.

 - Dennis

MUSINGS

I see no reason that a podling with a small, new initial code base could rely 
on freely available tools, providing portable source code that can be easily 
built on and for different platforms by including platform-abstraction layers 
that suit that project's purposes and that otherwise satisfy requirements for 
Apache releases.

TLPs, such as Apache OpenOffice, where Microsoft Windows is a crucial target 
platform, have greater difficulty when the project-specified versions of the 
Visual C++ compiler and essential platform libraries (including redistributable 
run-time) predate the current comprehensive, freely-available versions.  This 
is a different challenge with historical origins in a legacy code base.


-Original Message-
From: Greg Stein [mailto:gst...@gmail.com] 
Sent: Thursday, August 6, 2015 02:13
To: general@incubator.apache.org; ro...@shaposhnik.org
Subject: Re: third party tooling.

On Thu, Aug 6, 2015 at 2:25 AM, Bertrand Delacretaz bdelacre...@apache.org
wrote:

 On Thu, Aug 6, 2015 at 1:57 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...you can call yourself open source software all you want,
  but unless you get an exception from Fedora Packaging Committee
  you are not open enough for the distribution to consider your work...

 But that's doesn't make your project invalid or useless.


Right.

I don't know where you're coming from Roman, but the Foundation doesn't
require our projects to be built via bootsrappable [sic] from source using
*only* open source software binaries as the input. Never has, never will.
So to Jan's original question: totally fine, no issues with compiler
dependencies for certain platforms.

Our software is defined by ALv2 and the Category licenses for
dependencies.

[ ... ]


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

RE: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Dennis E. Hamilton]

+1 

with the understanding that there is the usual flexibility between policies and 
practices, consistent with the spirit and principles of the ASF for Apache 
Projects.  

And, to be fair, I think TLPs should also self-assess on a periodic basis as an 
accountability of the PMC, nudged as necessary by the Chair (not to do it as 
much as to direct the PMCs eyes to the ball).

I can also imagine the maturity model items being used on an exception basis, 
only reporting maturity-model deviations and how they are being addressed as 
part of a report to the Board.

 - Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Thursday, August 6, 2015 00:28
To: Incubator General general@incubator.apache.org
Subject: Re: Podlings and the ASF maturity model (was: Reform of Incubator...)

On Thu, Aug 6, 2015 at 8:46 AM, Niclas Hedhman nic...@hedhman.org wrote:
 ...the maturity model shouldn't be a set of gating criteria, but that the
 podling should self-assess its position and to what degree, as well as how,
 each point is handled. Yes, many of the points are non-negotiable, but
 don't claim that all are...

So you would see the maturity model as one element of the Incubation
graduating checklist, with self-assessment from the podling and its
mentors? I like the idea.

-Bertrand

-
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: Podlings and the ASF maturity model (was: Reform of Incubator...)

[Dennis E. Hamilton]

OK, thanks Bertrand.  My recollection of the maturity-model discussion was that 
it is about an ideal state and not some gate, and that projects would always be 
correcting their state toward that defined in the model.  I confirm that the 
current document simply characterizes what the state is for a mature project.

I see no statement anywhere that a TLP, or a graduating incubator project, must 
pass through a maturity assessment.  It would certainly be useful for a podling 
to conduct a self-assessment of its maturity before requesting graduation.  

It would also be useful for an operating TLP to assess itself with respect to 
the model, especially if there are concerns in that regard.

I am neutral on how this fits into graduation criteria for podlings.  However, 
if it is used for gating purposes, I think that needs to be made very clear by 
the IPMC lest it just lead to more randomizing of the podling seasoning 
process.  In particular, mentors need to be on board with respect to their 
responsibilities.  I can also imagine a graduation going forward (just as 
releases can) with certain items remaining to be addressed post-graduation.  I 
note that, at the moment, there is no direct reference to the Project Maturity 
Model at the https://www.apache.org/dev/project-requirements draft nor at the 
Incubation Policy, 
https://incubator.apache.org/incubation/Incubation_Policy.html.

I can also imagine a TLP using (or being asked to use) the project maturity 
model as a checklist in assessing their current state in a report to the Board. 
 

Are these the kinds of applications that folks have in mind?

 -- Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Wednesday, August 5, 2015 00:44
To: Incubator General general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Podlings and the ASF maturity model (was: Reform of Incubator...)

Hi,

On Wed, Aug 5, 2015 at 12:24 AM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 ...I understand the maturity model to be something to aspire to and that 
 Apache Projects
 will always be working toward it.  I mean TLPs, not podlings, although 
 podlings should be
 aware of it and also aspire to it...

I don't see why podlings should be different here, once they are about
to graduate.

Why can't we define our incubation process as a way for podlings to
learn to operate according to that maturity model [1]?

This would allow us to use the maturity model [1] as a checklist for
graduating podlings - do you see anything in there that shouldn't be
required from a podling that's about to graduate?

-Bertrand

[1] http://community.apache.org/apache-way/apache-project-maturity-model.html

-
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: third party tooling.

[Dennis E. Hamilton]

I don't have an answer about tooling with respect to the need for 
widely-available tools.  If the concern is for ability to use free tools on 
Windows, but there are alternatives to requiring an expensive commercial IDE 
for users while still taking advantage of the Microsoft development tool chain.

The Visual Studio Community Edition 2013 is free to use for open-source 
projects.  I would recommend it simply because it is available for development 
on and for Windows and should work for Corinthia (although I haven't tried your 
builds there).  This works if you are creating/publishing Visual Studio 
projects.

It might also be desirable to use Visual Studio Community Edition 2015, which 
is now released and available. 

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Wednesday, August 5, 2015 12:04
To: general@incubator.apache.org
Subject: third party tooling.

Hi.

We have recently (again) on different list discussed third party libraries.
Some strong
opinions have been aired.

So we have rules/policies for libraries but how about tooling, I have not
been able to
find any do not do this page.

I am about to prepare a release for Corinthia, which is a C99 project. I
would like to
write in the release note, that on ms-Windows we test with Visual Studio
2013, simply
because that is a fact.

But Visual Studio 2013 is not a free version so which rules/policies will I
break by not
testing with e.g. GCC on windows ?
(I hope none, but better ask than have to cut a new release candidate).

rgds
jan i.


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

RE: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Dennis E. Hamilton]

Sorry, my comment was too brief.  

I understand the maturity model to be something to aspire to and that Apache 
Projects will always be working toward it.  I mean TLPs, not podlings, although 
podlings should be aware of it and also aspire to it.  

I was commending the structure and clarity of the maturity model as a basis, 
not about it being somehow held to podlings as a graduation yardstick or 
anything else.

I was responding in the context of Bertrand's comment,

   Creating a release checklist in a structured text format
   sounds like a good start anyway, so we can start with that
   ... .

that used the maturity model format as a suggested form.

 - D



-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Tuesday, August 4, 2015 10:37
To: general@incubator.apache.org; orc...@apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

On 4 August 2015 at 18:46, Dennis E. Hamilton orc...@apache.org wrote:

 +1 on how to start, with the maturity model as exemplar, is an outstanding
 idea.  Thanks.

 (I even have a poddling in mind for stress-testing it.)

It is clear to me, that incubator offer many advantages...but our current
overweight to control everything is seen (and are) a negative effect,
anything
that can reduce that is good.

I think the maturity model is good, but to used with care. If I think of
the same podling as Dennis, that would clearly be a test done too early.

rgds
jan i.



  - Dennis

 -Original Message-
 From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
 Sent: Tuesday, August 4, 2015 05:57
 To: Incubator General general@incubator.apache.org
 Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from
 the Apache Incubator)

 Hi Daniel,

 On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno humbed...@apache.org wrote:
  On 2015-08-04 13:01, Bertrand Delacretaz wrote:
 ... IMO the Incubator PMC can very much own this checklist, and I
  volunteer to contribute to creating it...

  If interested, I would very much like to work with you on perhaps turning
  this into a sort of 'online compliance check' where podlings could
 upload a
  tarball or some such, and the service would scan it for compliance, go
  through the checklist, and report back which elements are compliant and
  which are not...

 Wow, that's more ambitious than what I envisioned but I know your are
 able to do that  ;-)

 Creating a release checklist in a structured text format sounds like a
 good start anyway, so we can start with that and if you and others
 want to turn it into an online analysis service that would be
 fantastic.

 -Bertrand

 -
 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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Dennis E. Hamilton]

+1 on how to start, with the maturity model as exemplar, is an outstanding 
idea.  Thanks. 

(I even have a poddling in mind for stress-testing it.)

 - Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, August 4, 2015 05:57
To: Incubator General general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

Hi Daniel,

On Tue, Aug 4, 2015 at 1:15 PM, Daniel Gruno humbed...@apache.org wrote:
 On 2015-08-04 13:01, Bertrand Delacretaz wrote:
... IMO the Incubator PMC can very much own this checklist, and I
 volunteer to contribute to creating it...

 If interested, I would very much like to work with you on perhaps turning
 this into a sort of 'online compliance check' where podlings could upload a
 tarball or some such, and the service would scan it for compliance, go
 through the checklist, and report back which elements are compliant and
 which are not...

Wow, that's more ambitious than what I envisioned but I know your are
able to do that  ;-)

Creating a release checklist in a structured text format sounds like a
good start anyway, so we can start with that and if you and others
want to turn it into an online analysis service that would be
fantastic.

-Bertrand

-
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: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Dennis E. Hamilton]

+1 

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Monday, August 3, 2015 09:37
To: general@incubator.apache.org
Subject: Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the 
Apache Incubator)

[ ... ]

It's not the central Incubator folks like our regular release
reviewers and report contributors who invent these extra criteria --
it's individual Mentors out on the podling lists.  Inaccuracy and
overreach on general@incubator is self-correcting, precisely because
this is where everyone comes together.  When inaccuracy and overreach
out on individual podling dev lists, whether that gets corrected
depends on whether the podling is fortunate enough to have a
well-rounded collection of active Mentors.

[ ... ]

The objective of establishing clear policy documentation is certainly
not going to be made any easier by atomizing the Incubator.  Instead,
Mentors who have strong opinions and strong personalities will
entrench provincial points of view in the podlings they oversee. When
we finally come together, it will be that much more painful to
establish consensus, whether that is to discuss policy on
general@incubator or legal-discuss@apache, or when the Board comes
into conflict with a TLP that received bad advice as a podling.

As someone who has worked hard building consensus for policy
documentation at Apache, and who has seen that hard work pay off when
Incubator threads which would have been contended several years ago
are now settled quickly, I certainly agree that documenting clear
objective criteria is valuable.  But nothing about the present makeup
of the Incubator gets in the way of pursuing that objective -- it's
the opposite.  Its because we resolve our differences in small amounts
here that we do not end up as irreconcilable factions later.

Marvin Humphrey

-
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: Licensing Issue

[Dennis E. Hamilton]

Small but important correction.

It is not permissible to claim a public-domain creation of another as your 
own.  There is no open-range, mustang copyright arrangement.

In the US, works of the US Government are born public-domain.  Not others.  

Oddly, you as an individual in the US can't *put* a work into the public 
domain, but you can make a quit claim that forswears defense of any of the 
exclusive rights of you, the copyright holder.  That does not in any way remove 
the copyright that the work was born having, however.

But either way, one cannot assert any kind of property right over a work that 
is not yours (or of someone providing work for hire to you), whether public 
domain or not.

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Thursday, June 25, 2015 23:51
To: general@incubator.apache.org
Subject: Re: Licensing Issue

Stefan,

In order to open source something, you have to define what you mean by
open source.  If you mean that anybody can do anything at all with the
code including claim it as their own, then you mean to put it into the public
domain https://en.wikipedia.org/wiki/Public_domain.

[ ... ]


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

RE: Licensing Issue

[Dennis E. Hamilton]

There's a difference between making a claim, affixing a notice, etc., and it 
being lawful and the right to having done so being legally defensible.

I suspect this normally doesn't matter and is a trifle unless a conflict of 
some sort drags the usurper into court.  Finding plagiarism, even in a 
derivative, will be quite unfortunate.

 - Dennis

orcnote / below.

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Friday, June 26, 2015 18:18
To: general@incubator.apache.org; Dennis Hamilton
Subject: Re: Licensing Issue

On Fri, Jun 26, 2015 at 6:58 PM, Dennis E. Hamilton dennis.hamil...@acm.org
 wrote:
[ ... ]
 But either way, one cannot assert any kind of property right over a work
 that is not yours (or of someone providing work for hire to you), whether
 public domain or not.


Perhaps true in a literal sense.  Nearly trivial (nearly!) derivative works
can be claimed with no attribution, I think if a license like the CC0 has
been applied. The issue of moral rights, especially in Europe, seems sticky.

orcnote
  If the creation of the derivative work is allowed, the claim by the creator 
of the derivative extends only to the aspects that are original with that 
creator.  I think it is basically the case that one does not gain copyright 
over work that is not one's own (or obtained by hiring someone) by any means 
unless there has been a [recorded] copyright transfer (a license not being 
enough).

[This might be a (probably-minor) component in how the Oracle v. Google appeal 
is resolved by SCOTUS.)]
/orcnote


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

RE: [POLL] Using this list to discuss pTLP proposals, ok?

[Dennis E. Hamilton]

Oh.  I confused myself.  The POLL is about the processing of proposals to 
create pTLPs, and I was thinking about the creation of procedures for the 
processing of proposals to create pTLPs.  I think the first is fine, right here 
where it has been.  

It might be strange for a pTLP proposal to be refined and then acceptance to be 
voted (i.e., on a project definition to be forwarded to the board) on 
general-incubator.  I have lost track of the remit for IPMC though.

So,

+0.5 on using this list, 

With some clear demarcation and agreement on forwarding of a recommendation to 
the Board possibly having quite a different procedure.  Determining that 
incubation is preferable might also be an exit from that procedure, although I 
think that would become known as the project proposal is worked on and reviewed.

 - Dennis

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Monday, March 23, 2015 01:13
To: Incubator General
Subject: Re: [POLL] Using this list to discuss pTLP proposals, ok?

On Sun, Mar 22, 2015 at 8:27 PM, Alan D. Cabrera l...@toolazydogs.com wrote:
 ...The mailing lists derive their power from being focused on specific 
 topics

I disagree, our mailing lists are focused on *communities*, not topics.

 ...With that said, pTLP and direct-to-TLP issues have no business being on the
 Incubator lists since they are not under the purvey of the Incubator

I also disagree ;-)

The Incubator community, on which this list is focused, has experience
handling the formation of podlings and their graduation. Creating a
TLP without incubating shares a lot of steps and concerns which those
operations, so discussing that here makes perfect sense.

-Bertrand

-
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: [POLL] Using this list to discuss pTLP proposals, ok?

[Dennis E. Hamilton]

Would moving this to members make this a members-only conversation?  

-Original Message-
From: Alan Cabrera [mailto:l...@toolazydogs.com] 
Sent: Sunday, March 22, 2015 07:33
To: general@incubator.apache.org
Subject: Re: [POLL] Using this list to discuss pTLP proposals, ok?

I am very much in favor for provisional TLP's and direct-to-TLP's here at the 
Apache Software Foundation.

With that said I am very much against the noise here on our incubator lists and 
wiki.  We should really create a list in the wiki for this kind of endeavor. It 
really it should take place on members, since this is ultimately the purvey of 
the foundation members not the incubator, and a new wiki For general 
discussions should be made.

[ ... ]


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

RE: [VOTE] Accept Groovy into the Apache Incubator

[Dennis E. Hamilton]

+1 (non-binding)

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Wednesday, March 18, 2015 23:56
To: general@incubator.apache.org
Subject: [VOTE] Accept Groovy into the Apache Incubator

[ ... ]

The proposal is available at:
https://wiki.apache.org/incubator/GroovyProposal
and is also included at the bottom of this email.

Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST

 [ ] +1 accept Groovy in the Incubator
 [ ] ±0
 [ ] -1 because...

Thanks,
Roman.

[ ... ]


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

[OFF-LIST] RE: [DISCUSS] Groovy Incubation proposal

[Dennis E. Hamilton]

+1 Nice. Great anticipation and risk management.  Great to see made visible.


 -- Dennis E. Hamilton
orc...@apache.org
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail




-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Friday, March 13, 2015 14:39
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Groovy Incubation proposal

(Disclosure Ben works for my employers, so I have slightly more ability to
bend his ear. As a result I got him to agree to do two full exports from
JIRA, one to let us test the process and a second when we are ready to
migrate)

On 13 March 2015 at 21:37, Stephen Connolly stephen.alan.conno...@gmail.com
 wrote:

 We @ Maven will have a full dump of the Codehaus JIRA and we have a VM set
 up to test migration...

[ ... ]


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

RE: [DISCUSS] Groovy Incubation proposal

[Dennis E. Hamilton]

I think the business about numbers of committers and how additions to the 
community are cultivated is a sniff test concerning sustainability.  The idea 
is to have some sense that there is a sustainable community in place and that 
there is as much attention on nurturing that sustainability as there is in code 
wrangling.  

Being able to produce releases is also a related consideration that has a 
sustainability component.  How is release manager rotation handled?  Is there 
release-manager rotation?  (Not graduation criteria, AFAIK, but a similar 
concern and perhaps not quite the right terms for Groovy.)
 
What these mean in practice depends a lot on what the scope of the project is, 
of course. 

My very limited experience with two podlings suggests that this all gets worked 
out in incubation (at least in terms of the direction to continue as a TLP), 
not before incubation.  Attention to these considerations most definitely does 
not end at graduation, either. 

-Original Message-
From: Paul King [mailto:pa...@asert.com.au] 
Sent: Thursday, March 12, 2015 03:17
To: Bertrand Delacretaz; Incubator General
Cc: Cédric Champeau; Jochen Theodorou; pascalschumacher; Guillaume Laforge
Subject: Re: [DISCUSS] Groovy Incubation proposal


I would have thought that graduation would be all about showing that whatever 
list of committers we have (big or small) is working well? Having a large 
number of committers certainly makes sense with a subversion mindset but it's 
possibly an anti-pattern with a DVCS mindset (at least for a stable language in 
any case)?

The Groovy community has always valued the actual code contribution more than 
who the person was who contributedthe code. I hope we can continue in that 
fashion.

Obviously, there are logistics concerns, you need enough committers to handle 
the administrative tasks involved (and that will change with less full-time 
people contributing on that side perhaps), so we should expect changes. And, 
the voting is a bit different to what we have done in the past, so making that 
work well will be important too. I just hope we are targeting a working system 
rather than some magic number of committers.

Cheers, Paul.

On 12/03/2015 7:57 PM, Bertrand Delacretaz wrote:
 Hi,

 On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote:
 ...The proposal talks several places about a vibrant community and the 
 initial
 commiters are only 5...

 As others have said this was discussed while preparing the proposal. I
 also agree that it's fine to include only the core Groovy committers
 to enter incubation, as usual it will be their task to grow that
 community before graduating.

 The alternative would be to start with a huge list of initial
 committers (everybody who contributed more than X to Groovy) and
 before graduating reduce it to the list of people who actually
 contributed during incubation, but that's much more work IMO.

 -Bertrand



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com


-
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: Binary Convenience Package Dependencies

[Dennis E. Hamilton]

The answers below are not on behalf of the ASF, but based on what the
common sense appears to be, from my individual perspective.

In particular, your project is not relieved from learning what a license
requires of it and demonstrating satisfaction of such requirements.

 -- replying below to --
From: Alex Harui [mailto:aha...@adobe.com] 
Sent: Monday, January 5, 2015 09:52
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies

[ ... ]
2A) If your build script downloads an MPL jar, must it provide an option
to download the source?

2B) If your build script downloads an MPL jar, is any other additional
warning or explicit action required?

orcmid
   It depends on what the governing license requires with respect to 
   Whatever is being done with the download.  If you are redistributing
   the jar or anything in it, see (2C).

   As a *practice* it can be valuable to download accompanying licenses
   and to make it clear where the download is obtained.  That's a matter
   of being transparent with regard to the provenance of code being used
   and what version it is, etc.  That can matter in the event there is a
   later concern about revelations of upstream defects, vulnerabilities,
   and such.

   Presumably the upstream source will provide any determination on the
   availability of source code.  (In (2B) there is no indication that the
   ASF project is accessing such source code itself.)
/orcmid

2C) If your binary package bundles an MPL jar (assuming the answer to #1
allows it), must it provide an option to download the source?

orcmid
   This item has nothing to do with the ASF policy about category B software.
   For (2C), the obligation is to comply with the MPL license with respect
   to redistribution of a binary component that is provided under that 
   license.  
  In particular, what other ASF projects might or might not do is not a
   reliable precedent for what your project does.  What your project must
   do is comply with the applicable license.  There may be additional steps
   required as part of the ASF policy and recommendations, but the minimum
   is determined by the governing license.
  For example, your project's LICENSE and NOTICE files included in your
   binary package bundle will likely also address the presence of the 
   MPL-licensed dependency, as required in accordance with ASF policy.
/orcmid


Thanks,
-Alex

[1] http://www.apache.org/dev/release.html
[2] http://www.apache.org/legal/resolved.html


-
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: Binary Convenience Package Dependencies

[Dennis E. Hamilton]

Interesting.  I had not read that passage with a critical eye until just now ...

 -- replying below to --
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Monday, January 5, 2015 17:41
To: general@incubator.apache.org
Subject: Re: Binary Convenience Package Dependencies

Hi,

I would strongly recommend that you review with legal, in addition to the
incubator on this type of question.

If I look here: http://www.apache.org/legal/3party.html
MPL is listed under Category B, which has the following associated with it:

Although the source must not be included in Apache products, the NOTICE
file, which is required to be included in each ASF distribution, must point
to the source form of the included binary (more on that in the forthcoming
Receiving and Releasing Contributions document).

orcmid
   I don't see how this is going to work in the case of redistributables
   for which source is not supplied and is not open.  

   What come immediately to mind are the Microsoft Windows redistributables
   for native runtime libraries that are commonly installed with those
   convenience binaries that depend on their presence.  

   Installing a JVM or a .NET Framework for internal use by a binary
   would probably raise the same issues.

   Of course, when the ASF project doesn't actually build the redistributed
   binary artifact, it's not easy to point to *the* source either.
/orcmid

This implies to me that you must include a link in your NOTICE to the
source code.  This doesn't mean you need to distribute the source, nor add
a download option (from my perspective).

orcmid
   I think the minimum is to link to the source *of* the code.  Whether that is
   direct to the source code might not even be the best choice, depending on
   circumstances, even if possible.
/orcmid

John

On Mon Jan 05 2015 at 12:53:41 PM Alex Harui aha...@adobe.com wrote:

 Hi, anybody willing to try to answer this?

 Thanks,
 -Alex

 On 12/22/14, 8:11 AM, Alex Harui aha...@adobe.com wrote:

 Hi,
 
 I have some questions about Binary Convenience Packages:
 
 1) In [1] it says: the binary/bytecode package .. may only add
 binary/bytecode files that are the result of compiling that version of the
 source code release”.  An Apache Flex SDK source package has a build
 script that downloads jars such as Saxon and JavaCC.  Does the text I
 quoted mean that the binary package cannot bundle Saxon and JavaCC because
 we did not compile those jars from their sources?  Or does “compiling”
 really mean “running the build script on”?
 
 2) In [2] it says for Category B: By including only the object/binary
 form, there is less exposed surface area of the third-party work from
 which a work might be derived; this addresses the second guiding principle
 of this policy. By attaching a prominent label to the distribution and
 requiring an explicit action by the user to get the reciprocally-licensed
 source, users are less likely to be unaware of restrictions significantly
 different from those of the Apache License.”  Does “including” means
 “bundling”?  If so, the quoted text must be referencing binary packages
 and not source packages since source packages can never include
 object/binary forms.  Or does “including” also refer to build scripts that
 download an MPL jar like Saxon?
 
 2A) If your build script downloads an MPL jar, must it provide an option
 to download the source?
 
 2B) If your build script downloads an MPL jar, is any other additional
 warning or explicit action required?
 
 2C) If your binary package bundles an MPL jar (assuming the answer to #1
 allows it), must it provide an option to download the source?
 
 Thanks,
 -Alex
 
 [1] http://www.apache.org/dev/release.html
 [2] http://www.apache.org/legal/resolved.html


 -
 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: Git write access for podlings

[Dennis E. Hamilton]

+1

-Original Message-
From: David Nalley [mailto:da...@gnsa.us] 
Sent: Wednesday, December 31, 2014 11:44
To: general@incubator.apache.org
Subject: Re: Git write access for podlings

[ ... ]
 git is tied to LDAP, and all podling repos are writable by anyone in
 the incubator LDAP group. (there are no podling LDAP groups)


 Got it thanks.  I'll update the docs to reflect this as the permission
 scheme.

 And here I think will come in Jan's bigger question - do we really want all
 podling committers to be able to commit to all other podlings?


My question is: What problem are you trying to solve? And has it
really proven to be a problem?
I don't think anyone has abused their ability to commit to all
projects, and it's been this way as long as git has been available.

--David

-
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 report sign-off

[Dennis E. Hamilton]

+1

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, December 30, 2014 00:56
To: Incubator General
Subject: Re: Incubator report sign-off

On Mon, Dec 29, 2014 at 9:32 PM, Andrew Purtell
andrew.purt...@gmail.com wrote:
 ...Certainly some projects have a de facto lead that coincide with Chair and 
 I'm pretty sure
 in some cases that is an honorary arrangement agreed to by the community

*loud red alarms going off all over my brain*

If that's the case, such projects should make sure they implement a
regular PMC chair rotation. Or be prepared to go down in flames once
that leader changes their mind and no one has a clue how their project
runs.

-Bertrand

-
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: [Proposal] TinkerPop: A Graph Computing Framework

[Dennis E. Hamilton]

Thank you for the clarification.
-Original Message-
From: Marko Rodriguez [mailto:okramma...@gmail.com] 
Sent: Monday, December 29, 2014 09:34
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [Proposal] TinkerPop: A Graph Computing Framework

Hello,

Here is how TinkerPop current runs it TinkerPop-Contributors.

1. If you are a vendor, you get one engineer from your organization to 
be on TinkerPop-Contributors who speaks on behalf of your organization/product. 
(~15 people)
- e.g. That API addition will be extremely expensive for us to 
implement. Can we get the next release out within the next month because we 
are about to release our product and want the latest features?, etc.
2. If you are working on core TinkerPop day-in and day-out you are part 
of TinkerPop-Contributors. (~3 people)
- e.g. On the Google Hangouts, nit-picky about documentation, 
committing code and maintaining your code…the people who baby the source.
3. If you have worked on TinkerPop core at some point. (~5 people)
- e.g. You were hot and heavy on the codebase for a month+ 
straight but then lost interest but still want to hang around. Perhaps it looks 
good on the resume why you don't want to leave… who knows?

Most people are in group 1 or 3. I was told by our champion (David Nalley) that 
you can't have people be on the board because of who they work for. Thus, the 
concept of one engineer per company is not acceptable. Next, I don't think it 
is smart to just have everyone in group 3 mapped over. I think its best to 
start with the minimum requirement of people and grow from that core. Who are 
these three people?

Marko -- has been coding on TinkerPop day in and day out for the last 
5 years. 
Stephen -- has been coding on TinkerPop day in and day out for the 
last 3 years.
James --  has been an evangelist for TinkerPop for the last 5 years and 
is getting the TinkerPop book effort underway.

These are the most hardcore members of TinkerPop. Now, once (and if) 
TinkerPop goes Apache, I'm sure more engineers (either currently in 
TinkerPop-Contributors or new to the scene) will want to make concerted 
efforts to be apart of TinkerPop. Through the years I have become too painfully 
aware of commit and split-contributors (here is a big ball of features, 
merge it…oh, I can't work on that anymore, my boss doesn't care about graphs 
anymore. good luck maintaing that code. --- many group 3 people are in this 
camp). Once we realize someone is here for the long haul and truly cares 
about the project, we are happy to have them join. 

Lets start small and grow is the philosophy behind the 3 initial committers.

Cool?

Thank you,
Marko.

http://markorodriguez.com

On Dec 25, 2014, at 3:12 PM, Dennis E. Hamilton dennis.hamil...@acm.org 
wrote:

 -- with reply below --
 From: Marvin Humphrey [mailto:mar...@rectangular.com] 
 Sent: Thursday, December 25, 2014 13:39
 To: general@incubator.apache.org; Dennis Hamilton
 Subject: Re: [Proposal] TinkerPop: A Graph Computing Framework
 
 On Thu, Dec 25, 2014 at 1:06 PM, Dennis E. Hamilton
 dennis.hamil...@acm.org wrote:
 I am puzzled by the TinkerPop proposal identifying 3 initial committers and
 yet there is this long list of affiliated folks.
 
 What is that separate list intended to signify if none of them are worthy to
 be initial committers?
 
 If it's like other projects, I speculate that the people on that longer list
 have exhibited varying levels of activity over time.  I don't think it's a bad
 thing if the initial committer list is only a subset (though 3 is arguably too
 small even to start).  So long as the podling busies itself with the task of
 voting new people in, it should be OK.  I think the way Marko put it bodes
 well:
 
Thus, typically finding those people is the difficult part, not the
accepting of those who do so.
 
 orcmid
   That list is noise, then, especially with no accompanying explanation of
   how it supports the proposal.
 
   With regard to finding committers, I notice that folks request 
   being added to the initial committers list of a proposal and 
   those are vetted one way or another by the proposer/champion.
   Has the proposal been publicized to that group and any 
   interest in being initial committers (and especially filing 
   Apache iCLAs) elicited?
 /orcmid
 
 Marvin Humphrey
 
 -
 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

RE: [Proposal] TinkerPop: A Graph Computing Framework

[Dennis E. Hamilton]

I am puzzled by the TinkerPop proposal identifying 3 initial committers and yet 
there is this long list of affiliated folks. 

What is that separate list intended to signify if none of them are worthy to be 
initial committers?

 - Dennis

-Original Message-
From: Ted Dunning [mailto:ted.dunn...@gmail.com] 
Sent: Thursday, December 25, 2014 12:21
To: general@incubator.apache.org
Subject: Re: [Proposal] TinkerPop: A Graph Computing Framework

Sure.  You need three minimum.  But you need three minimum active people at
nearly *any* given time.

With only three to choose from that can be really hard.

From my experience with changing priorities and such, having 10 or more is
much more practical.

[ ... ]

On Wed, Dec 24, 2014 at 4:12 PM, Marko Rodriguez okramma...@gmail.com
wrote:

 Hello,

 I had read somewhere that you needed 3 people at minimum for the PPMC. I
 ran the names (Marko,Stephen,James) by our TinkerPop-Contributors list and
 there was no pushback.

 Moving forward, if someone does provide sustained, beneficial work to
 TinkerPop, they are more than welcome to get involved to the depths they
 feel necessary. This is always a desire --- to find people who will spend
 days in and days out (for years in and years out) dedicated to providing
 their time and patience to TinkerPop. Thus, typically finding those people
 is the difficult part, not the accepting of those who do so.

 Thank you for your thoughts,
 Marko.

 http://markorodriguez.com

 On Dec 24, 2014, at 11:05 AM, Ted Dunning ted.dunn...@gmail.com wrote:

  On Wed, Dec 24, 2014 at 9:54 AM, Marvin Humphrey mar...@rectangular.com
 
  wrote:
 
 
 AA. Initial Committers
 
 We would like to keep the voting rights to 3 individuals: Marko A.
 Rodriguez (Aurelius), Stephen Mallette (Nidomics), and James Thornton
 (Electric Speed).
 
 
  This is a problem for other reasons as well.  Many actions require 3
  positive votes.  This means that if anybody is MIA, the project is dead
 in
  the water with no ability to make releases or even to add somebody to the
  PPMC to get back to having 3 voters.


 -
 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: [Proposal] TinkerPop: A Graph Computing Framework

[Dennis E. Hamilton]

 -- with reply below --
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Thursday, December 25, 2014 13:39
To: general@incubator.apache.org; Dennis Hamilton
Subject: Re: [Proposal] TinkerPop: A Graph Computing Framework

On Thu, Dec 25, 2014 at 1:06 PM, Dennis E. Hamilton
dennis.hamil...@acm.org wrote:
 I am puzzled by the TinkerPop proposal identifying 3 initial committers and
 yet there is this long list of affiliated folks.

 What is that separate list intended to signify if none of them are worthy to
 be initial committers?

If it's like other projects, I speculate that the people on that longer list
have exhibited varying levels of activity over time.  I don't think it's a bad
thing if the initial committer list is only a subset (though 3 is arguably too
small even to start).  So long as the podling busies itself with the task of
voting new people in, it should be OK.  I think the way Marko put it bodes
well:

Thus, typically finding those people is the difficult part, not the
accepting of those who do so.

orcmid
   That list is noise, then, especially with no accompanying explanation of
   how it supports the proposal.

   With regard to finding committers, I notice that folks request 
   being added to the initial committers list of a proposal and 
   those are vetted one way or another by the proposer/champion.
   Has the proposal been publicized to that group and any 
   interest in being initial committers (and especially filing 
   Apache iCLAs) elicited?
/orcmid

Marvin Humphrey

-
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: P. An Excessive Fascination with the Apache Brand

[Dennis E. Hamilton]

Two thoughts ...

 -- replying to --
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Wednesday, December 24, 2014 00:33
To: Incubator General
Subject: Re: P. An Excessive Fascination with the Apache Brand

On Tue, Dec 23, 2014 at 11:25 PM, Ted Dunning ted.dunn...@gmail.com wrote:
 ...Of course, it isn't politic to ask a high profile mentor to recuse
 themselves for lack of helping

Maybe we need to add no politics allowed to our collection of slogans ;-)

If someone's not active as a mentor, it's perfectly fine to politely
ask them if they intend to become active again. If's also fine for
mentors to be temporarily inactive, they should just let others know
so that replacements can be arranged.

orcmid
One valuable contribution of a mentor is demonstration of accountability.
By that I mean providing an account (what accountants do), not the
common notion of something to do with obligation and duty.

Mentors in their interactions with PPMCs can provide certainty with
regard to their own presence by being visible and indicating when they
are unavailable.  Mentors should not be mysterious.

With regard to this general concern about status-seeking, perhaps it
would be useful to have mentor apprentices who themselves are being
coached (off-list) and who are discouraged from serving on multiple
PPMCs until they have demonstrated consistency.  One could go so far
as have PPMCs rate their mentors (since measures need to come from
somewhere).  I offer this only as identifying an area to think about.
Being willing and consistent at demonstrating involvement and being
available needs some form of encouragement and also accountability.
/orcmid
 
-Bertrand

-
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: Votes for git repos - commit id vs tag

[Dennis E. Hamilton]

 -- in reply to --
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org] 
Sent: Tuesday, December 23, 2014 01:28
To: Incubator General
Subject: Re: Votes for git repos - commit id vs tag

On Tue, Dec 23, 2014 at 3:54 AM, Marvin Humphrey mar...@rectangular.com wrote:
 ...Although many consider it best practice for release tarballs to be tied 
 back
 to a specific version control identifier (including me), Apache release policy
 does not require it

As we tried to say above, the timeline gets into play here.

Tying releases to version control is very useful *in the short term*
for people to verify the release, but in the long term you cannot
count on it. That's why our release policy centers on tarballs, the
rest is convenience.

orcmid
   I can see that the policy is appropriate because of the archival 
preservation 
   of the tarball.  On the other hand, tarballs do not usually preserve history.
   Although one cannot be assured of preservation of the repository as a match, 
   knowing what the match was, and might still be, is useful historically.  
   One could recommend the convenience without it being a substitute for
   the tarball.  (Of course, with Git one can snapshot all of it [;).
/orcmid

-Bertrand

-
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 report sign-off

[Dennis E. Hamilton]

As a participant, I have two concerns about a player-mentor requirement.  

 1. Sustainability.  In many ways, it is mentors who need to have their 
attention on The Apache Way and cultivating a sustainable project.  That means, 
from my perspective, that mentors need to encourage others to do things, 
especially around project management and procedural matters, and not just take 
on matters without leaving any bread crumbs.  It seems important that others 
learn how to do that sort of thing too, whether or not special karma is 
eventually required to perform the same activities.

 2. I have learned repeatedly, and it is evidently well-known, that a developer 
is his own worst project manager.  It has to do with attention being at a 
completely different place when heads-down in development tasks than when 
heads-up watching the horizon and keeping objectives and current effort 
aligned. When I am in developer mode, I need someone else to pull my attention 
out of the weeds and look to see what course I am on and where I am at on that 
course.

I remember in the 60s when a colleague had ended up managing a project at GE 
Medical Systems (or something similar) and he confessed that his team made a 
terrible mistake -- they allowed him to program on their project.  

I'm not saying that a mentor could not be an effective player. I think doing it 
well while mentoring is not common and it might interfere with training and 
development as well.

 - Dennis


-Original Message-
From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] 
Sent: Friday, December 19, 2014 11:01
To: general@incubator.apache.org
Subject: RE: Incubator report sign-off

Strawman:

What if a mentor is *required* to be an active participant of the project. That 
is contributing code, voting on releases and generally engaging with the 
community, they would be a better mentor since they have a vested interest in 
the project itself. Sure, we might reduce the number of projects coming into 
the foundation but (IMHO) that is not a problem. Our goal as a foundation is 
not to be large, it is to be high quality.

[ ... ]


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

[OFF-LIST] RE: Incubator report sign-off

[Dennis E. Hamilton]

Now we are getting somewhere?

This post disappeared too.  But yours in the same thread before it didn't.  Are 
you replying to Chris's post or another here?

Was there anything else at all different?

Is there more than one way you read from the lists (i.e., via a news reader or 
something)?

-Original Message-
From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] 
Sent: Friday, December 19, 2014 12:46
To: general@incubator.apache.org
Subject: RE: Incubator report sign-off




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

RE: [OFF-LIST] RE: Incubator report sign-off

[Dennis E. Hamilton]

Sorry, I forgot to change the automatic reply to list when moving this to an 
off-list investigation.

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Friday, December 19, 2014 15:07
To: general@incubator.apache.org
Subject: [OFF-LIST] RE: Incubator report sign-off

Now we are getting somewhere?

This post disappeared too.  But yours in the same thread before it didn't.  Are 
you replying to Chris's post or another here?

Was there anything else at all different?

Is there more than one way you read from the lists (i.e., via a news reader or 
something)?

-Original Message-
From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] 
Sent: Friday, December 19, 2014 12:46
To: general@incubator.apache.org
Subject: RE: Incubator report sign-off




-
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: Votes for git repos - commit id vs tag

[Dennis E. Hamilton]

+1 on including commit ID (or SVN revision number) along with any tag (or SVN 
tag/branch) for convenience.

-Original Message-
From: John D. Ament [mailto:johndam...@apache.org] 
Sent: Thursday, December 18, 2014 05:58
To: general@incubator.apache.org
Subject: Votes for git repos - commit id vs tag

All,

I was looking through the incubator site and I don't see anything definite.

Whenever a podling goes for a vote, and they include a git tag in their
vote message, it's typically asked to change to a commit id.  It seems to
me this is done for the reproducible builds concept.  Tags are mutable, and
therefore could be changed and rebuilding a tag could give you a different
result.

So, is this the right understanding? Do we want to ask podlings to always
submit a git commit id?  If so, is there a place in the website we can
clarify this?

Thanks,

John


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

RE: [VOTE] accept corinthia into incubator

[Dennis E. Hamilton]

+1 (non-binding)

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Tuesday, December 2, 2014 09:09
To: general@incubator.apache.org
Subject: [VOTE] accept corinthia into incubator

Hi

As champion for corinthia, I hereby ask for a vote on accepting corinthia
into incubator.

It seems the discussion have died out, in reality most of the discussion
has been through private mails and IRC/hipchat (which disturbes me). As a
result the proposal is now more clear about what the project is and what it
isnt.

We have added a committer and a mentor during the discussion period.

The proposal is available in
http://wiki.apache.org/incubator/CorinthiaProposal
http://wiki.apache.org/incubator/CorinthiaProposal?action=recallrev=60
Remark the vote is for revision #60 (the newest).
Proposal is added as text to the bottom of this mail.

Please vote
+1 for accepting corinthia into incubator
0 for dont care
-1 for not accepting corinthia into incubator (please add a reason).

Vote is open until Sunday december 7, 23:30 UTC. If needed the period can
be prolonged.

Thanks for your vote.
on behalf of project corinthia
jan i.

[ ... ]


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

RE: [PROPOSAL] [DISCUSSION] Corinthia Abstract

[Dennis E. Hamilton]

I put together an abstract in the Corinthia Podling Proposal.  It is a bit 
lengthy and requires review that it captures the essence of what Corinthia is 
for without over/under-stepping.

Here is the text also added to 
https://wiki.apache.org/incubator/CorinthiaProposal,


Corinthia converts among document file formats via transformation through an 
HTML-grounded intermediary.  The selection of document file formats is 
expandable by addition of import and export plugins.  

Editing in Corinthia is via a responsive editor, implemented in JavaScript and 
HTML (CSS), that works on the web, in the cloud, and also adapts across device 
form factors for practical use on mobile devices, tablets, and touch-enabled as 
well as keyboard-oriented interfaces.  Corinthia document viewing and editing 
is on the intermediate form, limited to common, widely-supported features. 
Corinthia is not a comprehensive substitute for format-specific authoring, 
editing, and final-form printing/production software.

To avoid irreversible loss of features from imported documents, Corinthia 
encapsulates unsupported feature occurrences in a form that can be recovered 
from the intermediate as part of subsequent export to the same or different 
format.

Identification and confirmation of inter-convertible features of different 
formats for dependable import and export involves development of extensive test 
documents in the different formats.  There is profiling of the extent to which 
standardized formats are supported in practice, with identification of 
deviations and implementation-dependent choices that impact convertibility.  

All of the Corinthia test cases, profiling, plugin development, libraries, and 
utilities are reusable resources to other projects.  All development of 
source-code for binaries is in portable C Language for multi-platform 
compilation as well as API wrapping for delivery to other programming models, 
such as for Python, .NET, Java, and Node.js.  Document format file import and 
export plugins may be adaptable as import-export extensions used with other 
document-processing software.


-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Wednesday, November 26, 2014 03:13
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] [DISCUSSION] Corinthia for Incubation.

Hi all.

We, at the project, hope that the lack of discussion is not a negative sign
!

In the meantime, we have been working behind the scenes, and a couple of
things have happened:

- The proposal is now on the incubator wiki / corinthiaProposal
https://wiki.apache.org/incubator/CorinthiaProposal

- Dennis Hamilton (incubator, aoo committer) joined the initial committer
list. His expertise in especially document formats will be of great value
to the project, Dennis is also providing a lot of good feedback on our open
issues.

- Daniel Gruno (Humbedooh) has volunteered to be mentor for the project. We
look forward to guidance in all the tricky paper work.

- Talks are being prepared for ACNA.


We are more than happy to answer any questions and make requested changes.

on behalf of the project
jan i


On 24 November 2014 at 22:14, Ross Gardler (MS OPEN TECH) 
ross.gard...@microsoft.com wrote:

 There are some passing similarities with Forrest here. I'm not suggesting
 any changes to the proposal, just flagging that the intermediate format
 approach described here is the approach Forrest takes. The focus for
 Forrest was not on document format conversion but there is a lot of
 experience there in using intermediate formats.

 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation

 -Original Message-
 From: jan i [mailto:j...@apache.org]
 Sent: Monday, November 24, 2014 12:37 PM
 To: jan i
 Cc: general@incubator.apache.org
 Subject: Re: [PROPOSAL] [DISCUSSION] Corinthia for Incubation.

 Hi.

 Sorry, somebody hit me with the big GIT hammer !! I did something with git
 that should not be done.

 The correct text is:
[ ... ]


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

Request to be part of contributor group

[Dennis E. Hamilton]

I also request addition to the contributor group for the purpose of working 
on the Corinthia proposal.

My Incubator Wiki User ID is orcmid.

-Original Message-
From: Louis Suárez-Potts [mailto:lui...@gmail.com] 
Sent: Wednesday, November 26, 2014 06:28
To: general@incubator.apache.org
Subject: request to be part of contributor group

Hi
I’d like to be included in the contributor group so that I can edit the 
Corinthia proposal and otherwise contribute.

thanks
louis
-
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: Proposals - wiki required?

[Dennis E. Hamilton]

+1 on Jan's observations, below.

Also, from my experience with the Proposal for Apache OpenOffice and a few 
others, there is considerable refinement of proposals from first draft to the 
version that is essentially frozen at the time of podling-acceptance balloting. 
 The Wiki is perfect for this, as is community involvement in the refinement. 
(Some podling proposals are a bit more closely-held than the way the AOO one 
was developed and edited, so *maybe* that doesn't matter so much.)  The key 
thing is that early proposals are moving targets and while some are advanced by 
a single benevolent editor, it is useful to have a wiki for the ground-truth du 
jour, addition of initial committers, etc.

-Original Message-
From: jan i [mailto:j...@apache.org] 
Sent: Sunday, November 23, 2014 11:00
To: general@incubator.apache.org
Subject: Re: Proposals - wiki required?

On 23 November 2014 at 19:41, Alan Cabrera l...@toolazydogs.com wrote:

[ ... ]

 As for storing them in one place after acceptance, why?

SImple so that new recruits can go and get ideas of how to interpret the
different headlines. The headlines might be simple to you, but I had to
look at some proposals to understand some of the headlines.

I am champion for 2 projects (one seems to go in another direction) and
found it very useful to point the projects at the wiki. It saved my quite a
lot of explanations (and discussions). I have found that projects who want
to join, dont really understand how/why a proposal is needed, giving
examples of successful projects makes that part a lot easier.



 Adding strongly worded shoulds dilutes guidelines and adds to the
 reading homework of new podlings that will already have the good sense to
 use a wiki, or something better that us old folk haven't thought of.


Like you I am against rules, and I don't care whether its wiki or foo, I
simply like to know where I can find real life proposals. My idea of
using should instead of rule was to signal, that it must be stored
somewhere, preferable (for now) in wiki.

Seen with my iPMC hat on, it is a bit of history that we should not throw
away, I used it a couple of times on a couple of projects to see how they
have evolved.

[ ... ]


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

RE: Convenience Binary Policy

[Dennis E. Hamilton]

orcnote in-line.
-Original Message-
From: br...@apache.org [mailto:br...@apache.org] 
Sent: Thursday, October 23, 2014 01:47
To: general@incubator.apache.org
Subject: Re: Convenience Binary Policy

On 22.10.2014 03:02, Justin Mclean wrote:
 Hi,

 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.
 You may possibly be forgetting about Category B licensed dependancies. These 
 may only be included in binary form in an Apache product. [1] They would be 
 still be consider open source by most people :-) The source does exist it's 
 just not able to be included in a Apache product due to the weak copy left 
 provision the licences include.

I have trouble visualising how any ASF project could have /mandatory/
dependencies on anything from the B-list.

orcnote
For an indication of the kinds of non-ASF dependencies that go into
Apache OpenOffice binary distributions, take a look at this list: 
http://sourceforge.net/projects/oooextras.mirror/files/?source=directory. 
 
(To see the full names, mouse over the names in the Name column.)
There is a non-neglible potential for more Category B dependencies
in the future, now that LibreOffice releases are under the MPL 2.0.
/orcnote


-- Brane



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

RE: Convenience Binary Policy

[Dennis E. Hamilton]

orcnote below,

-Original Message-
From: shaposh...@gmail.com [mailto:shaposh...@gmail.com] On Behalf Of Roman 
Shaposhnik
Sent: Wednesday, October 22, 2014 21:37
To: general@incubator.apache.org
Subject: Re: Convenience Binary Policy

On Tue, Oct 21, 2014 at 5:57 AM, Marvin Humphrey mar...@rectangular.com wrote:
 On Mon, Oct 20, 2014 at 10:26 PM, Roman Shaposhnik ro...@shaposhnik.org 
 wrote:

 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.

 And yet that issue keeps rearing its ugly head. Given the amount
 of traffic I've seen around clarifying some finer (and not so fine)
 points of release/licensing implication it is about time we start
 an FAQ on that. Me thinks at least.

 We have several release FAQs spread across the ASF, though -- which, taken
 together, are comprehensive beyond the point of excess.

 The problem is that we lack a concise policy document.  That's where the ASF
 release policy codification proposal as worked through on legal-discuss a few
 months ago is supposed to help.

   http://s.apache.org/aGm
   https://github.com/rectang/asfrelease

 It's delayed because I got swamped but it seems that the need has not
 diminished.

It would be really nice if you/we could finish this. That said, I
still maintain,
that focusing exclusively on source releases will simplify our life greatly.
IOW, Apache FOO version x.y.z can only designate a source release.

I understand the need of projects like OO to provide binaries of some sort,
I just don't understand why do they have to be 'blessed' by ASF. Once
source gets built and packaged a whole new set of issues kick in. I don't
think the foundation is well prepared to deal with those. We might as
well admit it explicitly.

orcnote
   That's fine.  However the Apache OpenOffice project has an important
   need to establish the provenance and integrity of the end-user 
   binary distributions it makes.  There are an incredible variety of
   poseur builds that are distributed by third parties for the purpose
   of embedding adware. These also pose as official releases, including
   all of the links to support, pinging for updates, etc.  When folks come
   with complaints, the project lists refer them to the authentic builds
   that the project curates.  This is a significant portion of support
   requests to users @oo.a.o and dev @oo.a.o.
  Now that there is code-signing for the Windows (and Mac?) builds,
   this is going to become easier to fend off.  Having the binary distros
   available from the operating-system store applications will provide
   further safeguards.
  It is true that the package systems of *nix systems is helpful
   in terms of authenticity and sourcing of OS-integrated builds and 
   their updates.  There is no such source for 80% of the community of
   Apache OpenOffice users.  Before, that community was served by Sun,
   Oracle, Novell, and IBM.  Now, but for the Apache OpenOffice project
   and The Document Foundation, there are no prominent, responsible parties
   for distributions to the Windows and Mac communities of users.
  I do agree that this can be considered a project-specific arrangement
   and does not need to be under ASF governance as strictly as for source
   distributions, so long as the more-than-merely-convenient binary
   distributions do not reflect badly on the foundation.  Guidance would
   still be helpful, since there are many projects and podlings need some
   touchstone to encourage good behavior in this area.
/orcnote

Thanks,
Roman.

P.S. To be super explicit: I'm not saying that binary artifacts should be
banned, rather that a binary artifact compiled by a member of a project
is no different from one compiled by RedHat or Debian and thus requires
no special treatment whatsoever.

-
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: [VOTE] Release Apache Calcite 0.9.1 (incubating)

[Dennis E. Hamilton]

I suggest that the release manager and anyone else in the KEYS file should 
have added key fingerprints to their Apache profiles at 
https://id.apache.org/.

This will have their PGP keys refreshed regularly under their Apache ID at 
https://people.apache.org/keys/committer/.

With regard to an identifiable association of the key, presence in this 
manner connects the PGP key to The Apache ID by demonstration of control 
over the committer's Apache profile.

One can go farther by adding the user...@apache.org to an User-ID on the key.
Verifying that one has control over that e-mail address (and all User-IDs)
Is done by registering the public key at the PGP Global Directory service at 
https://keyserver2.pgp.com/vkd/GetWelcomeScreen.event and completing the
ceremony specified there.  After the ceremony is completed, you can retrieve
your counter-signed PGP key from that service and synchronize it to a public
PGP key server.  The ASF will pick it up on a future refresh.

Use of the key from the Apache ID list has certain valuable properties.  It is
not fixed, as in the key files in the project and in distributions.  That means
any additional (web-of-trust) certifications of the keys association with a 
committer are updated automatically.  That includes any revocations.


 -- Dennis E. Hamilton
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail



-Original Message-
From: Justin Mclean [mailto:jus...@classsoftware.com] 
Sent: Sunday, October 12, 2014 22:29
To: general@incubator.apache.org
Subject: Re: [VOTE] Release Apache Calcite 0.9.1 (incubating)

Hi,

 First, the signing key is present in SVN, but has not been uploaded to the
 standard key-servers, nor has it been signed by anyone.

I found it here:
https://pgp.mit.edu/pks/lookup?search=Julian+Hydeop=index

Even if the key is part of a web trust it may not be part of everyone's web of 
trust. I'd see that as a hard requirement to meet.

Thanks,
Justin
-
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: [PROPOSAL] Silk as new Incubator project

[Dennis E. Hamilton]

orcnote below

-Original Message-
From: dwhyt...@gmail.com [mailto:dwhyt...@gmail.com] On Behalf Of Donald Whytock
Sent: Friday, September 19, 2014 13:52
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Silk as new Incubator project

On Fri, Sep 19, 2014 at 12:57 PM, Roman Shaposhnik ro...@shaposhnik.org
wrote:

 On Fri, Sep 19, 2014 at 8:36 AM, Christian Grobmeier
 grobme...@gmail.com wrote:
  Not saying anything on the proposal itself, I would be concerned because
  of the name Silk.
  There is this:
  http://lucidworks.com/product/integrations/silk/
[ ... ]
* Apache Silk (preferable name)
* Apache Sylk
* Apache Memstor
* Apache Ignite

 It would be very useful if we can get feedback on
 the most/least pref. ones from that list.

[ ... ]

I'd think Ignite is a standard-enough English word that no one could
reasonably claim exclusivity (but IANAL).

Don

orcnote
Ignite is used within software names, as in AIR Music Technology Ignite.  The 
splash screen says Ignite by air.  I have no idea whether Apache Ignite is 
enough for non-confusion.  Too bad about Sylk.
/orcnote


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

RE: [VOTE] Accept Olingo proposal as an incubating project

[Dennis E. Hamilton]

+1 (non-binding)

On Mon, Jul 1, 2013 at 11:38 AM, Florian Müller f...@apache.org wrote:

 Hi all,

 I'd like to call a VOTE for acceptance of Olingo into the Apache incubator.

 The proposal is pasted at the bottom on this email.
 The corresponding wiki page is: http://wiki.apache.org/**
 incubator/OlingoProposal http://wiki.apache.org/incubator/OlingoProposal

 [ ] +1 Accept Olingo into the Apache incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept Olingo into the incubator because...



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

[OT] The promise of Olingo

[Dennis E. Hamilton]

Today, the Bing wall-paper features a beautiful image of a ring-tailed cat 
(clearly adaptable to an O'Reilly cover, if it hasn't been already).

Having read up on Olingo, I immediately thought raccoon and indeed, this is a 
Procyonidon cousin of the Olingo, 
http://en.wikipedia.org/wiki/Ring-tailed_Cat.

I'm sharing this because the Bing image is great and also because of an 
observation made about the domestic cat and the ring-tailed cat (not a feline) 
-- both have succeeded in domesticating humans by virtue of their habits 
(theirs, ours, whatever).

Let us trust that at last, the OAuth Olingo can do the same in the realm of 
safe habits in cyberspace.

 - Dennis

PS: If you go to http://bing.com, you'll see that the image is a video of the 
fellow.  You might need to click through earlier images to see it in its Utah 
red-rock environment.

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org] 
Sent: Friday, June 21, 2013 08:42 AM
To: 'Klevenz, Stephan'; general@incubator.apache.org
Subject: RE: [PROPOSAL] OData Proposal for Incubator

Stephen,

I support your choice to have a different name.  

 - Dennis

I'm not sure how Olingo is pronounced in Spanish but I'm certain there will 
be much fun creating artwork of the little critter.  It looks like an animal 
that must be on the cover of an O'Reilly book somewhere.  (I find raccoons, 
their cousins, more appealing, except when they are pillaging the cherry tree 
at my house.)

[ ... ]


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

That page talks about transfer of copyright and addition of Apache copyright 
notices on the code as imported.  Huh?

Why aren't the guidelines for transfer of cleaned-up contributions under SGAs 
being followed, and an SGA being filed that details the contribution?

 - Dennis

-Original Message-
From: Noah Slater [mailto:nsla...@apache.org] 
Sent: Wednesday, June 26, 2013 06:03 AM
To: general@incubator.apache.org
Subject: Re: [IP CLEARANCE] BigCouch

Woop! Thanks Bob! +1


On 26 June 2013 13:55, Robert Newson rnew...@apache.org wrote:

 Cloudant has donated the source code artifact detailed at [1] to the ASF.
 This email is to request lazy consensus from the IPMC for the IP
 clearance of this donation.

 B

 [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html

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




-- 
NS


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

Under the heading Copyright there is an item with text Check and make sure 
that the papers that transfer rights to the ASF [have] been received.  It is 
only necessary to transfer rights for the package, the core code, and any new 
code produced by the project.

In the next box it says

Check and make sure that the files have been donated have been updated to 
reflect the *new* ASF copyright. ...  [emphasis mine].

It is my understanding that an SGA is not a transfer of rights but a grant of 
license.  This language is all wrong, wherever it comes from.  It suggests what 
appears to be a copyright transfer when everything we are told around here is 
that the ASF neither requires nor does such things.  Furthermore, adding ASF 
copyright notices in the headers for individual files that are otherwise 
unchanged is very naughty.  (Unless, of course, there has indeed been a 
copyright transfer, and I'm not all that sure about even that case.)

 - Dennis

PS: And, of course, the license grant is about more than the exclusive rights 
of copyright holders, too.  In any case, the non-exclusive licenses granted in 
SGAs and CLAs are not transfers.  (Since standing is much in the news today, 
another way to put it is that the ASF has no power to sue for infringement of 
copyright in the contributed works, nor any patent infringement related to the 
use of the contributed works.)

-Original Message-
From: Noah Slater [mailto:nsla...@apache.org] 
Sent: Wednesday, June 26, 2013 08:14 AM
To: general@incubator.apache.org; dennis.hamil...@acm.org
Subject: Re: [IP CLEARANCE] BigCouch

Dennis, can you clarify your concerns please?

The page you are looking at is generated from a template. Bob has simply
filled in the dates as he stepped through the process.

Which specific guidelines do you not believe have been followed?

Why do you believe that an SGA has not been filed?


On 26 June 2013 16:05, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

 That page talks about transfer of copyright and addition of Apache
 copyright notices on the code as imported.  Huh?

 Why aren't the guidelines for transfer of cleaned-up contributions under
 SGAs being followed, and an SGA being filed that details the contribution?

  - Dennis

 -Original Message-
 From: Noah Slater [mailto:nsla...@apache.org]
 Sent: Wednesday, June 26, 2013 06:03 AM
 To: general@incubator.apache.org
 Subject: Re: [IP CLEARANCE] BigCouch

 Woop! Thanks Bob! +1


 On 26 June 2013 13:55, Robert Newson rnew...@apache.org wrote:

  Cloudant has donated the source code artifact detailed at [1] to the ASF.
  This email is to request lazy consensus from the IPMC for the IP
  clearance of this donation.
 
  B
 
  [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 NS


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




-- 
NS


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

RE: [IP CLEARANCE] BigCouch

[Dennis E. Hamilton]

I don't think I've seen the template before, or it was too long ago and I 
failed to notice at the time.

Noah has explained my concern and added discussion on remedies.  (I won't be 
creating a JIRA issue and it appears that others have a better sense of what 
would express what is appropriate.  I just saw what was clear to me was 
inappropriate.)

With respect to that checklist, my only lingering concern is that it is 
difficult to know what was actually done, following the instructions as given, 
especially with regard to the headers of files, given how the item is worded.

I would definitely change the heading from Copyright to Licensing too.

 - Dennis

-Original Message-
From: Robert Newson [mailto:rnew...@apache.org] 
Sent: Wednesday, June 26, 2013 09:36 AM
To: general@incubator.apache.org; dennis.hamil...@acm.org
Cc: Noah Slater
Subject: Re: [IP CLEARANCE] BigCouch

Dennis,

I'm following the instructions I'm given, I don't know if this is the
place to comment on the process the incubator project has been
following up to this point. Have I followed it incorrectly? I don't
know you personally, are you pointing out problems with *this* ip
clearance thread in particular or are you commenting on the template
itself? Had you seen the template before today?

B.


On 26 June 2013 17:27, Dennis E. Hamilton dennis.hamil...@acm.org wrote:
 Under the heading Copyright there is an item with text Check and make sure 
 that the papers that transfer rights to the ASF [have] been received.  It is 
 only necessary to transfer rights for the package, the core code, and any new 
 code produced by the project.

 In the next box it says

 Check and make sure that the files have been donated have been updated to 
 reflect the *new* ASF copyright. ...  [emphasis mine].

 It is my understanding that an SGA is not a transfer of rights but a grant of 
 license.  This language is all wrong, wherever it comes from.  It suggests 
 what appears to be a copyright transfer when everything we are told around 
 here is that the ASF neither requires nor does such things.  Furthermore, 
 adding ASF copyright notices in the headers for individual files that are 
 otherwise unchanged is very naughty.  (Unless, of course, there has indeed 
 been a copyright transfer, and I'm not all that sure about even that case.)

  - Dennis

 PS: And, of course, the license grant is about more than the exclusive rights 
 of copyright holders, too.  In any case, the non-exclusive licenses granted 
 in SGAs and CLAs are not transfers.  (Since standing is much in the news 
 today, another way to put it is that the ASF has no power to sue for 
 infringement of copyright in the contributed works, nor any patent 
 infringement related to the use of the contributed works.)

 -Original Message-
 From: Noah Slater [mailto:nsla...@apache.org]
 Sent: Wednesday, June 26, 2013 08:14 AM
 To: general@incubator.apache.org; dennis.hamil...@acm.org
 Subject: Re: [IP CLEARANCE] BigCouch

 Dennis, can you clarify your concerns please?

 The page you are looking at is generated from a template. Bob has simply
 filled in the dates as he stepped through the process.

 Which specific guidelines do you not believe have been followed?

 Why do you believe that an SGA has not been filed?


 On 26 June 2013 16:05, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

 That page talks about transfer of copyright and addition of Apache
 copyright notices on the code as imported.  Huh?

 Why aren't the guidelines for transfer of cleaned-up contributions under
 SGAs being followed, and an SGA being filed that details the contribution?

  - Dennis

 -Original Message-
 From: Noah Slater [mailto:nsla...@apache.org]
 Sent: Wednesday, June 26, 2013 06:03 AM
 To: general@incubator.apache.org
 Subject: Re: [IP CLEARANCE] BigCouch

 Woop! Thanks Bob! +1


 On 26 June 2013 13:55, Robert Newson rnew...@apache.org wrote:

  Cloudant has donated the source code artifact detailed at [1] to the ASF.
  This email is to request lazy consensus from the IPMC for the IP
  clearance of this donation.
 
  B
 
  [1] http://incubator.apache.org/ip-clearance/couchdb-bigcouch.html
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 NS


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




 --
 NS


 -
 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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

Stephen,

I support your choice to have a different name.  

 - Dennis

I'm not sure how Olingo is pronounced in Spanish but I'm certain there will 
be much fun creating artwork of the little critter.  It looks like an animal 
that must be on the cover of an O'Reilly book somewhere.  (I find raccoons, 
their cousins, more appealing, except when they are pillaging the cherry tree 
at my house.)

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Friday, June 21, 2013 06:34 AM
To: dennis.hamil...@acm.org; general@incubator.apache.org
Subject: Re: [PROPOSAL] OData Proposal for Incubator
Importance: High

Hi Dennis,

Sorry for coming back so late to your valuable feedback. After re-thinking
about the trademark issue and your thoughts about confusion we come to
conclusion to use a different name for the project. I would like to change
our project name to

Apache Olingo

Olingo is a little bear [1] and that name should avoid any confusion with
the OASIS standard or any other potential trademark holder. If there are
no concerns then I will go and change our proposal to Apache Olingo.

WDYT?

Regards,
stephan

[1] http://en.wikipedia.org/wiki/Olingo

On 18.06.13 15:58, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

I think there will be an issue with regard to trademarks and you will
have to deal with folks seeing the trademark of Apache OData as a
land-grab at OData itself.  The simplicity you think is avoiding
confusion is, in that respect, causing confusion.

In any case, it is always wise to avoid confusion of a (standard)
specification, even OASIS Standard OData v3.0 or whatever, with the name
of an implementation.  OASIS is going to make their own claims about some
of those terms as well, if the past practice is any guide.

 - Dennis

The ODF Toolkit snuck by, much to my dismay, even capturing odf as their
incubator repository name, but they may have to deal with that to
graduate to a TLP.

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com]
Sent: Tuesday, June 18, 2013 06:27 AM
To: general@incubator.apache.org
Cc: dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] OData Proposal for Incubator

Hello Dennis,

Good point! The project naming was a challenge for us and maybe I just can
explain why we prefer Apache OData as project name. The main reason is
search. 

Someone who is interested in OData will use this term and the result page
will today list odata.org as the protocols homepage, Wikipedia which is
fine and the OASIS TC. In future we would like to see that Apache OData is
highly ranked and completes the search result list.

If we use a different name someone has to know this name and has to search
for it explicitly. We would like to keep it simple and avoid confusion.

We had also a look into the ASF project naming guidelines and I think most
of the points there are considered by the name Apache OData.


Regards,
Stephan

On 18.06.13 03:28, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

I think one concern here is appropriation of a generic, specified-tied
name to an implementation, even a reference implementation.

Apache OData seems over-reaching in that respect, especially since
there are other projects, at ASF and elsewhere, that may employ OData
bindings and services of one sort or another.
[ ... ]



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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

I think there will be an issue with regard to trademarks and you will have to 
deal with folks seeing the trademark of Apache OData as a land-grab at 
OData itself.  The simplicity you think is avoiding confusion is, in that 
respect, causing confusion.

In any case, it is always wise to avoid confusion of a (standard) 
specification, even OASIS Standard OData v3.0 or whatever, with the name of an 
implementation.  OASIS is going to make their own claims about some of those 
terms as well, if the past practice is any guide.

 - Dennis

The ODF Toolkit snuck by, much to my dismay, even capturing odf as their 
incubator repository name, but they may have to deal with that to graduate to a 
TLP.

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Tuesday, June 18, 2013 06:27 AM
To: general@incubator.apache.org
Cc: dennis.hamil...@acm.org
Subject: Re: [PROPOSAL] OData Proposal for Incubator

Hello Dennis,

Good point! The project naming was a challenge for us and maybe I just can
explain why we prefer Apache OData as project name. The main reason is
search. 

Someone who is interested in OData will use this term and the result page
will today list odata.org as the protocols homepage, Wikipedia which is
fine and the OASIS TC. In future we would like to see that Apache OData is
highly ranked and completes the search result list.

If we use a different name someone has to know this name and has to search
for it explicitly. We would like to keep it simple and avoid confusion.

We had also a look into the ASF project naming guidelines and I think most
of the points there are considered by the name Apache OData.


Regards,
Stephan

On 18.06.13 03:28, Dennis E. Hamilton dennis.hamil...@acm.org wrote:

I think one concern here is appropriation of a generic, specified-tied
name to an implementation, even a reference implementation.

Apache OData seems over-reaching in that respect, especially since
there are other projects, at ASF and elsewhere, that may employ OData
bindings and services of one sort or another.
[ ... ]


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

RE: [PROPOSAL] OData Proposal for Incubator

[Dennis E. Hamilton]

I think one concern here is appropriation of a generic, specified-tied name to 
an implementation, even a reference implementation.

Apache OData seems over-reaching in that respect, especially since there are 
other projects, at ASF and elsewhere, that may employ OData bindings and 
services of one sort or another.

-Original Message-
From: Klevenz, Stephan [mailto:stephan.klev...@sap.com] 
Sent: Monday, June 17, 2013 08:36 AM
To: general@incubator.apache.org
Subject: [PROPOSAL] OData Proposal for Incubator

Dear ASF members,

We would like to propose the OData project to the Incubator.

The OData Proposal is available at: 
https://wiki.apache.org/incubator/ODataProposal

We welcome your feedback and suggestions.

Thanks!

Stephan Klevenz


[ ... ]



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

RE: Correct process for signing keys?

[Dennis E. Hamilton]

@Christian

The other advantage of the people list is that it is automatically updated from 
the federation of PGP key servers so it reflects the latest web of trust and 
also, I presume, any revocation.  

In some cases, PMC wide is a bit too generous though.  I think the release 
manager's Apache ID is better, using https://people.apache.org/keys/id.asc. 
 This is probably more confidence-inspiring that the web of trust itself for 
those who do not participate in Apache projects and don't know who those folks 
who've counter-signed the certificate happen to be.  In that case, the lock to 
an ASF committer is valuable.  (It is unfortunate that committers and 
especially release managers are often not visible by their id@apache.org, 
thus providing even more confidence in the connection for observers.)

 - Dennis

PS: I notice I just did the thing I'm complaining about.  But I don't think 
orcmid@ a.o is subscribed to this list [;).

-Original Message-
From: Christian Grobmeier [mailto:grobme...@gmail.com] 
Sent: Sunday, June 2, 2013 01:24 AM
To: general@incubator.apache.org
Subject: Re: Correct process for signing keys?

Hi Andrew,

here are some basic docs:

http://www.apache.org/dev/release-signing.html
http://www.apache.org/dev/openpgp.html#update

I could not find information on your specific question. At log4php we were
curious recently about the same and decided to go with this:
http://www.apache.org/dist/logging/log4php/KEYS

But we made sure it would match this:
https://people.apache.org/keys/group/logging-pmc.asc

Basically my understanding is the one from people would be fine alone.
There is some danger people would take the KEYS file from a mirror which is
to my knowledge not possible from people.

My 2 cents- hopefully somebody with more knowledge on that matter (infra)
can add a note.

Cheers



On Thu, May 30, 2013 at 10:44 PM, Andrew Phillips andr...@apache.orgwrote:

 Hi all

 Apologies in advance if this is not the correct audience for this
 question: what is the correct process now for publishing signing keys for
 releases? jclouds currently has a KEYS file [1]; there is another
 (different) file containing keys in the groups list [2] on people.apache,
 and most individual committers *also* have their personal keys
 automatically retrieved via people.apache (e.g. [3]).

 In an email thread on this topic Brian (McCallister) indicated that:

  Upon investigation, if release signing keys are published via
 https://people.apache.org/**keys/ https://people.apache.org/keys/ then
 we don't need a KEYS file and should remove it.

 -Brian


 In that case, I'd be grateful if you could give some guidance on what the
 validity of the other approaches (KEYS file published somewhere or group
 KEYS file) is, and what we should do with those files, if anything.

 Thanks!


 Andrew

 [1] 
 http://www.apache.org/dist/**incubator/jclouds/KEYShttp://www.apache.org/dist/incubator/jclouds/KEYS
 [2] 
 https://people.apache.org/**keys/group/jclouds.aschttps://people.apache.org/keys/group/jclouds.asc
 [3] 
 https://people.apache.org/**keys/committer/andrewp.aschttps://people.apache.org/keys/committer/andrewp.asc

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




-- 
http://www.grobmeier.de
https://www.timeandbill.de


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

RE: [META DISCUSS] talking about the overall state of this PMC

[Dennis E. Hamilton]

It's often called a dead-man's switch.  I think the term applied originally to 
locomotive engineers and also metro car drivers.  (I'm not sure what a dead 
pilot switch could accomplish in an aircraft.)

I think having mentors review and sign PPMC status reports is an effective 
dead mentor's switch [;).

 - Dennis

-Original Message-
From: Alan Cabrera [mailto:l...@toolazydogs.com] 
Sent: Saturday, May 11, 2013 10:10
To: general@incubator.apache.org
Subject: Re: [META DISCUSS] talking about the overall state of this PMC


On May 11, 2013, at 7:33 AM, Joseph Schaefer joe_schae...@yahoo.com wrote:

 Frankly I find the notion that the board will do a better job of MENTORING
 these projects than the IPMC to be batshit insane, but that's just me.
 We need manpower, and there is plenty of that available amongst the competent
 volunteers who actively participate in these projects.  Let's just do
 what's easiest for once and promote these folks to the IPMC in order
 to get the job done right.  It's a proven model that we need to stop
 fighting.


Yes, shuttling the kids off the the grandparents is not going to solve 
anything.  If individuals on the board have the bandwidth to help they should 
come over here. There's nothing specific about the auspices of the board that 
would improve the situation.


I personally think that we have almost enough people to mentor.  I think that 
the burnout comes from our constant churning of policy and lack of tooling to 
make mundane tasks easier.

For example, maybe
better reminders for reports
automatic nudging of mentors who have not signed reports
dead pilot buttons to detect inactive mentors (Is it called a dead pilot button)
maybe a standard to podling releases to make vetting easier - i.e. apply tooling
changes/additions to vetting procedures taking place outside of release votes. 
(ok not a tooling issue)


Regards,
Alan



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

RE: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

[Dennis E. Hamilton]

Regarding (4),

Once you've created the signature file, simply prepend text to it in front of 
the 

-BEGIN PGP SIGNATURE-

line.  You can have something like

Signature by Release Manager Jordan Zimmerman
Public Key Certificate: 
  https://people.apache.org/keys/committer/randgalt.asc
-BEGIN PGP SIGNATURE-
[ ... ]

I suppose it would be useful to also link to a page on how to check the 
signature.

It seems strange to have that in the clear, but it is harmless.

I just confirmed that text in front of the initial ASCII armor line is simply 
ignored by GnuPG and I suspect all other PGP signature verification 
implementations.

 - Dennis

PS: Here's a page that describes how to check, although a group of keys is 
recommended in that case:
http://www.openoffice.org/download/checksums/3.4.1_checksums.html#howto.

-Original Message-
From: Jordan Zimmerman [mailto:randg...@apache.org] 
Sent: Wednesday, May 01, 2013 15:54
To: general@incubator.apache.org
Subject: Re: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

 1. Add a UID having your Apache ID, randgalt@ apache.org, in that PGP 
 public-key certificate.  You can indicate that it is your preference for code 
 signing, if you desire.
That UID is there already. Can you explain what's missing?

 2. Log into your randgalt@ a.o profile at https://id.apache.org/ and 
 provide the fingerprint of your key as part of your profile.
done

 3. BONUS RECOMMENDATION.  Do not put a copy of the public key in the 
 repository.
Already removed. My .asc file should show up in /keys/committer/ soon.

 4. GRAND PRIZE RECOMMENDATION.  For all external signatures that you create, 
 add to the ascii-armored signature text (outside of the armor) a link to 
 https://people.apache.org/keys/committer/randgalt.asc.
No comprende. I'll research how to do this.

-JZ
-
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: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

[Dennis E. Hamilton]

Four suggestions:

 1. Add a UID having your Apache ID, randgalt@ apache.org, in that PGP 
public-key certificate.  You can indicate that it is your preference for code 
signing, if you desire.

 2. Log into your randgalt@ a.o profile at https://id.apache.org/ and provide 
the fingerprint of your key as part of your profile.  This will accomplish two 
things: (1) It establishes that the fingerprint was provided by someone having 
the ASF credentials for randgalt@ a.o; (2) it causes the public key to be added 
to a secure location as file 
https://people.apache.org/keys/committer/randgalt.asc.  That file is 
regularly synchronized with PGP key services and confirms that it is the key 
provided by randgalt@ in step (1) and also reflects (web-of-trust) 
certifications of that key by others as well as any revocation if that becomes 
necessary.

 3. BONUS RECOMMENDATION.  Do not put a copy of the public key in the 
repository.  Instead, put a link to 
https://people.apache.org/keys/committer/randgalt.asc there, if desired.  If 
it is in a file called KEYS, update the instructions to refer to the locations 
in the committer keys folder.  (If there will be many release managers and 
signers in the future, you can instead instruct users to obtain all Curator 
committer keys from https://people.apache.org/keys/group/curator.asc once 
Curator becomes an ASF top-level project.)

 4. GRAND PRIZE RECOMMENDATION.  For all external signatures that you create, 
add to the ascii-armored signature text (outside of the armor) a link to 
https://people.apache.org/keys/committer/randgalt.asc.

The idea is to use access to your Apache profile as an additional factor beyond 
your self-signing of the certificate and any web-of-trust certifications of 
your certificate.  It also lets those non-ASF folk who desire to verify 
signatures know whose signature the verification is expected to confirm and 
that the signer is an ASF committer.

 - Dennis

 
-Original Message-
From: Jordan Zimmerman [mailto:jor...@jordanzimmerman.com] 
Sent: Wednesday, May 01, 2013 13:39
To: general@incubator.apache.org
Subject: Re: [CANCEL] [VOTE] Release Apache Curator 2.0.0-incubating (updated)

That was (yet another) misunderstanding on my part. The KEYS are now in the 
standard (?) location:

http://www.apache.org/dist/incubator/curator/KEYS

On May 1, 2013, at 1:32 PM, Marvin Humphrey mar...@rectangular.com wrote:

 On Wed, May 1, 2013 at 1:07 PM, David Nalley da...@gnsa.us wrote:
 While we are at it, a link to your project's KEYS file would be
 helpful as well.
 
 Just unzip the archive. ;)
 
 Curator folks, please find another way to distribute the KEYS file.
 Distributing it embedded in the source archive is worthless at best.
 
 Marvin Humphrey
 
 -
 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: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))

[Dennis E. Hamilton]

Not so fast about dispensing with Category B requirements for pointers to 
source code.

In MPL 2.0, a common case, it is very clear that location of the source code is 
one of the requirements for distribution of the code in executable form or 
within a larger work (distributed in binary), that there must be identification 
of the origin of the code and where source code is available.  It is 
insufficient to simply include the license (by reference or otherwise).  

MPL 2.0 has a handy Appendix (which I have never seen followed, but I don't get 
out much) that stipulates a suitable notice.  The key is that it must be 
possible for a recipient of the executable to directly find the specific source 
code at a suitably archival location.

This is also a requirement for distribution of most Category X works in binary 
form, and that applies in some cases where Category X licenses are bundled in 
binary distributions under sanitary conditions that satisfy ASF requirements.

 - Dennis

PS: That these requirements are typically satisfied in the breach is not, it 
seems to me, something that is appropriate for the ASF to countenance.  That 
there are projects out there that have never complied with such requirements is 
not justification.  For me, it does not serve the public interest, nor does it 
demonstrate the care for the provenance of contributions (and dependencies) 
that should be the norm.  Most of all, being careless about this undervalues 
the gift that such dependencies represent to projects that find reuse more 
convenient than not.

PPS: There is also a forensic value to satisfying these license requirements.  
In these days of rapid disclosures of security flaws all over the landscape, it 
is important for a recipient of executable code to know whether or not 
vulnerability disclosures apply to dependencies in the distribution they are 
relying upon and whether mitigation is called for.  (Although this is also of 
some benefit to adversaries, it must always be assumed that determined 
adversaries already know.)

-Original Message-
From: Sergio Fernández [mailto:sergio.fernan...@salzburgresearch.at] 
Sent: Tuesday, April 23, 2013 00:32
To: general@incubator.apache.org
Cc: Marvin Humphrey
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 
3.0.0-incubating (RC8))

Hi Marvin,

thanks for your time analysing our release. Please, find my reply inline.

On 18/04/13 02:30, Marvin Humphrey wrote:
 On Wed, Apr 17, 2013 at 11:00 AM, Sebastian Schaffert  wrote:
[ ... ]
 - for dependencies of category B, [2] specifies that Although the source
must not be included in Apache products, the NOTICE file, which is
required to be included in each ASF distribution, must point to the source
form of the included binary (more on that in the forthcoming Receiving
and Releasing Contributions document)., a fact that is not mentioned in
any of the other documents.

 This passage has somehow escaped my notice until now.  Based on my
 understanding about the origins of the NOTICE file, it does not ring true.  It
 seems to me that what works for category A should also work for category B:
 reference/quote the license in LICENSE and address mandatory attribution
 requirements in NOTICE.  The goal is to satisfy the licensing requirements of
 the dependency, not to give credit -- so IMO linking only makes sense if
 that's a requirement of the dependency's license.

So keep in NOTICE only those which require additional attribution 
requirements?

 Does anybody know any TLPs that are actually following the advice to link to
 source for category B dependencies in binary NOTICE files?

[ ... ]


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

RE: LICENSE/NOTICE revisited (was Release Apache Marmotta 3.0.0-incubating (RC8))

[Dennis E. Hamilton]

I agree, I didn't mean to generalize about Category B notice requirements.

With regard to there being a standard notice for MPL, I was careless. MPL 1.1 
had a template notice.  MPL 2.0 just has section 3.2(a):

  If You distribute Covered Software in Executable Form then:

  a.  such Covered Software must also be made available in Source
  Code Form, as described in Section 3.1, and You must inform 
  recipients of the Executable Form how they can obtain a copy 
  of such Source Code Form by reasonable means in a timely manner, 
  at a charge no more than the cost of distribution to the 
  recipient; [...]

The license is careful to discriminate between Source Code Form and Executable 
Form, and there is little detail on notifications associated with an Executable 
Form for MPL 2.0.

I would think that providing the information in NOTICE satisfies the 
requirement.  It would be much easier than coming up with another artifact 
beside LICENSE and NOTICE, which knowledgable folks already know to look for.  
I don't have any insight on dealing with the fact that the dependency is 
build-specific, however the information is provided.

 - Dennis




-Original Message-
From: sebb [mailto:seb...@gmail.com] 
Sent: Tuesday, April 23, 2013 10:43
To: Marvin Humphrey
Cc: orc...@apache.org; Sergio Fernández; Roy T. Fielding; 
general@incubator.apache.org
Subject: Re: LICENSE/NOTICE revisited (was Release Apache Marmotta 
3.0.0-incubating (RC8))

On 23 April 2013 18:05, Marvin Humphrey mar...@rectangular.com wrote:

 On Tue, Apr 23, 2013 at 8:39 AM, Dennis E. Hamilton orc...@apache.org
 wrote:
  Not so fast about dispensing with Category B requirements for pointers to
  source code.

 Thank you for the specific information about the MPL.  What I said was
 this:

 The goal is to satisfy the licensing requirements of the dependency,
 not
 to give credit -- so IMO linking only makes sense if that's a
 requirement
 of the dependency's license.

 We must not treat linking as a requirement of ALL category B licenses
 because
 SOME of them require it.


If the source code URL is required, then the question arises: does it
*have* to go in the NOTICE file?
Indeed is this one of the functions of the NOTICE file?
Or should it be documented somewhere else?


 Marvin Humphrey



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

RE: [PROPOSAL] Apache Linda

[Dennis E. Hamilton]

I've been biting my tongue all of this time and I can't resist any longer.

The missing case is Lovelace (bad joke), 

although WebLace is about linking too.

There's no need to borrow a human nick.

 - Dennis

-Original Message-
From: Nandana Mihindukulasooriya [mailto:nandana@gmail.com] 
Sent: Sunday, November 18, 2012 01:51
To: general@incubator.apache.org
Subject: Re: [PROPOSAL] Apache Linda

I have to say when I heard the name Linda, I really liked it because it
is short, catchy, easy to remember and goes well with Linked Data. But I
totally agree that it is good to avoid any name conflict issues or
trademark issues in this early stage where it is easily possible. I was
thinking whether LindaWeb or WebLinda would be an alternative choice.

Best Regards,
Nandana

On Sun, Nov 18, 2012 at 4:14 AM, David Crossley cross...@apache.org wrote:

 Another possblility is Adnil being reversed linked data.
 A nice twist.

 Anyway, up to the podling.

 There are some useful Incubator resources for quickly dealing
 with the Name issue. Here are some:
 http://incubator.apache.org/guides/graduation.html#notes-names
 http://incubator.apache.org/guides/names.html
 http://incubator.apache.org/guides/proposal.html#name

 There great advice in this thread that could be added
 to docs.

 -David

 -
 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: key signing

[Dennis E. Hamilton]

@Benson

There are two things that can be done, with (2) being what
matters to you, it seems to me:

 1. The committer can upload the fingerprint-associated public key
to the PGP Global Directory at http://keyserver.pgp.com/.

That will initiate an e-mail verification for every e-mail 
in the pubkey record (cert for short).  The procedure and its
risks are described in the Key Verification Policy, 
http://keyserver.pgp.com/vkd/VKDVerificationPGPCom.html.  

The key will not be published on that server until the e-mail 
verification occurs.  It will there be countersigned by the PGP 
Global Directory Verification Key.  Note that there is a 
revocation procedure and revocation (i.e., removal from that 
directory) will happen if one of the periodic e-mail 
confirmations fails.

Here's an example of how those counter-signings show up:

http://pgp.mit.edu:11371/pks/lookup?op=vindexfingerprint=onsearch=0xD80D0C3FA39327EC

The e-mail verification is vulnerable (as described in the Key 
Verification Policy) in much the same way that Apache credentials 
and Account records are vulnerable with respect to the use of 
e-mail association as authentication.

 2. In conjunction with checking for the key at (1), or independently, 
the advice from the PGP folk is that an independent means of 
identity agreement should be employed.  So long as you have a 
way of doing that, and the other party can confirms that is the 
public key for which they possess the secret key, it seems 
appropriate to countersign the public key.  

Technically, this should not rely on the e-mail address. Use a 
different channel whereby the committer confirms identity,
including having or knowing something that satisfies you.
Since you can be confident about your own public key, have
the party send you an encrypted message that satisfies you 
concerning the identity of the originator.  That message plaintext 
could also be signed by the party, demonstrating their possession 
of the private key for the pubkey in question.  

The odd thing about the WoT is that it depends on how much *you* 
are considered dependable in verifying the cert creator's identity. 
Each inspector of the committer certificate determines
their own trust of the counter-signing signatures (whether by
WoT transitivity rules or their own personal knowledge/trust). 


 -- Dennis 

Since I dropped in on this thread, I went through the key registration 
process for a unique key that only has orcmid@ a.o as the associated 
e-mail.  The public key was put wherever the Gnu Privacy Assistant puts 
them.  I uploaded the public key to the MIT PGP key server myself.  
I also went through the PGP Global Directory verification procedure.
I put the fingerprint in my Apache Account record and a version of the
cert magically appeared at 
https://people.apache.org/keys/committer/orcmid.asc.  (I'm not sure
where this is fetched from, so I'm not sure how counter-signed versions
show up.)
  I am continuing to experiment.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Monday, October 15, 2012 05:46
To: general@incubator.apache.org
Subject: Re: key signing

Now I have a practical problem. I've received email from a committer
on a project. I have met him in person -- some years ago. I helped him
get started at Apache. His fellow PMC members are telling him that
it's *necessary* for him to come up with one or more signatures on his
key to act at an RM.

Choices:

1) send email to him and his PMC fellows, referencing this thread, as
evidence that key signing is nice but optional.

2) go ahead and sign his key based on simple email. I'm a very bad
paranoid; I'm not interested in the idea that some person out there is
anxious to undermine Apache and has captured one or both or our gmail
accounts, or is acting as an MITM. I have plenty of writing-style
evidence that this email address disgorges communications from him.

3) Engage in some more or less baroque protocol involving skype or
carrier pigeons.

Anyone care to try to tell me what to do? My views are colored by my,
and his, complete disinterest in the WoT outside of its use at Apache,
and my conviction that I do, indeed, know that this key is under the
control of a particular person who signed a CLA and got voted in as a
committer of a particular project.

-
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: key signing

[Dennis E. Hamilton]

Ah, so the key servers federate!  Cool.

Thinking about the Man-in-the-Middle PKE attack, that is a little difficult 
with OpenPGP.

That involves a man in the middle substituting their public key for mine and 
also arranging to intercept messages sent to me that are encrypted using the 
MitM public key for decryption and re-encrypted with my actual public key.

Since I can easily tell whether or not the public key retrieved from any one of 
the key servers is one that goes with the secret key I have, it is pretty 
difficult to prevent me from detecting a public-key substitution.  And I can 
check even deeper than matching fingerprint reports.  

I think that is enough for two distant participants who are known to each other 
to find a way to confidentially exchange something private known only to the 
two of them as a way to confirm that their respective public keys are authentic 
and worthy of signing.  It does depend on our actually being known to each 
other in a way that allows such a procedure to be contrived.

I'm going to try that with a distant friend of mine.

 - Dennis

-Original Message-
From: Daniel Shahaf [mailto:d...@daniel.shahaf.name] 
Sent: Monday, October 15, 2012 11:22
To: Dennis E. Hamilton
Cc: general@incubator.apache.org
Subject: Re: key signing

Dennis E. Hamilton wrote on Mon, Oct 15, 2012 at 11:07:56 -0700:
 https://people.apache.org/keys/committer/orcmid.asc.  (I'm not sure
 where this is fetched from, so I'm not sure how counter-signed versions

Currently keys.gnupg.net

https://svn.apache.org/repos/asf/infrastructure/site/trunk/people/keys-fetch.py

 show up.)

-
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: key signing

[Dennis E. Hamilton]

+1

I'm assuming Benson means the digest (SHA1) by signature.  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position (how do we
improve assurance for probable actual users), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

-
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: key signing

[Dennis E. Hamilton]

I see I committed the sin of using signature two different ways, below.

I mean the file digest value (digital hash, SHA1) for what power users and 
appropriate downloader utilities check.

I mean the external digital signature and the signers public-key cert in the 
Apache keys with regard to checking digital signatures on release candidates 
and in any subsequent forensic investigation/confirmation.  

 - Dennis

-Original Message-
From: Dennis E. Hamilton [mailto:orc...@apache.org] 
Sent: Thursday, October 11, 2012 08:19
To: general@incubator.apache.org
Subject: RE: key signing

+1

I'm assuming Benson means the digest (SHA1) by signature.  Using those from 
the Apache site is probably the first-line for power users and about as much 
extra effort that can be expected.  The use of download utilities that reliably 
check signatures from authentic sources is a small boost -- for power users.  

 - Dennis

The verification of the external signatures also on the Apache site is 
something that I believe is material only for review of the release candidate 
and also any subsequent forensics work if there is a problem.  In all cases, 
the public-key cert should be obtained from the Apache site keys folder.  

The most-significant improvement in this, for binaries at least, is the use of 
embedded signatures that are verified as part of operating-system functions on 
the relevant platform.  That's as low-friction as it gets and users don't have 
to take any special steps at all, other than pay attention to the warning 
dialogs that the platform coughs up.

-Original Message-
From: Benson Margulies [mailto:bimargul...@gmail.com] 
Sent: Thursday, October 11, 2012 05:20
To: general@incubator.apache.org
Subject: Re: key signing

Greg having more or less restated my opening position (how do we
improve assurance for probable actual users), I'd throw in another
bit.

Threat analysis is all well and good, but it please don't forget the
biggest principle here. If the assurance mechanism is so abstruse that
users won't understand it, or so complex that they can't use it, then
they won't, and they will be at the mercy of the dumbest possible
attack.

Before we worry about MITM, or subverted Apache infrastructure, I
claim that we should be offering users a simple, easy-to-understand
means of protecting against fraudulent packages. As per Greg, the
signatures do that. As per me, unsigned keys verified against Apache
infrastructure do that.

Over and above that, we could then ask, 'how could we improve
protection against most complex problems?'

-
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: key signing

[Dennis E. Hamilton]

@Nick

I don't understand the supposed attack vector concerning the file digests being 
of no value and the WoT being essential.

 - Dennis

ANALYSIS

So long as the digest value is obtained from a reliable read-only source, it 
doesn't matter where the file comes from, the digest can be verified.  This 
will protect against and help detect a poisoned mirror site or a third-party 
redistribution that substitutes an inauthentic artifact.  That is, in fact, a 
very big deal and it defends against exploits that happen too regularly.

If the reliable read-only source is compromised, that means an adversary has 
managed to (1) replace the file in Apache custody, and (2) replace the digest 
that applies to that artifact.  (Or just replace the digest and make the 
authentic file look bogus and the poisoned downloads look authentic.)  If 
substitution of the file-digest pair is achievable, providing a different 
external signature can't be much harder, although the exploit might achieve the 
intended purpose without that. Introducing a verifiable external signature that 
finds a counterfeit public-key certificate on a key service may extend the ruse 
a little longer. 

The exploit continues until some Apache folk or security-proficient external 
party detect (1) the substitution or (2) a counterfeit external signature or 
(3) confirms that the external signature is not verifiable on the substituted 
file and digest pair.

I don't see the WoT as much of a factor if this exploit occurs.  It comes down 
to how quickly the exploit is detected, the damage detected, and a mitigation 
put in place.  I assume that infrastructure defense-in-depth measures have to 
expose the fact of an exploit, even if an insider is involved.  At the worst, 
it might be necessary to recall a release.

This assumes that the exploit is by exploit against the read-only distribution 
material in Apache custody.  

If the exploit is by tampering with a release prior to its approval, that is an 
entirely different problem, since it means the digital artifacts have been 
approved as authentic.  Even so, I think it is the trustworthiness committers, 
release managers, and PMC approval that matters here, not the WoT, and that is 
bolstered by the Apache Trust Chain.  The WoT does not protect against someone 
subsequently being revealed to have committed a bad act.  (The revocation of 
trust and how it is noticed is an aspect of WoT that I have not investigated.)

-Original Message-
From: Nick Kew [mailto:n...@webthing.com] 
Sent: Thursday, October 11, 2012 06:46
To: general@incubator.apache.org
Subject: Re: key signing


On 11 Oct 2012, at 09:57, Noah Slater wrote:

 On Thu, Oct 11, 2012 at 9:01 AM, Nick Kew n...@apache.org wrote:
 
 
 You have to extend that assumption not only to our infrastructure but to
 every proxy that might come between us and a user, and that might
 substitute a trojan along with the trojan's own SHA1.
 
 
 The same reasoning holds for the .asc file.

Only if there are no WOT paths to improve confidence in it.

And only if noone ever detects the imposter, which is a lot less
likely with a trojan PGP key (someone in particular is being
impersonated) than a checksum (owned by noone).

-- 
Nick Kew


-
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: key signing

[Dennis E. Hamilton]

@Marvin,

Can you say more about Multi-factor?  I know commonly-claimed schemes involve 
the same factor multiple times (e.g., more things that a party knows, like Aunt 
Gracie's dress size).  I agree that confirming a picture ID (something the 
individual has) is another factor.  What other factors are you thinking of?  (I 
am not sure how many factors signings by others count as new factors.)

 - Dennis

-Original Message-
From: Marvin Humphrey [mailto:mar...@rectangular.com] 
Sent: Thursday, October 11, 2012 11:46
To: general@incubator.apache.org
Subject: Re: key signing

On Wed, Oct 10, 2012 at 2:36 PM, Nick Kew n...@apache.org wrote:
 On 10 Oct 2012, at 17:04, Marvin Humphrey wrote:

 In my opinion, we have sufficient expertise here at the ASF to devise an
 authentication protocol whose reliability exceeds that of individuals
 participating unsupervised in a web of trust, particularly if the protocol
 were to incorporate archived video and auditing by a PMC.

 That may be, but I don't think general@incubator is the place to develop it.

The Incubator is where the acute need exists, because we are bootstrapping
entire communities where no one is linked into the web of trust.

For existing projects, the longer they've been around, the more likely that a
significant number of committers have attended an ApacheCon key-signing party
or otherwise had an opportunity to get their keys signed.  But here, we see
new RMs all the time who are isolated.  It would be nice if we had some
systematic way of integrating them.

In the absence of a formal protocol, suggesting that new RMs go find someone
to sign their key is unsatisfying, since at least some of the time that's
likely to mean email contact alone and potentially a tenuous relationship to
the signer.  The alternative of suggesting that new RMs with a release VOTE
pending go find a local key-signing party to attend seems unrealistic.

In my opinion, general@incubator is an appropriate venue to explore ways in
which the system can be improved.  That will necessarily mean talking about
some implementation details because it would be silly to assess feasibility
otherwise, but please note that the proposed protocol was labeled a rough
draft.  Maybe we can call it sample instead, implying the need to start
over later -- it doesn't matter to me.  I had always imagined that if the
protocol were to move forward it would undergo a process of relentless
scrutiny and refinement by interested parties outside the Incubator.

The payoff is that with a protocol in place which enables us to establish
identity to a high degree of certainty and add an individual to web of trust
on a short turnaround, the Incubator need not approve another release signed
by an RM who is not linked into the ASF web of trust.

 FWIW for myself I like to back WOT paths by checking manually,
 and feel best about it when I can identify a chain of trust involving only
 people I trust to be savvy enough not to sign keys willy-nilly.
 PGP/GPG support different levels of trust, so the model helps there.

The PR challenge is a separate question.  I will acknowlege that I have been
taken aback by the extreme skepticism in what I view as a straightforward
application of the principles of multi-factor authentication, faithful to
the spirit and letter of the GnuPG docs.

It pains me that the only outcome of this discussion may be that it gets even
harder to make an incubating release. :(

Marvin Humphrey

-
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