Re: Reuse Maven repository more

2016-09-30 Thread Stephen Connolly 
On Friday 30 September 2016, Jaroslav Tulach 
wrote:

> 28. 9. 2016 v 11:25, Greg Stein >:
>
> > On Tue, Sep 27, 2016 at 10:13 PM, Jaroslav Tulach <
> jaroslav.tul...@gmail.com 
> >> wrote:
> >> ...
> >
> >> One idea that keeps puzzling in my mind is to reuse central Maven
> >> repository
> >> more than we used to. If I understand correctly while the Maven central
> is
> >> operated by Sonatype, it is just "leased" to them and still oversight by
> >> Apache.
> >
> >
> > Not so much. We license the "Apache Maven" trademark to them, to provide
> a
> > fantastic service to the Maven community. But Maven Central is *all*
> > Sonatype, and the ASF generally just provides oversight over trademark
> use
> > (rather than operation).
> >
> > To state things another way: the ASF has zero control over what goes onto
> > their platform. Shoot, we have a copy of the software which runs Maven
> > Central, but it is proprietary and we merely hold a license to run it.
> This
> > isn't pillows and unicorns. You will need to make a business case with
> > Sonatype to include stuff beyond artifacts that Apache Maven can consume
> > from their repository.
> >
> > (that is my reasonably-informed understanding; a discussion with Sonatype
> > and the Apache Maven PMC is your best bet)


Not quite true.

Sonatype is running the active hosting of central, but there are
full mirrors of the content that are kept live (modulo a few hours for some
to a few days/weeks for others).

The URL that maven distos now point to is an apache.org URL rather than the
maven.org URL. If there were an issue with the current sonatype provided
service, we *could* switch to the apache mirror hosting on and change the
DNS entry.

The value sonatype currently provides is the artifact on-ramp (aside from
covering the bandwidth charges)

Previously there was a long complex set of rsync rules to pull content from
various sources. That has by and large been replaced by Sonatype Nexus and
some Mexus federation "magic".

We probably could get Artifactory to a place where it could perform the
same functionality but currently there is a gap...

Having said that, I think we are happy with the Sonatype service.


> Thanks Greg for your answer.
>
> On one side of my proposal is cost control for Apache foundation. By
> reusing infrastructure that already exists and is (has to be as the
> trademark is owned by the foundation) friendly, we can eliminate the load
> for extra services (http://plugins.netbeans.org) NetBeans currently has.
> I don't think the increase of the load is going to be any significant - the
> amounts of downloads Apache Maven central has to handle is way bigger than
> NetBeans needs, I assume.


Yeah but you'd want to check with Sonatype before adding that load onto
Central first...

The internal copy of Nexus that hosts repository.apache.org is probably not
sized to handle the netbeans load. Rather it is sized to handle the
deployment be developers, occasional downloads by PMCs testing artifacts
being voted on and the sync to central.


>
> Simplification of the build infrastructure is the other goal. If we use
> only the bits on the Apache Maven central, then we don't need any special
> support infrastructure (http://hg.netbeans.org/binaries). That requires a
> bit of work, but again it could help Apache control the cost of adopting
> NetBeans.


For building netbeans, yes you want to go that route.


>
> The last side is related to legal issues. Any infrastructure that helps to
> distribute 3rd party code is troublesome: viruses, malware, spyware, etc.
> By reusing the same infrastructure as Apache Maven, we align NetBeans with
> existing Apache approved solution. Apache NetBeans would only download what
> Apache Maven can - e.g. The risk of using NetBeans would be the same as
> using Maven. In my view, this should make the foundation OK with
> distributing such software like NetBeans.
>
> I agree with Wade, that all such changes should only happen when NetBeans
> is accepted for the incubation phase. The only reason of my proposal is to
> show that we don't have "insolvable issues". We may have challenging ones,
> but I am sure, we can solve all of them.
>
> Jaroslav Tulach
> NetBeans Platform Architect
>
>
>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

-- 
Sent from my phone

Re: [IP CLEARANCE] Aether, renamed to Maven Artifact Resolver

2016-09-28 Thread Stephen Connolly 
+1 from me as maven PMC member and as one of the contributors to the code
base (all 7 commits worth iirc ;-) )

On Wednesday 28 September 2016, Hervé Boutemy  wrote:

> Apache Maven received a code donation for Aether, that we renamed to Maven
> Artifact Resolver to fix a trademark issue:
>
> http://incubator.apache.org/ip-clearance/maven-aether.html
>
> The import plan is more detailed at http://maven.apache.org/aether.html
>
> Please vote to approve this contribution. Lazy consensus applies. If no -1
> votes are cast within the next 72 hours, the vote passes.
>
> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>
>

-- 
Sent from my phone

Re: [VOTE] Accept NetBeans into the Apache Incubator

2016-09-28 Thread Stephen Connolly 
+1 (enthusiasting)

On Tuesday 27 September 2016, Ate Douma  wrote:

> Hi everyone,
>
> Now that the discussion thread on the NetBeans Proposal has ended,
> please vote on accepting NetBeans into the Apache Incubator.
>
> The ASF voting rules are described at:
>http://www.apache.org/foundation/voting.html
>
> A vote for accepting a new Apache Incubator podling is a majority vote
> for which only Incubator PMC member votes are binding.
>
> Votes from other people are also welcome as an indication of peoples
> enthusiasm (or lack thereof).
>
> Please do not use this VOTE thread for discussions.
> If needed, start a new thread instead.
>
> This vote will run for at least 72 hours. Please VOTE as follows
> [] +1 Accept NetBeans into the Apache Incubator
> [] +0 Abstain.
> [] -1 Do not accept NetBeans into the Apache Incubator because ...
>
>
> The proposal is listed below, but you can also access it on the wiki:
>https://wiki.apache.org/incubator/NetBeansProposal
>
>
> Thanks,
> Ate.
>
> == Abstract ==
>
> NetBeans is an open source development environment, tooling platform, and
> application framework, used by 1.5 million individuals each month.
>
> == Proposal ==
> Apache NetBeans will continue to focus on the areas it has focused on while
> sponsored by Sun Microsystems and Oracle. It will continue to primarily
> focus on
> providing tools for the Java ecosystem, while also being focused on tools
> for
> other ecosystems, languages and technologies, such as JavaScript, PHP, and
> C/C++. It will continue to actively support its community by means of
> mailing
> lists, tutorials, and documentation.
>
> == Background ==
> NetBeans started in 1995/96 in Prague, in the Czech Republic, as a student
> project. Sun Microsystems acquired and open sourced it in 2000 and, with
> the
> acquisition of Sun Microsystems by Oracle in 2010, became part of Oracle.
> Throughout its history in Sun Microsystems and Oracle, NetBeans has been
> free
> and open source and has been leveraged by its sponsor as a mechanism for
> driving
> the Java ecosystem forward.
>
> == Rationale ==
> Although NetBeans is already open source, moving it to a neutral place like
> Apache, with its strong governance model, is expected to help get more
> contributions from various organizations. For example, large companies are
> using
> NetBeans as an application framework to build internal or commercial
> applications and are much more likely to contribute to it once it moves to
> neutral Apache ground. At the same time, though Oracle will relinquish its
> control over NetBeans, individual contributors from Oracle are expected to
> continue contributing to NetBeans after it has been contributed to Apache,
> together with individual contributors from other organizations, as well as
> self-employed individual contributors.
>
> == Initial Goals ==
> The initial goals of the NetBeans contribution under the Apache umbrella
> are to
> establish a new home for an already fully functioning project and to open
> up the
> governance model so as to simplify and streamline contributions from the
> community.
>
> == Current Status ==
> Meritocracy: NetBeans has been run by Oracle, with the majority of code
> contributions coming from Oracle. The specific reason for moving to Apache
> is to
> expand the diversity of contributors and to increase the level of
> meritocracy in
> NetBeans. Apache NetBeans will be actively seeking new contributors and
> will
> welcome them warmly and provide a friendly and productive environment for
> purposes of providing a development environment, tooling environment, and
> application framework.
>
> Community: NetBeans has approximately 1.5 million active users around
> the
> world, in extremely diverse structures and organizations. NetBeans is used
> by
> teachers and instructors at schools and universities to teach Java and
> other
> languages. It is used by students as an educational tool. It is used by
> large
> organizations who base their software on the application framework beneath
> NetBeans. It is used by web developers for creating web sites and by
> developers
> using a range of tools, languages, and technologies to be productive and
> efficient software developers.
>
> Core Developers: The core developers will come from a range of
> organizations, including Oracle, which will continue its investment in
> NetBeans.
>
> Alignment: The application framework is the basis of a range of mission
> critical scientific software at large organizations in defense, aerospace,
> logistics, and research, such as at Boeing, Airbus Defense and Space,
> NASA, and
> NATO.
>
> == Known Risks ==
> Orphaned Products: The community proposing NetBeans for incubation is
> strong
> and vibrant. The size and diversity of the community is a guarantee
> against the
> project being orphaned.
>
> Inexperience with Open Source: NetBeans has been free and open source
> since
> the early days of its

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

2015-11-26 Thread Stephen Connolly 
On Wednesday 25 November 2015, Steve Loughran 
wrote:

>
> > On 22 Nov 2015, at 22:34, Branko Čibej >
> wrote:
> >
> >
> > The major question here, for me, is: if the project is RTC, then why
> > would I make an effort to become a committer if at the end of the day
> > I'm still not trusted to know when to ask for review? It'd be less work
> > to throw patches at the developers and let them deal with the pain of
> > reviewing and applying.
> >
>
> what you gain as committer is not so much the right to do the housekeeping
> of svn commit/git commit, it's the right to commit other people's code in
> after reviewing it.
>
> And while anyone is encouraged to review patches on JIRA/github, etc, your
> ability to +1 code says you are trusted to make changes to the code without
> breaking things. That is: your knowledge of the code is deemed sufficient
> to be able to review the work of others, to help guide them into a state
> where it can be committed, and if not: explain why not. You just still have
> to go through the same process of submission and review with your peers, so
> there is a guarantee that 1 other person is always aware of what you do.
>
> That ability to +1 code is the right and the responsibility.


I believe that to be an anti-pattern.

At the Maven project, we started to track on votes which votes were from
the PMC (ie binding for making a release with the legal protection of the
foundation)

The nett effect was a reduction of engagement from the community... When
they saw these "+1 (binding)" votes being treated differently, they stopped
voting on releases...

So now we are trying to rebuild the engagement... Much harder after you
have lost it than not to lose it in the first place.

Now releases are more visible than commits, but I believe the same
principle applies.

With CTR anyone can be a "drive by" reviewer. With RTC the "drive by"
reviewer doesn't have the same status... So it is harder to engage them and
pull them into the community


>
>
>
> > How would it feel to get a mail like this:
> >
> >Congratulations! The developers of Project FOO invite you to become
> >a committer. All your patches to date have been perfect and your
> >other contributions outstanding. Of course we still won't let you
> >commit your changes unless [brass hats] have reviewed and approved
> >them; we operate by a review-then-commit process. The only real
> >benefit of committer status is that you can now review other
> >people's patches and have a binding opinion, unless [brass hats]
> >have written otherwise in the bylaws.
>
> yes: you get to have a direct say in what goes into the codebase.
>
> you also get a duty: you need to review other people's work. We need to
> encourage more of that in the Hadoop codebase. I know its a chore, but
> Yetus is helping, as should the github integration.
>
> >
> >P.S.: Any competent engineer will immediately see that the optimal
> >way to proceed is to join an informal group of committers that
> >mutually +1 each other's patches without unnecessary hassle, and/or
> >ingratiate yourself with [brass hats] to achieve equivalent results.
> >After all, it's all about building a healthy community, right?
>
> it would, though it'd stand out. And if you want things to work without
> fielding support calls, you want the quality of what goes in to be high -no
> matter from whom it came.
>
> If you work in specific part of the code, you do end up knowing the people
> who also work there, their skills, their weaknesses: who is most likely to
> break things. So you may show some favouritism to people  you trust.
> Explicit tradings of patches? Not me.
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>


-- 
Sent from my phone

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

2015-11-26 Thread Stephen Connolly 
On Wednesday 25 November 2015, Steve Loughran 
wrote:

>
> > On 22 Nov 2015, at 22:34, Branko Čibej >
> wrote:
> >
> >
> > The major question here, for me, is: if the project is RTC, then why
> > would I make an effort to become a committer if at the end of the day
> > I'm still not trusted to know when to ask for review? It'd be less work
> > to throw patches at the developers and let them deal with the pain of
> > reviewing and applying.
> >
>
> what you gain as committer is not so much the right to do the housekeeping
> of svn commit/git commit, it's the right to commit other people's code in
> after reviewing it.
>
> And while anyone is encouraged to review patches on JIRA/github, etc, your
> ability to +1 code says you are trusted to make changes to the code without
> breaking things. That is: your knowledge of the code is deemed sufficient
> to be able to review the work of others, to help guide them into a state
> where it can be committed, and if not: explain why not. You just still have
> to go through the same process of submission and review with your peers, so
> there is a guarantee that 1 other person is always aware of what you do.
>
> That ability to +1 code is the right and the responsibility.


I believe that to be an anti-pattern.

At the Maven project, we started to track on votes which votes were from
the PMC (ie binding for making a release with the legal protection of the
foundation)

The nett effect was a reduction of engagement from the community... When
they saw these "+1 (binding)" votes being treated differently, they stopped
voting on releases...

So now we are trying to rebuild the engagement... Much harder after you
have lost it than not to lose it in the first place.

Now releases are more visible than commits, but I believe the same
principle applies.

With CTR anyone can be a "drive by" reviewer. With RTC the "drive by"
reviewer doesn't have the same status... So it is harder to engage them and
pull them into the community


>
>
>
> > How would it feel to get a mail like this:
> >
> >Congratulations! The developers of Project FOO invite you to become
> >a committer. All your patches to date have been perfect and your
> >other contributions outstanding. Of course we still won't let you
> >commit your changes unless [brass hats] have reviewed and approved
> >them; we operate by a review-then-commit process. The only real
> >benefit of committer status is that you can now review other
> >people's patches and have a binding opinion, unless [brass hats]
> >have written otherwise in the bylaws.
>
> yes: you get to have a direct say in what goes into the codebase.
>
> you also get a duty: you need to review other people's work. We need to
> encourage more of that in the Hadoop codebase. I know its a chore, but
> Yetus is helping, as should the github integration.
>
> >
> >P.S.: Any competent engineer will immediately see that the optimal
> >way to proceed is to join an informal group of committers that
> >mutually +1 each other's patches without unnecessary hassle, and/or
> >ingratiate yourself with [brass hats] to achieve equivalent results.
> >After all, it's all about building a healthy community, right?
>
> it would, though it'd stand out. And if you want things to work without
> fielding support calls, you want the quality of what goes in to be high -no
> matter from whom it came.
>
> If you work in specific part of the code, you do end up knowing the people
> who also work there, their skills, their weaknesses: who is most likely to
> break things. So you may show some favouritism to people  you trust.
> Explicit tradings of patches? Not me.
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> 
> For additional commands, e-mail: general-h...@incubator.apache.org
> 
>


-- 
Sent from my phone

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

2015-11-25 Thread Stephen Connolly 
Spoilsport ;-)

