Re: [IMPC] [VOTE] Graduate Apache Jena as a Top Level Project

2012-04-03 Thread Leo Simons
On Mon, Apr 2, 2012 at 11:10 AM, Andy Seaborne a...@apache.org wrote:
 This is a call for vote to graduate the Apache Jena podling from Apache
 Incubator to be a top level project.

+1, binding, mentor

cheers!

- Leo (doing a little celebration dance)

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



Re: [VOTE] Release Jena LARQ 1.0.0-incubating

2012-04-03 Thread Leo Simons
On Sun, Apr 1, 2012 at 9:48 PM, Paolo Castagna
castagna.li...@googlemail.com wrote:
 here is a vote on a release for Apache Jena LARQ module:
 jena-larq-1.0.0-incubating.
...
 Proposed files and structure to merge with existing dist/ area:
 http://people.apache.org/~castagna/merge-jena-larq-1.0.0-RC-1/

+1

cheers,

Leo

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



Re: Question about downloading binaries

2012-04-03 Thread Leo Simons
(dropped infra@)

On Mon, Apr 2, 2012 at 10:54 PM, Benson Margulies bimargul...@gmail.com wrote:
 I'm exceedingly sorry here that the IPMC as a whole let you down by
 not turning into these issues and dealing with them at the outset.

Me too.

 Personally, I have no objection to including mutant jars in a -deps
 binary with a clear explanation of what they are, but I would like to
 see some support for that view, because I'd could imagine some
 objections based on recent email.

Me neither.

But let me expand on that :-)

Note the recent (explosive?) discussions were about source releases.
If you get those right, what ancillary stuff (binaries, -deps
packages, maven-repo-structured jar directories, ...) you can then
_also_ have is not so much under discussion I think.

Looking into ManifoldCF a bit, I think what you need is

* buildable source release that contains all the source for ManifoldCF
* source release that contains all the custom patches for the
dependencies that need patches
** you could include the source code, but I'd actually prefer not to do that
* source release that contains instructions for patching and then
installing needed dependencies
** ideally this is all scripted of course (`build.xml
install-and-patch-xerces` downloads xerces source release, extracts
and applies patch, builds jar, copies jar into place, ...), but I
don't see that as a requirement

And if you have all that, then yeah, having various binary
conveniences as well is not much of a discussion.


cheers,


Leo

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



Re: Question about downloading binaries

2012-04-03 Thread Leo Simons
On Tue, Apr 3, 2012 at 5:04 PM, Karl Wright daddy...@gmail.com wrote:
 It sounds like I wasn't clear enough.

 The proposal is for the following release artifacts:

 (1) A source-only tar
 (2) A source+binary dependencies convenience tar
 (3) A binary tar

 This is instead of:

 (1) A source-only tar
 (2) A binary dependencies convenience tar
 (3) A binary tar

 Hope that helps...  The question is, will Roy (or anyone else) be
 unwilling to vote for the first option?

Can't speak for Roy of course, but *my* interpretation is that what
matters is having (1).

A readily buildable source release that contains all the source code
that comprises the project, that is the official release of the
project by the ASF, that is the open source apache-licensed thing that
is carefully inspected and tested by the (P)PMC, that is the thing
that is voted on, that you point to from your website as the source
release, and such and so forth.

Once you have (1), there's many different acceptable approaches for
(2),(3),(4), and so on. I personally feel ManifoldCF (like any other
project), perhaps with help from their mentors, can decide for
themselves what is the best approach. For example, I don't
particularly understand the purpose/value of either version of (2)
(wouldn't I just always want the binary version?), but that's fine :)


cheerio,


Leo

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



Re: Multi-licensed dependencies

2012-03-30 Thread Leo Simons
On Thu, Mar 29, 2012 at 8:42 PM, sebb seb...@gmail.com wrote:
 On 29 March 2012 18:43, Roy T. Fielding field...@gbiv.com wrote:
 On Mar 29, 2012, at 6:17 PM, Marvin Humphrey wrote:
 Personally, I agree with Roy.  Perhaps it might seem a little odd to include
 the text of e.g. the GPLv2 in one of our LICENSE files (alongside a more
 permissive license), but the key here is that it is both legally OK for us 
 to
 distribute a product bundling such a dependency without explicitly 
 justifying
 our usage, and legally OK for a downstream consumer to distribute a product
 bundling ours which asserts usage of the dependency under a different
 rationale.

 I prefer to put our license in the file and then, at the bottom, refer
 to a list of other licenses per dependency (if included in this package),
 wherein the dependency licenses are in separate files near the dependency.

 However, this does not agree with the following [1]:


 ...
 When an artifact contains code under several licenses, the LICENSE
 file should contain details of all these licenses. For each component
 which is not Apache licensed, details of the component and the license
 under which the component is distributed should be appended to the
 LICENSE file.
 

 [1] 
 http://www.apache.org/dev/release.html#distributing-code-under-several-licenses

...the license file SHOULD contain ...

I believe at least some of these
how-to-put-the-license(s)-into-the-file(s) statements are not
necessarily backed up by it must be this way legally or this is
unambiguously always the best way kind of thoughts, but more by this
is a good standard way to do it, that is easy to do and
(automatically) verify. So Roy saying I prefer does not necessarily
conflict with the SHOULD in the policy.

I very much like the approach where the Incubator teaches the
documented policies that have been defined by Legal. While it's
probably good to have Roy's preferences (which I trust are good ones)
reflected in our policy docs, that should happen via legal-discuss in
this case, and even after that, we should not change what we teach our
podlings until the docs have changed. It gets way too confusing way
too quickly, otherwise.


cheerio,


Leo

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



Re: Binary dependencies in source releases (Was: [VOTE] Release ManifoldCF 0.5-incubating, RC0)

2012-03-27 Thread Leo Simons
On Tue, Mar 27, 2012 at 12:57 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Let's decouple this thread from the specific issue of the ManifoldCF
 release. There's a long tradition of Apache releases like the ones
 ManifoldCF is producing, so turning this suddenly into a blocker is
 IMHO bad business, especially since no legal issues are involved (this
 is about Apache policy). If we do come to the consensus that releases
 like this are contrary to Apache policy,

*jaw drops*. Huh?

But, but, but. But! It's called open *source*.

I am honestly just really surprised that this can even come up as a
discussion topic. It's such a core concept that source releases are,
well, *source* releases, everything is built on top of it. It's not a
policy thing, it's a definition thing.

The one case I can imagine that might be sort-of ok is if you ship a
release with an ant-based build that includes a custom task, and in
the source release of your entire project you *also* include a binary
version of the custom task, so lazy people (or those without a working
bash, or whatever) can avoid running your bootstrap script. (and
simlarly, s/ant/maven/, s/task/plugin/, etc). But there's obviously
better ways to do that stuff (target that compiles task, taskdef for
task in next target, that kind of thing).

 then affected projects should
 be given a reasonable amount of time to adapt.

Uhm. Normally I'd want to take a similar approach. But. But. But! Open
*source*. It's so fundamental to what we do.

This seems exactly the reason why we have incubation disclaimers: so
we make clear to our downstream users we might be making some mistakes
like this, and so that we can then be agile in fixing it. Whoops,
made a mistake folks, no downloads here, stand by while the podling
makes a new release

I'd think that when we find a problem like this after a release is
published, we (we as in the PMC, this is not a task to shove onto
infra!) should immediately explain the problem and then immediately
yank any existing incubation releases that have an issue here. No
grace period, no voting, no discussion. Just fix it.

That said, I'm not aware of us actually having such a release out there?

How to deal with this stuff for TLPs that got it wrong, well, I guess
that's a conversation for (a) different mailing list(s).


g'night


Leo, still trying to pick his jaw up from the floor

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



Re: [VOTE] Release Jena Fuseki 0.2.1-incubating

2012-03-21 Thread Leo Simons
+1 from me.

Can we get 2 more IPMC votes?

(Checked KEYS, signatures, LICENSEs, NOTICEs, license headers. Built
source release, watched maven download the internet. Ran compiled
source and binary distribution and played with web interface. Almost
remembered how to write SPARQL. Etc. All looks good to me.)

cheers,

Leo

On Sun, Mar 18, 2012 at 9:20 PM, Andy Seaborne a...@apache.org wrote:
 Hi,

 Here is a vote on a release for Jena Fuseki module, 0.2.1-incubating. This
 RC-2 of this release.

 Please vote to approve this release:

   [ ] +1 Approve the release
   [ ]  0 Don't care
   [ ] -1 Don't release, because ...

 This vote will be open until:

   Wednesday 21/March 23:59 UTC
   (3 whole days: 72 hours from the same hour tonight).

 jena-dev thread:
 http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201203.mbox/%3C4F63A159.7010506%40apache.org%3E

 Staging repository:
 https://repository.apache.org/content/repositories/orgapachejena-081/

 Proposed files and structure to merge with existing Jena dist/ area:
 http://people.apache.org/~andy/merge-jena-fuseki-0.2.1-RC-2/

 Keys:
 http://www.apache.org/dist/incubator/jena/KEYS

 SVN tag:
 https://svn.apache.org/repos/asf/incubator/jena/Jena2/Fuseki/tags/jena-fuseki-0.2.1-incubating/


     Andy

 -
 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: Jena mentors (Was: [VOTE] Release Jena Fuseki 0.2.1-incubating)

2012-03-21 Thread Leo Simons
On Wed, Mar 21, 2012 at 5:54 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 On Wed, Mar 21, 2012 at 5:34 PM, Leo Simons m...@leosimons.com wrote:
 Can we get 2 more IPMC votes?

 On a related note, who are currently mentoring Jena? The status page
 [1] doesn't show.

 The Jena team page [2] lists you, Bertrand, Benson and Ross as
 mentors. Is that accurate? If yes, please update the status page
 accordingly.

Well, I do remember Ross mentioning at some point he never intended to
be a mentor and ending up on the roster by mistake (he was Champion).
Of course, being the engaged guy he is, he did in fact do a lot of
mentoring anyway, so I would guess he can be on the list :-). But
maybe he'd prefer not to.

TBH I'm semi-seriously considering not doing any more voting about
jena, unless it is to +1 their board resolution to graduate :-P

cheers,

Leo

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



Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)

2012-03-08 Thread Leo Simons
On Sun, Mar 4, 2012 at 11:19 PM, Andy Seaborne a...@apache.org wrote:
 The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

 and we would now be grateful if members of IPMC would review and vote for
 this release.

+1 from me.


cheers,


Leo

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



Re: [VOTE] Graduate Apache Accumulo to TLP

2012-03-08 Thread Leo Simons
On Mon, Mar 5, 2012 at 3:49 PM, Billie J Rinaldi
billie.j.rina...@ugov.gov wrote:
 Please vote on recommending the graduation of
 Apache Accumulo with the following resolution to
 the ASF Board.

+1 from me.

Well done, that was pretty fast :)

Is it right that your PMC roster doesn't have apache members on it?
That's fine, but I do hope your mentors stick around for a bit...it
tends to help 'grease the wheels' during your transition to PMC.

cheers,

Leo

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



Re: Thoughts on Incubator board reports

2012-03-08 Thread Leo Simons
Hey hey,

Jukka this is sounding so timid :). You know, I think I'll break rank
and tell you what I really think. You may want to sit down first.



You [1] did a *kick ass* job on the last report. Kick. Ass. [2]. Kapow!


As well as spending the time to look through and digest it all
beforehand on e-mail, you made sure we had discussion about it. Which
btw, wasn't a flamewar, which was nice, too.

I know that prompted me to do a similar run-through on half of your
list (I ran out of steam/time...I guess I'll start at the bottom next
time) and I simply found nothing to add, but I did do much more
overseeing by following along than I would have done if, say, I had
gotten nagged a couple thousand times more.

So, definitely +1 to keep going like that, thanks for spelling it out
too, you should know we got your back :)


cheers,


Leo

[1] helped by others of course, yada yada, we so love all you bearded
folks, you know who you are
[2] http://images.allmoviephoto.com/2010_Kick-Ass/2010_kick-ass_001.jpg

On Tue, Mar 6, 2012 at 12:29 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 During the February board meeting there was a discussion
 about what the directors would like to see in Incubator reports.
...
 we should keep including the individual podling reports
...
 the IPMC should also provide a report summary along the
 lines of what we did last month.
...
 we should also highlight any notable issues or other
 topics the board may want to focus on.
...
 we'll take some time to discuss the podling reports

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



Re: [DISCUSS] - Packages renaming and backward compatibility (was: Re: [VOTE] Graduate Sqoop podling from Apache Incubator)

2012-02-29 Thread Leo Simons
On Wed, Feb 29, 2012 at 3:00 PM, Benson Margulies bimargul...@gmail.com wrote:
 Leo, are you out there?

Hmm? Oh, this again...

Having company names or trademarks in java namespaces is a pretty
stupid convention. It gets us mess like this...

There is no policy that incubating java projects must rename to use an
org.apache namespace. There has never been such a policy. We don't
need such a policy. There's (typically/usually/knock on wood) no
legal/trademark issue. There's ample precedent of keeping 'legacy'
namespaces around 'a while' for backwards compatibility. And that's
fine.

At the same time, (incubating) projects should definitely carefully
consider whether it is reasonable to change their namespaces, how to
go about it, etc. Incubation can be a good time and/or trigger to make
such changes, especially for projects for whom backwards compatibility
isn't a big issue (yet) or that are doing a major revision as part of
coming here.

With my incubator PMC hat on, I like to see that a project community
has thought this situation through, discussed it on their dev list,
and got to some kind of consensus on what to do. I'd imagine such
plans will include a strategy for eventually having all their code end
up in an org.apache namespace or at least not in a com.company
namespace.

I'm sure other people said all this already, apologies for the noise,
but hey, I got prodded, so... :-)


cheerio,


Leo

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



Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

2012-02-26 Thread Leo Simons
On Thu, Feb 23, 2012 at 4:50 PM, Andy Seaborne a...@apache.org wrote:
 The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

 and we would now be grateful if members of IPMC would review and vote for
 this release.

+1 from me.

(justification:

1) I do not consider unintuitive file name and directory layout
conventions blockers for release; I think this thread shows
unintuitive is subjective anyway. I pointed the deviations out
before on jena-dev, and then folks obviously thought about this and
decided to do things differently from a lot of other projects. Even if
the chosen convention is wacky that does not make it wrong.

2) Whilst LEGAL-124 remains unresolved there's plenty of precedent for
not having license headers in test data and similar auxiliary files,
all around apache, and so I consider it fine to continue current
standard practice until different rules arrive.

3) all looks good to me ;-)
)


cheers,


Leo

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



Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)

2012-02-12 Thread Leo Simons
(back from holiday, still catching up, just replied on jena-dev, but
for the record since this is a [VOTE]...)

 On 8 February 2012 13:03, Andy Seaborne a...@apache.org wrote:
 The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

 and we would now be grateful if members of IPMC would review and vote for
 this release.

-1, specifically based on

On Sun, Feb 12, 2012 at 1:22 PM, sebb seb...@gmail.com wrote:
 The tag and the packaging also need to be sorted out before release.

Sorry, but it seems to me like you'll have to bake another RC with some fixes.


cheers,


Leo

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



small, reversible steps

2012-02-12 Thread Leo Simons
Hey folks,

TL;DR

Small steps! Less friction! Lazy consensus! Reversible change!
Meritocracy! YAY :-D

History

Use small reversible steps is a powerful idea when evolving things,
like when evolving a software architecture. It's an idea that was made
popular @ apache by Stefano. Since the idea seems to be drifting to
the back of our minds a bit lately, I thought I'd bring it to the
front again [1,4]:

  It's exactly like thermodynamics, where a infinite number of small
  reversible steps is more efficient than a small number of big but
  not-reversible steps.

  The good old Software Engineering practices they teach you in college
  are bullshit: making architecture decisions without continous
  reversibility is expensive because design constraints change too much.
  Those who want to apply hardware engineering practices miserably fail.
  Open source is here to prove that such a messy way to do code is
  actually the only one that works and scales.

Thankfully, 'incrementalism' is much more prevalent in IT now than it
was a decade ago :-). Perhaps not as well understood, but, it is also
a very powerful approach to shaping communities and community behavior
[2]. Among other things, gaining consensus gets easier the smaller the
increment, to the point that you can get away with lazy consensus for
the smallest of steps, which is indeed very efficient.

Erosion vs destruction

I do suspect radical goals such as deconstructing the incubator [3]
are worthwhile to pursue.

The deconstruction of jakarta followed (after much deliberation) an
incremental approach with many small and reversible steps. That was
the right choice then, and I'm confident it is the right approach
here. I.e. deconstruction by erosion instead of by destruction.

By contrast, heavyweight big-bang discussion full of rhetoric where
conversation is cast into argument with those 'for' and 'against' is
of very limited value. Turning sets of ideas into a 'platform' that
you must buy in to (or not) is worse. It divides a community that does
not need to be divided, and it impedes consensus much more than
needed. We won't get far that way. I'm glad I missed a week full of
such e-mail while I was on holiday :-). I shall continue to try to
steer clear of it!


(hug),


Leo


[1] 
http://mail-archives.apache.org/mod_mbox/cocoon-dev/200010.mbox/%3c39fad0b5.2d3f4...@apache.org%3E
[2] http://psteitz.blogspot.com/2011/08/engineering-emergent-behavior.html
[3] http://wiki.apache.org/incubator/IncubatorDeconstructionProposal
[4] that took ages to find btw. I think it's the first reference on a
public list to entropy concepts in IT, at least around here?

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



Re: [VOTE] Jukka Zitting for IPMC Chair (was Re: NOMINATIONS for Incubator PMC Chair)

2012-02-10 Thread Leo Simons
+1

- Leo

On Thu, Feb 9, 2012 at 4:16 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:
 In the interest of moving the current discussion matters forward, please VOTE
 on this recommendation to the board by the IPMC. I'll leave the VOTE open
 for at least the next 72 hours:

 [ ] +1 Recommend Jukka Zitting for the IPMC chair position.
 [ ] +0 Don't care.
 [ ]  -1 Don't recommend Jukka Zitting for the IPMC chair position because...

On Fri, Feb 10, 2012 at 3:28 AM, Noel J. Bergman n...@devtech.com wrote:
 +1

        --- Noel

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



Re: February report review

2012-02-10 Thread Leo Simons
+1

I'd also suggest that the below is a partial answer to the board's
questions to the IPMC on how it would improve oversight so it should
probably go in our report.

cheers,

Leo

On Thu, Feb 9, 2012 at 4:59 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 On Thu, Feb 9, 2012 at 4:30 PM, Sam Ruby ru...@intertwingly.net wrote:
 On Thu, Feb 9, 2012 at 9:14 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 What I would like to see is the Incubator start identifying PPMCs that
 are stalled, and to consider what information they need (in future
 reports) to help them (us) make such a determination.  I am not
 suggesting that this be made retroactive.  Or that it be done
 immediately.  A plan would be fine: i.e., setting a date by which the
 IPMC will have decided what information needs to be in such reports,
 and a schedule by which the PPMCs need to start providing said
 information.

 My suggestion is to ask the podlings now in category 2 to report again
 in May on their progress on the identified blockers. If there's been
 no measurable progress by then, we'll dig deeper to see what we can
 do. Podlings reporting in other months can be picked up for a similar
 oversight cycle over the coming months. By July we should then have a
 pretty accurate record of progress throughout the entire Incubator,
 including a clear list of podlings that are stuck and need help.

 Before the next quarterly report I'd rely on mentors to help the
 podlings identify and implement ways to move forward. And of course,
 if a podling or its mentors feel that more help is needed, asking on
 general@ or submitting an extra report is always a good idea.

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



Re: Incubator, or Incubation?

2012-02-02 Thread Leo Simons
Hey folks,

I just wanted to chime in with a +1 for the general direction. I think
there's actually a lot of work to do to iron out how to reorganize
things. Before digging in, I suggest we abstract out a little bit to
see if we have consensus on the overall goals and desired end state
before starting to debate the details, or the process by which to get
there.

1) There are people who produce guides, rules and policy that describe
the incubation process. These rules are then imposed on other groups
at apache by board decree.
2) At any point in time, there shall be many groups of people
following the incubation process.
3) There is a mechanism in place to provide oversight over all the
different ongoing incubations.
4) The differences between communities going through incubation and
those that aren't is clear and understood by all (including end users,
press, etc).

I think the above invariants describe both incubation as of yesterday
and incubation as of tomorrow. But, we have some issues with the
current incubator.

a) The volume of incubation activity has grown such that oversight is difficult.
b) Large group sizes (particularly general@ and IPMC roster) make
accountability and consensus-building difficult.
c) meritocracy is hampered by having the people doing the work not
having binding votes on their own work.
d) ... add your own similar issues ...

The basic realization is that combining all the people from 1) and 2)
into effectively one big group [1] is no longer the best idea.

So, we want to redesign how we organize into groups, and associated
with that we want to tune our oversight mechanisms.

The basic idea is to split the current single really big group that is
the incubator into smaller groups that still cooperate and discuss and
whatnot, but are accountable and overseen separately. These smaller
groups become their own committees with their own VPs that report to
the Board.

Is that a reasonable re-statement of the abstract idea? Is that
something we can all get behind?

The next steps then involve deciding just how to split things up.
Since I'm off to go skiing tomorrow I won't be around next week to
participate in the details of all that. Have fun :-)

cheerio,

Leo

[1] the choice of the vague term 'group' is intentional: give us some
degrees of freedom to design the structure, in a formal *and* an
informal sense. One kind of group is a PMC, but there's also another
kind of group which is people subscribed to a mailing list and
another one people that read the stuff that's on the mailing list
and another which is people who feel responsible for what's going on
on that mailing list, etc.

On Wed, Feb 1, 2012 at 11:25 PM, William A. Rowe Jr. wr...@apache.org wrote:
 On 1/31/2012 5:05 PM, Mattmann, Chris A (388J) wrote:

 On Jan 31, 2012, at 1:28 PM, Roy T. Fielding wrote:

 Having said that, I should note that the context of Incubator is
 significantly different than a normal PMC.  If incubator wants to structure
 itself more like a board and less like a project, I really don't have
 much to say against that.  Note that it should effect all of the decision
 guidelines that give veto power, not just personnel decisions.

 Isn't that the problem right now though? Like it or not, the Incubator PMC
 has evolved into a mini-board, in the worse sense of the word. You guys
 have a monthly meeting via telecon; an agenda; a set of action items, and
 you still don't get everything that you want to get done, done.

 A very small percentage of folks within the IPMC actually maintain that type
 of board-like oversight over its podlings. And thus, because of that, the 
 more
 I think about it, quite honestly, I don't know what the Incubator PMC is 
 doing
 other than delay the inveitable eventuality that many of these projects will
 graduate and become TLPs and thus the board's problem; whereas many
 of them will not graduate, and become not Apache's problem. We have an
 Attic for projects that make it to TLP for that. Heck, we have SVN and could
 even reboot Incubator dead projects if a group of individuals came along
 and wanted to maintain the code.

 My conclusion from all the ruckus recently has been that the Incubator PMC
 is nothing more than an Incubator mailing list where many ASF veterans
 and those that care about the foundation discuss (and sometimes argue)
 about the foundation's policies and interpretations of law that not even 
 lawyers
 are perfect at -- we're all human yet we try and get on our high horse here
 and act like we speak in absolutes and the will of one or a small subset is
 the will of the many when we all know that in the end, if it's not fun 
 anymore,
 we wouldn't be here.

 What would be so bad about saying that the Incubator, over its existence,
 has served its purpose and has devolved into an umbrella project of the type
 that we are looking to get rid of at the Foundation. I agree with Bill on the
 perspective that I'm sure at some point (and it's probably already 

Re: [names] Public Review

2012-01-30 Thread Leo Simons
Hey Robert,

Thanks for this; it was obviously a lot of work! I like the word
picks, flow and style of this guide a lot. There's a lot to read here
and some new stuff to learn for me -- I confess I've been ignoring as
much about trademarks as I can until a time comes up when I actually
have a need to dig into it more. So I can't really help write, but I
can ask questions :)

On Sun, Jan 29, 2012 at 3:05 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 On Sun, Jan 29, 2012 at 11:45 AM, Robert Burrell Donkin
 robertburrelldon...@gmail.com wrote:
 The new documentation describing in more detail one way to check the
 suitability of the proposed name is just about ready for public review

 The URL is http://incubator.apache.org/guides/names.html

 It's fine to just dive in to improve phrasing, add examples etc.

Once the information is collected and collated,
then ask the trademark team to help interpret and
analyse these results on the private lists, copying
in the PPMC.
Finally discuss the results of your investigation on
the private PPMC list.

We could probably do with some guidance of *how* to do this
discussion. I.e. I _assume_ the CC is to trademarks@ but it's not
stated. Similarly it's not quite clear what things need to be
discussed. The discussion could be well a lot of stuff uses this name
too but whatever it's probably ok -- +1, or it could be looks
risky we may need to evaluate whether we are infringing (and then
what happens?).

 Here's a good place to ask questions. This thread is also a good place
 to discuss content and dispute process details.

* I personally think the way you wrote down that this is one possible
approach is quite clear. I'll leave it to others to fix what they
don't like about it ;-)

I agree it's important that we know it's one possible way to care of
this stuff. For example with Apache OpenOffice or Apache SpamAssassin
or Apache Jena or other long-existing projects that come to the
incubator the process is different since they typically did it years
ago, are known to be the number one hit for that phrase, etc etc.

* It's not clear to me what role the trademarks folks have in this
process; I thought trademarks@ was primarily concerned with defending
our marks, and providing policy to PMCs, i.e. not with doing the
picking of the marks we use? Is it an advisory role because these
folks happen to have experience, or is the advice intended to be, err,
'binding'?

* If you are a new project and you have to pick a name, this is a
useful guide. If you are a new project and you picked a name, but you
didn't do your due diligence, you need to be nudged rather insistingly
into doing your due diligence. And that then has a painful dynamic to
it, because a group of people picked and decided and voted on a name
and then they changed it.

To fix this, we could put the process for the picking of the suitable
name as part of the proposal process, i.e. you can choose to do it
before you even send your proposal to general@. WDYT?

 Thus, instead of setting strict rules and requirements, I think the
 guide should just document the best current practice and suggest why
 following it is a good idea.

Hmm, so there's an interesting balance here, and it's probably overdue
for some shifting. I think we do need to make clearer the MUSTs around
trademarks to new projects, basically passing on the PMC
responsibilities we've gotten from the board via trademarks@. Perhaps
we need another bit of documentation in the policy that points out the
MUSTs, and then that bit links to this guide.


cheers,


Leo

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



Re: [DISCUSSION] Regular rotation PMC chair

2012-01-30 Thread Leo Simons
On Sun, Jan 29, 2012 at 9:39 PM, Christian Grobmeier
grobme...@gmail.com wrote:
 On Sun, Jan 29, 2012 at 9:37 PM, Ralph Goers ralph.go...@dslextreme.com 
 wrote:
 On Jan 29, 2012, at 12:16 PM, Benson Margulies wrote:
 On Sun, Jan 29, 2012 at 2:23 PM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Jan 29, 2012, at 6:18 AM, Ate Douma wrote:
 FTR: as should be clear from my above response, I disagree with the topic 
 of this discussion thread. This should be about Regular (re)election of 
 the PMC Chair. Regular rotation IMO would be unwise and undesirable.

 Good point.  I share the same opinion.

 Let me try to state some alternatives:

 1) No particular policy: The PMC has no special policy about
 recommending a new chair to the board. It will happen if the chair
 resigns, or if the PMC as a whole reaches a consensus on a change.

 2) Fixed election schedule: On some schedule (e.g. annually),
 nominations are opened, including potentially the current chair, and a
 vote takes place. (I'd hate to have to fire up the full secret ballot
 mechanism used for board members.) Whomever wins is recommended to the
 board.
...
 If we don't reach a consensus on something else, we stick with the
 current state of affairs, which is, I claim, (1).

+1. I would like it changed.

 My preference is option 2 alone. I don't see the point of
 term limits as I believe that will take care of itself.  I'm
 not in favor of 1 because it always seems to end up
 feeling like it is personal when people bring up rotating
 the chair - i.e. isn't the current chair doing a good enough
 job, the current chair should say they want to resign first,
 etc., rather than it just being time to allow the PMC to
 reevaluate itself

 +1 for option 2 and what Ralph said

+1


cheers,


Leo

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



[RT] Community over policy, and similar thoughts

2012-01-16 Thread Leo Simons
Hey folks,

I started writing this e-mail in November or so. My normal approach
with stuff like this is wait for a non-contentious quiet period before
starting a new thread, to maximize the chance the words will be read
for what they say rather than interpreted in the context of some
heated debate. Unfortunately, heated debates have been happening here
for a long time, with little break, and though I have something here
that is not hot, it still needs contributing.

So, sorry about the timing, but I'm posting it anyway Mwuhahah. Hah?


cheers,


Leo


TL;DR [10][12]
==
There ought to be more gentle, humble, consensus-building
conversations. And, hugging.

TOC
===
* TL;DR
* TOC [11]
* Preface
* Community over policy
* Consensus-building
* Poldermodel
* Community-building
* Focus and feelings
* Lack of a call to action
* References

Preface [0]
===
[RT] are Random Thoughts.  This is a tradition in the Cocoon
community. RTs are basically long and thought-provoking mails with new
project propositions, that are discussed and scrutinized at length.
One distinguishing characteristic about RTs is the complete and utter
lack of consistency with respect to quality: some are pure crap,
others are pure genius.  Even the original author of a RT is not sure
which category any given posting falls into at the time it is issued.
This posting is no exception.

Community over policy
=
We have this shorthand saying of community over code: at apache,
while we value code, when given the choice, we value community more.
Of course there is a lot of complexity and nuance that you lose in the
summary, but, once you understand the meaning, the shorthand is
useful.

I would like to add community over policy: at apache, while we
accept some policy is needed, when given the choice, we value
community more. Note the words I would like, because I don't think
that's where we are today and I also don't think we have consensus on
it.

A partial corollary would be that the incubator policy documentation
is done not when there is nothing left to add, but when there is
nothing left to take away. I think everyone agrees with that in
principle, but it may not get the focus it deserves in practice.
Unfortunately bureaucracies have the tendency to grow more
bureaucratic over time. Beyond a certain threshold, those
bureaucracies then ever so gently shun away a certain class of people,
then another, until only bureaucrats remain.

Consensus-building
==
The most important new communication skill to learn for people when
they get into apache-style open source is probably the nitty gritty of
how to build consensus. I've never quite seen how to do that online
written down. It involves something like
* write for a global audience, [2]
* use principled negotiation, and [3]
* speak softly, be humble. [4]

It is quite difficult to lose ambiguity, to remove localized
colloquialisms without sounding too formal, to avoid using hard words
like colloquialism, and still convey the message you want to convey.
This is hard to teach and harder to master.

Once you figure out how to write, you then need to figure out how to
write it concisely. And when you know how to do that, you still need
to figure out the right things to write. That is, you need to actively
restructure your thoughts, plans and ideas to be easy enough (as easy
as possible?) to get consensus on. If you're a rigid thinker (perhaps
because you're a software developer?) the natural form of your
thoughts probably is not the easiest-agreeable form.

Unfortunately most of the messages to general@incubator from people
that have been around apache a while don't use this style at all. I've
seen the prevalence of an authoritative, declarative and
confrontational style increase further and further over the years here
(and elsewhere at apache).

It's unfortunate, but the incubator does not set a good example these
days when it comes to how to build consensus [9]. A big part of the
reason for that is that the incubator is solving hard problems, but
another part of the reason is the way that communication happens. It's
especially difficult for me to see this and harder to correct. That's
partly because I learned a lot of how to do this from the same people
I know see dive into confrontation after confrontation, but mostly
because I want to avoid even a hint of censorship.

Poldermodel
===
As an aside. To provide some missing cultural context. I'm Dutch.
According to Wikipedia [1],

The polder model is a term with uncertain origin that was first
used to describe the internationally acclaimed Dutch version of
consensus policy in economics, specifically in the 1980s and
1990s.[citation needed] However, the term was quickly adopted for
a much wider meaning, for similar cases of consensus
decision-making, which are supposedly typically Dutch. It is
described with phrases like 'a pragmatic recognition of
pluriformity' and 

Re: [RT] Community over policy, and similar thoughts

2012-01-16 Thread Leo Simons
Hey Don,

Thanks for your reply. You are quite right, of course. I hope I am
also right at the same time :-). Maybe I can clarify...

On Mon, Jan 16, 2012 at 4:48 PM, Donald Whytock dwhyt...@gmail.com wrote:
 Like Apache, But Sexier...LABS?  I can totally see that.  Anyone want
 to start an Apache LABS podling?

I am assuming you know but I will nevertheless redundantly point out
for those that don't that there is actually a http://labs.apache.org/
. It is pretty cool and has a relatively sexy web site :)

 But while community can be flexible in a lot of ways, policy generally
 can't be.  The rules are there; exceptions can be made, but in terms
 of law it's generally safer to assume they won't be.  So, as much as I
 hate to say it, I don't think community over policy can actually
 work.

Indeed, some of the rules apache has are rules that it has to have
because of the law. Some others come from its tax status -- apache
could ignore those rules, but then it would lose a financially
beneficial tax status. Others rules apache has written down in its
bylaws [1], and the apache members could jump through a bunch of hoops
to change some of those.

But, then, a lot of the rules that apache has are there because apache
wants to have them.

I will write you out an example.

Once upon a time the incubator had said that incubating projects
should not do binary releases, for a couple of reasons:
* to avoid users downloading incubating software: apache was concerned
that end users would not understand the tentative status of incubating
projects;
* to give projects yet another incentive to do their incubation
process quickly: incubation should be as short as possible. Back then
I think we thought 3-6 months would be the norm;
* legal umbrella: apache the Foundation appoints Officers who have
Committees who make Decisions on behalf of the Foundation. Releasing
software is such a Decision and it's reserved for PMCs. Podlings don't
have PMCs so who should release?

But then along came a project that really wanted to release early,
release often, and also do binary releases [2]. Their mentor had
actually encouraged this since he believed release early, release
often is good engineering and community-building practice. So what to
do?

Well, the issue was discussed, at some length, and it was decided that
perhaps we could have releases if we added a disclaimer, and that the
incubator PMC would vote and assume responsibility for the release.
The project added the disclaimer to its website and made its release.
Everything seemed fine, so someone turned those words into a template
[3] and stuck them on the policy website along with a description of
how to do a release. That was in September 2003 [4], and it's been
policy since [5].

If for some reason you find these disclaimers really really horrible,
you can go back into the commit history for the policy docs, and then
into the e-mail archives to figure out why the policy says what it
says, think about it some more, and perhaps come up with a better
idea. Then that idea can be discussed and the policy can be changed,
by the community :-)

I personally think this is *fascinating* history. I'm weird like that.

Unfortunately in 2012 those words from 2003 seem to have significantly
gained in weight. A lot of projects have followed the rule without
complaining, so why should you? This is not just some words some guy
wrote, it's a community decision with a rule on a pretty website (not
on a rebel CSS-less wiki with an edit this page invitation), and it
has the word policy slapped on top of it.

These days we probably have mentors that had never thought about open
source communities, when the incubator had those rules already on the
website. They've seen that rule, and they hand the rule to their
podlings, who then follow the rule. The feeling is very different and
the dynamic is different: it has changed from hmm, how should we
tackle this into do what the rules say. This isn't bad per se (it's
a good rule, probably), but I believe we do need to spend effort to
compensate for the lack of positive feeling.

Hence, community over (but not against) policy!


cheerio,


Leo

[1] http://www.apache.org/foundation/bylaws.html
[2] 
http://mail-archives.apache.org/mod_mbox/incubator-general/200309.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a0...@usseex01.amer.bea.com%3E
[3] I tried to find the first version of the wiki page, but that was
hosted on a machine owned by sun and inside a sun data centre, and we
didn't migrate all the history (sort of in violation of apache
infrastructure rules even then, but hey, projects really really wanted
wikis and there was no apache hosted wiki...oh man, those dare-devil
incubator rebels, breaking the rules!)
[4] 
http://mail-archives.apache.org/mod_mbox/incubator-general/200310.mbox/%3c4c2f1577f2ef2840a9ae9ec61860c8810a1...@usseex01.amer.bea.com%3E
[5] http://incubator.apache.org/guides/branding.html


Thoughts about reporting (was: Re: [RT] Community over policy...)

2012-01-16 Thread Leo Simons
On Mon, Jan 16, 2012 at 6:42 PM, Sam Ruby ru...@intertwingly.net wrote:
snip/
 We may also have semantic gaps.  Leo's [RT] may be presuming that a
 podling's board report[sic] is merely a bureaucratic requirement.
snip/

Hmm :-)

And so the threads collide...

...I guess I'll allow it. But since we're in my thoughts now, I'll go
ahead and say something :-)

I would say that
you need to provide a quarterly report using this template
and add it to that wiki page
and then get it signed off by a mentor [1]
is a somewhat bureaucratic expression of
your community needs to be self-reflective
and periodically tell us how things are going,
because of [X] and [Y] [1]
and that the expression of the latter is perhaps more important than
the expression of the former. It's definitely more interesting!

I think as far as requirements go, submitting written reports to be
collated and read and then discussed in a conference call is not the
best way of overseeing stuff. If I chaired a group of people that had
to oversee something like apache I'd probably try and change how to go
about that. Something involving green flags in checkboxes I think.
Similarly, if I had to report into those people I would make a point
of changing the style of the report every so often, to keep them on
their toes, and make their oversight job as pleasant as possible.
Fortunately, I don't hold any furniture-related titles.

Having said that, I think incubator reports are good practice for
board reports so as long as board reports function the way they do,
podling reports should function similarly. Which is why I've been
happy enough for current, former and future board members to present
their opinions [2] on the subject and stay silent myself :). Fail.

In fact, my personal plan [3] was to stay out of this discussion, and
continue to do as little reading of reports as I can possibly get away
with. My talents lie elsewhere. Benson can be the deals-with-reporting
mentor, I can be the deals-with-license-headers mentor, and yet
someone else can be the
I-critically-review-30-incubating-projects-including-the-report-Benson-already-signed-off-on
[4] PMC member. I will thank you for your reviewing and
signing-off-ing efforts, and I will ensure my mentorees all buy you
beverages.

Come to think of it, I guess a good plan for the future is to
co-mentor with at least 2 people that are on the board, since they
read all the reports anyway eventually for their meeting, and if they
don't, there'll be people frowning at them over the conference call,
so they'll be much more motivated than me to do it well. Even better,
I could try and make my co-mentors into board members, and I guess one
of them should be the incubator PMC chair, too.

Yes, that sounds like a plan. Mwuhahah. Hah?

 In any case, I hope somebody beats me to a thorough review of next
 month's podling reports, but if not, I intend to repeat the the
 process where I provide feedback here before providing feedback that
 will ultimately be published on the ASF web site as a part of the ASF
 board meetings.

Thank you, Sam. I doubt I will beat you, though I may have a go :)


cheers,


Leo