On 25 November 2015 at 16:47, Upayavira  wrote:

> Not replying to this mail specifically, but to the thread in general...
>
> People keep using the terms RTC and CTR as if we all mean the same
> thing. Please don't. If you must use these terms, please define what you
> mean by them.
>
> CTR is a less ambiguous term - I'd suggest we all assume that "commit"
> means a push to a version control system.
>
> However, RTC seems to mean many things - from "push to JIRA for review
> first, wait a bit, then commit to VCS" through "push to JIRA, and once
> you have sufficient +1 votes, you can commit" to "push to JIRA for a
> review, then another committer must commit it".
>
> If we're gonna debate RTC, can we please describe which of these we are
> talking about (or some other mechanism that I haven't described)?
> Otherwise, we will end up endlessly debating over the top of each other.
>
> Upayavira
>
> On Wed, Nov 25, 2015, at 09:28 AM, Harbs wrote:
> > AIUI, there’s two ways to go about RTC which is easier in Git:
> > 1) Working in feature/bug fix branches. Assuming RTC only applies to the
> > main branch, changes are done in separate branches where commits do not
> > require review. The feature/bug fix branch is then only merged back in
> > after it had a review. The reason this is easier is because branching and
> > merging is almost zero effort in Git. Many Git workflows don’t work on
> > the main branch anyway, so this is a particularly good fit for those
> > workflows.
> > 2) Pull requests. Using pull requests, all changes can be pulled in with
> > a single command.
> >
> > I’ve personally never participated in RTC (unless you count Github
> > projects and before I was a committer in Flex), so it could be I’m
> > missing something.
> >
> > Of course there’s nothing to ENFORCE that the commit is not done before a
> > review, but why would you want to do that? That’s where trust comes to
> > play… ;-)
> >
> > Harbs
> >
> > On Nov 25, 2015, at 4:08 AM, Konstantin Boudnik  wrote:
> >
> > > I don't think Git is particularly empowering RTC - there's nothing in
> it that
> > > requires someone to look over one's shoulder.
> >
>
> -
> 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...)

2015-11-18 Thread Stephen Connolly 
typo s/every/revert/

If you do CTR and there are lots of vetos... which can happen if the
reviews are requesting rework or changes... then there would need to be a
lot of revert commits to revert the commits that were vetoed.

Thankfully in CTR mostly the case is you just commit the rework rather than
revert the commit. The only case where you want to revert the commit is the
case of compromised IP where the revert is saying "actually this IP is not
correctly assigned"

On 18 November 2015 at 17:02, Ross Gardler <ross.gard...@microsoft.com>
wrote:

> I agree, mostly, with your mail Stephen, but I wonder about the reference
> you make to "the mess of every commits". Do you really see that?
>
> If you do see it I suspect the project has a problem. In my experience
> reverts are rare. We prefer people improve what is there rather than revert
> what they don't like. It's not always possible so occasional reverts are
> likely, but you shouldn't be seeing lots of reverts.
>
> Sent from my Windows Phone
> ____
> From: Stephen Connolly<mailto:stephen.alan.conno...@gmail.com>
> Sent: ‎11/‎18/‎2015 7:21 AM
> To: general@incubator.apache.org<mailto:general@incubator.apache.org>
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On 18 November 2015 at 14:24, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
> > Le 18/11/15 14:34, Stephen Connolly a écrit :
> > > On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com>
> > > wrote:
> > >
> > >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> > >>> I believe the issue here is that with CTR it is very easy to miss the
> > 72h
> > >>> lazy consensus voting (with an assumed +1 absence any votes cast)
> that
> > >> most
> > >>> CTR projects operate under... and thus it can also be very easy to
> miss
> > >> the
> > >>> fact that there are reviews going on (and I am being generous here, I
> > >>> suspect that a lot of CTR commits are only reviewed within the 72h
> by a
> > >>> blind man on a galloping horse)
> > >> I'm not sure why you are correlating commit reviews and a 72h vote...
> > >> They are two really different things.
> > >
> > > When I last read up my understanding is that CTR operates as if there
> is
> > a
> > > vote for each commit.
> >
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=TL9a3HXjrIU7ntwJs8RqxDraGBtcz%2bzbjJACbgh%2f9LM%3d
> :
> >
> > *Commit-Then-Review*<
> >
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23CommitThenReview=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=3qCZYrBRMPK4j7qZpzlgHAmNW9L%2bGQp2QYgPjeDzm%2bI%3d
> >
> > (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> > changes which permits developers to make changes at will, with the
> > possibility of being retroactively vetoed
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23Veto=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=Bwshvacajf1bpiCM%2bmzVxo0Ow8DgsidGmOhW5dLKSEY%3d>.
> C-T-R is an
> > application of decision making through lazy consensus
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23LazyConsensus=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=7GegAJIQoysXF8P6q2pb17XIDqDaNo3G48W0uYME9%2bk%3d>.
> The
> > C-T-R model is useful in rapid-prototyping environments, but because
> > of the lack of mandatory review it may permit more bugs through in
> > daily practice than the R-T-C
> > <
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fwww.apache.org%2ffoundation%2fglossary.html%23ReviewThenCommit=01%7c01%7cRoss.Gardler%40microsoft.com%7cd4b92b7624054c648d7a08d2f02bdd99%7c72f988bf86f141af91ab2d7cd011db47%7c1=WwxXkFBwIeUhUMcao%2ff4kffNgSy8T8eN1amIhOiv%2fvo%3d
> >
> > alternative.
> >
> > The important piece here is '...the lack of mandatory review...'
> >
> >
> > From the same glossary:
>
> Lazy consensus
> > (Also called 'lazy approval'.) A decision-making policy which

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

2015-11-18 Thread Stephen Connolly 
On 18 November 2015 at 14:24, Emmanuel Lécharny <elecha...@gmail.com> wrote:

> Le 18/11/15 14:34, Stephen Connolly a écrit :
> > On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com>
> > wrote:
> >
> >> Le 18/11/15 11:31, Stephen Connolly a écrit :
> >>> I believe the issue here is that with CTR it is very easy to miss the
> 72h
> >>> lazy consensus voting (with an assumed +1 absence any votes cast) that
> >> most
> >>> CTR projects operate under... and thus it can also be very easy to miss
> >> the
> >>> fact that there are reviews going on (and I am being generous here, I
> >>> suspect that a lot of CTR commits are only reviewed within the 72h by a
> >>> blind man on a galloping horse)
> >> I'm not sure why you are correlating commit reviews and a 72h vote...
> >> They are two really different things.
> >
> > When I last read up my understanding is that CTR operates as if there is
> a
> > vote for each commit.
>
> http://www.apache.org/foundation/glossary.html :
>
> *Commit-Then-Review*<
> http://www.apache.org/foundation/glossary.html#CommitThenReview>
> (Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
> changes which permits developers to make changes at will, with the
> possibility of being retroactively vetoed
> <http://www.apache.org/foundation/glossary.html#Veto>. C-T-R is an
> application of decision making through lazy consensus
> <http://www.apache.org/foundation/glossary.html#LazyConsensus>. The
> C-T-R model is useful in rapid-prototyping environments, but because
> of the lack of mandatory review it may permit more bugs through in
> daily practice than the R-T-C
> <http://www.apache.org/foundation/glossary.html#ReviewThenCommit>
> alternative.
>
> The important piece here is '...the lack of mandatory review...'
>
>
> From the same glossary:

Lazy consensus
> (Also called 'lazy approval'.) A decision-making policy which assumes
> general consent if no responses are posted within a defined period. For
> example, "I'm going to commit this by lazy consensus if no-one objects
> within the next three days." Also see Consensus Approval
> <http://www.apache.org/foundation/glossary.html#ConsensusApproval> , Majority
> Approval <http://www.apache.org/foundation/glossary.html#MajorityApproval> ,
> and the description of the voting process
> <http://www.apache.org/foundation/voting.html>.

<http://www.apache.org/foundation/glossary.html#LazyConsensus>

So Lazy consensus is a voting process... if the code was committed more
than three days ago, then there must have been a successful vote for
committing that code... it was a lazy vote because there was no explicit
[VOTE] thread.

My point is that when I see people arguing for RTC over CTR what I maintain
they are actually arguing over is the lazy consensus voting of each commit.

People who want RTC really do not want lazy voting.
People who want CTR really want lazy voting.

I suspect that RTC with lazy consensus would be just as good an option for
Greg and just as bad an option for Tony

I also suspect that (in a parallel universe where the mess of revert
commits could be magically resolved) CTR without lazy consensus would be
just as good an option for Tony and just as bad an option for Greg.

*My* point is that it is the lazy consensus that people are arguing about.

CTR works best with lazy consensus (as there is the whole mess of
reverting... but you'd only do that for commits that fail on the code
provenance issue... so in practice it's not really anything even close to a
big deal)

RTC works best with non-lazy consensus and is acceptable with lazy
consensus.

In my day job, we use a sort of RTC with lazyish consensus...
It helps that all our stuff happens on DSCMs where we can just commit away
to our own branch until we are ready to merge.
We then flag the merge request for review... if you have 2 positive reviews
and no negative reviews in 12 hours, merge away... if you have 1 positive
review and no negative reviews after 12 hours, merge away... if you have no
reviews after 1 week, merge away


>
> >  It's a really lazy vote though as the vote passes if
> > nobody comments on the commit after 72h... And personally I do not see
> much
> > value in post-hoc votes... What are we going to do, rewrite history? But
> as
> > I understand the "vote" is so that the code in source control can be
> > covered by the legal umbrella despite it being outside of a formal source
> > release.
>
> AFAIU, it means it's very much a C[-T-R] and not a C-T-R...
>
>
> -
> 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...)

2015-11-18 Thread Stephen Connolly 
I believe the issue here is that with CTR it is very easy to miss the 72h
lazy consensus voting (with an assumed +1 absence any votes cast) that most
CTR projects operate under... and thus it can also be very easy to miss the
fact that there are reviews going on (and I am being generous here, I
suspect that a lot of CTR commits are only reviewed within the 72h by a
blind man on a galloping horse)

If the PMC is doing its duty, then when release time comes around, if they
have not been tracking the commits, then they should not be providing a
binding +1 for the release until they have reviewed the commit delta from
the last release *at least from the point of view of ASL compliance*.

So if we look at a well established CTR project such as Maven, you do not
see many comments on individual commits... from this you might be forgiven
if you concluded that there is no review going on... and thus infer that
CTR is really C. I cannot speak for the entire Maven PMC but I can assure
you that I reviewed each and every commit in the delta between the 3.3.3
release and the 3.3.9 release from both a technical perspective and the
legal umbrella perspective (does that mean I spotted every bug, nope... no
code review can catch every bug... and it took us 6 goes to get the release
out... but there was review)

[demagogue]
Now if a project is using RTC, in my view they probably should also be
using the 72h lazy consensus rule, in which case in the absence of a -1 the
code can be committed after 72h anyway and that should not slow down a
project or hamper contribution
[/demagogue]

I suspect the real debate should be whether RTC should use lazy consensus
voting or require at least one vote cast... that would - to my mind - get
to the heart of the debate (of course that decision is the responsibility
of each project's PMC)

I suspect that Todd would find a CTR with required vote casting or revert
just as acceptable (though much more noisy in SCM tracking with all the
revert commits)

-Stephen

On 18 November 2015 at 09:16, Ross Gardler 
wrote:

> Interesting, Todd, can you identify which of your three arguments for CTR
> are not present in RTC.
>
> Ross
>
> -Original Message-
> From: Todd Lipcon [mailto:t...@cloudera.com]
> Sent: Tuesday, November 17, 2015 11:23 PM
> To: general@incubator.apache.org
> Subject: Re: RTC vs CTR (was: Concerning Sentry...)
>
> On Tue, Nov 17, 2015 at 11:12 PM, Greg Stein  wrote:
>
> > On Wed, Nov 18, 2015 at 1:07 AM, Todd Lipcon  wrote:
> > >...
> >
> > > I think it's a _plus_ that contributors and committers contribute
> > > code in the same way -- it's more of a level playing field for new
> > > people contributing to the project.
> > >
> >
> > "level playing field"?? seriously??
> >
> > I find no logical or valid reasoning to drag committers down to the
> > same level as drive-by contributors.
> >
>
> I gave the logical and valid reasoning in previous posts in this thread:
> 1) no matter how seasoned a committer you are, you might make mistakes
> which are easily caught in code review
> 2) no matter how good you are at coding, your code might not make sense to
> a second pair of eyes, who can ask you to improve comments or docs
> 3) no matter if your code is perfect, the act of another person reading
> your code builds shared ownership over the code, thus alleviating
> bus-factor issues and improving the general feeling of a cohesive community
> developing a single project instead of a loose coalition of people with
> their own fiefdoms.
>
> I believe this to be generally accepted in the software engineering
> community. I don't know practices at every company, but I know at least
> that most of the well-regarded technology companies I've met with have some
> form of pre-commit review, and certainly many highly adopted open source
> projects as well (especially in infrastructure software).
>
> Either a high percentage of the world does this for "no logical or valid
> reason" or this is just a matter of opinion, and like I said, we can agree
> to disagree.
>
> -Todd
>

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