[1] these are imaginary quotes, no one said these things! I'm
inventing them and/or paraphrasing from memory.
[2] yes yes yes, not necessarily acting in their board member
capacity. Still, people doing the work (reading the reports, doing the
oversight), that know a lot about doing the work, they get to have a
say.
[3] Warning: I'm perhaps partly joking. I do read a lot of reports,
but I don't quite do 'critical review' most of the time.
[4] the last report I read for the podling I mentored was signed off
by either Benson or Ross, I forget. But the example is stronger if I
stick with Benson. Sorry Ross, I'll buy you an extra beverage.

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



Re: Q. Forks without concensus?; A. anytime / depends / never without agreement

2012-01-11 Thread Leo Simons
On Sat, Jan 7, 2012 at 10:24 PM, Roy T. Fielding field...@gbiv.com wrote:
 If there is a community
 and that community doesn't want Apache to fork the code that they created,
 then we will not fork that code at Apache.  If the original developers of the
 code do not want their license changed, then we will not fork the code at 
 Apache.
 We only accept voluntary contributions (contributions == the stuff we take on 
 as
 change-controller and managed as such by one of our collaborative projects).
 We use other open source code and include that other code in our own releases,
 but we don't take change-control over it without the blessing of the original 
 authors.

[Citation Needed]

While I agree with the general idea, the closest I can find to it
being written down is

  http://incubator.apache.org/guides/proposal.html#template-community

which is not very close at all.

Did the subject actually come up before or is this the first time you
wrote this down?

Also, we should consider that the modus operandi of open source is
changing. The default behavior on github for example is to put a fork
me on github button on your project website, which doesn't mean a
community fork, but for the healthier projects it does mean
community chaos as forks and pull requests simply happen all over
the place. So the relationship between take change-control and
community fork is a bit different in those instances. You could say
that the fork me on github (or just using github) is in fact
inviting everyone to take as much change control as they want.


cheers,


Leo

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



Re: Forks without concensus?

2012-01-03 Thread Leo Simons
Hey hey,

(Pff. I like replying in-line but this is a hard e-mail to reply to
in-line so I will top post.)

If I understand your policy question: will apache allow an incubating
community to show up and start a project when they are forking another
project?

I'd say, in general, yes, probably, if all the other criteria we have
are satisfied.

But, well, what if that other project is open source already, and some
people don't want the fork to exist at apache? Well, then probably
something is wrong in the first place, and it needs to be
investigated. Why, otherwise would a group of people show up that want
to fork at all?

I think it quickly becomes a judgement call.

On the one hand, should apache try and avoid getting tangled up into a
complex mess just because it is complex and messy? No, I don't think
so. If anything, apache is supposed to be good at helping people sort
out their complex messes. If we have mentors willing and able to help,
let's try and help.

On the other hand, should apache make sure that it's considerable
weight is not mistakenly thrown behind an initiative that somehow goes
against our core values (an open, collaborative, consensus-based
process)? Absolutely.

Etc.

So the generic policy is there is no generic policy, and instead there
is appropriate application of judgement to specific cases.


cheerio,


Leo

On Tue, Jan 3, 2012 at 6:35 PM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 On 1/3/2012 11:14 AM, Greg Stein wrote:
 On Jan 3, 2012 11:48 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote:
 ...
 A PMC I am on had this exact conversation with board members several
 months ago regarding a code base the project is dependent on that is 
 housed
 outside the ASF which we were considering bringing in as a subproject. We
 were told that under no circumstances could we fork the code without the
 owner's blessing, regardless of what the license allowed us to do. To 
 me,
 this answer is black and white.

 Not to me. :-)

 Which is the problem, isn't it?  Note; hat switch, you are now speaking
 with the authority of a Director.

 Euh, nope. Offering my personal opinions. A Director hat would (and does)
 mean nothing since I could not speak for the Board.

 So this is a question that should be put to bed once and for all, you have
 both been swinging pretty wildly at diametrically opposed answers to this
 question.

 If we read that the Board has charged this committee with acceptance criteria
 for submitted or proposed products... then the question above should be
 resolved.

 Essentially, we have several choices...

  [ ] Forks are accepted without judgement [Greg] [1]

  [ ] [something more nuanced here]

  [ ] Hostile forks are never acceptable [Roy] [2]

 If the answer lies somewhere in the middle, it would help potential
 contributors/forkers to know approximately where that middle sits.



 [1] I don't see it as our place to *judge* communities. If it is a fork,
    or a corporate spin-out, or a move, or brand new... All Good. 

 [2] At Apache, all contributions are voluntary.  We do not accept code
    from copyright owners who don't want us to have it, even if we have
    the legal right to adopt it for other reasons.

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



Re: [VOTE] Bloodhound to join the Incubator

2012-01-03 Thread Leo Simons
Hey folks,

I felt I had to take a look at this. Like Ralph I was very concerned
when I saw Ethan's e-mail. Thanks a lot for writing it Ethan, and
thanks for writing it with so much detail.

I just read all the e-mail about bloodhound I could find (that I had
pretty much ignored when I saw other people I trust were looking at
it) and then I read the last year of trac e-mail traffic (fwiw, the
relevant/interesting e-mail concerning the bloodhound proposal is all
in the last 2 months, older relevant e-mail is not on publicly
archived lists). I have to say I'm a lot less concerned now.

First impression: the trac community is full of really nice people and
it's mailing lists are full of gentle and carefully considered
communication. Very nice to see :-). I wish all open source
communities were like that! I really recommend anyone else trying to
form an opinion goes and looks at trac-dev. In particular you may want
to read the overview one of the core devs from trac wrote for our
benefit:

  https://groups.google.com/d/msg/trac-dev/kMVFq9pkfus/eYMCVfqyUwkJ

The bloodhound proposal and communication around it probably could've
been handled better over the last 9 months or so, but it also could've
been handled much worse. It's a typical example of the difficulty that
exists where a company wants to engage an open source community and
there isn't a strong legal/commercial story yet. All the parties seem
to be trying hard to come up with the best approach for everyone, and
the apache approach seems like it should be able to help produce a
healthy kind of collaboration.

The bloodhound proposers look like they're doing pretty well now in
communicating intent and approach clearly on the trac mailing list,
and the trac folks in turn seem pretty clear on what is and isn't
going on.

Bloodhound at apache will probably be better for all, than bloodhound
not at apache. If things continue on their current path, apache rules
and processes should help minimize negative impact on trac so that the
effect on trac will be a definitive net positive. I remember a bit
about trac internals from years ago and ISTR it's pretty cleanly split
into lots of little bits...so I imagine bloodhound can (and should)
take a careful licensing path contributing patches to core upstream as
BSD while making new/rewritten plugins available upstream as ALv2.
That seems to be the intent, too. Proof will be in the pudding :-D

I do think it would be nice and appropriate if someone updates the
proposal page along the lines that Ethan mentioned, probably by simply
removing the somewhat unfair depictions of the trac community.
(perhaps edit the current page, but keep a link there to the version
that was voted on, for clarity).

All in all I think bloodhound should continue on, and the incubator
PMC should trust the mentors to keep things on their current track
(hehe) of collaboration-where-possible, rather than turn this into an
overheated debate.


cheers,


Leo

On Fri, Dec 30, 2011 at 9:30 PM, Ethan Jucovy ethan.juc...@gmail.com wrote:
 -1

 The Bloodhound proposal is to build an issue tracker by first importing the
 Trac core code into the Apache Subversion repository.  As currently
 planned, this project has potential to be detrimental to the existing Trac
 brand and community, and it seems that the Bloodhound project's goals could
 equally be achieved without taking the heavy-handed first step of forking
 the Trac codebase.  I hope that the Bloodhound team will consider building
 Bloodhound as a set of plugins and configurations and an installer that
 distributes them with an upstream Trac version, rather than forking Trac as
 a first resort.

 My concerns fall into three categories:

 a) The Bloodhound proposal contains substantial allegations about the
 health of the Trac community and the competence of its maintainers, as
 motivating factors for the fork and rebuild community approach proposed.
  No documented evidence has been provided to support these claims, and many
 of the claims are directly contradicted by the publicly available records
 in the Trac community's issue tracker, mailing list archives and commit
 logs.

 b) Neither the Bloodhound proposal nor the ensuing discussions have
 demonstrated any compelling legal, procedural, technical or strategic
 reason why Bloodhound should be based on a fork of Trac rather than an
 upstream distribution of Trac.

 c) Although the people involved have been friendly and expressed a desire
 to keep the two projects in cooperation, the actions taken so far and the
 intentions announced are characteristic of a hostile fork.

 --

 (a) The Bloodhound proposal contains substantial allegations, without
 evidence, about the health of the Trac community and the competence of its
 maintainers.  These allegations are largely contradicted by publicly
 available records of the Trac community.

 * The Bloodhound proposal claims, Private efforts to engage the existing
 developers in implementing features have 

Re: [PROPOSAL] Flex for Apache Incubator

2011-12-21 Thread Leo Simons
Hey folks,

I had to think about this a bunch. We don't have anything like this at
apache today.

On Tue, Dec 20, 2011 at 9:37 PM, Greg Stein gst...@gmail.com wrote:
 On Tue, Dec 20, 2011 at 15:30, Raju Bitter rajubit...@googlemail.com wrote:
 (..) Adobe Flex is quite different from most Apache projects (...)
 it looks like the output of the compiler can only be used with Adobe-owned
 proprietary software at the moment. (...)

 As I mentioned above, I don't see this as a problem whatsoever. (...)

Just to pick this apart...

* Flex helps you make apps that target the flash player (or the AIR runtime...)
* There is effectively one implementation of flash player (supporting
the v10 SWFs that come out of flex...)
** which you get from adobe or someone that has an agreement with adobe
** which comes with very restrictive licenses [3]
*** basically you probably can't even *use* it if you want to
implement a flash player yourself [4].
* This flash player plays SWF files (and FLVs..).
** SWF has an open spec that isn't very open at all [1,2].
* Flex does not produce SWF files all by itself. It uses the Flash SDK
and the AIR SDK (and some other bits)
** which you have to get from adobe and which come with very
restrictive licenses.
* Adobe could unilaterally change the license for the flash player,
the SWF format, and/or the prerequisite SDKs, and flex would become
essentially useless.

Analogies to .Net or Java (or oracle databases) don't make much sense
to me. Instead if I had to come up with an analogy, it would be
something like having an apache http server that you could only
install on windows, and run only if you already had IIS, and that
would then host websites that you could only view if you had internet
explorer.

I don't understand why it's useful to have such a project at apache.
But, apparently, a lot of people do want to work on it, and flex is
obviously useful to a lot of people.

So is there a problem? I guess not. As long as the Apache Flex website
makes all this clear enough and no-one makes a PR mess out of it or
anything like that, I don't see any actual problem with the proposal.
I can't say I'm enthusiastic about it, but I don't have to be.


cheerio,


Leo

[1] http://en.wikipedia.org/wiki/SWF#Licensing
[2] http://www.adobe.com/devnet/swf.html
[3] http://labs.adobe.com/technologies/eula/flashplayer10.html
[4] 
http://en.wikipedia.org/wiki/Gnash#Adobe_Flash_Player_End_User_License_Agreement

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



Re: [PROPOSAL] Flex for Apache Incubator

2011-12-20 Thread Leo Simons
On Mon, Dec 19, 2011 at 9:20 PM, Alex Harui aha...@adobe.com wrote:
 I would like to propose Flex to be an Apache Incubator project.

 Here's a link to the proposal:
 http://wiki.apache.org/incubator/FlexProposal

Pasted inline:

= Apache Flex Proposal =

== Abstract ==

Apache Flex is an application framework for easily building
Flash-based applications for mobile devices, the browser and desktop.

== Proposal ==

Apache Flex allows developers to target a variety of platforms,
initially Apple iOS, Google Android, RIM !BlackBerry, Microsoft
Windows, and Mac OS X with a single codebase. Flex provides a
compiler, skinnable user-interface components and managers to handle
styling, skinning, layout, localization, animation, module-loading and
user interaction management.

== Background ==

Apache Flex is the software evolution of the popular Adobe Flex SDK project.
Adobe Flex SDK evolved from the need to provide developers with an
easy programming model for creating rich Internet applications that
can run in the browser, on the desktop or on mobile devices.

Adobe Flex SDK has always focused on a single goal: to provide
application developers with all of the constructs needed to boost
their productivity while building large-scale, visually expressive
applications. This meant that Flex provided all the traditional UI
components in a way that designers and developers could interact with
them along with a dynamic scripting language, !ActionScript, and a
declarative markup language, MXML.

Adobe will donate the Flex trademark to the Apache Software Foundation
as part of the incubation process. The source code, documentation and
related assets will all be contributed to the Apache Foundation as
Flex.

== Rationale ==

Content developers need to target multiple screens and the cost of
creating applications native to every target platform is high.
Additionally, the dominant window to the web is quickly becoming
devices, mostly phones, and delivering consistent experiences is key.
The Apache Flex project exists to bring the focus back to a consistent
development model, one where a single application can run the exact
same way across the web, desktop and mobile devices.

== Initial Goals ==

 * Donate all Adobe Flex SDK source code and documentation to the
Apache Software Foundation.
 * Setup and standardize the open governance of the Apache Flex project.
 * Rename all assets from Adobe Flex SDK to Apache Flex in project
source code, docs, tests and related infrastructure.

== Current Status ==

Flex is a mature software project. 1.0 was shipped in March of 2004
with 7 major releases having shipped since. The most recent release
was the 4.6 version which shipped on November 29th, 2011.

== Meritocracy ==

The Adobe Flex source code is available to the community on the Adobe
opensource site:
http://opensource.adobe.com/wiki/display/flexsdk/Flex+SDK.  Currently,
while the community has been invited to contribute patches to the
codebase, only Adobe employees decided on which patches to commit.
There were no external committers and this caused frustration in the
community.

Going forward, both Adobe and our community are eager to become one
single merit-based community working together.  To that end, Adobe
will only have minority representation on the initial committers list.
 Adobe is working to educate our community with meetings and blog
posts on how the Apache model makes this possible for them.

We have made it clear to our community that going forward, the
community, rather than Adobe, will determine the future of Flex.

== Community ==

The community surrounding Flex is vast, diverse, distributed globally,
and with all levels of proficiency in software development. The common
thread of application development binds all Flex developers together.

It is estimated that there is between 350,000 and 500,000 Flex
developers worldwide. Precise numbers are impossible for us to know
due to the open nature of Flex. A blog post calling for initial
committers received over 60 responses in two days.   The !FlexCoders
mailing list, a general-purpose mailing list for anyone working with
Flex, has over 9000 members.  A quick look on the Adobe Forums or
Twitter’s #!AdobeFlex hashtag usually shows activity within minutes.
The community is engaged and active daily and incredibly excited by
Adobe’s move to contribute Adobe Flex SDK to Apache. The community is
responsive, inclusive and honestly emphatic when it comes to bettering
Flex for application development.

== Alignment ==

The only way the Apache Flex project can work is if it is an open,
transparent and collaborative effort. The project has now grown in
mind-share and community enough that we believe it is time we work
with a foundation to see the code mature in a fashion consistent with
our values.

== Known Risks ==

Moving from a corporate-led project to the Apache model of
collaboration is a challenge, and Adobe is committed to help making
the transition as smooth as 

Re: [VOTE] Release jena-2.7.0-incubating (RC1)

2011-12-20 Thread Leo Simons
*bump*. We have 2 +1s from mentors already, so at a minimum we need
just one more binding vote to do this release. Anyone have time to do
the review?

thanks!

Leo

On Mon, Dec 19, 2011 at 10:16 AM, Andy Seaborne a...@apache.org wrote:
 Please vote on releasing the following as
  Apache Jena version 2.7.0-incubating

 This will be the first incubator release for Jena at Apache.

 == Overview

 Jena is a Java framework for building Semantic Web applications. Jena
 provides a collection of tools and Java libraries to help to develop
 semantic web and linked-data apps, tools and servers.

 Jena is composed of a number of modules.  Historically, they have been
 released semi-independently, sort of flying in formation. We intend to
 switch to a more integrated build process and we want to create the time to
 do that by making this first Apache release now.

 For this first release, we need to release several modules at once as none
 have been released at Apache before.  Our apologies for the extra checking
 work this results in.  It also makes building everything from scratch
 involve more steps than an integrated build would do.

 Jena is delivered as maven artifacts for the jar for each module.  It is
 also delivered as zip file containing all the jars and their dependencies so
 users have a download and unpack option.

 The version number of the release aligns with the main artifact and the
 packaged download.  Different modules have different version numbers.

 Detailed version numbers:

 jena-top      0-incubating        Parent POM
 jena-iri      0.9.0-incubating    IRI parsing library
 jena-core     2.7.0-incubating    Main Jena APIs for RDF and OWL.
 jena-arq      2.9.0-incubating    SPARQL query engine.
 apache-jena   2.7.0-incubating    Download, with all dependencies.

 == Project vote

 Apache archives:
 http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E

 Markmail:
 http://markmail.org/message/dob5hsk46ldqkqt4

 == Maven staging repository
 https://repository.apache.org/content/repositories/orgapachejena-334/

 == Proposed dist/ area:
 http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/

 == Keys
 https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

 == SVN tags

 Each module is currently tagged with the version and -RC-1 to denote the
 first release candidate for this release cycle.  If voted on successfully,
 the tag will be changed (svn mv) to the same but minus the -RC-1.

 https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/

 https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/

 https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/

 https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/

 https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/

 == Website

 Including details of this proposed release:
  http://jena.staging.apache.org/jena/


 Please vote on this release:

  [ ] +1 Approve the release of Apache Jena 2.7.0-incubating
  [ ] -1 Don't release, because ...

 This vote will be open until:
  Thursday 22/December 23:59 UTC
 (72 hours from the same hour tonight).


 As well as the vote, we'd also appreciate any feedback for improving our
 release process and project generally.

    Andy

 -
 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: Voting time period can be shortened ? (was: [VOTE] Release Kafka 0.7.0-incubating)

2011-11-30 Thread Leo Simons
Yupyup. I thought I'd add a little background rant here, that I wrote
for the jena podling a bit ago. Purely optional reading but maybe
illuminating for some.

cheerio,

- Leo

On Tue, Nov 8, 2011 at 9:44 PM, Leo Simons m...@leosimons.com wrote:
 On Fri, Nov 4, 2011 at 3:54 PM, Benson Margulies bimargul...@gmail.com 
 wrote:
snip/
 Release votes are about universally 72 hours.

 Benson is of course right, but I like pointing out reasons behind such
 conventions, so I'm going to give you a belated, long answer anyway,
 reading it is optional :-)

 I'm always a little annoyed when I see people say something like
 sorry your vote doesn't count it was too late, or you can't do that
 yet you have to wait 3 more hours someone might still vote -1 :-)

 The underlying point is to make sure to give everyone a reasonable
 chance to make up their minds and then vote (in the broadest
 everyone sense, and even if they may not have a binding vote).

 Religiously sticking to numbers is silly. Use your judgement. The duty
 of PMC members in the end is to act in the best interests of the
 apache foundation (which acts in the best interest of the general
 public), not to follow (or force onto others) particular rules.

 Some examples to illustrate, probably unneeded, but...

 If you consider people might be a day behind on their e-mail, and they
 might be on the other side of the globe, that's 36 hours absolute
 worst-case. If you add a weekend in the middle from friday 5pm to
 monday 9pm that's a total of 36 + 7 + 9 + 48 = 100 hours. If you
 consider that it may take a day, say, to verify a release and
 regression test it (say across your, err, 1000 node hadoop cluster,
 whatever), that's 124 hours. So you could have a long argument that 72
 hours is not enough, and decide as a project you will use a 124 hour
 minimum. You're allowed to do that, if that's what you think is best
 for your community.

 On the one extreme you can imagine a project with all the people on
 the mailing list being on UTC time or close to it where a vote is
 almost pro forma since consensus was clear anyway, where you start the
 vote at 9am in the morning and everyone subscribed to the mailing list
 has voted by 11am. Do you then want to wait 122 additional hours
 because that's a rule? Not really.

 On the other extreme, for something like here's a proposal to bring
 geronimo / harmony / openoffice into apache that impacts loads and
 loads of people and might cause corporations to move mountains, it's
 considered normal to allow reasonable amounts of time for discussion,
 where reasonable could be over a month.

 72 hours turns out from experience to be a nice standard number for
 release votes and other such important milestones, because it gives a
 very reasonable amount of time allowing for the broadest possible
 participation, without becoming a super-annoying super-long wait. It
 avoids people holding a project hostage and stalling, yet also avoids
 the temptation to rush through contentious changes when the majority
 (but not all) people are co-located at a hackathon, etc.

 But, use your own judgement. If one of the companies one of you works
 at would really really like an extra day to regression test a new
 version of jena at a large customer deployment, and that is delayed a
 bit because someone tied up all the jenkins instances with their
 hadoop stuff, it'll probably be a good idea to wait for the results
 rather than push through with a vote, since that means the general
 public gets to benefit from a better-tested release.

 This kind of balancing thing is, incidentally, why the how to do
 apache stuff docs don't have that many hard rules. Stubborn people
 like me keep editing them out :)


 cheers,


 Leo

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



[DISCUSS] how to add many committers to a new project (was: Re: [VOTE] Accept OpenOffice.org for incubation)

2011-06-13 Thread Leo Simons
Hey hey,

On Sun, Jun 12, 2011 at 7:04 PM, Joe Schaefer joe_schae...@yahoo.com wrote:
 +1 binding.  Given the sheer number of committers involved in this podling
 there will be some work to do trying to gel a coherent development community
 out of the group.  While I am optimistic, I am reminded of Roy's cautions
 about piling on [1] to a prospective podling, and am not entirely convinced
 that it's necessarily a good thing that we promote the idea of getting in
 on the ground floor wrt new podlings.

 [1]- http://s.apache.org/VT5

Perhaps one approach the podling could take at the guidance of its
mentors is to create accounts on demand. I.e. first order of business
is getting basic infrastructure up (I think everyone is looking
forward to having traffic on general@incubator back to normal -:) ),
next up is getting the initial code import. Next after that you start
adding in the people that have sent in CLAs and are wanting to touch
the code/website/etc. That's what harmony did. It helped the project
get into a mode of voting in new people frequently, and it also helped
make visible to the project that it was ok if you didn't show up on
day 0.

cheers...

Leo

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



Re: [VOTE] Accept OpenOffice.org for incubation

2011-06-11 Thread Leo Simons
On Fri, Jun 10, 2011 at 5:02 PM, Sam Ruby ru...@intertwingly.net wrote:
 As the discussions on the OpenOfficeProposal threads seem to be winding
 down, I would like to initiate the vote to accept OpenOffice.org as an
 Apache Incubator project.

+1 from me (binding).

cheers,

Leo

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



Re: [VOTE] Flume to join the Incubator.

2011-06-08 Thread Leo Simons
+1 and welcome on board.

cheers,

Leo

On Wed, Jun 8, 2011 at 5:38 AM, Jonathan Hsieh j...@cloudera.com wrote:
 [  ] +1 Accept Flume for incubation
 [  ] +0 Indifferent to Flume incubation
 [  ]  -1 Reject Flume for incubation
...
 = Flume - A Distributed Log Collection System =

 == Abstract ==

 Flume is a distributed, reliable, and available system for efficiently
 collecting, aggregating, and moving large amounts of log data to scalable
 data storage systems such as Apache Hadoop's HDFS.

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



Re: [VOTE] Accept Sqoop for Incubation

2011-06-08 Thread Leo Simons
+1!

cheers,

Leo

On Wed, Jun 8, 2011 at 4:39 AM, arv...@cloudera.com arv...@cloudera.com wrote:
 As there are no active discussions on the [PROPOSAL] thread for a few
 days now, I will like to initiate the vote to accept Sqoop as an
 Apache Incubator project. The proposal discussion thread and full text
 of the proposal can be found at the following locations:

 Discussion Thread:
 http://www.mail-archive.com/general@incubator.apache.org/msg27726.html
 Proposal: http://wiki.apache.org/incubator/SqoopProposal

 Please cast your votes:

 [  ] +1 Accept Sqoop for incubation
 [  ] +0 Indifferent to Sqoop incubation
 [  ]  -1 Reject Sqoop for incubation

Pasting wiki page below for archival/reference:


= Sqoop - A Data Transfer Tool for Hadoop =

== Abstract ==

Sqoop is a tool designed for efficiently transferring bulk data
between Apache Hadoop and structured datastores such as relational
databases. You can use Sqoop to import data from external structured
datastores into Hadoop Distributed File System or related systems like
Hive and HBase. Conversely, Sqoop can be used to extract data from
Hadoop and export it to external structured datastores such as
relational databases and enterprise data warehouses.

== Proposal ==

Hadoop and related systems operate on large volumes of data. Typically
this data originates from outside of Hadoop infrastructure and must be
provisioned for consumption by Hadoop and related systems for analysis
and processing. Sqoop allows fast provisioning of data into Hadoop and
related systems by providing a bulk import and export mechanism that
enables consumers to effectively use Hadoop for data analysis and
processing.

== Background ==

Sqoop was initially developed by Cloudera to enable the import and
export of data between various databases and Hadoop Distributed File
System (HDFS). It was provided as a patch to Hadoop project via the
issue [[https://issues.apache.org/jira/browse/HADOOP-5815|HADOOP-5815]]
and was maintained as a contrib module to Hadoop between May 2009 to
April 2010. In April 2010, Sqoop was removed from Hadoop contrib via
[[https://issues.apache.org/jira/browse/MAPREDUCE-1644|MAPREDUCE-1644]]
and was made available by Cloudera on
[[http://github.com/cloudera/sqoop|GitHub]].

Since then Sqoop has been maintained by Cloudera as an open source
project on GitHub. All code available in Sqoop is open source and made
publicaly available under the Apache 2 license. During this time Sqoop
has been formally released three times as versions 1.0, 1.1 and 1.2.

== Rationale ==

Hadoop is often used to process data that originated or is later
served by structured data stores such as relational databases,
spreadsheets or enterprise data warehouses. Unfortunately, current
methods of transferring data are inefficient and ad hoc, often
consisting of manual steps specific to the external system. These
steps are necessary to help provision this data for consumption by
Map-Reduce jobs, or by systems that build on top of Hadoop such as
Hive and Pig. The transfer of this data can take substantial amount of
time depending upon its size. An optimal transfer approach that works
well with one particular datastore will typically not work as
optimally with another datastore due to inherent architectural
differences between different datastore implementations. Sqoop
addresses this problem by providing connectivity of Hadoop with
external systems via pluggable connectors. Specialized connectors are
developed for optimal performance for data transfer between Hadoop and
target systems.

Analyzed and processed data from Hadoop and related systems may also
require to be provisioned outside of Hadoop for consumption by
business applications. Sqoop allows the export of data from Hadoop to
external systems to facilitate its use in other systems. This too,
like the import scenario, is implemented via specialized connectors
that are built for the purposes of optimal integration between Hadoop
and external systems.

Connectors can be built for systems that Sqoop does not yet integrate
with and thus can be easily incorporated into Sqoop. Connectors allow
Sqoop to interface with external systems of different types, ensuring
that newer systems can integrate with Hadoop with relative ease and in
a consistent manner.

Besides allowing integration with other external systems, Sqoop
provides tight integration with systems that build on to of Hadoop
such as Hive, HBase etc - thus providing data integration between
Hadoop based systems and external systems in a single step manner.

== Initial Goals ==

Sqoop is currently in its first major release with a considerable
number of enhancement requests, tasks, and issues logged towards its
future development. The initial goal of this project will be to
address the highly requested features and bug-fixes towards its next
dot release. The key features of interest are the following:
 * Support for bulk import into Apache HBase.
 * Allow user to supply password in 

OOo mirroring (was: Re: A little OOo history)

2011-06-07 Thread Leo Simons
On Tue, Jun 7, 2011 at 6:35 PM, Christian Grobmeier grobme...@gmail.com wrote:
 30 downloads per day or per month?

 52TB per month is still a lot...

 per day.
 Look at this chart:
 http://marketing.openoffice.org/marketing_bouncer.html

TL;DR: these bandwidth numbers are not actually that scary or
important -- the OOo infrastructure does not serve up all that
traffic, the many mirrors do, and traffic from the OOo infrastructure
to the mirrors is very efficient since it efficiently pushes out new
releases (with rsync). The big work in mirroring is setting up the
process and shepherding the mirroring community.

OOo has 118 mirrors. Apache has 294 mirrors. There is significant
overlap -- a lot of sites that mirror apache downloads already mirror
OOo downloads and vice versa.

  http://download.services.openoffice.org/mirrors/all.html
  http://www.apache.org/mirrors/

Note that many of the mirrors of OOo and of apache also mirror large
amounts of other open source software.

OOo uses mirrorbrain [1]. Apache uses some CGI scripts to accomplish a
lot but not all of the same functionality.

The set of data ASF pushes to its mirrors is somewhere downwards of
50GB [4]. The set of data OOo pushes is somewhere downwards of 300 GB
[2]. It doesn't seem like a good idea to push an additional 300GB to
all existing apache mirrors: that isn't quite what they signed up for.

As I understand it Oracle wants to transition out of maintaining the
OOo infrastructure eventually. So if OOo gets accepted into the
incubator, it seems like the smart approach would be to duplicate the
existing OOo mirrorbrain installation onto some apache hardware, with
the people that look after the OOo and apache mirrors figuring out the
specific details.

Will be a fair bit of work I imagine so definitely needs volunteers to
step up and all that, but nothing particularly scary I think, assuming
the existing OOo mirror maintainers [3] help out. Without their help
it will be much harder to figure out how to do things! If most of the
people that worked on mirroring at OOo are now at TDF (and looking at
mail archives it seems that might be true [7]), better be extra nice
to them TDF folks :-)

Long term, if there's people to do the work, one could imagine
updating the custom ASF mirror infrastructure to use mirrorbrain which
seems like a cool tool...but that is a _lot_ of work because the
existing CGI scripts integrate into the download pages of every apache
project.


cheers,


Leo

PS: LibreOffice also uses mirrorbrain [5], having about 65 mirrors.
They required only 15GB for a mirror though [6], not the OOo footprint
200GB. Sounds much more reasonable...

[1] http://mirrorbrain.org/
[2] http://wiki.services.openoffice.org/wiki/New_OOo_Mirror_Structure
http://distribution.openoffice.org/files.html
http://wiki.services.openoffice.org/wiki/Mirrors_Project
[3] http://openoffice.org/projects/distribution/lists
[4] http://www.apache.org/info/how-to-mirror.html
[5] http://download.documentfoundation.org/mirrors/all.html
http://wiki.documentfoundation.org/Mirrors
[6] http://download.documentfoundation.org/mirroring.html
[7] http://blog.gmane.org/gmane.comp.documentfoundation.mirrors

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



Re: A little OOo history

2011-06-07 Thread Leo Simons
On Tue, Jun 7, 2011 at 6:58 PM,  robert_w...@us.ibm.com wrote:
 Since this is a large download, I wonder whether the quoted numbers are
 impacted at all by timeouts, abandoned downloads attempts, etc.  In other
 words, is it counting the HTTP GET's?  Or the successful downloads?  That
 may influence the load by quite a bit.  It may even make it worse.

It is most likely the number of redirects that the MirrorBrain
software makes to download servers. You should take a look at what
MirrorBrain does, it's open source, err, free software :)

 And let's not even get started on the burst traffic when a major new
 release is announced.

 Of course, this is not necessarily a problem for Apache.  Think of it this
 way.  It would be perfectly possible, and actually quite easy for someone
 to host the files with a scalable cloud storage provider, e.g., Amazon,
 and charge $0.99 for the download, the cost of an iPhone app.   That is
 over $30 million/year.  Heck, I might just do that myself and retire!

 In any case, you can see how this problem solves itself given the Apache
 2.0 license.

You know, there is this large and interesting community of maintainers
of mirrors of open source software.

A fair share of them are your typical beard stroking [1] uber
experienced unix [2] system administrators who maintain a local mirror
for their company / campus / ISP mostly so that their local users are
served from their local infrastructure, saving on the bandwidth bill
of their uplink and keeping their users happy.

The art of software mirroring is mostly in making friends with these
folks and then staying friendly to them and keeping them happy and
well-fed and rsynced.

Putting things in the cloud is probably a pretty decent way to piss
these people off :-D

Incidentally, apache has decent mirroring mostly because it has its
own share of beard stroking [1] uber experienced unix [2]
administrators. They are typically referred to as the infra team, and
they must also be kept happy and well-fed at all times! [3]

cheerio,

Leo

[1] amount of beard on administrator may vary. Beard may contain traces of nuts.
[2] mistakenly referring to unix as linux often not advisable.
[3] I think it doesn't say this clearly enough in the incubator docs,
but, feed infra team a selection of their favorite beverage at
apachecon should probably be on the incubation checklist!

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



Re: OpenOffice.org Apache Incubator Proposal: Splitting the Community?

2011-06-03 Thread Leo Simons
On Fri, Jun 3, 2011 at 7:17 PM, Jim Jagielski j...@jagunet.com wrote:
 Just remember, we haven't yet even voted on whether or not to accept
 the podling.

 These are decisions the podling should be making.

 Are you ready to call for a vote? :)

Whoah! Please don't call for a vote -- I would much rather we first
arrive at a situation where I can comfortably vote +1! :)

I recognize that all important smiley (note I'm adding smileys too!!
(^_^) ), but let's pretend I'm ignoring that, in which case for me the
actual answer is something like...

* The, err, awkward language in the proposal that was pointed out [1]
should be fixed first.

* Arguably you need _at least_ 3 mentors first.

* There is a ton of information/opinions/plans/background on
blogs/twitter/press releases/etc (for example from IBM folks like Rob)
that is not quite reflected yet in the proposal, which should change:
the proposal should be complete so that you can read it from start to
end, have a good idea about everything going on, and cast a vote.

* There is a ton of stuff at OpenOffice.org (infrastructure, docs,
...) for which it is unclear what ASF its relation is going to be to
it, the proposal is not quite reflecting the reality of what OOo is
yet.

* You reached out to a bunch of organisations and existing communities
and asked them to provide feedback and/or sign up as committers, and
we have mostly not seen the response yet. I'm sure many people are
still trying to get to grips with what is happening.

* There are some conversations going on that seem a bit heated now but
also seem pretty resolvable. It seems a good idea to get rid of most
of that heat before voting on the next step.

* In general I see a couple of very excited people generating a lot of
e-mail traffic which means a not so great signal-to-noise ratio (which
is normal and fine and such, this is _huge_ for a lot of people :-) ),
making it very hard for people that have to vote on a proposal to get
a clear hold of the signal. Making having a very clear and complete
proposal (perhaps even with FAQ) even more important.

(...)

I'm not much of a process junkie, but I think the whole idea of OOo
coming here also includes following normal apache due diligence
processes, which tends to involve slowing things down a bit when they
get heated up. I personally completely fail to get excited about
office applications (but welcome on board guys! Good luck! :-) ) but
you're pretty obviously not done with some of the basics yet. The
responsible vote AFAICS right now would be something like -1, seems
like a good idea, but the proposal is not finished, so please fix it.



cheers!


Leo

[1] Oracle and ASF agree [broad statement]... IBM as Sponsor ... etc

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



Re: I think individuals need SGAs

2010-12-02 Thread Leo Simons
Hey hey,

I definitely understand the reasoning. Hmm. I think the way to look at it is, 
it depends, but do whatever is needed to allow apache liberal rights to 
sublicense all the IP to it's users.

The second way to look at it is that logic and legal stuff are not always as 
closely connected as you might think...so I think this really is something to 
run by legal-discuss / whoever designed the process (Roy?), people like me just 
regurgitate what they learned before :)

cheerio,

Leo



On Dec 1, 2010, at 10:15 PM, Benson Margulies bimargul...@gmail.com wrote:

 I've been thinking about Leo's email of the other day, and I think
 that my edit to the mentor page is not right and some guidance I've
 delivered to podlings is not right.
 
 I'd like to float my logic here and see how it gets shot at.
 
 As Leo pointed out, the CCLA has a specific section for granting
 rights to pre-existing IP.
 
 The ICLA does not. It has no schedule. It talks about contributions.
 
 When we import pre-existing code for a podling, it seems to me that it
 is dubious to characterize this as an act of 'contribution' by the
 historical authors, even if they are eagerly anticipating further
 contributions to the code in the incubator.
 
 Therefore, I think that I should edit my edit, and send new advice, to
 the effect that all historical contributors need to be covered by
 SGAs. Those could be in the form of SGA schedules or in the form of
 individual SGAs.
 
 --benson
 
 -
 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: Setting up the Jena podling

2010-12-02 Thread Leo Simons
On Thu, Dec 2, 2010 at 12:12 PM, Benson Margulies bimargul...@gmail.com wrote:
 I'm a bit up to my eyes in OpenNLP. Can one of you get the initial
 status page going?

On it.

- Leo

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



Re: Clarification about SGA versus CCLA

2010-11-28 Thread Leo Simons
Hey folks,

On Sat, Nov 27, 2010 at 4:34 AM, Craig L Russell
craig.russ...@oracle.com wrote:
 I think of a CCLA as a combination of an SGA to cover the software grant
 plus an acknowledgement that people in the company are going to work on
 Apache projects, whether on their own time or company time.

 So, if a CCLA is filed naming the software, a separate SGA is *not*
 necessary.

I always worry when we short-circuit the details like this: the
opportunity for misunderstandings is there :)

If and only if you fill out schedule B of a CCLA, then the CCLA also
is a software grant as well as an agreement for ongoing contributions.

Corollary - if as part of incubation a company sends in a CCLA
*without* actually filling out schedule B, then importing a large body
of existing code on which that company claims rights could be a bad
idea.

I don't think we should spend too much time over-documenting how to
actually use these documents -- in the end the documents themselves
are pretty clear.


cheerio!


Leo

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



Re: [VOTE] Accept Jena into the incubator

2010-11-21 Thread Leo Simons
+1 obviously!

- Leo

On Sun, Nov 21, 2010 at 5:49 PM, Benson Margulies bimargul...@gmail.com wrote:
 +1 binding

 On Fri, Nov 19, 2010 at 10:17 PM, Niclas Hedhman nic...@hedhman.org wrote:
 Lacking a lot of binding votes...

 +1 binding

 On Wed, Nov 17, 2010 at 9:10 PM, Ross Gardler rgard...@apache.org wrote:
 Please vote on the acceptance of JENA into the incubator. The proposal can
 be found at http://wiki.apache.org/incubator/JenaProposal and is copied
 below.

 [ ] +1 Accept Jena for incubation
 [ ] +0 Don't care
 [ ] -1 Reject for the following reason:

 The vote is open for at least 72 hours.

 Thanks,
 Ross

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



Re: [PROPOSAL] Zeta Components - Further comments?

2010-04-22 Thread Leo Simons

On 4/22/10 10:21 AM, Tobias Schlitt wrote:

I updated the proposal to reflect the objections regarding the
infrastructure. Our questions regarding the import of our SVN history
has been cleared.

Are there further comments, suggestions, objections?


Very nicely written proposal, well done! Looks like an interesting 
project to bring into the apache fold - some more PHP sounds like a good 
idea :)


It looks like you now need to sign up some mentors after which your 
proposal would be ready for a vote.



cheers,


Leo

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



Re: [PROPOSAL] Whirr Project

2010-04-22 Thread Leo Simons

On 4/15/10 10:42 PM, Tom White wrote:

I would like to propose Whirr as an incubator proposal.