2015-11-18 Thread Stephen Connolly 
On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com>
wrote:

> Le 18/11/15 11:31, Stephen Connolly a écrit :
> > I believe the issue here is that with CTR it is very easy to miss the 72h
> > lazy consensus voting (with an assumed +1 absence any votes cast) that
> most
> > CTR projects operate under... and thus it can also be very easy to miss
> the
> > fact that there are reviews going on (and I am being generous here, I
> > suspect that a lot of CTR commits are only reviewed within the 72h by a
> > blind man on a galloping horse)
>
> I'm not sure why you are correlating commit reviews and a 72h vote...
> They are two really different things.


When I last read up my understanding is that CTR operates as if there is a
vote for each commit. It's a really lazy vote though as the vote passes if
nobody comments on the commit after 72h... And personally I do not see much
value in post-hoc votes... What are we going to do, rewrite history? But as
I understand the "vote" is so that the code in source control can be
covered by the legal umbrella despite it being outside of a formal source
release.


> >
> > If the PMC is doing its duty, then when release time comes around, if
> they
> > have not been tracking the commits, then they should not be providing a
> > binding +1 for the release until they have reviewed the commit delta from
> > the last release *at least from the point of view of ASL compliance*.
> No. There is nothing that says such a thing.


>  http://www.apache.org/dev/release-publishing.html
All the source code of the project must be covered by the Apache License,
version 2.0. The license must be included in each source file. For the
license to be valid, the code must have been contributed by an individual
covered by an appropriate contributor license agreement, or have otherwise
been licensed to the Foundation and passed through IP clearance. S

Now I will agree that the above is not a very high bar:

1. Check all commits are authored by a committer (as committer has an ICLA)
2. For commits authored by non committers (git makes these easier to find)
check that the author provides clear intent to submit the code to the ASF
(a patch submitted to JIRA/project mailing list or a PR against Apache
GitHub repo seems clear intent) and that the patch is not "too big" (a
somewhat nebulous concept but as all the ones I have had to check were
under the 50-60 LOC metric I haven't had to probe that concept too hard)
3. If all else fails as the author to sign an ICLA

It would be very good if
> every PMC member casting a vote were reviewing all the commits since the
> last release, but this is unlikely to happen, and it's not even
> required.


> This is correct, as long as I review as we go for the above
(minimal) provenance checks then I am good to go and provide 1/3rd of the
legal umbrella.

And unless you point us to the so called ASL compliance, I
> think this is your own interpretation of the PMC member that you are
> pulling here.


See the link. It's not a strenuous compliance check like the paper exercise
that the interrupted view of planetary objects foundation performs... Thank
goodness do that... But it is a requirement of you read up on the PMC roles.


> >
> > So if we look at a well established CTR project such as Maven, you do not
> > see many comments on individual commits... from this you might be
> forgiven
> > if you concluded that there is no review going on... and thus infer that
> > CTR is really C. I cannot speak for the entire Maven PMC but I can assure
> > you that I reviewed each and every commit in the delta between the 3.3.3
> > release and the 3.3.9 release from both a technical perspective and the
> > legal umbrella perspective (does that mean I spotted every bug, nope...
> no
> > code review can catch every bug... and it took us 6 goes to get the
> release
> > out... but there was review)
> That's good for Maven. But that does not mean any other project should
> do so.
>
> Look, this is where we *trust* other committers - and this is the reason
> we voted them in, btw - : they *know* they should not break the ASF
> rules (IP, etc) plus they *know* they should not break the trust the
> community has put in them.
>
> In 10 years, I have very rarely seen such things happening - and most of
> the time it was a mistake -. I saw someone pushing some revamped Sun
> code (and signaled so to the project), vote -1 on one commit (not sure I
> should be proud of that veto, btw) and asked for some better code to be
> pushed a few times, but more as a discussion than as a formal request.
> Otherwise, did I saw some commits that needed some fixe because they
> were breaking the build ? You bet ! (and I plaid guilty as charge

Re: apache binary distributions

2015-08-25 Thread Stephen Connolly 
So there is - to my mind - the obvious stuff:

1. The package description should ACK our marks. End of Story there.
2. The package description should call out those cases where there are
significant deviations from the official distributions. Significant
deviations will be determined by the individual PMCs as they know what is
significant and what is not.

That leaves the technical package name.

Is using our mark in the technical package name (which cannot have space to
ACK the mark, but assuming there is an ACK of the mark in the description)
an issue?

So if we have:

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.

is the Manchu packaging of Foo ok to use foo as the package name?

It would seem to be a disservice to users to force Manchu to pick a
different name for Foo (i.e. the firefox vs iceweasel issue)

On the other hand, packaging up Apache Foo for the Manchu installer
framework may require significant patching of Apache Foo such that it is
necessary to declare that it is *based on Apache Foo*

Compare and contrast with homebrew's packaging of Apache Maven where they
just download the convenience binary published by the Apache Maven team...
that seems reasonable to be called `maven` because it is actually
installing exactly what the Apache Maven team released without
modifications.

Shane, do you need further clarifications?

On 25 August 2015 at 11:52, Roman Shaposhnik ro...@shaposhnik.org wrote:

 On Wed, Aug 19, 2015 at 1:46 AM, Stephen Connolly
 stephen.alan.conno...@gmail.com wrote:
  But I am still awaiting guidance from brand on whether a technical name
  usage - e.g. installer package name - is a use of the mark.

 Makes two of us. I see a log of good consensus on this thread which helps
 me get a gut feel on what is the right way to go about enforcing the use
 of the mark. That said, I still would love to read Shane's meditation
 on the matter ;-)

 Thanks,
 Roman.

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

Re: apache binary distributions

2015-08-19 Thread Stephen Connolly 
We could define a hierarchy of right to use the mark: pmc has ultimate
right, if the pmc are not producing a packaging for that system then the
developers of the packaging system have the right to define who can use the
mark in relation to their packaging system only.

The aim here would be to make our software available easily in different
packaging systems. The pmc may want to take ownership of popular packaging
systems, so we'd need to be able to trump others
On Wed 19 Aug 2015 at 10:27, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 I might add also that our integration tests should pass for patched
 releases (if you want to call the package maven)

 Let's take this straw man out for a walk:

 Microsoft produce a maven.msi and it is available for download on a page
 called how to get maven on the Microsoft website. The installer's first
 screen says clearly that this is microsoft's build of Apache maven and
 our marks are ack on the first screen.

 Is that ok?
 On Wed 19 Aug 2015 at 10:03, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 Perhaps, the maven pmc could decree: if you are making a convenience
 installer of maven for an OS where the maven pmc does not create a
 convenience installer, you may use maven as the packaging name provided
 the description clarifies it is a custom build and provides an ack of our
 marks. Also the version number is different if patches have been applied.

 Would that be an acceptable defence of our mark?

 On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest
 of the
  PMC, I may not call it Maven. If I did call it Maven then the
 remainder of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 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.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may
 have to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 But I am still awaiting guidance from brand on whether a technical name
 usage - e.g. installer package name - is a use of the mark.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-19 Thread Stephen Connolly 
I might add also that our integration tests should pass for patched
releases (if you want to call the package maven)

Let's take this straw man out for a walk:

Microsoft produce a maven.msi and it is available for download on a page
called how to get maven on the Microsoft website. The installer's first
screen says clearly that this is microsoft's build of Apache maven and
our marks are ack on the first screen.

Is that ok?
On Wed 19 Aug 2015 at 10:03, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Perhaps, the maven pmc could decree: if you are making a convenience
 installer of maven for an OS where the maven pmc does not create a
 convenience installer, you may use maven as the packaging name provided
 the description clarifies it is a custom build and provides an ack of our
 marks. Also the version number is different if patches have been applied.

 Would that be an acceptable defence of our mark?

 On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the
 remainder of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 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.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may
 have to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 But I am still awaiting guidance from brand on whether a technical name
 usage - e.g. installer package name - is a use of the mark.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-19 Thread Stephen Connolly 
Perhaps, the maven pmc could decree: if you are making a convenience
installer of maven for an OS where the maven pmc does not create a
convenience installer, you may use maven as the packaging name provided
the description clarifies it is a custom build and provides an ack of our
marks. Also the version number is different if patches have been applied.

Would that be an acceptable defence of our mark?

On Wed 19 Aug 2015 at 09:46, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the remainder
 of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


 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.

 The open question remains, is the *Package Name* a name that could be
 viewed as use of the trademark?

 Do the end users - i.e. developers - expect that `apt-get install maven`
 is installing Apache Maven? If they are junior developers my experience
 suggest they may think so...

 So if `apt-get install maven` causes confusion with our brand, we may have
 to ask Debian what they suggest they could do to remove the confusion.

 There are simple solutions, e.g. change the package name to mvn; stop
 making such large sweeping changes to our product; etc

 But I am still awaiting guidance from brand on whether a technical name
 usage - e.g. installer package name - is a use of the mark.

 This gets even more confusing with some of their packaged maven plugins,
 which for interop need to use maven:
 http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
  (more
 obvious with Fedora:
 http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
 Thankfully in these cases I believe the source code is not patched, but it
 is binaries rebuilt from source not pulled down from Maven Central... which
 can cause issues for users.

 Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-19 Thread Stephen Connolly 
On Wed, 19 Aug 2015 at 02:47 Niclas Hedhman nic...@hedhman.org wrote:

 On Wed, Aug 19, 2015 at 3:40 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

 
  Yes that was my analysis of the question: If I decide to produce an
  unofficial binary release of Maven without the approval of the rest of
 the
  PMC, I may not call it Maven. If I did call it Maven then the remainder
 of
  the PMC would be responsible for sending me a CD.
 

 Well, if  Debian can publish their built Apache Maven as maven and
 SteveNick can't publish their built Apache Maven as maven, then the
 inescapable question is; On what non-arbitrary grounds is one acceptable
 and the other is not? It can't be we like Debian, but not SteveNick,
 that is morally weak.


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.

The open question remains, is the *Package Name* a name that could be
viewed as use of the trademark?

Do the end users - i.e. developers - expect that `apt-get install maven` is
installing Apache Maven? If they are junior developers my experience
suggest they may think so...

So if `apt-get install maven` causes confusion with our brand, we may have
to ask Debian what they suggest they could do to remove the confusion.

There are simple solutions, e.g. change the package name to mvn; stop
making such large sweeping changes to our product; etc

But I am still awaiting guidance from brand on whether a technical name
usage - e.g. installer package name - is a use of the mark.

This gets even more confusing with some of their packaged maven plugins,
which for interop need to use maven:
http://pkgs.org/debian-sid/debian-main-i386/libmaven-compiler-plugin-java_3.2-4_all.deb.html
(more
obvious with Fedora:
http://pkgs.org/fedora-23/fedora-i386/maven-compiler-plugin-3.3-2.fc23.noarch.rpm.html)
Thankfully in these cases I believe the source code is not patched, but it
is binaries rebuilt from source not pulled down from Maven Central... which
can cause issues for users.

Fun Fun Fun




 Niclas

Re: apache binary distributions

2015-08-18 Thread Stephen Connolly 
On 18 August 2015 at 18:35, Dennis E. Hamilton dennis.hamil...@acm.org
wrote:

 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.


Yes that was my analysis of the question: If I decide to produce an
unofficial binary release of Maven without the approval of the rest of the
PMC, I may not call it Maven. If I did call it Maven then the remainder of
the PMC would be responsible for sending me a CD.



  - 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

2015-08-17 Thread Stephen Connolly 
On 17 August 2015 at 09:53, Jochen Theodorou blackd...@gmx.org wrote:

 Am 17.08.2015 10:45, schrieb Branko Čibej:
 [...]

 So wait ... If the Subversion PMC releases source, and, say, Debian
 creates a binary package called 'subversion-x.y.z' ... you're saying
 that's trademark infringement and we should be telling all the people
 who produce binary packages to stop using our registered trademark?
 Really?

 Producing binaries is different from creating a derived work. Even if
 packagers change the sources (which they often do, in minor ways, to
 tune the build to their platform), it's less than sane to tell them they
 should rename the packages because of that.

 It would be different if their changes resulted in changed
 functionality, but that's not what's happening.


 My take so far is: The PMC decides upon if they want to allow for that or
 not. So the Subversion PMC could forbid the redistribution of packages
 named subversion-x.y.z... But that does not mean they have to. Where the
 PMC should get active in such matters is if something claims to be
 subversion, but really is not. But again the PMC is responsible for that.


I don't know what Debian is doing to subversion... they are certainly
making - to my mind at least - significant changes to Maven:
http://anonscm.debian.org/cgit/pkg-java/maven.git/tree/debian/patches/plugins_version.diff?id=2628fdf44618983f3c714b6c0a9c320f68ab2ad2

On the other hand, Subversion and Maven both at least have an out for the
distros... we can ask them to use our short-name

I think it is acceptable for our users to

apt-get install mvn

That seems acceptable to me, and would not put into question the usage of
our mark.

For something like

brew install maven

Which really does this:

https://github.com/Homebrew/homebrew/blob/master/Library/Formula/maven.rb

I have a hard time arguing a case that homebrew is abusing our mark...
homebrew goes and grabs our convenience binary, removes some excess files
(windows batch files) and creates symlinks...

In short, my personal opinion is that `brew install maven` is installing
maven as provided by the Apache Maven PMC.

On the other hand, when I look at the description of Debian's maven package:


http://anonscm.debian.org/cgit/pkg-java/maven.git/tree/debian/control?id=2628fdf44618983f3c714b6c0a9c320f68ab2ad2#n47

Description: Java software project management and comprehension tool
  Maven is a software project management and comprehension tool. Based on
 the
  concept of a project object model (POM), Maven can manage a project's
 build,
  reporting and documentation from a central piece of information.
  .
  Maven's primary goal is to allow a developer to comprehend the complete
  state of a development effort in the shortest period of time. In order to
  attain this goal there are several areas of concern that Maven attempts
  to deal with:
  .
 * Making the build process easy
 * Providing a uniform build system
 * Providing quality project information
 * Providing guidelines for best practices development
 * Allowing transparent migration to new features


I see a potential abuse of our mark which I have raised with the rest of
the Apache Maven PMC. It's not a major abuse, for example I believe some
simple changes to this description would suffice:

e.g. by changing it with the following diff

Description: Java software project management and comprehension tool
 - Maven is a software project management and comprehension tool. Based on
 the

+ Debian's redistribution of Apache Maven.

+ .

+ Apache Maven is a software project management and comprehension tool.
 Based on the
   concept of a project object model (POM), Maven can manage a project's
 build,
   reporting and documentation from a central piece of information.
   .
   Maven's primary goal is to allow a developer to comprehend the complete
   state of a development effort in the shortest period of time. In order to
   attain this goal there are several areas of concern that Maven attempts
   to deal with:
   .
  * Making the build process easy
  * Providing a uniform build system
  * Providing quality project information
  * Providing guidelines for best practices development
  * Allowing transparent migration to new features
 + .
 + Apache, Apache Maven and Maven are trademarks of the Apache Software
 Foundation.


The critical question that does concern me, however, is the package name
`maven`... is the package name an abuse of our mark?

I really would appreciate guidance from brand management on the package
name thing.

Users of a distribution expect when they

yum install apache subversion maven

that they have installed Apache HTTPD, Apache Subversion and Apache
Maven... but really they have installed Fedora's httpd service based on
Apache HTTPD, Fedora's svn based on Apache Subversion and Fedora's mvn
based on Apache Maven.

So:

Is Debian calling a package `maven` that is a clearly different thing[1]
from Apache

Re: [VOTE] Accept Groovy into the Apache Incubator

2015-03-19 Thread Stephen Connolly 
+1 (non-binding)

On 19 March 2015 at 06:55, Roman Shaposhnik r...@apache.org wrote:

 Following the discussion earlier in the thread:
http://s.apache.org/KWE

 I would like to call a VOTE for accepting Groovy
 as a new incubator project.

 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.

 == Abstract ==
 Groovy is an object-oriented programming language for the Java
 platform. It is a language with features similar to those of Python,
 Ruby, Java, Perl, and Smalltalk.
 Groovy, if accepted by Incubator, will be a first major programming
 language developed under the umbrella of Apache Software Foundation.

 == Proposal ==
 Groovy is a programming language for the Java platform. It is a
 primarily dynamic language with features similar to those of Python,
 Ruby, Perl, and Smalltalk. It also has optional static type checking
 and static compilation facilities. It can be used as a scripting
 language for the Java Platform or to write complete applications, is
 compiled to Java Virtual Machine (JVM) bytecode, and interoperates
 with other Java code and libraries. Groovy uses a Java-like
 curly-bracket syntax. Most Java code is also syntactically valid
 Groovy, although semantics may be different. Groovy has long been
 developed under an Apache License v2.0 under an open governance
 community management process. However, so far Groovy has been a
 project mostly sponsored by a single company. This proposal aims at
 bringing Groovy community under the umbrella of the Apache Software
 Foundation.

 It must be explicitly noted, that a few sister projects such as Groovy
 Eclipse and others (some of them hosted under
 https://github.com/groovy and listed at
 http://groovy-lang.org/ecosystem.html) are not covered by this
 proposal. It is possible that these other projects will be joining ASF
 either independently or as sub-projects of Apache Groovy in the
 future. For now, we are only proposing groovy-core.

 == Background ==
 Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
 2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
 for release in 2016, with support for a new Meta Object Protocol.
 Since version 2, Groovy can also be compiled statically, offering type
 inference and performance very close to that of Java. Groovy 2.4 will
 be the last major release under Pivotal Software's sponsorship, which
 is scheduled to end on March 31, 2015.

 == Rationale ==
 Groovy is a pretty mature language. After 12 years of development, it
 has grown from being primarily a dynamic scripting language on the JVM
 to an optionally statically compiled language allowing the same
 performance level as Java applications. With the release of Groovy
 2.4, the language targets the largest pool of mobile developers with
 native Android support. Groovy has been integrated in a large number
 of applications, including well known open-source projects like
 Jenkins, Gradle, ElasticSearch, Spring and more.

 There are multiple alternative languages on the JVM: Scala, Clojure,
 Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
 which has proved to be very easy to integrate with Java in both ways:
 Groovy code using Java code, but also Java code using Groovy code.
 Groovy even provides a joint compiler which allows interdependent Java
 and Groovy classes to compile together. Groovy also supports dynamic
 code generation, that is to say classes at runtime, making it a
 perfect fit for scripting. With a very lightweight and malleable
 syntax, it is also easy to build internal Domain Specific Languages
 (DSLs) which integrate smoothly within applications.

 Groovy provides a number of unique features, like builders (Java 8 has
 lambdas but still has syntactic overhead and no notion of delegate),
 AST transformations (compile-time metaprogramming) or type checking
 extensions (which allows the developer to bring the compiler to levels
 of type checking and type inference that go far beyond what other
 languages do). Groovy also provides powerful integration options and
 customizations which set it apart from other languages. Groovy is also
 unique in the way it allows the developer to choose between various
 paradigms without compromise: functional vs object-oriented,
 statically compiled vs dynamic, scripting vs applications, etc.

 Despite all those advantages, and the fact that Groovy is widely
 adopted (4.5 million downloads in 2014 for Groovy alone), only a few
 Apache projects include Groovy and not a lot of them leverage its full
 power. Some developers tend to choose Scala for example to build DSLs
 without even knowing that the learning curve is much easier with
 Groovy, or that they can leverage powerful type inference in their own
 DSLs.

Re: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Stephen Connolly 
Arg! hit send too soon.

You should really check in with Hervé to confirm that Groovy was in the
export. I am 99% confident that your issues and comments are in the XML
dump, but you really should check with Hervé to be certain.

Also you may want to ask Mark Thomas what exactly is involved in preparing
and doing such an import. Our own timelines for Maven's switch may not
align with the Groovy incubation timelines... (mind you we are all at the
grace of Ben for getting our timeline for the second export he committed to
the Maven project)

On 16 March 2015 at 09:49, Stephen Connolly stephen.alan.conno...@gmail.com
 wrote:



 On 16 March 2015 at 09:19, Cédric Champeau cedric.champ...@gmail.com
 wrote:

 Thanks Stephen, sounds like a good news. For us the attachments do not
 matter much, there are not so many. However, keeping track of comments is
 very important, because some issues have a lot of discussions.

 2015-03-16 10:08 GMT+01:00 Stephen Connolly 
 stephen.alan.conno...@gmail.com
 :

  On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org wrote:
 
   Am 16.03.2015 09:25, schrieb Upayavira:
  
   When Stephen Connolly says ”We @ Maven will have a full dump of the
   Codehaus JIRA and we have a VM set
   up to test migration…” isn’t he implying that the Groovy issues are
   *included* in that? I.e. there’s not so much for you to worry about
   here?
  
  
   Even if Stephen gets a full dump, this does not mean we will get the
   Groovy part out of it. Ben was so far telling us he cannot give it out
  like
   that, because of private and internal data in there. Instead he
  suggested a
   json export (which most likely will not contain everything)
  
 
  Well we are getting the full XML dump because that's all you can get via
  the XML dump, but whether we get *all* attachments or only those for
 Maven
  is a different question.
 
 
  
   So unless Stephy has this clear with his employee I stand on the part,
   that we don't have that.
 
 
  Clarification: Ben and I are co-workers.
 
 
  
  
   bye Jochen
  
   --
   Jochen blackdrag Theodorou - Groovy Project Tech Lead
   blog: http://blackdragsview.blogspot.com/
   german groovy discussion newsgroup: de.comp.lang.misc
   For Groovy programming sources visit http://groovy-lang.org
  
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Stephen Connolly 
On 16 March 2015 at 09:58, Mark Thomas ma...@apache.org wrote:

 On 16/03/2015 09:53, Stephen Connolly wrote:
  Arg! hit send too soon.
 
  You should really check in with Hervé to confirm that Groovy was in the
  export. I am 99% confident that your issues and comments are in the XML
  dump, but you really should check with Hervé to be certain.
 
  Also you may want to ask Mark Thomas what exactly is involved in
  preparing and doing such an import. Our own timelines for Maven's switch
  may not align with the Groovy incubation timelines... (mind you we are
  all at the grace of Ben for getting our timeline for the second export
  he committed to the Maven project)

 The latest test export I have does not have any Groovy data in it.


I believe that is because Hervé is stripping out on the VM to handle the
version skew.

IOW as I understand it, Hervé has a full dump. Imports into Codehaus
version of JIRA, upgrades JIRA, removes all the non-maven stuff, does some
mapping and does an export for you.



 Mark


 
  On 16 March 2015 at 09:49, Stephen Connolly
  stephen.alan.conno...@gmail.com
  mailto:stephen.alan.conno...@gmail.com wrote:
 
 
 
  On 16 March 2015 at 09:19, Cédric Champeau
  cedric.champ...@gmail.com mailto:cedric.champ...@gmail.com
 wrote:
 
  Thanks Stephen, sounds like a good news. For us the attachments
  do not
  matter much, there are not so many. However, keeping track of
  comments is
  very important, because some issues have a lot of discussions.
 
  2015-03-16 10:08 GMT+01:00 Stephen Connolly
  stephen.alan.conno...@gmail.com
  mailto:stephen.alan.conno...@gmail.com
  :
 
   On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org
  mailto:blackd...@gmx.org wrote:
  
Am 16.03.2015 09:25, schrieb Upayavira:
   
When Stephen Connolly says ”We @ Maven will have a full
  dump of the
Codehaus JIRA and we have a VM set
up to test migration…” isn’t he implying that the Groovy
  issues are
*included* in that? I.e. there’s not so much for you to
  worry about
here?
   
   
Even if Stephen gets a full dump, this does not mean we will
  get the
Groovy part out of it. Ben was so far telling us he cannot
  give it out
   like
that, because of private and internal data in there. Instead
 he
   suggested a
json export (which most likely will not contain everything)
   
  
   Well we are getting the full XML dump because that's all you
  can get via
   the XML dump, but whether we get *all* attachments or only
  those for Maven
   is a different question.
  
  
   
So unless Stephy has this clear with his employee I stand on
  the part,
that we don't have that.
  
  
   Clarification: Ben and I are co-workers.
  
  
   
   
bye Jochen
   
--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org
   
   
   
 
  -
To unsubscribe, e-mail:
  general-unsubscr...@incubator.apache.org
  mailto:general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
  general-h...@incubator.apache.org
  mailto:general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Stephen Connolly 
On 16 March 2015 at 09:19, Cédric Champeau cedric.champ...@gmail.com
wrote:

 Thanks Stephen, sounds like a good news. For us the attachments do not
 matter much, there are not so many. However, keeping track of comments is
 very important, because some issues have a lot of discussions.

 2015-03-16 10:08 GMT+01:00 Stephen Connolly 
 stephen.alan.conno...@gmail.com
 :

  On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org wrote:
 
   Am 16.03.2015 09:25, schrieb Upayavira:
  
   When Stephen Connolly says ”We @ Maven will have a full dump of the
   Codehaus JIRA and we have a VM set
   up to test migration…” isn’t he implying that the Groovy issues are
   *included* in that? I.e. there’s not so much for you to worry about
   here?
  
  
   Even if Stephen gets a full dump, this does not mean we will get the
   Groovy part out of it. Ben was so far telling us he cannot give it out
  like
   that, because of private and internal data in there. Instead he
  suggested a
   json export (which most likely will not contain everything)
  
 
  Well we are getting the full XML dump because that's all you can get via
  the XML dump, but whether we get *all* attachments or only those for
 Maven
  is a different question.
 
 
  
   So unless Stephy has this clear with his employee I stand on the part,
   that we don't have that.
 
 
  Clarification: Ben and I are co-workers.
 
 
  
  
   bye Jochen
  
   --
   Jochen blackdrag Theodorou - Groovy Project Tech Lead
   blog: http://blackdragsview.blogspot.com/
   german groovy discussion newsgroup: de.comp.lang.misc
   For Groovy programming sources visit http://groovy-lang.org
  
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Stephen Connolly 
You should check with Hervé, but as far as I am aware it is a dump of
everything as JIRA only provides for a full export.

Because there are bits of security information in the export, access to the
dump is restricted, but ASF INFRA also have access to the dump, or we can
probably give one of you access to massage the dump into an importable
state. So I presume you should be ok on getting your issues imported...
though there is a fair bit of work involved and you probably need to check
with Hervé as to the effort has has expended getting ready to import our
issues.

On 16 March 2015 at 08:25, Upayavira u...@odoko.co.uk wrote:

 When Stephen Connolly says ”We @ Maven will have a full dump of the
 Codehaus JIRA and we have a VM set
 up to test migration…” isn’t he implying that the Groovy issues are
 *included* in that? I.e. there’s not so much for you to worry about
 here?

 Upayavira

 On Sat, Mar 14, 2015, at 12:13 AM, Jochen Theodorou wrote:
  Am 13.03.2015 22:38, schrieb Stephen Connolly:
   (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)
 
  ah ok, that explains it. It does not look like we get the privilege so
  far
 
  bye Jochen
 
  --
  Jochen blackdrag Theodorou - Groovy Project Tech Lead
  blog: http://blackdragsview.blogspot.com/
  german groovy discussion newsgroup: de.comp.lang.misc
  For Groovy programming sources visit http://groovy-lang.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: [DISCUSS] Groovy Incubation proposal

2015-03-16 Thread Stephen Connolly 
On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org wrote:

 Am 16.03.2015 09:25, schrieb Upayavira:

 When Stephen Connolly says ”We @ Maven will have a full dump of the
 Codehaus JIRA and we have a VM set
 up to test migration…” isn’t he implying that the Groovy issues are
 *included* in that? I.e. there’s not so much for you to worry about
 here?


 Even if Stephen gets a full dump, this does not mean we will get the
 Groovy part out of it. Ben was so far telling us he cannot give it out like
 that, because of private and internal data in there. Instead he suggested a
 json export (which most likely will not contain everything)


Well we are getting the full XML dump because that's all you can get via
the XML dump, but whether we get *all* attachments or only those for Maven
is a different question.



 So unless Stephy has this clear with his employee I stand on the part,
 that we don't have that.


Clarification: Ben and I are co-workers.




 bye Jochen

 --
 Jochen blackdrag Theodorou - Groovy Project Tech Lead
 blog: http://blackdragsview.blogspot.com/
 german groovy discussion newsgroup: de.comp.lang.misc
 For Groovy programming sources visit http://groovy-lang.org


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

Re: [DISCUSS] Groovy Incubation proposal

2015-03-14 Thread Stephen Connolly 
On Saturday, March 14, 2015, Steve Loughran ste...@hortonworks.com wrote:


  On 14 Mar 2015, at 00:13, Jochen Theodorou blackd...@gmx.org
 javascript:; wrote:
 
  Am 13.03.2015 22:38, schrieb Stephen Connolly:
  (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)
 
  ah ok, that explains it. It does not look like we get the privilege so
 far

 somewhat related  somewhat off-topic What's going to happen to those
 maven plugins that also live in codehaus?

 http://mojo.codehaus.org/

 Certainly http://mojo.codehaus.org/versions-maven-plugin/ is kind of
 important?

 Is anyone trying to recruit them to the ASF project -and get their JIRA
 logs in there too?


The ones that are license incompatible will be moved to a project hosted
on github. The discussion of that is ongoing on the mojo-dev list.

I would like to see the license compatible ones move to the ASF (perhaps
within the maven project where that makes sense). As the principle author
of the versions-maven-plugin I would favour moving that to maven but I
would need to sound out the rest of the maven community/pmc



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



-- 
Sent from my phone

Re: [DISCUSS] Groovy Incubation proposal

2015-03-13 Thread Stephen Connolly 
(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...

 On 13 March 2015 at 17:36, Cédric Champeau cedric.champ...@gmail.com
 wrote:

 Yes the biggest problem is going to be the migration of JIRA. Codehaus
 only
 wants to provide a CSV export which is far from being enough for us. I
 hope
 someone at Apache has experience on this and will be able to get in touch
 with Codehaus to provide a better migration path.

 2015-03-13 18:33 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org:

  On Fri, Mar 13, 2015 at 5:49 PM, Stian Soiland-Reyes st...@apache.org
  wrote:
   ...Is the wider Groovy community aware that transitioning to Apache is
  not
   done overnight? There is no guarantee this will be complete by
 mid-April,
   which to me sounds optimistic...
 
  The full transition might take some time, but as soon as a podling has
  a dev mailing list, code repository and issue tracker it can start to
  operate.
 
  And code obviously...so working on the software grants already [1]
  might be a good idea, and the Groovy podling committers who don't have
  @apache.org accounts yet can already send their iCLAs in [2], that
  doesn't hurt.
 
  Apache accounts creation is fast these days in my experience, I
  haven't seen  24 hours lately.
 
  -Bertrand
 
  [1] https://www.apache.org/licenses/software-grant.txt
  [2] http://www.apache.org/licenses/icla.txt
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-13 Thread Stephen Connolly 
We @ Maven will have a full dump of the Codehaus JIRA and we have a VM set
up to test migration...

On 13 March 2015 at 17:36, Cédric Champeau cedric.champ...@gmail.com
wrote:

 Yes the biggest problem is going to be the migration of JIRA. Codehaus only
 wants to provide a CSV export which is far from being enough for us. I hope
 someone at Apache has experience on this and will be able to get in touch
 with Codehaus to provide a better migration path.

 2015-03-13 18:33 GMT+01:00 Bertrand Delacretaz bdelacre...@apache.org:

  On Fri, Mar 13, 2015 at 5:49 PM, Stian Soiland-Reyes st...@apache.org
  wrote:
   ...Is the wider Groovy community aware that transitioning to Apache is
  not
   done overnight? There is no guarantee this will be complete by
 mid-April,
   which to me sounds optimistic...
 
  The full transition might take some time, but as soon as a podling has
  a dev mailing list, code repository and issue tracker it can start to
  operate.
 
  And code obviously...so working on the software grants already [1]
  might be a good idea, and the Groovy podling committers who don't have
  @apache.org accounts yet can already send their iCLAs in [2], that
  doesn't hurt.
 
  Apache accounts creation is fast these days in my experience, I
  haven't seen  24 hours lately.
 
  -Bertrand
 
  [1] https://www.apache.org/licenses/software-grant.txt
  [2] http://www.apache.org/licenses/icla.txt
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

2015-03-13 Thread Stephen Connolly 
On 13 March 2015 at 10:50, Russel Winder rus...@winder.org.uk wrote:

 I have been reading this thread via GMane with some worry. I have now
 joined the email list and this post is fortuitous in that it allows me
 to make some of the points I wish to contribute.

 On Fri, 2015-03-13 at 08:55 +0100, Bertrand Delacretaz wrote:
  On Thu, Mar 12, 2015 at 6:07 PM, Cédric Champeau
  cedric.champ...@gmail.com wrote:
   ...I see no point in wanting to reach a target number of
   committers. Having a large number of quality contributions, more
   contributors is IMHO more important than people having write access to
 the
   repo
 
  Once again, there's no set number that you have to reach to graduate -
  it is not about numbers.

 I think something has gone very wrong with this point about committer
 count, see below…
 


I will clarify my comments on committer count.

I am fine with the initial committer count being the current core team.
That makes perfect sense.

I do think that to exit incubation, the project needs to demonstrate that
it can grow. This is because there will always be attrition, and if a
project cannot grow to counter-balance the attrition rate then at some
point it will loose critical mass and be cast off into the attic.

What is the easiest way to demonstrate that the project can grow? The
easiest way is to add new committers and PMC members... this project has a
long history of contributors outside of the core group that could be mined
for potential new committers during incubation... if some of those people
can be encouraged to join as a committer then that is by far and above the
easiest demonstration of ability to grow

Is that the only way? Nope, you could have a watch-list of potential
committers and be tracking their progress against whatever bar you have
set, making sure that they demonstrate whatever qualities you deem as
necessary... if you go that route you will have to work harder to prove
that you have the ability to grow...

So, I do not think that Groovy needs to have 5+X committers in order to
exit the incubator. I think that Groovy needs to have demonstrated the
ability to grow its committer and PMC community *however* the Groovy
project chooses to demonstrate its ability to grow (and actual growth is
just the easiest demonstration... you cannot argue with facts)

-Stephen

Re: [DISCUSS] Groovy Incubation proposal

2015-03-11 Thread Stephen Connolly 
If there have been over 200 contributors to the project, I would expect to
see an effort to pull some of them in shortly after entering incubation...
Assuming they can demonstrate merrit.

An initial committer list of 5 for such a big project with a large and
diverse history of contributions would ring alarm bells to me only if it
remained that small when seeking to become a TLP

On Wednesday, March 11, 2015, Roman Shaposhnik r...@apache.org wrote:

 Hi!

 It is my pleasure and privilege to open up the following
 proposal:
 https://wiki.apache.org/incubator/GroovyProposal
 for wide discussion before conducting and IPMC
 vote on it. In order to engage as much potential stakeholders
 as possible we will be soliciting input on {dev,users}@groovy.codehaus.org
 javascript:;
 The main discussion, however, is going to happen on this thread.

 The copy of the proposal is included bellow, but please note
 that any required changes would be reflected on the wiki.

 Thanks,
 Roman (Groovy proposal champion and a nominated mentor).

 == Abstract ==
 Groovy is an object-oriented programming language for the Java
 platform. It is a primarily dynamic language with features similar to
 those of Python, Ruby, Perl, and Smalltalk. Groovy, if accepted by
 Incubator, will be a first major programming language developed under
 the umbrella of Apache Software Foundation.

 == Proposal ==
 Groovy is a programming language for the Java platform. It is a
 primarily dynamic language with features similar to those of Python,
 Ruby, Perl, and Smalltalk. It also has optional static type checking
 and static compilation facilities. It can be used as a scripting
 language for the Java Platform or to write complete applications, is
 compiled to Java Virtual Machine (JVM) bytecode, and interoperates
 with other Java code and libraries. Groovy uses a Java-like
 curly-bracket syntax. Most Java code is also syntactically valid
 Groovy, although semantics may be different. Groovy has long been
 developed under an Apache License v2.0 under an open governance
 community management process. However, so far Groovy has been a
 project mostly sponsored by a single company. This proposal aims at
 bringing Groovy community under the umbrella of the Apache Software
 Foundation.

 It must be explicitly noted, that a few sister projects such as Groovy
 Eclipse and others (some of them hosted under
 https://github.com/groovy and listed at
 http://groovy-lang.org/ecosystem.html) are not covered by this
 proposal. It is possible that these other projects will be joining ASF
 either independently or as sub-projects of Apache Groovy in the
 future. For now, we are only proposing groovy-core.

 == Background ==
 Groovy 1.0 was released on January 2, 2007, and Groovy 2.0 in July,
 2012. Groovy 2.5 is planned for release in 2015. Groovy 3.0 is planned
 for release in 2016, with support for a new Meta Object Protocol.
 Since version 2, Groovy can also be compiled statically, offering type
 inference and performance very close to that of Java. Groovy 2.4 will
 be the last major release under Pivotal Software's sponsorship, which
 is scheduled to end on March 31, 2015.

 == Rationale ==
 Groovy is a pretty mature language. After 12 years of development, it
 has grown from being primarily a dynamic scripting language on the JVM
 to an optionally statically compiled language allowing the same
 performance level as Java applications. With the release of Groovy
 2.4, the language targets the largest pool of mobile developers with
 native Android support. Groovy has been integrated in a large number
 of applications, including well known open-source projects like
 Jenkins, Gradle, ElasticSearch, Spring and more.

 There are multiple alternative languages on the JVM: Scala, Clojure,
 Ceylon, Kotlin, JRuby, Golo and others but Groovy is the only one
 which has proved to be very easy to integrate with Java in both ways:
 Groovy code using Java code, but also Java code using Groovy code.
 Groovy even provides a joint compiler which allows interdependent Java
 and Groovy classes to compile together. Groovy also supports dynamic
 code generation, that is to say classes at runtime, making it a
 perfect fit for scripting. With a very lightweight and malleable
 syntax, it is also easy to build internal Domain Specific Languages
 (DSLs) which integrate smoothly within applications.

 Groovy provides a number of unique features, like builders (Java 8 has
 lambdas but still has syntactic overhead and no notion of delegate),
 AST transformations (compile-time metaprogramming) or type checking
 extensions (which allows the developer to bring the compiler to levels
 of type checking and type inference that go far beyond what other
 languages do). Groovy also provides powerful integration options and
 customizations which set it apart from other languages. Groovy is also
 unique in the way it allows the developer to choose between various
 paradigms without compromise: functional

Re: LICENSE and NOTICE Role Models

2013-12-11 Thread Stephen Connolly 
All,

It would be great if we could get a resolution on some of the JIRA's in
legal, e.g.

https://issues.apache.org/jira/browse/LEGAL-26
https://issues.apache.org/jira/browse/LEGAL-27
https://issues.apache.org/jira/browse/LEGAL-31
https://issues.apache.org/jira/browse/LEGAL-136

Legal-discuss,

As PMC Chair of a TLP I find the situation with regards to these very
confusing. We have had some people state the opinion that our current
practice with regards to LICENSE  NOTICE files is not correct yet these
issues are still unresolved in the LEGAL JIRA and thus, I presume, no legal
decision has been formed. Absence a clear decision from the legal PMC we
have no choice but to presume that our current interpretation is just as
valid as any other interpretation and therefore are continuing with our
current practice, e.g.

The most critical one to the Maven PMC is LEGAL-26:

we have a number of SCM primary roots, for example all our plugins are
within http://svn.apache.org/repos/asf/maven/plugins/trunk/ individual
plugins are sub-folders within the whole, e.g.
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/ We
currently view the primary roots as expected checkout points and the
individual plugins as not being so. Most developers familiar with
Subversion will know that /trunk/ is a root identifier and should expect to
find the LICENSE and NOTICE information at that point.

Maven tooling generates a project site for every component, so you will
have a page such as
http://maven.apache.org/plugins/maven-deploy-plugin/source-repository.htmlwhich
tells you how to checkout the code of the specific module.

In some cases we have multiple modules released together as one operation,
e.g. http://maven.apache.org/surefire/index.html, so you have
http://maven.apache.org/surefire/source-repository.html as the real root
(though in this case this is a GIT based project and at least with GIT the
situation is more clear, namely put a LICENSE  NOTICE file in the root of
the GIT repository... since you cannot checkout a partial GIT repository)

So the net result is that
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/does
not have a LICENSE  NOTICE file *because* it is a tag of
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-deploy-plugin/which
is only a partial of the root
http://svn.apache.org/repos/asf/maven/plugins/trunk/.

FTR, best effort can result in nothing happening at all... after all we
can be an incompetent PMC, as long as we are doing our best effort there
is no guarantee that our best is good enough...

LEGAL-26 needs a very clear and exact ruling. Expected checkout points is
too vague... I may only be interested in the java code of Maven's deploy
plugin... is now
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/an
expected checkout point? what about
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/or
even
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-deploy-plugin-2.8.1/src/main/java/org/apache/maven/plugin/deploy/DeployRequest.java

IMHO we should just put a standard LICENSE and NOTICE file at the root of
the ASF SVN tree and projects that need to be exceptions to that general
LICENSE and NOTICE should have to put the file at the point where it makes
sense that is closest in scope to the content requiring the altered LICENSE
and NOTICE... so, as examples are better at divining meaning, *if* we had
copypasted some BSD code into the Maven Deploy Plugin *then* it would
require a custom LICENSE and NOTICE file as the one inherited from the root
would no longer be valid within that subtree... but in this case we do not
have any such code, so we are fine to retain the inherited code.



On 11 December 2013 05:24, Marvin Humphrey mar...@rectangular.com wrote:

 On Tue, Dec 10, 2013 at 8:10 PM, P. Taylor Goetz ptgo...@gmail.com
 wrote:
  It's kind of interesting to see how this has changed over time and varies
  from project to project.

 Here's Roy Fielding in June 2008, saying exactly the same thing you'll hear
 from us now:

 http://s.apache.org/Y4v

 If the notices aren't required by the bits in the package, then they
 don't belong in NOTICE.  That means there will be a different NOTICE
 file
 required for each differently packaged set of bits.  We must do this by
 hand.

 Because the file is named NOTICE, people tend to think it's for anything
 notice-ish.  This is a pernicious misconception which keeps coming back
 over
 and over like a weed, and it used to be that not a lot of people besides
 Roy
 were effective at combatting it.  Here's Roy in 2008 again:

 http://s.apache.org/ZIU

  Furthermore, I assume it is not problematic to have more stuff in the
  NOTICE file(s) than is really required.

 Yes, it is problematic.  Consider it a tax on all downstream
 recipients.

 Roy can't be everywhere,

Re: Majority vs Lazy Majority

2013-11-19 Thread Stephen Connolly 
well that type of lazy majority is really a majority of binding votes
cast with a quorum which differs from majority of binding votes cast,
majority of votes cast and quorum (i.e. the needs 3x+1 to release...
because remember you cannot veto releases ;-) though only a fool of a
release manager would go ahead with a release when there are a lot of
binding -1 votes cast )


On 19 November 2013 09:28, Bertrand Delacretaz bdelacre...@apache.orgwrote:

 Hi David,

 On Tue, Nov 19, 2013 at 9:52 AM, David Crossley cross...@apache.org
 wrote:
  Bertrand Delacretaz wrote:
  ...lazy majority is mentioned at
  http://ant.apache.org/bylaws.html but I didn't know there was such a
  concept in our projects.
 
  Many projects use it. See this Google search:
   site:apache.org Lazy Majority

 I stand corrected then.

 
  We use it at Forrest:
  http://forrest.apache.org/guidelines.html

 And define it there as a lazy majority vote requires 3 binding +1
 votes and more binding +1 votes than -1 votes.

 http://www.apache.org/foundation/voting.html mentions majority twice,
 and in both cases it is clear to me a majority there is defined as the
 Forrest guidelines define lazy majority.

 So I don't see a need for the term lazy majority. No need to change
 in existing projects bylaws or guidelines, but IMO we should keep it
 simple for the incubator.

 -Bertrand

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

Re: [DISCUSS] Release Apache VXQuery Incubating 0.2 (RC4)

2013-10-18 Thread Stephen Connolly 
On 17 October 2013 06:46, Vinayak Borkar vinay...@gmail.com wrote:

 Hi Marvin,


 Thanks for your email. I was unaware that votes are allowed to take a long
 time. My understanding (albeit flawed, I guess) was that votes are allowed
 to be outstanding for only 72 hours. Hence my email.


My understanding is that votes *by convention* must be open for at least
72h in order to ensure that people across time zones and weekends get a
reasonable chance to contribute to the vote.

If the vote receives its quorum by the time the 72h period is closed, then
the vote result can be called.

If the vote has failed to reach that vote's quorum within the 72h period,
then at the discretion of the person running the vote they can EITHER leave
the vote open and start pinging people who have a vote that would count
towards quorum to try and encourage them to cast OR throw in the towel and
declare the vote void (which is another way of trying to get the attention
of the people who can vote but haven't)

Additionally, if the *entire* electorate (or for certain classes of vote 
50% of the entire electorate) votes before the 72h period is closed then
the vote result can be called early.

For example, if you have a vote where the result will be decided by more
+1's than -1's and there are no vetos... if there are 10 people with a vote
and 6 of them vote +1 within 10 minutes of calling the vote... there is no
need to wait the full 72h (it would be polite to do so though)

If you have a vote where the result is 3x+1 with no veto allowed (e.g. a
release vote) you should not cut that short, as the -1's may indicate
problems with the release that the release manager (i.e. the person running
the vote) may want to address... though it is normally the discretion of
the release manager as to whether they will go ahead with the release if
they have 3x+1 and some -1's as technically they can release once they have
3x+1 (where those +1's are the binding ones of people who's vote
contributes to the quorum) but smart release managers will pay attention to
those -1 (binding) votes and see if there is merit in the objection.

The key things to pay attention to, with any vote, are:
* the electorate requirements - i.e. who has a binding vote...
* the quorum requirements - i.e. how much of the electorate must cast a
vote for the vote to be valid
* the result requirements - i.e. what votes are required in order to call a
vote result
* the minimum duration - i.e. what is the minimum time required before
either a result can be called or the vote abandoned

By convention at the ASF, 72h is the default minimum duration. Shortening
the duration may have no effect as you could be stalled waiting for quorum
anyway, but there could be valid reasons (i.e. zero-day security issue)
where a shorter release vote has merit. [repeatedly calling short votes
because 5 of the electorate are in the same room and will all vote +1
within 30s of the vote being called will raise alarm bells all the way up
to the board very quickly ;-)]

The type of vote determines the quorum requirements but the reasonable
convention is that votes need at least 3 votes from the electorate (i.e.
the governing PMC... which for projects in the incubator is the IPMC).

And for releasing source code form the ASF, the result requirement is at
least 3x+1 from the electorate (no majority needed!!! though again release
managers would be strongly advised to pay attention to any -1's be they
from the electorate or not)

-Stephen


 I do agree that retirement is a valid part of a software system's
 lifecycle. However, in the case of VXQuery the committers have quite some
 juice left in them to make more progress at this time. In fact a lot more
 work gets done on the project than what appears on visible forums like
 mailing lists. We use IM and Skype much more than we use mailing lists.

 The whole release process has been pretty frustrating due to a combination
 of two orthogonal factors that have just been a drain on the team.

 1. While there are guidelines that need to be adhered to by a release, we
 were struggling for a long time to automate the release process so that it
 produced all the artifacts that were needed to satisfy Apache's
 requirements. Instead of all the guidelines as the primary pointer to how
 releases should be made, having one link to the parent pom that can be
 inherited by a Maven-driven Java project that does all the heavy lifting of
 creating a release that meets Apache guildelines would have got us to a
 release a year ago. We finally found this POM by looking at the Helix
 project that had made a successful release.


 2. It feels that the whole voting process around releases is very ad-hoc
 and not very efficient. In fact at times it appears very subjective. As an
 example, look at the voting process around the RCs for VXQuery. All the
 issues raised around RC_i (i  1) have been true of the first RC created.
 So clearly all the issues could have been raised at one

Re: [DISCUSS] [PROPOSAL] Apache Monitoring

2013-09-25 Thread Stephen Connolly 
Why not try Celtic mythology I was thinking Apache Nechtan due to the
association with access to knowledge and floods... but heck I am not good
on my Irish mythology and the Norse ones always sounded way cooler


On 25 September 2013 13:23, Christian Grobmeier grobme...@gmail.com wrote:

 I also see thor is being used by infra:
 status.apache.org

 (mentioning, because it has been proposed as name too).

 However, it's not so bad. I actually mixed up Baldur with Heimdall, who is
 the actual protector of Bifröst. Baldur was more known because he was
 able to return from Hel (sounds like a good name for a server ;-)
 A quick crosscheck told me Heimdall is not used that often.

 For those who were concerned about using nordic godnames: Heimdall was
 named as the father of all humans.

 He was also known for his horn Gjallarhorn which he blew when danger
 appeared. Most notable he blew that horn when Ragnarökr (the end of our
 time and the fall of the gods) starts.

 I imagine the sound of a horn when critical notification of the tool
 happens ;-)

 Another idea i just had was Dagr. It old norsk for Day. In old myths
 Dagr is the son of night and he rides his horse Skinfaxi through heaven.
 The crest of the horse lights the earth with golden shimmer. I imagine
 Apache Dagr to shed light on the dark corners of our applications.


 Heck, when I was young i read a lot about northern mythology. Its so
 poetic. I should spend some time to read again.







 On 25 Sep 2013, at 10:19, Daniel Gruno wrote:

  On 09/25/2013 09:21 AM, Tammo van Lessen wrote:

 Baldr is fine with me, my only concern is the similarity to Apache
 Buildr.


 Just a heads up from infra; baldr.apache.org is already very much a
 thing, and has been for more than five years. If it can be avoided, we'd
 really appreciate it if we can keep the name Baldr for our infrastructure.

 With regards,
 Daniel.


 Tammo
 Am 25.09.2013 01:18 schrieb Olivier Lamy ol...@apache.org:

  So what about Baldr?
 BTW we can start incubation using Monitoring then change the name for
 TLP?
 WDYT?

 On 21 September 2013 06:30, Christian Grobmeier grobme...@gmail.com
 wrote:

 I would like to throw in this document:
 http://www.apache.org/**foundation/marks/naming.htmlhttp://www.apache.org/foundation/marks/naming.html

 We should make a few tests already before we start the process

 officially.


 here is the current list, i felt so free to add a few comments already.

 - CoMon
 There is Common Software, a company. We might have a trademarks
 problem because of similarity.

 - Leitstand
 Not sure if I like the sound :-), but did not find any repositories at
 github. From the meaning, a Leitstand is usually something were you can
 adjust things (more power, less steam and so on). Monitoring would be
 only a part of it. But on the other hand, it expresses things well and
 it is a unused word so far.

 - Thor
 Great name, great god, but unfortunately a lot of people use that name
 for their code :-(

 - Balder / Baldur, also possible: Baldr
 I haven't see a lot with that name, but we need to check this more in
 detail.

  From that perspective, Leitstand would be the best catch from a unique

 point of view. I like Baldr very much from that meaning.

 Lets see if there are more names the next days.




 Romain Manni-Bucau schrieb:

 Why not CoMon? Remind commons monitoring, that's fun and closer to
 english so easier to propagate IMO.
 Le 20 sept. 2013 12:59, Jean-Baptiste Onofré j...@nanthrax.net a

 écrit :


  I like the Apache Leitstand name.

 Regards
 JB

 On 09/20/2013 09:51 AM, Tammo van Lessen wrote:

  So if German is en vogue already, I'd propose Apache Leitstand
 [1],
 which
 means control room. I think it would make also a nice name when
 pronounced in English. This of course only works if the GUI is an
 important
 piece of the project, which is the case if I understood correctly.

 Cheers,
 Tammo

 [1] 
 http://de.wikipedia.org/wiki/Leitstandhttp://de.wikipedia.org/wiki/**Leitstand
 

 http://de.wikipedia.org/wiki/**Leitstandhttp://de.wikipedia.org/wiki/Leitstand
 



 On Fri, Sep 20, 2013 at 3:23 AM, Olivier Lamy ol...@apache.org

 wrote:


 So It looks we have more interested folks.

 But before starting the vote I'd like to find an other name for the
 project.
 Someone proposed Baldur or Balder (note, It's a popular
 germanic
 god). So as a French guy this proposition looks to be rude for me

 :-).

 More seriously, this name doesn't hurt me.
 If any other propositions, it's time to speak.

 Cheers
 --
 Olivier

 On 16 September 2013 08:25, Tammo van Lessen tvanles...@gmail.com
 
 wrote:

  Am 15.09.2013 15:35 schrieb Romain Manni-Bucau 

 rmannibu...@gmail.com

 :

  Hi

 Angular is great but i hope well keep extensibility possible

 without

 js.

  In

  all case well get at least a thread on it to discuss about the

 stack we

 want and well use ;)

  Looking forward to that discussion ;) I'd prefer progressive

 enhancement

 over SPAs in

Re: [PROPOSAL] BatchEE to implement JBatch @apache

2013-09-17 Thread Stephen Connolly 
This is interesting to me, not sure if I have the time to help much, but I
should be able to find some excuses to let my employers help fund (by
letting me use work time) work on this!


On 17 September 2013 11:21, Romain Manni-Bucau rmannibu...@gmail.comwrote:

 Dear ASF members,

 I would like to propose the BatchEE project to the Incubator.

 The BatchEE proposal is available at:
 https://wiki.apache.org/incubator/BatchEEProposal

 I welcome your feedbacks and suggestions.

 Thanks!

 Here is a copy of the proposal:

 = BatchEE, JBatch Implementation =

 === Abstract ===

 BatchEE will be an ASL-licensed implementation of the JBatch
 Specification which is defined as JSR-352 (for version 1.0).

 === Proposal ===

 BatchEE specification is an effort for defining a standard API and way
 to write batches in Java. It is integrated with JavaEE (JTA, CDI)
 but works out of the box in a standalone environment.


 BatchEE Project is responsible for implementing the runtime container
 contract for the JBatch specification. Besides the implementation,
 BatchEE Project will implement the core built-in components that
 further simplifies the developer complex interactions with other Java
 EE specific enterprise operations. For example, it will define default
 reader/processor/writer for jdbc, jpa, xml/json/flat files...

 === Background ===

 Until today writing batches in java meant using a proprietary
 framework and link to JavaEE was quite limited (or missing). JBatch
 defines an API fixing this issue and now developpers need a fix.

 === Rationale ===

 Current JBatch specificatin is released, and only the reference
 implementation is available but not really intended to be maintained.
 Moreover multiple Apache projects (geronimo, TomEE, ...) will need an
 Apache compatible Jbatch implementation to go ahread and implement
 JavaEE 7.


 === Initial Goals ===

 The initial goals of the BatchEE Project are

  * Fully implement the JSR-352 specification.
  * Attracts a community around the current code base.
  * Active relationship with the other dependent projects to further
 develop some useful batch components.

 == Current Status ==

 === Meritocracy ===

 Initial developer of the project is familiar with the meritocracy
 principles of Apache. He knows that the open source gets power from
 its great developers and freedom. He also developed some other open
 source projects. We will follow the normal meritocracy rules also with
 other potential contributors.

 === Community ===

 There is a great community within the OpenEJB, OpenWebBeans, Geronimo
 and TomEE Apache projects. BatchEE project is very related with these
 projects and in the some cases, it enhances these projects. We are
 thinking that BatchEE project gets strong community because it
 complete the needed frameworks of a java developper and unifies the
 using of these projects. It simplifies the developer effort for
 building complex enterprise applications batches.

 === Core Developers ===

 BatchEE project has been developing by the IBM then forked by Romain
 Manni-Bucau as a sole contributor.

 === Alignment ===

 BacthEE project will be a candidate for use in Geronimo AS and TomEE
 as a default JBatch implementation. Other projects could benefit from
 the BatchEE project as a general purpose component and context
 management.

 BatchEE project is closely aligned with the OpenEJB and OpenWebBeans
 projects perfectly. It depends on these projects to satisfy its
 requirements (mainly tests).

 == Known Risks ==

 === Orphaned products ===

 Even if the initial committer of the project has no plan to leave the
 active development, it must necessary to get other committers for the
 project. So that it less dependent on the single developer. The source
 code of the project is well documented and new committers could easily
 grasp the details. Initial committer continues to support actively
 this project.

 === Inexperience with Open Source ===

 Initial developer have worked on open source project before, including
 OpenEJB/TomEE, OpenWebBeans, XBean...

 === Homogeneous Developers ===

 Altough the initial committer of the project is single, developer team
 may be increased within the active project lifecycle from the
 different locations.

 === Reliance on Salaried Developers ===

 Project currently has no salaried developers. All the commitment is
 done by the volunteer developer.

 === Relationships with Other Apache Products ===

 BatchEE will likely be used in the Geronimo and Apache TomEE.
 OpenWebBeans could bring added value for tests and integration with
 CDI. OpenEJB will be great to pass EE tests (JTA is mandatory and CDi
 a must have).

 === An Excessive Fascination with the Apache Brand ===

 BatchEE project initial committer is the strong supporter of the open
 source projects. Initial committer of the project thinks that ASF has
 great place that provides wider colloboration and support of the open
 source project and it respects

Re: Looking for a Champion

2013-06-06 Thread Stephen Connolly 
There is no requirement in Jenkins to extend AbstractProject if you don't
need a SCM. For example we have a number of proprietary plugins that extend
from different points in the Jenkins object tree, e.g. TopLevelItem, Job,
etc depending on how much code reuse is required.

I am not knocking your proposal, but just pointing out that the
limitations in focus that you see with Jenkins are, from my perspective,
just limitations in imagination/knowledge as to where in the Jenkins object
tree to extend from.

I think KK sees Jenkins as a generic task scheduler with a set of default
tasks centred around CI, certainly he has felt that way since I first had
IRC chats with him in 2007-8, so it's not a new thing from my perspective.

OTOH if you already have a good code base or even a good itch that you feel
needs scratching and this is the best way for you to scratch that itch, go
for it...

From my perspective, if I felt that selecting SCM = None was too ugly for
me, I'd just knock up a Jenkins plugin that extends earlier in the object
tree (mind you I have written about 3-4 such plugins by now, so I know the
tricks)... the advantage with that tack is you get to leverage a large user
base... the disadvantage is you have to deal with jelly and stapler and
KK's lack of gröking how Maven works (which results in some Maven
anti-patterns in Jenkins and the Jenkins tooling... but he is getting
better ;-) )