Whirr will be a set of libraries for running cloud services, such as
Hadoop or Cassandra. The initial code (for Hadoop) is hosted as a
Hadoop contrib module, but I believe it would flourish as its own
project with its own community.

The proposal is on the incubator wiki at
http://wiki.apache.org/incubator/WhirrProposal.


...and pasted inline below (as is customary). The proposal looks fine to 
me. Like you mention your initial group of committers is a bit small 
which is a risk but hey, cloud is hot, go build community :)


You do know any ASF member can sign up to be an incubator mentor, right? 
If I count correctly you have two on your list :)


cheers,

Leo

--
= Whirr, a library of cloud services =

== Abstract ==
Whirr will be a set of libraries for running cloud services.

== Proposal ==
Whirr will provide code for running a variety of software services on 
cloud infrastructure. It will provide bindings in several languages 
(e.g. Python and Java) for popular cloud providers to make it easy to 
start and stop services like Hadoop clusters. The project will not be 
limited to a particular set of services, rather it will be expected that 
a range of services are developed, as determined by the project 
contributors. Possible services include Hadoop, HBase, !ZooKeeper, 
Cassandra.


== Background ==
The ability to run services on cloud providers is very useful, 
particularly for proofs of concept, testing, and also ad hoc production 
work. Bringing up clusters in the cloud is non-trivial, since careful 
choreography is required. (Designing an interface that is convenient as 
well as secure is also a challenge in a cloud context.)  Making services 
that runs on a variety of cloud providers is harder, even with the 
availability of libraries like libcloud and jclouds, since each 
platform's quirks and extra features must be considered (and either 
worked around, or possibly taken advantage of, as appropriate) . Whirr 
will facilitate sharing of best practices, both for a particular service 
(such as Hadoop configuration on a particular provider), and for common 
cloud operations (such as installation of dependencies across cloud 
providers). It will provide a space to share good configurations and 
will encode service-specific knowledge.


== Rationale ==
There are already scripts in the Hadoop project that allow users to run 
Hadoop clusters on Amazon EC2 and other cloud providers. While users 
have found these scripts useful, their current home as a Hadoop Common 
contrib project has the following limitations:
 * Tying the scripts' release cycle to Hadoop's means that it is 
difficult to distribute updates to the scripts which are changing fast 
(new features and bugfixes).
 * The scripts support multiple versions of Hadoop, so it makes more 
sense to distribute them separately from Hadoop itself.
 * They are general: people want to contribute code for non-Hadoop 
services like Cassandra (for example: 
http://github.com/johanoskarsson/cassandra-ec2).
 * Having a uniform approach to running services in the cloud, hosted 
in one project, makes launching sets of complementary services easier 
for the user. Today, the scripts and libraries hosted within each 
project (e.g. in Hadoop, HBase, Cassandra) have slightly different 
conventions and semantics, and are likely to diverge over time. Building 
a community around cloud infrastructure services will help enforce a 
common approach to running services in the cloud.


== Initial Goals ==
 * Provide a new home for the existing Hadoop cloud scripts.
 * Add more services (e.g. HBase)
 * Develop Java libraries for Hadoop clusters
 * Add new cloud providers by taking advantage of libcloud and jclouds.
 * (Future) Run on own hardware, so users can take advantage of the 
same interface to control services running locally or in the cloud.


== Current Status ==
=== Meritocracy ===
The Hadoop scripts were originally created by Tom White, and have had a 
substantial number of contributions from members of the Hadoop 
community. By becoming its own project, significant contributors to 
Whirr would become committers, and allow the project to grow.


=== Community ===
The community interested in cloud service infrastructure is currently 
spread across many smaller projects, and one of the main goals of this 
project is to build a vibrant community to share best practices and 
build common infrastructure. For example, this project would provide a 
home to facilitate collaboration between the groups of Hadoop and HBase 
developers who are building cloud services.


=== Core developers ===
Tom White wrote most of the original code and is familiar with open 
source and Apache-style development, being a Hadoop committer and an ASF 
member. There have been a number of contributors who have provided 
patches to these scripts over time. Andrew Purtell who created the HBase 
cloud 

Re: [VOTE] Subversion podling for graduation

2010-02-12 Thread Leo Simons

+1

- Leo

On 2/12/10 4:08 AM, Greg Stein wrote:

Hello all,

I started a discussion thread a week-ish ago to seek out issues for
Subversion's graduation. The couple bits that were raised[1] have been
handled, I believe. So with that said, I am unaware of any potential
showstoppers, and would like to request a vote for graduating the
Subversion podling. Should this result in a successful vote, I will
put a resolution before the Board (for its Feb 17 mtg) to construct a
new Subversion PMC.

Please vote:

[ ] +1 Graduation
[ ] -1 Hold, and continue incubating


Thanks!

Cheers,
-g

[1] incubator status page, and java bindings package name


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



Re: Discussion: graduating Subversion

2010-01-26 Thread Leo Simons

On 1/26/10 6:00 AM, Niclas Hedhman wrote:

On Tue, Jan 26, 2010 at 4:49 AM, Greg Steingst...@gmail.com  wrote:


Before calling for a vote to graduate Subversion, I figured it prudent
to have a discussion first. I believe Subversion is quite ready (and
has been, but the holidays and whatnot kept me from sending this
earlier).

Any thoughts on why Subversion should NOT graduate now?


I want to see a graduation. Motivation; Incubator is about fostering
the community, and I don't think that the Incubator can provide
anything additional from the Apache folks already present in the
Subversion community. Anything else sounds like bureaucracy for the
sake of it, to me...


Talking about bureaucracy, comparing

  http://incubator.apache.org/projects/subversion.html

and

  http://wiki.apache.org/incubator/January2010

looks like the status file is not quite up to date.

I'm assuming the question of graduation being asked means that all 'em 
boxes should in fact have been ticked by now. If so I say tick 'em and 
vote :)


cheers,

Leo

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



Re: [VOTE] Graduate Apache Shindig as an Apache Top Level Project

2010-01-14 Thread Leo Simons

On 1/14/10 11:41 AM, Vincent Siveton wrote:

I would like to start an official vote to recommend the graduation of
Apache Shindig as a Top Level Project to the Board.


+1!

- Leo

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



The incubator is here to help projects

2009-12-13 Thread Leo Simons

Hey folks,

The incubator is here to help. It is about education. It is about 
teaching podlings how to work here at apache, about showing people what 
to be aware of.


The incubator is *not* here to assess or judge or dictate or lecture or 
draft policy or go on long rants about The One True Way To Do X or to 
have a Long Argument About Whether Anyone Did Anything Wrong. What not 
to do is important: the best way to learn is to learn by doing, and by 
doing something fun, and all this other stuff really gets in the way.


When addressing a (potential) project or discussing it here on general@, 
please do take care to always get off your soap box first, and please 
always remember you are here to help them. If what you're going to say 
about a project won't help anyone, please do reconsider sending that e-mail.


Just a friendly reminder...


thanks for reading!


Leo

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



Re: [PROPOSAL] Validation incubator for JSR-303 Bean Validation

2009-12-11 Thread Leo Simons

On 12/11/09 1:14 AM, Donald Woods wrote:

I would like to present an incubator proposal for a new Validation
podling, which would be a JSR-303 Bean Validation follow-on to the
existing Apache Commons Validation 1.x project, but based on a new
incoming codebase with a software grant from Agimatec GmbH.

The proposal is available on the wiki at:

http://wiki.apache.org/incubator/ValidationProposal


The proposal looks fine on paper, but I'll agree with some of the other 
comments that it seems a bit silly to incubate this as a disjoint project.


If you have 3 capable and able mentors *and* a whole bunch of people 
that are already committers, why can't they mentor your one or two new 
committers while those people are constrained to their specific sandbox, 
and avoid tons of bureaucracy and overhead?


I have no real idea why anyone would think that doing incubation looks 
like it'll have a better chance of success in this case.


Put another way - what does doing incubation buy you, and why is it 
seen as a better option?


Can you please reconsider and see if you can do this as an ip clearance 
only?


If it helps I can hop on a mailing list and object to some objections? :-D

ciao...

- Leo

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



Re: [PROPOSAL] OpenCMIS incubator for Content Mangement Interoperability Services (CMIS)

2009-12-11 Thread Leo Simons

Heya OpenCMIS folks,

Since it looks like you aren't currently supported by a champion or 
mentor [1], I thought I'd fill in a small part and inject some warm 
fuzzies...


*Thanks* for open sourcing your project and *thanks* for considering 
doing it at apache. Its always a lot of effort to go through this kind 
of public vetting and I'm sure the wider CMIS community will somehow 
benefit from you taking the time.


Though it may look like you're not really receiving the warm welcome you 
perhaps expected, this kind of discussion is quite normal when people 
(engineery types especially!) are excited about a topic...in some ways 
the only warm welcome we do is the hot welcome :)


So even if it doesn't feel that way, having this boatload of discussion 
is actually sort of good news -- you have sparked lots of interest and 
people are looking carefully at your proposal, Jukka's even looking at 
all the code in detail, that doesn't always happen ;)


It looks like you're doing a good job keeping it cool and answering 
questions. I'm sure there's a couple of days more work ahead to sort out 
what looks like a pretty complex discussion about the relationship 
between OpenCMIS and Chemistry. Keep at it!



cheers,


Leo

[1] no, you really don't want me as a mentor [2], so don't ask :)
[2] because I would offer you an opinion or two about CMIS and it'd all 
end in tears...


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



Re: How documentation != code, and how to do policy (was: Re: Publishing api docs for Subversion)

2009-12-08 Thread Leo Simons
On Tue, Dec 8, 2009 at 5:16 AM, Niclas Hedhman nic...@hedhman.org wrote:
 this is also the case for Nightly Builds, accessible by the
 public; Legally they are publishing to the public (i.e. opposite of
 'for private use') and bound by licenses and agreements.
 And finally, from Copyright law perspective, you are right that code
 and text is effectively the same thing, but that code has a common
 tendency to be depending on other work, introducing licensing into the
 legal mix. I think it was Leo who also pointed out that Trademarks is
 an additional legal aspect of it.

I have no idea what it you mean exactly, but I'm pretty sure I said
nothing about nightly builds and I said nothing about trademarks.
Here's some of what was said just a few e-mails back:

 Doug:
  What's special about documentation?

Leo:
 (...) Less legal risk (...), generally not subject to patent concern

which I probably should not have said since I didn't back it up with a
reasonable reference. Sorry about that.

cheers,

Leo

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



Re: OSS Java AAC Decoder?

2009-12-07 Thread Leo Simons
On Mon, Dec 7, 2009 at 3:41 PM, Branko Čibej br...@xbc.nu wrote:
 Todd Volkert wrote:
 Does anyone on this list know of an existing open source pure-Java Advanced
 Audio Coding (AAC) library?  If not, are there any audiophiles on this list
 that would be interested in incubating such a project with me? :)  Do you
 know of any barriers to such a project (like performance of a pure-Java
 library being a problem given the complexity of the encoding)?


 I wouldn't know about the performance of Java in general, but certainly
 AAC(+) encoding isn't trivial. Decoding is somewhat easier, as usual.

 However, the whole idea is probably quite a bit problematic, because AAC
 coding, streaming and playback are subject to a ton of patents and
 MPEG-LA licensing. I wouldn't know how that fits withtin the ASF, but
 I'd imagine it's edge-case at best.

Yup, I'm pretty sure it won't fit well at all with our (C)CLA -- to
learn a bit more about the problems of AAC and such as combined with
open source, try and look for google chrome (which, IIRC, includes a
version of ffmpeg) topics on the subject -- (again) IIRC google pretty
specifically (sub)licenses or will sublicense a bunch of those patents
to chrome users and re-distributors which I imagine was a rather huge
can of worms for them to accomplish.

I can't find it now, but I could swear Chris DiBona actually did a
bunch of e-mails about such a topic together with one of google's
laywers. It might be worth getting in touch with them...

...also it seems like java is actually quite fine for
encoding/decoding of low-level high-bandwidth things like audio and
video, as long as you stay away from java.util.* and other high-level
stuff like that and you tune your GC appropriately :)

ciao,

Leo

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



How documentation != code, and how to do policy (was: Re: Publishing api docs for Subversion)

2009-12-05 Thread Leo Simons
Hey hey,

I wasn't going to say anything but since this is dragging on...

On Sat, Dec 5, 2009 at 1:08 AM, Doug Cutting cutt...@apache.org wrote:
 Would we permit someone to mirror other files from trunk on the website?

Yes, definitely. Most projects publish their websites by pushing files
into SVN. Many projects automate this - commit an xml file, its turned
into html and published online. That is in fact the encouraged
process, though we do allow other mechanisms (like a plugin which
takes confluence content and pushes that out automatically).

  What's special about documentation?

Less legal risk, less risk that anyone puts a bug in docs that crashes
a users computer or corrupts their data or takes down the internet,
generally not subject to patent concern, less desire for the general
public to fork and redistribute, and much more. Like, barriers to
working on it have to be as low as possible or no-one will do it,
people inclined to work on docs are often less technical, etc etc.

Perhaps it helps to flip the question around: what is special about
(source) code? And the answer is: lots :)

 its changes are subject to vetos, etc.

Not on most of the projects I work on! Most projects use lazy
consensus for documentation. I don't think I have *ever* seen someone
veto a documentation patch.

snip/
 It's otherwise treated just like code.

Well, in some ways (that you pointed out) docs are treated a lot like
code, and in many other ways they aren't.

 Publication  release are two different things - thats the point.

 I don't see that yet.  Can you tell me more about the difference?  I use
 publish, distribute and release more or less synonymously when
 referring to project content.

I'd say we don't really have precise definitions that will provide you
with a model explaining exactly what is and isn't ok in the general
case, and I think it won't help to look for it either. Instead,
judgement should be applied to the specific case.

 Subversion contains only working drafts.

And stable branches and release tags and documentation and websites
and quickbooks and contact info and meeting minutes and ... We use
subversion for nearly everything that needs to be auditable and be
backed up and be collaboratively edited. We don't always particularly
care about the versioning bit :)

But, for the sake of illustration, let's do a mental exercise.


The ASF does creation and distribution of software to the general
public. When we say software we mostly mean source code (and some
binaries for convenience). Pretty much everything around here is
structured to support this creation and distribution of software.

There's a variety of supporting things, like websites, incubators, an
org structure, various committees, conferences, etc. All of it
supports creation and distribution of our software.

What constitutes the software that a project releases to the public
depends on that project.

Subversion is one project, it has a website and it creates software
which it distributes. Subversion releases a single tarball of (mostly
C) source code with some build scripts and whatnot. Running the build
produces an apache module, a server program, a client program and some
utilities. Subversion's users then install this software on their
system and use it. Most subversion users probably get a pre-built
binary from a third party.

The subversion project provides a manual for how to install and use
svn on its website, but I suspect most users will actually use the svn
book.

There is a relatively small side activity for subversion which
involves using its libraries and APIs to build custom client software
that interacts with a subversion server (or perhaps even extend the
server though I think very few people do that). For this activity, you
need the API docs we're talking about here. Of course, the subversion
developers themselves need those API docs too.

It's a fair assumption that the expert developer people using these
API docs know *quite a lot* about subversion already, including about
its versioning and compatibility policies, how to download releases
and code out of svn, etc etc. It's also a fair assumption that the
most important API to develop against is in fact the SVN trunk API.

So, subversion publishes their trunk API docs nightly, for the
convenience of their own developers and the surrounding tool developer
community. All those people mostly want trunk API docs, and they want
them mostly so they don't have to run doxygen themselves. There's
really no need to protect the normal users of the subversion website
from bad API docs, they won't be using those docs at all.


Now, the point of this long story: subversion as a community has
thought about all this and are evidently doing a pretty good job at
keeping users and wider developer community (well perhaps not the java
dev community who are afraid of native code :-D ) happy.


Within all this context, one of the subversion developers (or this I
assume) asked a 

Re: Question for mentors: crediting the original project?

2009-12-01 Thread Leo Simons
On Tue, Dec 1, 2009 at 11:02 AM, Ross Gardler
ross.gard...@googlemail.com wrote:
 2009/12/1 Scott Wilson scott.bradley.wil...@gmail.com:
 On http://incubator.apache.org/wookie/ is it possible to add somewhere that
 the original development was funded by the European Commission through the
 TENCompetence Project?

 I see no reason why this should not be allowed.

Agreed! If the project feels its appropriate to do something like
that, it's quite ok. One particularly relevant example I can think of
is HTTPD crediting NCSA [1], so we have in fact a lng tradition of
doing this kind of thing :)

 please add the link as a nofollow to avoid upsetting any sponsors
 (who only have nofollow links).

Yep. Other kinds of foreign branding like an external project logo are
probably also best avoided.

 One reason why others don't credit the original source of the code is
 that it might give an impression that company X owns the code and thus
 impacts the impartiality of the project. However, given that, in this
 case, we are talking about public funding in the EU I don't see that
 as an issue here.

Hmm, I would actually not be that worried either if it was a company
credit. As long as such statements are (a) true and (b) they don't
interfere with sponsoring efforts. I think what's most important is to
stick to facts and provide relevant information to users and
(potential) contributors. I think a project's origin is relevant
(though it probably becomes less relevant over time).


cheers,


Leo

[1] http://svn.apache.org/repos/asf/httpd/httpd/trunk/ABOUT_APACHE

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



Re: [VOTE] release Apache VCL 2.1

2009-11-24 Thread Leo Simons
Hey hey,

On Wed, Nov 18, 2009 at 8:42 PM, Josh Thompson josh_thomp...@ncsu.edu wrote:
 The Apache VCL community voted on and approved a proposal to release Apache
 VCL 2.1.  We would like to request the endorsement of the Incubator PMC to
 publish this release.

 The release artifact, sums, and GPG signature can be found here:
 http://people.apache.org/~jfthomps/apache-VCL-2.1-RC2-incubating/

1) Basic package looks good to me, though I didn't try to install or
run it. I checked RAT and checksums and read the various instructions.

2) The licensing situation looks 'interesting' - you have a few GPLed
dependencies like MySQL and mcrypt and Nmap without which I imagine
the product doesn't work. I would like to see VCL run on a non-GPL
database and be ensured that it can function without other
viral-licensed components as hard dependencies, some time before
graduation (I think its ok to release, as long as some kind of plan is
in place).

3) There is no website yet? You really have to do a basic homepage
over at http://incubator.apache.org/vcl/, for example so that you can
point people at mirrors (see http://www.apache.org/dev/#mirror about
the mirroring system).

4) Since this is PHP code I did a cursory code review for SQL
injection / XSS / etc. It seems like that's had some attention, but at
a glance maybe its not quite perfect? For example checkAccess() in
utils.php:

$xmlpass = $_SERVER['HTTP_X_PASS'];
if(get_magic_quotes_gpc())
$xmlpass = stripslashes($xmlpass);

where $xmlpass is used moments later to execute SQL:

$query = SELECT x.id 
   . FROM xmlrpcKey x, 
   .  user u 
   . WHERE x.ownerid = u.id AND 
   .   u.unityid = '$xmluser' AND 
   .   x.key = '$xmlpass' AND 
   .   x.active = 1;

Another piece of suspect code would be in submitLogin() in
authentication.php which does not appear to validate the
$_POST['password']. I'm by no means a PHP expert so I might be making
a fool of myself here, but better safe than sorry. So, can you explain
(preferably on, err, your website) what measures are in place to guard
against things like SQL injection and XSS?

thanks,

Leo

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



Re: JavaHL package namespace / migration / compatability

2009-11-18 Thread Leo Simons
On Wed, Nov 18, 2009 at 4:40 AM, Niclas Hedhman nic...@hedhman.org wrote:
 On Wed, Nov 18, 2009 at 12:06 AM, Justin Erenkrantz
 jus...@erenkrantz.com wrote:

 As Hyrum suggests, we can use org.apache.subversion.* if we want to
 create a new (better) Java interface within our versioning rules - but
 that isn't necessary nor should it be a pre-req for graduation.

 IMNSHO, either Subversion address this issue pre-graduation, OR we
 remove the package name change requirement for ALL incubating
 projects, leaving it up to the project post-graduation to address it.

Any reference to this being a requirement? I looked for it the other
day but didn't find anything.

If its not documented rule it is not a rule.

 It has been a contentious issue in the past, and will be so in the
 future, and I am not going to defend ASF's position if it doesn't
 apply to everyone.

 I would actually like to hear from more Java-centric developers of
 Board and IPMC what they think about this...

I wouldn't say I'm java-centric but I do a lot of it :)

I think package renaming is in many cases required for branding or
trademark reasons (which goes both ways -- org.apache.java.framework
was an issue once, com.google.httpd would be today, but on the upside
import org.apache may make people feel nice and cosy, too).

I think sf.net.foo or org.tigris.foo is not that big an issue to
keep (for a while), if there's good enough reasons (like api
compatibility for an established codebase).

Beyond that, I personally think the java standards for package naming
are really a mixed blessing, and if a project wanted to break them
(say subversion decided to go with subversion.stuff instead of
org.apache.subversion.stuff), fine, good luck to them. Regardless of
the stupidity of the rules (or the stupidity of breaking the rules),
we as incubator should really not even try to enforce these kinds of
standards; projects should make their own decisions about that.


ciao,


Leo

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



Re: [VOTE] Graduation of Apache Pivot

2009-11-17 Thread Leo Simons
On Tue, Nov 17, 2009 at 5:47 PM, Todd Volkert tvolk...@gmail.com wrote:
 The Apache Pivot community feels that it is ready to graduate into the
 Apache Pivot top-level project.

+1 from me!

cheers,

Leo

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



Re: [Discussion] Graduation of Pivot Podling

2009-11-16 Thread Leo Simons
Hey hey,

I've checked in on Pivot now and again and reviewing recent
activities, I think its definitely ready to leave the nest! I will be
happy to vote +1 when it comes to a vote.

cheers,

Leo

On Mon, Nov 16, 2009 at 3:10 AM, Todd Volkert tvolk...@gmail.com wrote:
 The feeling among the members of the Pivot podling (mentors included) is
 that it is ready for graduation.

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



Re: Review-Then-Commit

2009-11-11 Thread Leo Simons
On Wed, Nov 11, 2009 at 5:20 PM, Matthieu Riou matth...@offthelip.org wrote:
 On Wed, Nov 11, 2009 at 8:31 AM, Daniel Kulp dk...@apache.org wrote:

 As Martijn alluded to, I think we'd need some more context as to why and
 how they use RTC.

 Yes, sorry for the lack of details. The context is Cassandra and they're
 doing RTC by community choice. They all seem to agree that RTC is the best
 for their own codebase given that some parts of it can be pretty tricky. And
 even committers who aren't too big on RTC generally speaking seem to agree
 that it's working well for them (see [1] for the whole thread, including
 Paul's objection). So it really seems to be community driven.

 Thank for the inputs.

Cassandra does about the same thing as hadoop right, where patches go
into jira for an explicit +1?

While I think that's rather painful (if *I* were to do RTC I would
definitely want to manage it within SVN perhaps with the aid of
svnmerge.py), I don't think it is _wrong_. If the community really
wants to do it that way, I say let them. Sorry Paul :)

cheers,

Leo

PS: for the record I've followed cassandra on and off and I would most
likely +1 on a graduation vote.

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



Re: Two other issues to discuss for Subversion

2009-11-11 Thread Leo Simons
On Tue, Nov 10, 2009 at 7:27 PM, Greg Stein gst...@gmail.com wrote:
 There are two other issues to discuss for the Subversion podling:

 * moving the mailing lists directly to @subversion.apache.org
 * placing the source code at /subversion/ rather than /incubator/subversion/

 We are hoping to minimize overall disruption to the community with a
 move to incubator space, then a move to apache space.

I think a good thing we started here is to dig back in memory to find
the core reasons why the process is what it is and make sure we stick
to what's important. I think we have two main reasons to have the
incubator name in most those places normally:

1) make clear to users what the status of a project is, i.e. where
incubation is implying that a project may not become an apache project
or that it may not be quite safe legally yet or it may not have a
healthy community behind it or we don't have the trademarks yet or
whatever

2) protect the apache brand (you know...if an incubating project goes
up in flames, well, that's ok, we told you that might happen)

3) make it easier to keep a tight leash on PR

I would argue we are not very worried about subversion being unsafe
for use by the general public :-).

Similarly, the main thing that would hurt our brand is if the
subversion community would decide to cancel the incubation process
(because apache really sucks, you know...). The most important thing
these days is probably clear messaging on the relevant website(s).

So, as long as y'all make sure to do that good stuff (be clear to
users and protect the involved brands), I think what infrastructure
goes where exactly, can be up to infra@, in this case. And y'all are
talking to PRC anyway about any press stuff. I see no real risks.


cheers,


Leo

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



Re: Side Discussion; Mentorship [PROPOSAL][VOTE] Subversion

2009-11-10 Thread Leo Simons
On Tue, Nov 10, 2009 at 8:23 AM, William A. Rowe, Jr.
wr...@rowe-clan.net wrote:
 Greg Stein wrote:

 Sponsors
  * Champion: Greg Stein

 Cool

  * Nominated Mentors: Justin Erenkrantz, Greg Stein, Sander Striker, Daniel 
 Rall

 Once again, caution against committers == mentors (== 'project leads').
 It puts certain committers above others, an inequitable situation.

But it has the huge advantage of making sure that the mentors are
actively engaged all the time, know quite a lot about the podling's
situation, and are already well-known and trusted by the project's
community. I would say the very clear benefits far outweigh the
potential problems, and I prefer the model like that.

Most communities have situations where certain people have more power
than others whether officially or in practice, and communities that
can't deal with that have other issues.

In any case, a good way to offset any perceived risk is probably to
have some lively discussion between the mentors and the rest of the
incubator. So, risk mitigated, I say :)

ciao,

Leo

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



Re: Insanity (of the release process)

2009-11-10 Thread Leo Simons
On Tue, Nov 10, 2009 at 4:05 PM, Greg Stein gst...@gmail.com wrote:
 On Tue, Nov 10, 2009 at 04:07, William A. Rowe, Jr. wr...@rowe-clan.net 
 wrote:
 Leo Simons wrote:

 Here's what I understand:

 1) Apache rule: all apache releases must be made by PMCs
 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s
 3) from #1 and #2 it follows that all incubator releases must be made
 by the incubator PMC

 If you see a way to fix this mess, please do. I suspect rule #1 is the
 whopper that is just quite hard to get around and from it follows a
 lot of other mess. I don't know exactly where that rule comes from,
 but it is very old and it has always seemed very solid, too. IANAL.

 Mechanically, it's possible to recharter Incubator PMC as a board committee
 which has the authority to assemble and dissolve fully empowered PPMCs so
 they could begin binding votes from the outset.  The 'P' would change from
 'pre' to 'provisional'.  I don't know if this is what we want to do, or not.

 The Board is trying to move away from Board committees.

 The IPMC is in charge of its operation. It can redefine the rules of
 releases as it pleases. The three +1 rule was developed to show that
 the PMC is in charge of the release, and is therefore legally liable
 for it. The IPMC can do whatever it likes around releases, as long as
 that process specifically claims or disclaims liability.

Ok, that is interesting (and probably more workable than a big reorg).
I still think we should claim liability.

Could we, for example, have a release process that is lazy-by-default
from the IPMC side and still claim that the ASF gets liability?

for example, to release:

1) PPMC must vote for the release according to their rules (which
should at least match the 3 +1 / majority rule requirements)
2) at least one PMC member must vote +1 (usually the mentor)
3) if there are no -1 votes, the PPMC sends the general@ list a
request for a release ACK, after they get that ACK from a PMC member,
they wait for 72 hours, and if there are still no -1s, the release is
approved.
4) if there are any -1 votes, then the rule becomes the normal 3 +1s
from PMC members / majority

Downside:
* more complex
* increased dependency on single person to teach the basics

Upside:
* better reflects relationship between incubator and PPMC
* more responsibility for project
* hopefully fewer stalled releases

thoughts?

Leo

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



Re: [VOTE] Release cassandra 0.4.2

2009-11-09 Thread Leo Simons
+1, nice work folks!

cheers,

Leo

On Fri, Nov 6, 2009 at 5:37 PM, Eric Evans eev...@rackspace.com wrote:

 The Cassandra community voted on and approved the release of Apache
 Cassandra 0.4.2. We would now like to request the approval of the
 Incubator PMC for this release.

 Cassandra is a massively scalable, eventually consistent, distributed,
 structured key-value store.

 Podling vote thread:
 http://www.mail-archive.com/cassandra-...@incubator.apache.org/msg01036.html
 0.4.2 artifacts: http://people.apache.org/~eevans
 SVN tag:
 https://svn.apache.org/repos/asf/incubator/cassandra/tags/cassandra-0.4.2
 Project home: http://incubator.apache.org/cassandra/
 Incubation status: http://incubator.apache.org/projects/cassandra.html

 Note: We've already received two binding +1s during the poddling release
 vote[1][2].

 The vote will remain open for 72 hours (or longer if needed).

 Regards,

 [1] http://article.gmane.org/gmane.comp.db.cassandra.devel/505
 [2] http://article.gmane.org/gmane.comp.db.cassandra.devel/501


 --
 Eric Evans
 eev...@rackspace.com

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



Re: [VOTE] Release Wink 1.0 (RC-5)

2009-11-09 Thread Leo Simons
+1 from me!

cheers,

Leo

On Thu, Nov 5, 2009 at 3:53 PM, Nicholas Gallardo
nickgalla...@yahoo.com wrote:
 The Wink community has voted on and approved the release
 of Wink 1.0 (RC-5).  We would now like to request the
 approval of the Incubator PMC for this release.

 Details of the Wink community vote can be found here:
 http://n2.nabble.com/VOTE-Release-Wink-1-0-RC-5-td3936613.html#a3936613

 The Maven staging area is at:
 https://repository.apache.org/content/repositories/orgapachewink-011/

 The distributions are in:
 https://repository.apache.org/content/repositories/orgapachewink-011/org/apache/wink/apache-wink/1.0-incubating/

 This release is tagged at:
 https://svn.apache.org/repos/asf/incubator/wink/tags/wink-1.0-incubating/  
 (revision 832289)

 The vote will be open here for at least 72 hours.


 Regards,

 -Nick

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



Re: [PROPOSAL][VOTE] Subversion

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 2:26 AM, Niclas Hedhman nic...@hedhman.org wrote:
 On Mon, Nov 9, 2009 at 7:39 AM, Leo Simons m...@leosimons.com wrote:
 PS: +1 to start incubation obviously. The record is 2 weeks set for
 MerlinDeveloper back in 2003...you have 9 days left to try and beat it

Hey, you snipped the smiley! I'm going to stubbornly add it back in:

:)

Smileys matter :)

Now, I intended to convey perhaps a few things:
* I wouldn't mind at all seeing svn graduate a few weeks after it
starts incubation
* there is even reasonable precedent for that kind of speed
* this is not really a very important topic, its a P.S. at most

Obviously I have to work on my communication skills, since it seems
like you read this as something completely different.

snip rant/

 I am ashamed of us...

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

cheers,

Leo

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



Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 1:25 AM, Greg Stein gst...@gmail.com wrote:
 The Apache Incubator is about EDUCATION. It is about TEACHING podlings
 how to work here at Apache.

So what are you teaching with e-mails like this, Greg?

When you disagree with someone, SHOUT a bit and write a long rant?

Or perhaps that using an argument based on authority is a good strategy?

Not very good lessons either. Please kindly step off the soap box...

Thanks,

Leo

PS: For the record I do agree that its not really necessary for
subversion to do an incubation release. I like to think that kind of
stuff is a judgement call for the mentors.

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



Re: [VOTE] Release Wink 1.0 (RC-5)

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 2:23 PM, Nicholas L Gallardo nlgal...@us.ibm.com wrote:

 Thanks Leo, your input is much appreciated.

 In addition to this +1, we received a +1 from Kevan Miller in the Wink 
 community vote. Is that vote transportable here? If so, then we just need one 
 more +1 to release as the vote has already been open for 72 hours.

Yeah that's fine, basically you need:
* at least 3 binding +1s (i.e. binding = from PMC members)
* more binding +1s than -1s
* enough time for people to evaluate the release and vote (72 hours is
just a custom rather than a hard rule, i.e. its nice to take into
account weekends and holidays)

I see Ant just voted, so you're done.

cheers!

Leo

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



Re: Insanity. Apache Incubator should be about education (was: [PROPOSAL][VOTE] Subversion)

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 2:15 PM, Justin Erenkrantz jus...@erenkrantz.com wrote:
 To be clear, it's on the mentors to decide what is applicable and
 necessary for graduation - not the IPMC as a whole.  The IPMC as a
 whole has only two roles: approving a proposal and recommending
 graduation

Also, to be clear, as an IPMC member I spend quite a bit of time with
projects where I am not a mentor, casting (binding) votes on things
like their releases. I will continue to do that, inline with procedure
and policy and common sense. I'm pretty sure you're not really meaning
to question that :)

 I believe it's reasonable to ask for the
 trust that goes with ensuring that we'll be sure to keep Subversion in
 line with Apache practices and procedures - and we will continue to do
 so long after the Incubator has recommended Subversion for graduation.
  =)

You have it!


cheers,


Leo

PS: Just make sure to keep close tabs on the bearded Slovenian ;-)
PPS: for clarity, that was yet another attempt at a bad joke in a post script

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



Re: Insanity (of the release process)

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 3:24 PM, Justin Erenkrantz jus...@erenkrantz.com wrote:
 On Mon, Nov 9, 2009 at 4:03 PM, Leo Simons m...@leosimons.com wrote:
 Also, to be clear, as an IPMC member I spend quite a bit of time with
 projects where I am not a mentor, casting (binding) votes on things
 like their releases. I will continue to do that, inline with procedure
 and policy and common sense. I'm pretty sure you're not really meaning
 to question that :)

 This is where I think the Incubator has gone awry: the claim that you
 are an IPMC member implies that you have merit on a project (in the
 form of a binding vote) is false.

Not merit, just binding vote. I agree that it sucks, but it is not
something where the incubator has gone awry, it has _always_ been
messed up like this.

Here's what I understand:

1) Apache rule: all apache releases must be made by PMCs
2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s
3) from #1 and #2 it follows that all incubator releases must be made
by the incubator PMC
4) a lot of incubating projects have difficulty getting enough +1s, or
even any qualified help sorting out releases
5) from #3 and #4 it follows that a lot of incubating projects get stuck
6) since #5 sucks rather badly, I and many others try and fill this
gap so projects can do some releases, attract some attention, gain
critical mass, and get out of here
7) we have further optimized by making the incubator PMC very very
large and by making it really easy (for ASF members) to get on the
incubator PMC, creating a large pool of potential voters.

If you see a way to fix this mess, please do. I suspect rule #1 is the
whopper that is just quite hard to get around and from it follows a
lot of other mess. I don't know exactly where that rule comes from,
but it is very old and it has always seemed very solid, too. IANAL.

ciao,

Leo

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



Re: Insanity (of the release process)

2009-11-09 Thread Leo Simons
On Mon, Nov 9, 2009 at 4:48 PM, Greg Stein gst...@gmail.com wrote:
 On Mon, Nov 9, 2009 at 11:16, Leo Simons m...@leosimons.com wrote:
...
 Not merit, just binding vote. I agree that it sucks, but it is not
 something where the incubator has gone awry, it has _always_ been
 messed up like this.

 Here's what I understand:

 1) Apache rule: all apache releases must be made by PMCs
 2) Apache rule: a release needs at least 3 binding +1s and more +1s than -1s

 I think those -1s are more where Justin in concerned, rather than a
 bunch of IPMC people jumping in with *support*, providing a +1 where a
 podling doesn't have enough active IPMC members.

 It's the *negative* support -- the hurdles and process and checklists,
 some of which make zero sense for the particular podling. These can be
 just as bad as a bunch of people jumping in with -1 votes.

Yes, it is really bad. But in some cases, what is the alternative?

Given this situation:

*) project has rolled a release and voted on it (+1s everywhere, yay,
cool stuff!)
*) one mentor has voted +1 (well done folks)
*) wait for other mentors, no response
*) the project comes to the general@ list to ask for additional votes
*) I look at the release candidate, and I find a reasonably serious
problem (usually legal crap, for example, let's say it ships LGPL
code)

What would you expect me to do at that point? This is a pretty common
situation, and it sucks to be in it, for everyone.

Some options:

1) don't say anything, let someone else deal with it
2) explain the problem, don't vote. This typically results in the vote
stalling (because no-one else is going to vote +1 after I've pointed
out the problem).
3) explain the problem, vote -1. This typically is enough to kill the
vote (because no-one else is going to vote +1 after I voted -1).
4) don't say anything, vote +1, claim ignorance later if someone
points out the problems.
5) explain the problem, vote +1, ask that the project fixes it later
(but can't claim ignorance...).

a) one of the above, and also go poke the AWOL mentors for not doing
their part (usually followed by mentor resigning, or staying AWOL)

I would like to have option #5 be a realistic option, but it requires
that I have some ability to do a legal risk assessment (and a brief to
take those risks), which I don't. So usually I go for #2 or #3. That's
not me being a pencil-licking process-loving bureaucrat, it is me
trying to make the best of a messed-up situation.

I can try very hard to write my e-mails nicely (and I do), but usually
at this point in the time the EDUCATION is just not well-received
because it is tied to NOT ALLOWING THE RELEASE. There is no carrot,
just a stick.

I don't know what Justin was talking about, but I will bet you that a
significant part of the friction that incubating projects experience
is due to some variant of the above scenario [1].

Can you think of a way to fix the mess?


cheers,


Leo

[1] That, and AWOL mentors

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



Re: [PROPOSAL][VOTE] Subversion

2009-11-08 Thread Leo Simons
On Fri, Nov 6, 2009 at 7:46 PM, Greg Stein gst...@gmail.com wrote:
 On Fri, Nov 6, 2009 at 14:44, Greg Stein gst...@gmail.com wrote:
 All of the existing tags/branches of svn use a tweaked Apache Software
 License, v1.1, and generally have a file header claims a copyright by
 CollabNet.

 trunk is licensed under Apache License, v2, and has a file header as
 defined by the Apache Legal Affairs Committee, though with SVNCorp
 rather than ASF as the rights-holder to the distribution. After we
 import the codebase, we intend to tweak all of the file headers on
 trunk with s/SVNCorp/ASF/.

 To clarify this further: I believe that a release from *trunk* matches
 a standard Apache release.

Well, at the moment, probably not quite. In particular, the incubator
PMC is (in)famous for being very nitpicky (err, careful) about
licensing stuff, it's an enlightening experience to go through I
would say. You might want to have some fun with RAT:
http://incubator.apache.org/rat/

It finds things like this:

* No license header (some examples):
  ./subversion/bindings/swig/ruby/svn/core.rb
  ./tools/bdb/svnfs.py
  ./tools/client-side/server-version.py

* GPL license header (I understand why, but, ugh):
  ./build/config.guess

(and some 600 other complaints most of which are readily ignorable).
The various tools and scripts that say stuff like released under the
same license as subversion could probably do with a little attention
as well.

AIUI it from reading dist.sh those files would go into the released
tarball (I didn't attempt to actually run dist.sh, that'd take me too
much time to try and do properly).

Oh and according to what I read the other day on legal-disc...@a.o the
reference to the license details about the python bindings probably
ought to belong in the LICENSE file not in the NOTICE file.