On 6 June 2013 07:53, Andy Van Den Heuvel andy.vandenheu...@gmail.comwrote:

 Jenkins is used to build software projects. It's a continuous integration
 server.
 Tashlin will be more generic, used to build any set of tasks. Also business
 processes are possible.

 Example: Let's say I want a job to do a HTTP GET call every 5 minutes and
 show the results.
 In Jenkins, I'll probably create a free-style project, but it asks me for a
 SCM which makes no sense for this scenario.
 I think a lot of people today hack around the fact that Jenkins is a
 continuous integration server, because it is easy to use and to setup
 scheduling tasks.

 If we make a generic platform we can create a one stop shop for all
 schedeling tasks.



 On Thu, Jun 6, 2013 at 8:17 AM, Alexei Fedotov alexei.fedo...@gmail.com
 wrote:

  There is no requirement to be different to join, I just wonder
  06.06.2013 9:36 пользователь Andy Van Den Heuvel 
  andy.vandenheu...@gmail.com написал:
 
   My apologies for causing confusion. Hopefully this will clear things
 up:
  
   Abstract
   Tashlin is a lightweight application for composing and executing batch
  jobs
   via a web user interface.
  
   Brief Description
   Tashlin allows you to create and run batch jobs in a standalone
  application
   for use cases where you want to automate a set of tasks. It will
 provide
  a
   simple workflow
   which allows users to set up automation up in minutes with provided
  plugins
   for common functionality. This differs from tools like Jenkins in that
 it
   can be used in a
   more generic way. Continuous integration is just one of the
 possibities.
   (E.g. integration with SCM or build automation is not a requirement).
   Other use cases are Monitoring, Backups, General Process Automation...
  
   The basic idea runs around these concepts:
   Recipe: Users will compose recipes. This is a template that will be
   executed by a Job
   Flow: A recipe contains 2 flows: a buildflow (= will stop when an
  exception
   is thrown) and a feedbackflow (will run, even when exceptions are
 thrown
  to
   notify interested parties)
   Step: A flow will execute a set of steps. Step logic will be provided
   through the use of plugins. Step configuration can be configured.
   Job: A job will be executed on a specific trigger. (on-demand,
   cron-based...) and can contain parameters.
   Parameter: A parameter is a value that can be used in a recipe so that
   recipes can be reused
  
   Because it has come up on this thread, I'll give continuous integration
  as
   an example.
   Let's say I want to setup continuous integration for my maven project.
   I create a recipe with 2 build steps ('CheckOut From Subversion',
 'Build
   With Maven') and 1 feedback step ('Email results').
   I create a job using this recipe and providing a parameter 'Goals' with
   value 'clean install'
   The 'Build With Maven' step will have ${GOALS} as a placeholder, the
  value
   will be provided when executing the recipe (via EL).
   Now I can create a 2nd job providing a parameter 'Goals' with value
  'clean
   test -Dtest=*IntegrationTests' etc.
  
   Keep in mind that this is just a very basic example. The goal of the
   project is to bridge the gap for people who simply want to automate
 stuff
   and see the results of it.
   I think that a lot of people could benefit from this.
  
  
  
  
  
  
  
  
  
   On Wed, Jun 5, 2013 at 4:36 PM, Mohammad Nour El-Din 
   nour.moham...@gmail.com wrote:
  
@Ate Yes I noticed but not enough information here in the thread to
  make
anyone

Re: [DISCUSS] Apache Mayhem proposal

2012-11-05 Thread Stephen Connolly 
On 3 November 2012 17:22, Olivier Lamy ol...@apache.org wrote:

 2012/11/3 Simone Tripodi simonetrip...@apache.org:
  Hi again Mohammed,
 
  one think I am curious about the Git management for Mayhem is how to
  handle the fact that Mayhem is composed by components, like apache
  commons, each component has his own lifecycle.
 
  While on SVN I would have imported components in a structure like
 
  trunk
   `- component1
   `- component2
   `- component3
   `- component4
  tags
   `- component1-0.1
   `- component1-0.2
   `- component2-0.1
 
  how the same structure can be replicated in Git? I am asking because I
  noticed on [1] that commons components have 1 git repo for each
  component.
 AFAIK not possible (git is poor for supporting such sparse checkout mode).
 So we (infra folks) will have to maintain one git repo per component
 and create a new git repo for each new component (IMHO a pain ..).
 In some case git is probably nice but not here !
 We have very similar situation in maven projects (with some components
 which have their own lifecycle) and we decided to not move those parts
 to git.


YET

you forgot the YET.

We may still decide to move them to git ;-)


 But hey what is most important build a community around cool
 code/projects or being able to use the last à la mode scm tool ?

 
  Many thanks in advance, all the best!
  -Simo
 
  [1] http://git.apache.org/
 
  http://people.apache.org/~simonetripodi/
  http://simonetripodi.livejournal.com/
  http://twitter.com/simonetripodi
  http://www.99soft.org/
 
 
  On Fri, Nov 2, 2012 at 1:56 PM, Simone Tripodi simonetrip...@apache.org
 wrote:
  Hi Mohammed!
 
  IMO it would be easier to move into a Git repository, which I will
 help in
  setting it up. IMO, it will also be helpful for ASF Git support to have
  more projects using Git which will help us understand different needs
 and
  use cases of different project to provide better Git support by time,
 by
  better I mean that now it is really good IMO but for sure we can make
 it
  better :)
 
  agreed! can you update the reference in the proposal, please? TIA!!!
 
 
  The thing is we still need to have SVN for content related operations
 like
  website and so cause it needs to be published using SVN pub-sub. I will
  collect more details about that
 
 
  thanks a lot! Can we propose the site be published on Git, like we
  already did on GitHub in the `gh-pages` branch? WDYT?
 
  All the best,
  -Simo
 
  http://people.apache.org/~simonetripodi/
  http://simonetripodi.livejournal.com/
  http://twitter.com/simonetripodi
  http://www.99soft.org/
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 



 --
 Olivier Lamy
 Talend: http://coders.talend.com
 http://twitter.com/olamy | http://linkedin.com/in/olamy

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

Re: key signing

2012-10-10 Thread Stephen Connolly 
On 10 October 2012 15:20, Ted Dunning ted.dunn...@gmail.com wrote:



 Sent from my iPhone

 On Oct 10, 2012, at 2:47 AM, Noah Slater nsla...@tumbolia.org wrote:

  Can you clarify? I understand that being able to speak to someone face to
  face, and seeing their mannerisms and expressions, allows you to
 understand
  them better. Some deep rooted human thing. But how does this impact
  security or trust, in the context of key signing?

 I have friends who live far away.  I know them well.  I don't know their
 key fingerprint.

 If we send emails or if we text back and forth I  not clear that it is
 them.  If I have a video conference and the hold up the fingerprint I know
 it is them.


or someone with a very good disguise... and you don't rule out the man in
the mask behind the camera holding the gun pointed at them to get them to
hold up the masked man's fingerprint and not their own.

Though face-to-face doesn't remove the masked man threats... it does make
them harder (relying on threats to family/friends, etc)

;-)




 
  On Wed, Oct 10, 2012 at 4:00 AM, Ted Dunning ted.dunn...@gmail.com
 wrote:
 
  If you know the person, it adds something that you don't get.
 
 

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

[ANN] Committer School for people who want to become Maven Committers

2012-07-11 Thread Stephen Connolly 
Hi everyone,

I just posted on my blog about an idea to get some more committers involved
in the Maven project:

http://javaadventure.blogspot.ie/2012/07/do-you-want-to-become-maven-committer.html

If you are interested sign up.

Also please consider tweeting, google+ing, facebooking, etc so we can get
the word out.

-Stephen

[ANN] JSZip Maven Plugin 0.1-alpha-1 released

2012-06-01 Thread Stephen Connolly 
Hi everyone,

So I have been working on my view of what JavaScript based web
application development should be like with Maven, to that end I have
created the JSZip set of projects. The first semi-ready piece of work
from that set of projects is the JSZip Maven Plugin.

This is very early code, but it works... I just cannot and will not
promise that the exact way it works in 0.1-alpha-1 will be the same as
in 1.0 when I get to 1.0... however, the *functionality* should remain
the same.

The key differentiator of the JSZip Maven plugin is multi-module live
development... i.e.

1. You start with a multi-module project with multiple java and
javascript modules and a webapp.
2. At the root aggregator project, you start maven like so: mvn jszip:run
3. At the first cut this looks like jetty:run, except that it skips
execution on modules which are not of packaging=war, so you can run at
the aggregator root.
4. You fire up a browser and start testing your app
5. You find a problem, in your editor, fix the JavaScript file (it's
in a different module from the war module) and save it
6. *First difference from jetty:run* Just hit reload in your browser
[Note: no need for ^C, mvn clean install -DskipTests  mvn jetty:run
-f webapp/pom.xml]
7. Oh dear you need a change to the backing java class (it's in a
different module from the war module), make the change,
8. *Second difference from jetty:run* Tell your IDE to recompile the
class, servlet restarts automatically [Note: no need for ^C, mvn clean
install -DskipTests  mvn jetty:run -f webapp/pom.xml]
9. Oh dear, you know what I need to add a dependency to finish coding
that java method
10. *Third difference from jetty:run* Add the dependency to the
pom.xml, edit the java method using the new dependency, tell your IDE
to compile the java class, dependency is downloaded automatically and
added to the classpath and the servlet is restarted automatically.
[Note: no need for ^C, mvn clean install -DskipTests  mvn jetty:run
-f webapp/pom.xml]

The dependencies can even come from the reactor *providing the reactor
build order is maintained*. If the reactor build order is modified, we
have to stop the process as there is only so much dynamic that can be
supported.

The next steps are:

1. Refactor the pile of hacks into something that can be:
* used by others (i.e. let jetty:run and tomcat:run benefit from my tricks)
* maintainable by me and others

2. Figure out the best way to handle modular javascript with Maven now
that this plugin delivers a live-development experience

This release is aimed at providing something that will enable others
to help with the above two goals.

Note: bugs, their reporting and fixing are going to be ignored until
after steps 12 have been solved.

Note 2: The intention is that at least the JSZip Maven Plugin and and
shared components will be moved into the ASF incubator once the rough
edges have been knocked off and a community has been built. Some
components will necessarily have to remain outside, such as community
packaging of GPL licensed JavaScript libraries where the maintainers
of the JavaScript library are not interested in producing a JSZip
module packaging of their library.

Please join us at

  jszip-us...@googlegroups.com
and/or
  jszip-...@googlegroups.com

Thanks

-Stephen

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

Re: [ANN] JSZip Maven Plugin 0.1-alpha-1 released

2012-06-01 Thread Stephen Connolly 
Doeth:

http://jszip.org

On 1 June 2012 10:13, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
 Hi everyone,

 So I have been working on my view of what JavaScript based web
 application development should be like with Maven, to that end I have
 created the JSZip set of projects. The first semi-ready piece of work
 from that set of projects is the JSZip Maven Plugin.

 This is very early code, but it works... I just cannot and will not
 promise that the exact way it works in 0.1-alpha-1 will be the same as
 in 1.0 when I get to 1.0... however, the *functionality* should remain
 the same.

 The key differentiator of the JSZip Maven plugin is multi-module live
 development... i.e.

 1. You start with a multi-module project with multiple java and
 javascript modules and a webapp.
 2. At the root aggregator project, you start maven like so: mvn jszip:run
 3. At the first cut this looks like jetty:run, except that it skips
 execution on modules which are not of packaging=war, so you can run at
 the aggregator root.
 4. You fire up a browser and start testing your app
 5. You find a problem, in your editor, fix the JavaScript file (it's
 in a different module from the war module) and save it
 6. *First difference from jetty:run* Just hit reload in your browser
 [Note: no need for ^C, mvn clean install -DskipTests  mvn jetty:run
 -f webapp/pom.xml]
 7. Oh dear you need a change to the backing java class (it's in a
 different module from the war module), make the change,
 8. *Second difference from jetty:run* Tell your IDE to recompile the
 class, servlet restarts automatically [Note: no need for ^C, mvn clean
 install -DskipTests  mvn jetty:run -f webapp/pom.xml]
 9. Oh dear, you know what I need to add a dependency to finish coding
 that java method
 10. *Third difference from jetty:run* Add the dependency to the
 pom.xml, edit the java method using the new dependency, tell your IDE
 to compile the java class, dependency is downloaded automatically and
 added to the classpath and the servlet is restarted automatically.
 [Note: no need for ^C, mvn clean install -DskipTests  mvn jetty:run
 -f webapp/pom.xml]

 The dependencies can even come from the reactor *providing the reactor
 build order is maintained*. If the reactor build order is modified, we
 have to stop the process as there is only so much dynamic that can be
 supported.

 The next steps are:

 1. Refactor the pile of hacks into something that can be:
    * used by others (i.e. let jetty:run and tomcat:run benefit from my tricks)
    * maintainable by me and others

 2. Figure out the best way to handle modular javascript with Maven now
 that this plugin delivers a live-development experience

 This release is aimed at providing something that will enable others
 to help with the above two goals.

 Note: bugs, their reporting and fixing are going to be ignored until
 after steps 12 have been solved.

 Note 2: The intention is that at least the JSZip Maven Plugin and and
 shared components will be moved into the ASF incubator once the rough
 edges have been knocked off and a community has been built. Some
 components will necessarily have to remain outside, such as community
 packaging of GPL licensed JavaScript libraries where the maintainers
 of the JavaScript library are not interested in producing a JSZip
 module packaging of their library.

 Please join us at

  jszip-us...@googlegroups.com
 and/or
  jszip-...@googlegroups.com

 Thanks

 -Stephen

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

Re: [mojo-user] [ANN] JSZip Maven Plugin 0.1-alpha-1 released

2012-06-01 Thread Stephen Connolly 
On 1 June 2012 15:19, Christopher Hunt hu...@internode.on.net wrote:
 Hi Stephen,

 Not sure if you know, but the JS Import project (1) can already utilise zip 
 files with a www classifier. The regular Assembly plugin can be used to 
 make these packages. The following type of dependency declaration can then be 
 made:

                dependency
                        groupIdorg.codehaus.mojo/groupId
                        artifactIdbootstrap-amd/artifactId
                        version2.0.2-alpha-1/version
                        classifierwww/classifier
                        typezip/type
                /dependency


Oh I know about that but it prevents the live editing that is possible
by using the jszip packaging type.

 In addition to this the following libraries are present on Maven Central via 
 the MJS project (2):
 * almond
 * bootstrap
 * d3.js
 * jquery
 * jquery-mobile
 * jquery-ui
 * knockout.js
 * qunit

They can all be reused by specifying the dependency type as jszip and
the classifier, though if they are produced in the reactor you don't
get the live linking with jszip:run


 Kind regards,
 Christopher

 (1) http://mojo.codehaus.org/js-import-maven-plugin/
 (2) http://mojo.codehaus.org/javascript-maven-tools/index.html

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

Re: [jszip-dev] Re: [mojo-user] [ANN] JSZip Maven Plugin 0.1-alpha-1 released

2012-06-01 Thread Stephen Connolly 
Yes, though jars don't work as well for packaging... let's drop the
other mailing lists (left on BCC to let them know they are being
dropped ;-) ) and move to just jszip-...@googlegroups.com

On 1 June 2012 15:24, LeClaire Garvin garvin.lecla...@gmail.com wrote:
 I think there is also some overlap with the web jar repository 
 (https://github.com/webjars/webjars.github.com) project


 Regards,

 Garvin LeClaire
 garvin.lecla...@gmail.com



 On Jun 1, 2012, at 10:19 AM, Christopher Hunt wrote:

 Hi Stephen,

 Not sure if you know, but the JS Import project (1) can already utilise zip 
 files with a www classifier. The regular Assembly plugin can be used to 
 make these packages. The following type of dependency declaration can then be 
 made:

                dependency
                        groupIdorg.codehaus.mojo/groupId
                        artifactIdbootstrap-amd/artifactId
                        version2.0.2-alpha-1/version
                        classifierwww/classifier
                        typezip/type
                /dependency

 In addition to this the following libraries are present on Maven Central via 
 the MJS project (2):
 * almond
 * bootstrap
 * d3.js
 * jquery
 * jquery-mobile
 * jquery-ui
 * knockout.js
 * qunit

 Kind regards,
 Christopher

 (1) http://mojo.codehaus.org/js-import-maven-plugin/
 (2) http://mojo.codehaus.org/javascript-maven-tools/index.html
 -
 To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email



 --
 You received this message because you are subscribed to the Google Groups 
 JSZip Developers group.
 To post to this group, send email to jszip-...@googlegroups.com.
 To unsubscribe from this group, send email to 
 jszip-dev+unsubscr...@googlegroups.com.
 For more options, visit this group at 
 http://groups.google.com/group/jszip-dev?hl=en.


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

Re: Question RE a non-ASF hosted project requiring contributors to have a signed ICLA submitted to the ASF

2012-04-21 Thread Stephen Connolly 
On 21 April 2012 10:32, Mark Struberg strub...@yahoo.de wrote:

 PS: whoever does some builds with maven and has JavaScript in those
 projects should take a peek at jszip.org. It's really a nice project!


Thanks, great praise given that I only have the dynamic cross-reactor
classpath reloading working at this point.

Yes, you read that right, you go mvn jszip:run at the root of your reactor
and then while that serves up your webapp you can work on the javascript in
any module and just hit reload... work on a class in any module, just tell
your IDE to compile it and 10sec later the servlet container will restart
with the new classpath... add an external dependency to any pom and the
servlet container will restart after it's downloaded... add an internal
dependency to any pom and provided the reactor build order is not affected,
the servlet container will restart also.

Remaining features to integrate are the minifiers, LESS - CSS compiler
(and others), and the AMD simplified support... once I have that done it
will be call in the alpha testers ;-)




 - Original Message -
  From: Jukka Zitting jukka.zitt...@gmail.com
  To: general@incubator.apache.org
  Cc:
  Sent: Friday, April 20, 2012 5:04 PM
  Subject: Re: Question RE a non-ASF hosted project requiring contributors
 to have a signed ICLA submitted to the ASF
 
  Hi,
 
  On Fri, Apr 20, 2012 at 4:34 PM, Greg Stein gst...@gmail.com wrote:
   One issue is making releases. If you have a small community, then
 growing
   it is much easier if you have an active series of releases. It garners
   attention. Unfortunately, incubating projects have a little harder time
   making releases (either the initial release getting things in order, or
   gathering three +1 votes if they're small)
 
  That's what we have mentors for (among other things). Even small
  podling should be able to cut releases as long as they have mentors
  who're willing to help.
 
  Of course that highlights the issue of having active mentors. If a
  potential podling can't find enough interested mentors, then it's
  probably best to first build momentum elsewhere before considering
  incubation.
 
  BR,
 
  Jukka Zitting
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 

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

Question RE a non-ASF hosted project requiring contributors to have a signed ICLA submitted to the ASF

2012-04-19 Thread Stephen Connolly 
Bertrand suggested to send this question here.

I have a non-ASF hosted project (jszip.org hosted on github in case you are
interested), which I am hoping to build enough of a developer community
(currently it is just me) around to be able to bring it into the ASF.

To this end, I am licensing it under the ASL.

I don't want to have to maintain the ICLAs and CCLAs of contributors.

Would it be OK if instead I just require that they have a signed ICLA with
the ASF and that they grant the copyright to the ASF since my eventual
intent is to bring this project into the ASF (once I have sufficient
community to bring it in that is! ;-) )

Thanks for considering this question.

-Stephen