On Sat, Nov 7, 2009 at 12:07 AM, Greg Stein gst...@gmail.com wrote:
 We're not ready for an alpha, but we could do an internal experimental
 release. I seem to recall seeing that in the docs.

 How about that?

Sure :)


ciao,


Leo

PS: +1 to start incubation obviously. The record is 2 weeks set for
MerlinDeveloper back in 2003...you have 9 days left to try and beat it
:)

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



Re: [PROPOSAL] Libcloud Project

2009-10-27 Thread Leo Simons
On Tue, Oct 27, 2009 at 6:59 AM, Paul Querna p...@querna.org wrote:
 I would like to propose incubating the existing Libcloud project to join the 
 ASF

Cool! I will try to make the time to help out a little; I'm interested
in this space :)

cheers,

Leo

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



Re: [VOTE] Release Wink 1.0

2009-10-27 Thread Leo Simons
Yo. Looking pretty cool! Sorry, but, few tidbits inline...

On Fri, Oct 23, 2009 at 3:53 PM, Nicholas L Gallardo
nlgal...@us.ibm.com wrote:
 The Wink community voted on and approved the release of Apache Wink 1.0. We
 would now like to request the approval of the Incubator PMC for this
 release.

 Podling vote thread:
 http://www.mail-archive.com/wink-...@incubator.apache.org/msg02060.html

 The Maven staging area is at:
 https://repository.apache.org/content/repositories/wink-staging-002/

You're not going to get a +1 from me on all those artifacts - its way
too much work for me to look through all of them [1]. I looked just at
the distributions...

 The distributions are in:
 https://repository.apache.org/content/repositories/wink-staging-002/org/apache/wink/apache-wink/1.0-incubating/

The source release has a LICENSE and a NOTICE file that indicates it
contains a bunch of stuff it does not actually contain. AFAICS it
should simply have a LICENSE that is just the Apache License and a
NOTICE file that has just our standard license header.

The NOTICE file for the binary release should include only those
notices that are actually required by the included library
dependencies, and they should reproduce the exact text of those
notices. For example, the slf4j notice line should not be there since
slf4j does not require it.

cheers,

Leo

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



Re: [VOTE] Release Wink 1.0

2009-10-27 Thread Leo Simons
On Tue, Oct 27, 2009 at 4:45 PM, Bryant Luk bryant@gmail.com wrote:
 The source release has a LICENSE and a NOTICE file that indicates it
 contains a bunch of stuff it does not actually contain. AFAICS it
 should simply have a LICENSE that is just the Apache License and a
 NOTICE file that has just our standard license header.

 I think you're suggesting a different LICENSE/NOTICE for source versus
 binary distributions.

Yep, I see how it looks like thatthough maybe I'm _really_
suggesting a source-only distribution :-)

Look, the general rule is quite simple: LICENSE files MUST contain all
the license information that applies to an artifact, and SHOULD
contain only the license information that applies to that artifact.
Similarly, NOTICE files MUST contain all the notices that apply to an
artifact, and SHOULD contain only the notice information that applies
to that artifact.

Whenever you violate that SHOULD, you are turning lazyness/sloppiness
into a mess for your users.

For example, with this current wink distribution, you are (appear to
be?) passing on a lot of CDDL obligations down to wink users, which is
annoying to users that care about such things. If all your user wants
to do is copy/paste the glue code from GzipHandler, that's a rather
heavy license to wade through. Similarly, that user of that
GzipHandler code now has to copy/paste the entire contents of the
NOTICE file.

Do you really want to place a burden on your users like that?

 I did some random checking looking at some
 source versus binary Apache project distributions (incubator and
 non-incubator) and as far as I can tell, they kept their same LICENSE
 and NOTICE files even though they were not re-distributing the
 dependency binaries in the source archive.

 Don't mean to say we should just follow the crowd, but I don't think
 this is standard practice unless another thread has a viewpoint on
 this.

Unfortunately, most apache projects are not as good at following
policies as they should be, and most engineers (including me! :-) )
are not nearly as good at applying legal rules and guidelines as they
should be.

http://www.apache.org/dev/release.html#license

What Are The Requirements To Distribute Other Artifacts In Addition
To The Source Package?
...
Nothing in this section is meant to supersede the requirements defined
here and here that all releases be primarily based on a signed
source package.

 The NOTICE file for the binary release should include only those
 notices that are actually required by the included library
 dependencies, and they should reproduce the exact text of those
 notices. For example, the slf4j notice line should not be there since
 slf4j does not require it.

 I see varying degrees of attribution to slf4j in other Apache
 (incubating and non-incubating) projects (some have none, some have a
 line).  The slf4j line was kept from the Wink 0.1 release.  IMHO, this
 is not a release blocker, but we can remove it in a future release if
 it is the right thing to do.

Fortunately we have quite a clear rule on this topic these days, so no
opinions are necessary:

http://www.apache.org/dev/release.html#notice-content

What Content Is Appropriate For The NOTICE File?
...
Only mandatory information required by the product's software
licenses. Not suitable for normal documentation.

For background color, here's an earlier thread on this list (which is
where I learned about the existence of that clear rule):

http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e


cheers,


Leo

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



Re: [VOTE] Release Wink 1.0

2009-10-27 Thread Leo Simons
On Tue, Oct 27, 2009 at 9:23 PM, Bryant Luk bryant@gmail.com wrote:
 Thanks for the links.  One general comment I have is that I understand
 this is part of the incubation process (and no offense intended to Leo
 since obviously taking energy and time for this) but if I can't look
 and see if other Apache projects are doing things the right way, I
 think we should have more examples of what goes in the NOTICE and
 LICENSE files and points out licenses/situations/projects/wording that
 require that they be put in LICENSE/NOTICE files and not.  It seems to
 be a common sticking point on this list for incubator projects.  I
 would put up a patch for the website but obviously I am still
 learning.

Yeah it's painful isn't it? How to get the legal stuff right remains
surprisingly difficult after all these years. Help making it easier is
always very welcome! [1]

 Look, the general rule is quite simple: LICENSE files MUST contain all
 the license information that applies to an artifact, and SHOULD
 contain only the license information that applies to that artifact.
 Similarly, NOTICE files MUST contain all the notices that apply to an
 artifact, and SHOULD contain only the notice information that applies
 to that artifact.
...
 just out of curiosity, how does this apply with
 Section 4.4 of the Apache license?

Ooh, you're getting into this now, eh? Good :-)

IANAL, I don't really know. I suspect the precise nitty-gritty legal
case is actually a little more lenient than our policies. As in, even
if legally all is sound whatever way, our release policies try to
enforce some additional clarity and consistency to make things as easy
as possible for the user.

 http://www.apache.org/dev/release.html#notice-content

 What Content Is Appropriate For The NOTICE File?
 ...
 Only mandatory information required by the product's software
 licenses. Not suitable for normal documentation.

 For background color, here's an earlier thread on this list (which is
 where I learned about the existence of that clear rule):

 http://mail-archives.apache.org/mod_mbox/incubator-general/200909.mbox/%3cf767f0600909090615t6582bfd1m36e4d8abe1392...@mail.gmail.com%3e

 Thanks for the link to the information.  However, I would like to get
 a consensus to make sure that we should not be attributing SLF4J at
 all.

In an artifact that does not contain SLF4J (like your source distro),
do not attribute (at all).

In an artifact that does contain SLF4J (like your binary distro),
well, see https://issues.apache.org/jira/browse/LEGAL-59 to figure out
that no-one is really that sure. If you look at HTTPD, it has the
expat license (which is MIT) inside its LICENSE file:

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE

but no mention about it in its NOTICE file:

  http://svn.apache.org/repos/asf/httpd/httpd/trunk/NOTICE

Is that ok? Probably. Is that the *only* right way? Not so sure. My
personal rule is that when in doubt do what Roy voted +1 on is not a
bad strategy when it comes to licensing stuff [2].

 which I believe have been used in recent release votes.  I'm fine with
 deleting/re-wording the attributions (afterall, less for us to
 maintain) and hope not too troublesome but I would like some consensus
 to make sure that this and future releases are right (without quotes
 ;-) ).

Please note, I didn't actually vote on the release, I just pointed out
a few things that probably ought to change. I didn't vote because I
don't want to go and review all those very many binaries (or the build
process that creates them) and I'm not familiar enough with the
codebase to somehow know that all those binaries are somehow ok. If
I had thought these minor tidbits that I raise are enough to actually
vote -1, I would've made that clear, sorry that it wasn't.

Even if I _did_ vote, releases are majority votes, and 2 +1 beats a
single -1. Its just you need 3 votes.

In other words, all you need is one more +1 :)


ciao,


Leo

[1] Oh, and for reference, my first encounter with apache licensing
policy was when someone had imported the entire codebase of some
non-apache project into apache CVS, stripped all the license headers
including copyright info, and replaced them with apache ones. We got a
polite note from the original projects' owners to fix that pretty
please. We got spanked around pretty bad for that one at the following
apachecon, and then we all had lots of beer :)
[2] there is another rule, have whatever Greg is having, though less of it

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



Re: [VOTE] Release cassandra 0.4.0-rc2

2009-09-16 Thread Leo Simons
On Mon, Sep 14, 2009 at 6:05 PM, Leo Simons m...@leosimons.com wrote:
 On Mon, Sep 14, 2009 at 4:46 PM, Eric Evans eev...@rackspace.com wrote:
 I'm curious though, when you say ...which makes me whinge just enough
 to not give a +1, is that hypothetical, or is there feedback that we
 could incorporate so that you would actually vote for our release?

 Nah, it means just fix your open jira eventually and lobby some other
 IPMC members for +1s...just I don't have more time to look at things
 atm to convince myself all is fine.

Had a better look. It does all seems pretty obvious which code comes from where.

So, +1 from me.

cheers,

- Leo

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



Re: [VOTE] Accept Aries proposal for incubation

2009-09-16 Thread Leo Simons
On Wed, Sep 16, 2009 at 1:09 PM, Jim Jagielski j...@jagunet.com wrote:
 On Sep 16, 2009, at 4:32 AM, Niall Pemberton wrote:
 On Tue, Sep 15, 2009 at 11:43 PM, Niclas Hedhman nic...@hedhman.org wrote:
 On Tue, Sep 15, 2009 at 9:07 PM, Jim Jagielski j...@jagunet.com wrote:
 After much thought, I am voting -1 for 1 main reason.

 1: From the get-go, this appears headed towards an umbrella project.
  Too many ways to justify yeah, this belongs here and far too
  few ways to justify nope, this doesn't quite fit in. So
  whether TLP or part of Felix (as was the discussion), this appears
  too comprehensive.

 This comment surprised me enough to read this proposal again, and I
 have to agree with Jim. On one hand, the proposal starts out to speak
 of current and future EEG specifications, but then becomes very blur
 of what that really means. Components, not solutions, not a server,
 not a framework, but components could as Jim points out mean
 everything (or at least anything one can stick in a Bundle in OSGi
 lingo).

 Does it warrants a -1? Yes, I think it does. But considering how many
 PMC members are on the roster, I doubt it will stop anything.

 -1 from me, until I see a limitation in scope that is describable...
 I like the intent, but not the formulation. Look at your current
 plans, distill the essence and put that in the proposal.

 IMO this is more a graduation issue, rather than something that should
 prevent entry to the incubator - since thats when destination is
 decided. There are many possible outcomes from that - perhaps some
 parts will go to felix and others to a new TLP(s) - but I say lets see
 how it works out during graduation rather than shooting it down now.

 I agree that the rubber hits the road when graduation, and when there
 is a resolution before the board to make this a TLP. However, my
 thoughts are that without this concern front-and-center from the get-go,
 the podling runs the risk of hitting this roadblock right at the end,
 at which point who knows how much impact this may have on it... In other
 words, if a podling umbrella attempts to graduate into a TLP umbrella, it
 will likely be shot down. Do we really want to wait until the end to
 address this once and for all?

I understand and subscribe to the concern. However,

1) it sounds like most of the Aries folk are aware of the need to
balance this kind of thing out a bit
2) not all umbrellas are all bad (some projects with pretty broad
scopes and many subprojects AND healthy communities AND good oversight
include geronimo, maven, felix, hadoop, commons, and others)
3) I think the main issue is the sweeping statements in the proposal
which is typical of java framework land, but in practice I suspect the
actual project focus is pretty narrow, people just don't really know
how to express that yet
4) given #3, I suspect that as the project matures its scope
definition is easier so that we'll see a nice and specific board
resolution eventually

So I'm personally rather optimistic that things will work out ok, and
so here's my +1 to the proposal.

cheers,

- Leo

 PS: BTW, I think it's a great proposal and podling and technically am a big
    +1 on it. My only concern is lack of directed focus...

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



Re: [VOTE] Release cassandra 0.4.0-rc2

2009-09-14 Thread Leo Simons
On Mon, Sep 14, 2009 at 4:06 PM, Eric Evans eev...@rackspace.com wrote:
 On Mon, 2009-09-14 at 08:52 +0100, sebb wrote:

 The source archive contains 3 files that are not in SVN:

 Cli.tokens
 CliLexer.java
 CliParser.java

 These are generated files.

 Either store the files in SVN and release them, or remove them from
 the release.

 I think everyone sort of forgot about these, (there is an open issue on
 this, CASSANDRA-316); is this considered blocking?

Hrmpf, not sure. Since they're in a gen-java directory its pretty
obvious what the story with them is, but CLILexer.java also misses a
license header, which makes *me* whinge just enough to not give a +1,
but that's also because I don't know much about the provenance of the
codebase. You might get +1s from other folks, you did before, the
files are there in the 0.3.x :)

- Leo

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



Re: [VOTE] Release cassandra 0.4.0-rc2

2009-09-14 Thread Leo Simons
On Mon, Sep 14, 2009 at 4:46 PM, Eric Evans eev...@rackspace.com wrote:
 I'm curious though, when you say ...which makes me whinge just enough
 to not give a +1, is that hypothetical, or is there feedback that we
 could incorporate so that you would actually vote for our release?

Nah, it means just fix your open jira eventually and lobby some other
IPMC members for +1s...just I don't have more time to look at things
atm to convince myself all is fine.

ciao,

- Leo

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



Re: [VOTE] Release Apache Empire-db 2.0.5-incubating (rc5)

2009-09-13 Thread Leo Simons
On Sun, Sep 13, 2009 at 7:38 PM, Francis De Brabandere
franci...@gmail.com wrote:
 I added myself a while ago to the keys in our
 repo/trunk/tools/KEYS.txt. Should we move that file to trunk and
 publish it in the dist?

I would say so. The advantage of having the KEYS file also in the
/dist/ is that it'll be close to where its used. The advantage of SVN,
well that should be obvious :)

 also from here:
 http://incubator.apache.org/guides/releasemanagement.html#distribution-checksums-sigs
 that the KEYS file contains the public key. (Storing public keys in a
 KEYS file is recommended but is not policy.)
 further my public key is available here:
 http://pgp.mit.edu:11371/pks/lookup?search=francisdb

Yeah, publishing a KEYS file by itself does not really provide the end
user with much additional guarantee beyond a SHA1 hash of the file
(which is why imagine KEYS files are not policy). The thing that
matters much more is linking up to the apache web of trust:

  http://www.apache.org/dev/release-signing.html#web-of-trust

For similar reasons it is also good if multiple people sign releases -
more trust :)


cheers,


- Leo (who in java land already considers it a win these days when
people opt out of auto-downloading from ibiblio.org, so personally no
longer bothers with GPG)

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



Re: Review of cassandra NOTICE and LICENSE requested.

2009-09-09 Thread Leo Simons
On Tue, Sep 8, 2009 at 10:28 PM, sebbseb...@gmail.com wrote:
 On 08/09/2009, Eric Evans eev...@rackspace.com wrote:
...
 Does the release actually *include* JUnit, or is that only used for testing?
 If so, then it should not be the in the NOTICE file, nor in the binary 
 release.

Even if it is not in the release I believe there is nothing wrong with
putting an acknowledgment in the NOTICE file. (putting terms in the
LICENSE file that do not apply is bad, though).

 Is ANTLR actually needed at run-time, or is it only needed for
 building the code?
 I'm not sure whether it needs to be mentioned in NOTICE if it is only
 used at build-time.
 It should not be in the binary release if it's not needed at run-time.

Same comment -- it shouldn't hurt to have it in NOTICE.

ciao,

- Leo, who often gives credit to his stuffed animal wombat in NOTICE files

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



minimal NOTICE files (was: Re: Review of cassandra...)

2009-09-09 Thread Leo Simons
(dropped cassandra-dev)

On Wed, Sep 9, 2009 at 10:44 AM, sebbseb...@gmail.com wrote:
 On 09/09/2009, Leo Simons m...@leosimons.com wrote:
 Even if it is not in the release I believe there is nothing wrong with
  putting an acknowledgment in the NOTICE file. (putting terms in the
  LICENSE file that do not apply is bad, though).

 I think it's confusing, and NOTICE is supposed to be as minimal as possible.

And so indeed it says in our draft release management guide since a few weeks:

  
http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?r1=805581r2=805940

  The NOTICE document is for additional copyright and attribution statements
  those licenses may require. A typical NOTICE document at a minimum
  includes a copyright and attribution statement for The Apache Software
  Foundation. Nothing else belongs in the NOTICE document.

Joe obviously agrees :)

The important new (to me) bit is Nothing else belongs in the NOTICE
document. Someone want to explain me the background for that?

From my perspective, I've always thought it nice/polite/good karma to
acknowledge significant giants on whose shoulders you are standing.
It's probably best not to go overboard, but expressing 'Built with
Ant' or 'Tested with JUnit' or 'ANTLR for code generation' always
seemed a cool kind of attribution to me -- especially since the legal
status of the NOTICE file means that the expression will stay around.

cheers,

- Leo

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



Re: minimal NOTICE files (was: Re: Review of cassandra...)

2009-09-09 Thread Leo Simons
On Wed, Sep 9, 2009 at 2:00 PM, Leo Simonsm...@leosimons.com wrote:
 (dropped cassandra-dev)

 On Wed, Sep 9, 2009 at 10:44 AM, sebbseb...@gmail.com wrote:
 On 09/09/2009, Leo Simons m...@leosimons.com wrote:
 Even if it is not in the release I believe there is nothing wrong with
  putting an acknowledgment in the NOTICE file. (putting terms in the
  LICENSE file that do not apply is bad, though).

 I think it's confusing, and NOTICE is supposed to be as minimal as possible.

 And so indeed it says in our draft release management guide since a few weeks:

  http://svn.apache.org/viewvc/incubator/public/trunk/site-author/guides/releasemanagement.xml?r1=805581r2=805940

  The NOTICE document is for additional copyright and attribution statements
  those licenses may require. A typical NOTICE document at a minimum
  includes a copyright and attribution statement for The Apache Software
  Foundation. Nothing else belongs in the NOTICE document.

 Joe obviously agrees :)

 The important new (to me) bit is Nothing else belongs in the NOTICE
 document.

Its new in this (informative) guide only, has been (normative) ASF
policy for a while:

  http://www.apache.org/dev/release.html#notice-content

Quite clearly: Only mandatory information required by the product's
software licenses.

 Someone want to explain me the background for that?

I still want to know :)

- Leo

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



Re: Review of cassandra NOTICE and LICENSE requested.

2009-09-09 Thread Leo Simons
On Wed, Sep 9, 2009 at 10:44 AM, sebbseb...@gmail.com wrote:
 On 09/09/2009, Leo Simons m...@leosimons.com wrote:
 On Tue, Sep 8, 2009 at 10:28 PM, sebbseb...@gmail.com wrote:
  Does the release actually *include* JUnit, or is that only used for 
  testing?
  If so, then it should not be the in the NOTICE file, nor in the binary 
  release.

 Even if it is not in the release I believe there is nothing wrong with
  putting an acknowledgment in the NOTICE file. (putting terms in the
  LICENSE file that do not apply is bad, though).

 I think it's confusing, and NOTICE is supposed to be as minimal as possible.

For the record, I was wrong, and here's the policy statement that
confirms what Sebb said:

http://www.apache.org/dev/release.html#notice-content

What Content Is Appropriate For The NOTICE File?

Read [http://apache.org/legal/src-headers.html#notice].

Only mandatory information required by the product's software
licenses. Not suitable for normal documentation.

cheers,

- Leo

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



Re: [VOTE] Release Apache Incubator Shindig version 1.1-BETA2

2009-09-08 Thread Leo Simons
://issues.apache.org/jira/browse/SHINDIG-1134] -
   JsonProperty Annotations not working properly for both
   marshalling/unmarshalling

 Improvement

   - [SHINDIG-678 https://issues.apache.org/jira/browse/SHINDIG-678] -
   Autoloader chain
   - [SHINDIG-822 https://issues.apache.org/jira/browse/SHINDIG-822] -
   Remove caja's dependence on opensocial feature
   - [SHINDIG-855 https://issues.apache.org/jira/browse/SHINDIG-855] -
   Enum value should be checked if it is empty
   - [SHINDIG-856 https://issues.apache.org/jira/browse/SHINDIG-856] -
   Defaults to cont...@type=html when omitted
   - [SHINDIG-857 https://issues.apache.org/jira/browse/SHINDIG-857] -
   public key id param key should be xoauth_public_key
   - [SHINDIG-1107 https://issues.apache.org/jira/browse/SHINDIG-1107] -
   Clean up shindig dependencies
   - [SHINDIG-1135 https://issues.apache.org/jira/browse/SHINDIG-1135] -
   Bump ehcache to 1.6.1




-- 
cheers,

Leo Simons
--
http://lsimons.wordpress.com/

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



Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

2009-09-02 Thread Leo Simons
On Tue, Sep 1, 2009 at 3:38 PM, Jeremy Hugheshugh...@apache.org wrote:
 We appreciate any feedback and comments on the proposal.

* Any chance of one or two of the other ASF members involved also
stepping up as a mentor?

* Projects that consist of groups of components often have some
problems maintaining sufficient cohesion as a community. I hope you
guys will give that the specific attention it probably requires and
tune the project charter appropriately.

* I have no problems with having multiple OSGi projects at apache as
long as they're all healthy communities and they play nice with each
other.

(...)

Of course the play nice part is interesting here -- I'm frowning a
bit at seeing this how-to-interact-with-felix discussion kick off with
a pretty much finished proposal going to the incubator. Surely the
conversation can go a bit differently? For example maybe you could've
approached felix first and discussed seeding the project with some of
the parts-of-felix (along with developers) that are argued to need an
independent-from-felix re-brand? Maybe you can take a step back
together even now and see if something like that might make sense? Or,
maybe you can co-operate on a shared registry / website of the OSGi
components in all the different projects so that people visiting
apache.org are not confused? Or something like that?

I hope you guys find a way to reduce the friction and co-operate;
having what looks like battle lines being drawn up at the start of
incubation is _not_ a good thing.

I do expect to see that felix/aria conversation resolved clearly one
way or another before the proposal goes up for a vote. Even if the
resolution is there will significant charter overlap and duplication
of effort and code and probably little committer overlap between the
communities because we disagree on how to do things then I'd like to
see that clearly spelled out.


cheers,


- Leo

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



Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

2009-09-02 Thread Leo Simons
On Wed, Sep 2, 2009 at 4:29 PM, Guillaume Nodetgno...@gmail.com wrote:
 We have in this proposal a lot of people who are not felix committers and
 who are not even apache committers at all.

 They want to work on some code and create a community around it.  The way
 the ASF works means that the incubator is the right place to do so.

Sidenote: not necessarily always the *only* possible right place.

A PMC can easily grant lots of access to its repositories to existing
committers. For example, the gump repo is open to all ASF committers,
and the excalibur repo is open to cocoon, james and turbine
committers.

Adding new committers obviously has a few more barriers, but those
barriers are not all bad. It can also be quite healthy for people new
to apache to submit patches that are committed by those people that
are already apache committers; I believe its often a faster way to
learn apache-style processes than the sort-of sandboxing that
happens in incubator. In fact, Harmony started with 0 committers (and
lots of contributors) and the community dynamic that resulted from
that approach was actually quite a good one, and I don't think it
meant lost velocity in the end either.


cheers,


- Leo

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



Re: incorrect terminology: lead developers

2009-08-11 Thread Leo Simons
On Tue, Aug 11, 2009 at 4:40 AM, Greg Browngkbr...@mac.com wrote:
 If I can attempt to summarize, there is a difference between the *concept*
 of a leader and the *title* of a leader here at ASF (please correct me if I
 am wrong).

Correct! You missed the rationale in the summary, though :-)

* There is a goal that leadership comes from multiple people (and also
not from people at a single company, and only as allowed by the
community, and ...).
* There is a goal that who lead can change over time.
* There is a goal that it is easy for new people to feel included and
get involved.
* There is quite a bit more emphasis on
leadership-that-is-not-software-development at the ASF and especially
during incubation.

And such and so forth. The terminology (not) in use tends to help just
a little bit to work towards those goals.

...just a little bit, though, most of it is still up to you! :)


cheers,


- Leo

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



Re: XAP?

2009-08-10 Thread Leo Simons
On Mon, Aug 10, 2009 at 4:07 PM, Jukka Zittingjukka.zitt...@gmail.com wrote:
 So who's going to do what about XAP?

 I tried understanding the related threads, but I couldn't figure out
 why it's so complicated. If it were up to me, I'd simply follow [1].
 In fact, unless someone takes some action on XAP by the end of this
 month, I'll do just that based on the already passed suspension vote.

 [1] http://wiki.apache.org/incubator/RetiringPodlings

Go for it +1; you shall be owed some beer :-)

cheers,

- Leo

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



Making some thrift releases

2009-08-04 Thread Leo Simons
Hey thrift folks,

Someone just pointed out

  http://incubator.apache.org/thrift/download/

I'm afraid that's not exactly what we'd like to see. Can you
please spend some time reviewing the pages at

  http://incubator.apache.org/guides/releasemanagement.html

? It would be really good if y'all could expend the effort to make a
release [1].

((A release in the apache sense is an important milestone. Among other
things it implies a whole bunch of legal checking has been done, i's
are dotted and t's are crossed. The apache thrift project and the
responsible PMC (until you graduate, that's the incubator PMC) make an
explicit decision (through voting) to release a piece of software to
the general public. Its a vital step in the lifecycle of any apache
project. check out from SVN here is not really what we're looking
for, and clone this non-ASF-hosted git repository is a bit worse
than that.))

Please check in with your incubator mentors if you need any more help
figuring out what to do. Thanks!!

cheers,

- Leo

PS: I'm not on thrift-dev@; feel free to CC gene...@incubator if you
want a response from me! :)

[1] at a very minimum you really need appropriate disclaimers, i.e. stuff like

Apache Thrift is an effort undergoing incubation at The Apache
Software Foundation (ASF). Incubation is required of all newly
accepted projects until a further review indicates that the
infrastructure, communications, and decision making process have
stabilized in a manner consistent with other successful ASF projects.
While incubation status is not necessarily a reflection of the
completeness or stability of the code, it does indicate that the
project has yet to be fully endorsed by the ASF.

on the download page and the home page

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



Re: [Proposal][Vote] Traffic Server

2009-07-03 Thread Leo Simons
On Fri, Jul 3, 2009 at 12:03 AM, Leif Hedstroml...@yahoo-inc.com wrote:
 As you know, we've been preparing our proposal to submit Traffic Server to
 the Incubator for a few weeks now. With the help from our champion (thanks
 Doug!), and the entire Incubator community, it's my pleasure to submit a
 request for Traffic Server to be accepted into the Incubator.

+1 welcome on board!

- Leo

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



Re: Community readiness-when does it show?

2009-06-24 Thread Leo Simons
On Tue, Jun 23, 2009 at 11:08 PM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
 If a community meets all the criteria, but hasn't discovered a new
 committer (or two) by itself, is the community ready for graduation?

Potentially, yes. Likely, no :-)

 If not, how can we—mentors— nudge the community to focus on this
 thing, without it becoming an exercise in checking the check marks?

You can do something like this every quarter or so:
---
To: $podling-priv...@incubator.apache.org
Subject: any new committer material?
(...)
Has anybody identified any contributors that they think might be ready
for committer-ship? Also are there any people you imagine might be
ready soon if they continue their current contributions?
(...)
---

Really no need to refer to obligation or process or checkboxes.

Simply asking the question will make people think about it. For many
developers its still a bit of scary thought that they have to evaluate
others in this way, but it is something you learn quickly. In my
experience the first time you try this, the apache newbies in the
group usually won't really speak up, but among mentors you can still
have those kinds of conversations on the mailing list. Teach through
example.

I distinctly remember a thread along those lines on the harmony
mailing list every other month or so, and I'd say that it worked very
well.

Come to think of it, I think harmony started with _just_ mentors on
the PPMC, and no other committers. That worked out well -- because the
community got into a pattern of growth immediately -- just about
everyone on the PPMC got there by explicitly getting voted onto it.

Another thing that can work is to lower the barrier and try and
allow for the babiest of steps. For example you could have a
ppmc-private potential-committer-watchlist.txt file in SVN which
people can edit to add their thoughts on who is worth watching,
which is a bit less of a statement than ooh this person should become
a committer so its easier to say. You'll probably quickly see a
piling on where other people will agree with such thoughts, slowly
dissipating the vacuum and re-inforcing each others confidence in
people.

Of course, you do need active contributors in the first place to add
in. The evangelism and outreach parts of community building take more
effort. I like to follow the Henri school of community building --
most important is to talk about what you're doing. You might even want
to do what feels like over-talk. Example:

http://blog.generationjava.com/roller/bayard/entry/first-work-of-the-vacation-commons-cli-12

Write things in blogs, in comments on blogs, in forums, on twitter, on
community mailing lists, on your own mailing lists. Etc etc.

Encouraging outreach behavior is harder, and I think the people that
do it really well are also rare. Harmony as an example again had some
very active mentors that did a lot of that stuff, and the community
watched and adopted the successful behavior. Wicket was fortunate
enough to have a very energetic leader already and so I think it
didn't really much nudging :-)

sorry for the rant I hope it helps you anyway :-)

cheers,

- Leo

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



Re: [VOTE] Release Apache Incubator Shindig version 1.0 (RC4)

2009-06-18 Thread Leo Simons
On Thu, Jun 4, 2009 at 12:28 PM, Ian Bostoni...@tfd.co.uk wrote:
 Please review and vote on approving the first release of Apache
 Shindig version 1.0-incubating.
...
 Proposed release:
 https://repository.apache.org/content/repositories/shindig-staging-002//org/apache/shindig/shindig/1.0-incubating/

+1 (binding, IPMC) from me.

sorry for the delay, have been a tad busy lately :-)

cheers,

- Leo

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



Re: [Proposal] Traffic Server

2009-06-18 Thread Leo Simons
Hi,

 We already got two new mentors signed up (thanks to your posts to the httpd
 devel list I think). So, we're up to three now, how many do we need to be
 considered for a vote?

3 mentors is usually considered enough :)

 Is there anything else missing?

Nope, it looks like you have your ducks in a row! +1 from me.

Sounds like the an obvious/interesting challenge will be to try and
attract some contributors from outside of yahoo -- with such a big
(and probably sophisticated =) ) code base I imagine it might be hard
for newbies to get up to speed...then again I can also imagine more
than a few people would be interested in this stuff :)


cheers,


- Leo

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



Re: [VOTE] Release Pivot 1.2 RC3

2009-06-18 Thread Leo Simons
On Tue, Jun 9, 2009 at 2:48 AM, Todd Volkerttvolk...@gmail.com wrote:
 The Pivot community voted on and has approved a proposal to release Apache
 Pivot 1.2 Release Candidate 3. We would now like to request the permission
 of the Incubator PMC to publish the artifacts on the Pivot download page.
...
 http://people.apache.org/~tvolkert/dist/pivot/v1.2-rc3/.

+1 from me.

cheers!

- Leo

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



Re: [VOTE] Approve the release of Shindig Incubator 1.0

2009-05-25 Thread Leo Simons

On May 23, 2009, at 10:50 PM, Santiago Gala wrote:

Is it that we have identified a new issue that actually affects
_all_ Maven based releases, not just Shindig?


No not necessarily. You can use maven to produce binary releases that
have all the required legal details inside of them; it just isn't
automatically taken care of.


Not that I want to mud the waters even more,


you failed :)

but how does the word binary vs source affects the code that is  
both binary and source?


N/A.

I'll try and be even more specific - the point _in this case_ is that  
by default a _maven-style_ binary release will _typically_ embed third- 
party dependencies in the binary distribution package (i.e. for  
shindig the .war contains non-apache .jars), while a _maven-style_  
source release will _typically_ embed only things already found in the  
source repository (i.e. for shindig third party .jars are not included  
in the source tarball).



Substantial parts of shindig are ecmascript and php. In fact a release
of shindig-php that does not contain *any* binary that is not source  
at

the same time is a very realistic thought.

Would this hypothetical release be considered source or binary?


Source.

I ask because it is clear that there are different requirements to  
both.


Not really (from the legal side) -- released artifacts have to contain  
all the right legal details in all the right places for everything  
that they contain. This is always true - whether the release is  
binary, source, runnable source, mixed or yo mamma's.


cheers,

- Leo



smime.p7s
Description: S/MIME cryptographic signature


Re: [PROPOSAL] Graduate Apache Sling as Top Level Project

2009-05-25 Thread Leo Simons

On May 25, 2009, at 9:31 AM, Felix Meschberger wrote:

The Sling podling has voted on asking the Incubator PMC to support its
graduation as a top level project.


Enthousiastically and confidently +1.

All the best!

 - Leo



smime.p7s
Description: S/MIME cryptographic signature


Re: [VOTE] Approve the release of Shindig Incubator 1.0

2009-05-23 Thread Leo Simons

On May 21, 2009, at 1:03 PM, Upayavira wrote:

I am a mentor for Shindig, but I am aware of a weaknesses of mine as a
mentor is that I'm not that knowledgeable or experienced with the
release process at Apache, and therefore have not followed this thread
in detail, which I really should have.

It seems that this release is stalled, but I am not entirely sure how,
and want to understand this better.


Sebb has raised some valid concerns; some were addressed, some are  
left; shindig has to address those concerns, but up new artifacts, and  
then ask for another vote.


The thing that confuses me is that, as I understand it, Shindig is  
just

using Maven to produce its artefacts (binary jars as a convenience to
users). If that is the case, surely those artefacts are structured in
the same way as other Maven based releases from other projects?


The apache-hosted maven-based projects I've checked (including maven  
itself!) only officially release source archives. As Jason pointed  
out, this is now pretty easy to do in accordance with policy, thanks  
to some plugin work David did quite a while ago.


To release binary archives that embed third-party dependencies is more  
work. The LICENSE and NOTICE file have to have details about  
dependencies, if those dependencies are in the binary distributions.  
With maven, automatic resolution of transitive dependencies is  
possible, which shindig relies on. However, there is not automatic  
resolution of licensing details, which makes crossing the legal t's  
and dotting the legal i's quite a chore.


Is it that we have identified a new issue that actually affects  
_all_ Maven based releases, not just Shindig?


No not necessarily. You can use maven to produce binary releases that  
have all the required legal details inside of them; it just isn't  
automatically taken care of.



If so, how can we both unblock the Shindig release


Shindig can choose to either do the work to get the legal bits and  
pieces related to their dependencies sorted out and produce binary  
releases that follow the rules, or they can opt to do a source-only  
release.


and also get this issue resolved in such a way as it covers all  
Maven based projects?


To solve this issue in a way that covers all maven-based projects  
requires making sure that all required legal details and notices are  
put inside the maven repositories in a machine-processable manner, for  
all artifacts, and then modifying a maven plugin or two to aggregate  
those details automagically, and then to make use of that plugin  
everywhere. In other words, that's a few months of work at the least :-)


cheers,

- Leo



smime.p7s
Description: S/MIME cryptographic signature


Re: Sending CouchDB Software Grant?

2008-03-01 Thread Leo Simons
That should be fine! As far as I know, the ASF has just the one fax number.

(An alternative to faxing is printing, filling out, dating and
signing, then scanning, and then emailing the resulting scanned image
to [EMAIL PROTECTED] Another alternative is using snail mail.)

cheers,

- Leo

On 2/28/08, Damien Katz [EMAIL PROTECTED] wrote:
 I'm hoping someone who's knowledgeable in such matters to confirm if
  I've done this correctly. My understanding is we CouchDB contributors
  need to sign and send a Apache software grant form:
   http://www.apache.org/licenses/software-grant.txt

  But I wasn't really sure how with this form and where to send it, but
  for the Representing blank, I wrote Self and for the List of
  software and other intellectual property covered by this agreement:
  area I wrote CouchDB 0.7.2 (or more recent version).

  I didn't see instructions where to fax it, so I faxed it to
  919-573-9199 (same place you fax ICLAs).

  Anyway, I'm not sure I've done things correctly here, so any pointers
  would be much appreciated. Thanks!

  -Damien

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




-- 
cheers,

Leo Simons
--
http://lsimons.wordpress.com/

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



Re: TripleSoup and CouchDB

2008-02-23 Thread Leo Simons

On Feb 21, 2008, at 7:36 PM, Noel J. Bergman wrote:
Now that CouchDB has been brought into the Incubator, is there  
anything that

the old TripleSoup project would have to offer?


Hmmmh? Like what?

TripleSoup code is mostly in C, for serving up triples, using an  
apache module for HTTP/REST.


CouchDB code is mostly in Erlang (right?), for serving up document- 
based stuff, using MochiWeb (right?).


The projects are similar in that they are both infastructure for  
building web stuff, but AFAICS everything else about them is just  
about completely different, most importantly the underlying vision.


The TripleSoup-ish semantic web vision is all about a world with  
*less* documents, instead going towards a more granular triples- 
based web, whereas CouchDB is firmly document-based. RDF mandates  
URIs whereas CouchDB mandates only strings, but suggests UUIDs. Etc etc.



  Would the people who were
interested in TripleSoup be interested in participating on CouchDB?


I wouldn't know...but based on the above, probably not so much :-)

cheers!

- Leo


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



Re: Subversion vs other source control systems

2008-02-17 Thread Leo Simons

On Feb 17, 2008, at 4:51 PM, Noel J. Bergman wrote:
Most of the use cases mentioned so far for git, including some  
where people are using it on top of SVN with ASF projects, run  
counter to ASF principles.


Let me fix that:

  Use case: work on apache project while on plane
  ---
  * export list of jiras of your favorite ASF project into spreadsheet
  * sync project repo to your laptop
  * get on a plane for 14 hours
  * slave away at the bug list, fixing a bunch
* create one patch per bug, with a good commit message, referring
  to the bug report, and commit locally
  * get off the plane
  * get online
  * sync project repo to your laptop
* resolve any conflicts
  * for each bug report
* submit and commit the fix
* close the bug report

This is easy to do with git. It's a small nightmare with SVN,  
especially if your project is a million lines of code.


(you could substitute while on plane with even if network craps  
out at hackathon or with at a customer site with big firewall)


I am saying that (a) the ASF has a uniform source control  
infrastructure, which is currently based on SVN servers, and (b)  
our practices mean that development is done in public, not done in  
private and submitted en masse as a fait accompli.  These  
statements are independent of the SCM technology used by the ASF.


Exactly!


cheers,


- Leo


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



  1   2   3   4   5   >