Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Wed, 03 Jul 2019 16:06 -0700:
> > On Jul 3, 2019, at 3:59 PM, Daniel Shahaf  wrote:
> > Alex Harui wrote on Wed, 03 Jul 2019 21:35 +:
> It really is up to the PPMC Members coming around to how a full PMC and 
> RM would act in the Apache Way!

No, it isn't.  Getting the LICENSE file correct is like having a warnings-free
build: it's good software development practice that's not specific to
any particular license or governance model.

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

Re: New disclaimer text

[Daniel Shahaf]

Alex Harui wrote on Wed, 03 Jul 2019 21:35 +:
> Re-rolling required re-GPG-signing, new hashes, etc.

Yes, I know how re-rolling works.  I've RM'd things before.  I still think 
in-band is better.

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

Re: Podlings, the Incubator, relationships and Apache

[Daniel Shahaf]

Jim Jagielski wrote on Wed, 03 Jul 2019 16:59 -0400:
> IMO, we want 2 things:
> 
>   1.  Podlings, and PPMC members, to enjoy the legal protection of the 
> foundation when they do a release
> 
>   2. The outside world, and esp downstream end-users, to know that 
> podling releases should be expected to not be fully compliant with the 
> normal expectations associated w/ PMC releases.

Re #2, I'd be concerned about two kinds of fallout:

A. Podling Foo releases non-compliant artifact.  Downstream users apply the 
same expectations to Podling Bar.

B. Podling Foo releases non-compliant artifact.  Downstream users apply the 
same expectations to PMC Baz.



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

Re: Podlings, the Incubator, relationships and Apache

[Daniel Shahaf]

David Nalley wrote on Wed, 03 Jul 2019 16:21 -0400:
> On Wed, Jul 3, 2019 at 2:38 PM Roman Shaposhnik  wrote:
> >
> > On Tue, Jul 2, 2019 at 10:27 PM Greg Stein  wrote:
> > >
> > > On Wed, Jul 3, 2019 at 12:10 AM Justin Mclean 
> > > wrote:
> > > >...
> > >
> > > > Hi,
> > > >
> > > > > Although not a "real" PMC, we do need to provide legal protection for
> > > > each PPMC and distributing releases is the time that most legal
> > > > considerations "kick in" as it were. So we need a
> > >
> > >
> > > Or we *don't* provide legal protections. That *is* what the disclaimer is
> > > there for.
> >
> > That's exactly the direction I personally would like this to go into.
> >
> 
> As VP Legal, I think that's well within your bailiwick to make such a 
> decision.
> As a member, I find that it's counter to one of the stated purposes of
> the Foundation - which is to shield individuals[1] and find it
> concerning that we are wanting to shift that back to the individual.

2017 - Project Foo is a non-Apache project
2018 - Project Foo has joined the Incubator
2019 - Project Foo graduated to PMC

Releases in 2017 are not Apache releases.  Releases in 2019 are Apache
releases.  Starting from some point in 2018 the Foo podling releases
should enter the legal shield — but that point needn't coincide with the
start of Incubation.  Thus, instead of expecting that *every* release
made while in Incubation be an Apache release, expect that *eventually*
every release will be an Apache release.

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

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Wed, 03 Jul 2019 12:16 -0700:
> This only works for issues known before a release is cut. It does NOT 
> WORK if the issue is discovered during the release vote. Why? Because we 
> are trying to allow the release to go through without redoing it and 
> this would require reworking the release.
> 
> I would rather do it outside of the release. Policing the actual 
> DISCLAIMER is not easily feasible and decreases the burden.

I recommend to put the information in DISCLAIMER.  Yes, that means bugs
in DISCLAIMER require re-rolling, but:

1. Bugs in DISCLAIMER should be found before the first artifact is
   rolled.  It's simply an audit and it can be done directly on the
   source tree in version control.

2. Re-rolling shouldn't be an expensive step that should be avoided. It
   should be "Edit DISCLAIMER, commit, run script to roll" followed by
   everyone diffing the old artifact to the new one and re-casting their
   votes based on the work they already did to review the old artifact.
   (And yes, it's still some effort, about which, see #1.)

3. Artifacts should state their exact license terms — accurately,
   completely, and (de facto standard) in-band.

Daniel

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

Re: Podlings, the Incubator, relationships and Apache

[Daniel Shahaf]

Guys, aren't you forgetting something?  The VP is to sign the Board
report.  Everything else that Justin is  doing he's doing as a rank and
file Incubator committer.  If you disagree with Justin, that's one
thing, but his being VP is orthogonal to your disagreement.

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

Re: New disclaimer text

[Daniel Shahaf]

Dave Fisher wrote on Tue, 02 Jul 2019 10:28 -0700:
> > On Jul 1, 2019, at 1:30 AM, Bertrand Delacretaz 
> >  wrote:
> > 
> > Hi,
> > 
> > On Sun, Jun 30, 2019 at 1:39 AM Justin Mclean  
> > wrote:
> >> ...I put up suggested text changes for an incubator disclaimer here [1]...
> > 
> > Basically just adding this, right?
> > 
> >> Some of the project releases may not follow ASF policy or have
> >> incomplete or unknown licensing conditions
> > 
> > It works for me but I'd say "incubating project" to be clearer.
> 
> How is this?
> 
> “Some of the incubating project’s releases may not be fully compliant 
> with ASF policy. For example, releases may have incomplete or unreviewed 
> licensing conditions. Known issues will be described on the project’s 
> status page."

I think the meaning you guys are after is "The artifact may not be in
compliance with Apache's policies (CatA/CatB/CatX, etc)", but what you
actually drafted so far can be read as "We do not promise to you that the
LICENSE file is complete and accurate", which would be a deal breaker to
downstreams.

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

Re: Podling expectations and some issues encountered in incubation

[Daniel Shahaf]

Geertjan Wielenga wrote on Sun, Jun 30, 2019 at 18:14:52 +0200:
> Any community joining Apache should be very clear in their own minds that
> the Incubator is there for them to get used to the Apache Way. It is not
> there for getting releases done in the same cadence as before the community
> entered the Incubator, nor does it carry the responsibility for that. Until
> leaving the Incubator, a project is not in the hands of its community but
> in those of the Incubator. There should be no confusion about that very
> simple principle.

I don't understand what you mean by your penultimate sentence.  Might you
explain it in different words?

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

Re: New disclaimer text

[Daniel Shahaf]

Justin Mclean wrote on Sun, Jun 30, 2019 at 09:39:22 +1000:
> I put up suggested text changes for an incubator disclaimer here [1].

Fullquote of the link:

> Apache Podling-Name is an effort undergoing incubation at The Apache Software
> Foundation (ASF), sponsored by the name of Apache TLP sponsor. 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.
> 
> Some of the project releases may not follow ASF policy or have incomplete or
> unknown licensing conditions.

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

[PATCH] clutch: Fix broken links in the hasStatusEntry column

[Daniel Shahaf]

The links in the 'F' column are broken.  Patch:

Index: clutch.py
===
--- clutch.py   (revision 1855125)
+++ clutch.py   (working copy)
@@ -1117,7 +1117,7 @@ for k in sorted(projectNames, key=str.lower):
 '  {0}\n'.format(projects[k]['hasReportingGroup']))
 
 if projects[k]['hasStatusEntry']:
-fileXml.write('  {1}\n'.format(
+fileXml.write('  {1}\n'.format(
 projects[k]['statusFileName'], projects[k]['hasStatusEntry']))
 else:
 fileXml.write(

Cheers,

Daniel

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

Re: [Cava] Suitable name search - choosing a name

[Daniel Shahaf]

Antoine Toulme wrote on Fri, Mar 01, 2019 at 15:09:39 -0800:
> I am happy to mention that you mentioned this term on list.

Thanks.

> What language should I use?

The public part of PNS tickets should be factual, so I'd say:
.
"In the _Star Wars_ universe there exists a character named Obi-Wan Kenobi"
.
with a link to Wikipedia for good measure.

Cheers,

Daniel

> > On Mar 1, 2019, at 3:06 PM, Daniel Shahaf  wrote:
> > 
> > Antoine Toulme wrote on Fri, Mar 01, 2019 at 09:10:08 -0800:
> >> I’ll open a pooling name search ticket for Obiwarn and will test the 
> >> waters over there.
> > 
> > When you create a PNS ticket, please note on it the existence of
> > <https://en.wikipedia.org/wiki/Obi-Wan_Kenobi>.

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

Re: [Cava] Suitable name search - choosing a name

[Daniel Shahaf]

Antoine Toulme wrote on Fri, Mar 01, 2019 at 09:10:08 -0800:
> I’ll open a pooling name search ticket for Obiwarn and will test the waters 
> over there.

When you create a PNS ticket, please note on it the existence of
.

Cheers,

Daniel

P.S. Mentors, you may wish to create a private@ list now in order to enable the
PPMC to engage with trademarks@ directly.

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

Re: [Cava] Suitable name search - choosing a name

[Daniel Shahaf]

Kevin A. McGrail wrote on Tue, 26 Feb 2019 23:57 +00:00:
> Re: Winch, might be a common name and undefendable as a trademark, etc. 
> Otherwise, though, I couldn't find much relevant in OSS spaces except a
> company called winch gate. 

There's the SIGWINCH signal in terminal applications.

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

Re: Apache ODF Toolkit (retired) migration to TDF

[Daniel Shahaf]

Thorsten Behrens wrote on Mon, 04 Feb 2019 17:49 +0100:
> 2. adding a pointer from the ASF website
>https://incubator.apache.org/projects/odftoolkit.html to the new
>TDF website for the project, such that people looking for it still
>find the active project:
> - perhaps also adjusting other references, e.g. README in the
> code repo archive at
> https://svn.apache.org/repos/asf/incubator/odf/trunk/README.txt
>   - or are all those resources not preserved beyond a transition
> period?

What about this page:

http://odftoolkit.incubator.apache.org/odftoolkit/index.mdtext


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

Re: Apache ODF Toolkit (retired) migration to TDF

[Daniel Shahaf]

Dave Fisher wrote on Mon, 04 Feb 2019 09:35 -0800:
> > On Feb 4, 2019, at 8:49 AM, Thorsten Behrens  
> > wrote:
> > 3. if bugtracker, mailing list archives and the like are _not_
> >   preserved or archived somewhere - if TDF could get a copy of at
> >   least the public part of that data for some continuity in
> >   development?
> 
> The bug tracker is read only and is here: 
> https://issues.apache.org/jira/projects/ODFTOOLKIT 
> 
> Public email archives are here:
> http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/ 
> 

It's not very obvious in the UI, but links such as
http://mail-archives.apache.org/mod_mbox/incubator-odf-dev/201812.mbox
can be used to download the raw archives from there.

Also, you might want to update the lists' autoresponders.

Cheers,

Daniel

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

Re: How to review so-called "binary releases"?

[Daniel Shahaf]

Julian Hyde wrote on Wed, Nov 14, 2018 at 11:33:55 -0800:
> The question with which I started this discussion has not been
> answered. Given that a collection of artifacts is up for a vote, and
> those artifacts are a mixture of source and binary artifacts, what is
> a reviewer to do:
> 
> 1. Vote -1. The release contains binaries.
> 

I'd vote -1 on the binary artifacts only, since I can't review/audit
them, and vote on the source artifacts on their own merits.

> 2. Perform some cursory checks on the binaries (e.g. L&N) and vote 
> accordingly.
> 
> 3. Ignore the binaries. Vote only based on the source artifacts, but
> allow the binary artifacts to appear alongside them in
> https://www.apache.org/dist/ (and other places such as Maven Central).
> 
> Current policy, for both the incubator and many other projects, seems
> to be 3. Yet this seems to me to contradict statements by Jim and Greg
> that we only produce source releases.
> 

I think Jim and Greg were describing theory, not practice.  We can shout
from the rooftops that We Do Not Release Binaries, but then you have
download pages like [1] that present binary artifacts on equal footing
with source artifacts, without even paying lip service by including the
term "convenience" somewhere.

The PMC in [1] _is_ releasing binaries as official artifacts — possibly
in contravention of Board policy, but that's neither here nor there:
users who visit download pages are not expected to know Board policies.
A user who visits [1] _will_ consider the binary artifacts official,
because they are presented as such.

If that's an undesirable outcome, then the Board should enforce its
policy that download pages aren't to present binaries as official
artifacts.  (Which, I think, is what David was getting at.)

> My favorite is 2. It reflects reality - we DO release binary artifacts
> along with releases, we have to trust the release manager to have not
> compromised the binaries during the build process, but reviewers can
> help by running cursory checks.

Cheers,

Daniel

[1] .  (I won't name and
shame, sorry.  Could someone volunteer his own PMC's download page for
a case study?  I would volunteer Subversion but I think our download
page is compliant.)

> I would like to achieve clarity by voting on the 3 alternatives above
> (plus any other alternatives people would like to propose).

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

Re: How to review so-called "binary releases"?

[Daniel Shahaf]

Myrle Krantz wrote on Wed, Nov 14, 2018 at 17:19:35 +0100:
> On Wed, Nov 14, 2018 at 1:12 PM Daniel Shahaf 
> wrote:
> 
> > The answer to (1) depends on the build platform and toolchain.
> > Reproducible builds [in the sense of "building the same source twice
> > gives bit-for-bit identical binaries"] can help with it.  When the
> > answer is negative, the next question is whether those unauditable
> > artifacts should be carried by ASF mirrors alongside the source
> > artifacts.
> >
> 
> So if a project puts in the effort to
> a.) make their build reproducible (which can actually be very difficult to
> do), and
> b.) do a bit-for bid compare on a release across at least two build
> artifacts, created by different people on different machines...
> 
> ...would we be willing to see that threat as sufficiently eliminated for
> our purposes?  Would we then be willing to "officially" release binaries?

I would say yes.

I would further note that this is a *sufficient* condition, not a
necessary one.  Often, binaries are _nearly_ reproducible but not _bit
for bit_ reproducible — for example, they might contain a date in the
RM's timezone, or the RM's uname(1) output, etc.  Such differences are
auditable, and it would be reasonable for a PMC member to compare the
proposed binary artifact to one he built locally, see that the
differences are acceptable, and vote +1 on the binary artifact — just
like we do for source artifacts (when we compare tarballs to tags).

Cheers,

Daniel

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

Re: How to review so-called "binary releases"?

[Daniel Shahaf]

Myrle Krantz wrote on Wed, 14 Nov 2018 12:24 +0100:
> I had understood the reason that the foundation only officially supports
> source releases to be the fear of undetected malware in the release (like
> in the Ken Thompson hack).
> 
> Is that correct?  Are we all are in agreement that the probability of that
> kind of hack is very low?
> 
> I'd extend that by one step: Isn't the probably of that kind of hack
> *lower* if we compile our code ourselves, than if we ask our users to do it?

Yes, the problem with binary artifacts is that it's harder to audit them
to ensure they are not malicious.  (For source artifacts that is not a
problem because every change between successive source releases results
in a post-commit email and the PMC is assumed to review its commits@
mailing list.)  However, regarding Thompson's _Reflections on Trusting
Trust_ attack¹, that specific attack is not the primary concern here:
there's no need for a backdoor to be self-propagating in order to be of
concern to ASF.

The simple and immediate attack vector is for whoever generates binary
artifacts that end up on the dist/ tree — usually, the RM — to generate
them incorrectly, i.e., to build them not from the official source tree
but from a patched source tree.  (This can happen due to any number of
reasons: bug, malice, coercion…)  The concern is then:

1. Given that it is possible for an RM to generate binary artifacts
not from the official source, is it feasible for a PMC to review the
binary artifacts to catch that?

2. Suppose an RM generates malicious binary artifacts and uploads them
to the dist/ tree, whence they are then downloaded.  Is ASF liable
for the results?

The answer to (1) depends on the build platform and toolchain.
Reproducible builds [in the sense of "building the same source twice
gives bit-for-bit identical binaries"] can help with it.  When the
answer is negative, the next question is whether those unauditable
artifacts should be carried by ASF mirrors alongside the source
artifacts.

I don't know what the answer to (2) is.  IANAL.

Cheers,

Daniel

¹ Thompson postulates a self-propagating backdoor in a self-hosted compiler.

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

Re: How to review so-called "binary releases"?

[Daniel Shahaf]

CC += legal-discuss@ since this really isn't an incubator-specific topic any
more.  The context is precompiled binary artifacts on
https://www.apache.org/dist/.

David Nalley wrote on Tue, Nov 06, 2018 at 17:06:50 -0500:
> So let's assume a PMC (or PPMC) goes through the same process with
> binaries in terms of reviewing, voting on, promoting, and publishing
> to the world a binary release on behalf of the PMC and Foundation.
> Binaries are published to the same location that source tar balls are
> - are featured on download pages provided by the ASF. Perhaps even
> with the situation being that people download the binary artifacts
> from ASF resources tens of thousands, or maybe even millions of times
> more frequently than the source tarballs.
> 
> From that scenario I have some questions:
> 
> 1. Would a reasonable person (or jury) suspend disbelief long enough
> to consider our protestations that our 'releases' are source only, and
> that as a Foundation we didn't release, propagate, promote, or
> distribute the binaries in question? A rose by any other name.
> 2. Should the Board be taking an active interest in projects (release
> managers?) who promote and publish their binaries in this manner on
> our hardware?
> 3. Is lack of Board action tantamount to tacit approval of this
> behavior? Can we really claim ignorance?
> 4. Should Infrastructure be actively monitoring and removing binaries
> which find their way to dist.a.o/archive.a.o - especially since our
> header for dist.a.o says that the directories contain releases of
> Apache software?
> 5. Should we be alerting individual release managers that publishing
> convenience binaries exposes them individually to liability?

6. What alternative can we offer to projects that want to distribute binaries?
Can the RM upload precompiled binaries to his https://home.a.o/~availid/ space?
Can the project's download page link to them as the
primary/canonical/recommended binaries?  Can the project's download page link
to the RM's binaries as one alternative among many (compare
https://subversion.apache.org/packages#windows)?

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

Re: Digests in releases

[Daniel Shahaf]

Dave Fisher wrote on Thu, 31 Aug 2017 13:35 -0700:
> Regardless of what Jane User knows, and we have 200 million Jane Users of 
> Apache OpenOffice, I think it would be helpful to have an Apache Download 
> checker program/script that could be run to confirm the bonafides.
> 
> An idea.

Why stop here?  On unix this problem is largely solved, by
'${packagemanager} install foo' (substitute your distro's package
manager).  Why not set up a package manager (program + repository
service) for windows?

With 200M users, though, somebody's going to write phishing software
that impersonates the package manager.  There's no easy way around the
web of trust.

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

Re: Seeking interest and a champion for bifroest - a backend for graphite-web, on Apache Cassandra

[Daniel Shahaf]

Harald Kraemer wrote on Tue, Oct 07, 2014 at 10:59:35 +0200:
> Thus, the first thought of bifroest was born: Why don't we take the good
> parts of Cyanide, a solid distributed database, such as Apache Cassandra,
> and the good parts of carbon and toss them in a big stew?
> 
> That's what we did, and that's what we are currently deploying as our
> productive monitoring system, graphite on bifroest as a frontend for apache
> cassandra.
> 
...
> a) is this project interesting enough for everyone? :)
> b) Are there people who would volunteer to coach me and my team through the
> proposal and the incubator?

Happy to help.  My relevant experience is in the Apache Subversion
development community.

Daniel

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

Re: Reports needing shepherd attention

[Daniel Shahaf]

Roman Shaposhnik wrote on Sat, May 31, 2014 at 23:39:06 -0700:
> On Sat, May 31, 2014 at 10:18 AM, Daniel Shahaf  
> wrote:
> >> Regardless, I guess my real question is this: if a podling feels that they
> >> need to achieve a certain milestone in software completeness before
> >> they can confidently graduate, are we really in a position to push
> >> them out of the incubator somewhat against their will?
> >
> > I can imagine situations in which you'd graduate a podling that has a
> > diverse and self-managing PPMC and advise the PMC to work with Press, or
> > Infra, or Brand, or Comdev post-graduation to improve some aspect or
> > another.
> 
> I can't. If the community doesn't think it is ready the best you can do is
> try to persuade them that they are ready, but not graduate by force.
> 

We aren't talking about the same thing.

I don't think it would make sense to graduate somebody by force.

I'm just saying that I see scenarios in which a project graduates that
still has some problems, which the PMC-to-be can address by itself
(i.e., doesn't need IPMC's hand-holding with addressing).

> > Back to the instance at hand: the project reported that adding a feature
> > is a graduation blocker.  That is unusual.  The likely explanation is
> > that they misunderstood what graduation is about.  The situation should
> > therefore be checked.
> > If the project has a misunderstanding then it
> > should be corrected, and if it doesn't then it'd be better if they
> > clarified in future reports why they, unusually, consider adding a
> > feature to be a graduation blocker.
> 
> That's a good point, but see below.
> 
> > A podling was asked "Has your community grown" and replied that the
> > statistics server was down.  To me, that's not a satisfactory answer,
> > for the same reason that (with car drivers) a broken speedometer is not
> > a carte blanche to speeding.
> 
> [...] only hope is to have good mentors.

+1

> > Time for reductio ad absurdum.
> 
> Never a good move on an email thread ;-)

Because...?

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

Re: Reports needing shepherd attention

[Daniel Shahaf]

[ Brett: thanks for communicating my feedback to Roman; I missed his
question to me in his previous mail. ]

Roman Shaposhnik wrote on Sat, May 31, 2014 at 08:27:55 -0700:
> On Wed, May 21, 2014 at 10:45 PM, Brett Porter  wrote:
> > The first example listed a piece of software functionality
> > as a graduation goal, which may misunderstand that graduation is about the 
> > completeness
> > of the community, IP transfer, and understanding of Apache policies; not 
> > the completeness
> > of the software.

Yes, that is precisely the point I was trying to make.

> Regardless, I guess my real question is this: if a podling feels that they
> need to achieve a certain milestone in software completeness before
> they can confidently graduate, are we really in a position to push
> them out of the incubator somewhat against their will?

I can imagine situations in which you'd graduate a podling that has a
diverse and self-managing PPMC and advise the PMC to work with Press, or
Infra, or Brand, or Comdev post-graduation to improve some aspect or
another.

Back to the instance at hand: the project reported that adding a feature
is a graduation blocker.  That is unusual.  The likely explanation is
that they misunderstood what graduation is about.  The situation should
therefore be checked.  If the project has a misunderstanding then it
should be corrected, and if it doesn't then it'd be better if they
clarified in future reports why they, unusually, consider adding a
feature to be a graduation blocker.

> > The second example was that the answer to a question about how a
> > community has developed doesn't depend on mail statistics (though might be 
> > aided by it),
> > so the podling might have misunderstood what the template suggested.
> > However, I'll leave it to Daniel to further clarify if he wishes (perhaps 
> > on the incubator lists for
> > the benefit of those shepherding the podling reports).

A podling was asked "Has your community grown" and replied that the
statistics server was down.  To me, that's not a satisfactory answer,
for the same reason that (with car drivers) a broken speedometer is not
a carte blanche to speeding.

Time for reductio ad absurdum.  Suppose Infra switched to a mailing
lists software that did not allow (P)PMCs to obtain subscriber counts.
Would you consider it reasonable, in that scenario, for (P)PMCs to report
to the Board that they have no idea how their community is doing?  What
would you expect them to do instead?  That is what the PPMC in question
should have done.

Cheers,

Daniel

P.S. Please CC me on replies.

> 


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

Re: INFRA-6774

[Daniel Shahaf]

Joseph Schaefer wrote on Tue, Nov 19, 2013 at 23:18:11 -0500:
> 
> On Nov 19, 2013, at 10:50 PM, Joseph Schaefer  wrote:
> 
> > 
> > On Nov 19, 2013, at 10:40 PM, Jordan Zimmerman  wrote:
> > 
> >> Can someone please explain to me what I need to do to have 
> >> curator.incubator.apache.org redirect to curator.apache.org?
> > 
> > You need to create an .htaccess file at the top-level of your tree with the 
> > following contents
> > 
> > RewriteCond %{HTTP_HOST} curator.incubator.apache.org
> > RewriteRule (.*)  https://curator.apache.org/
> 
> Sorry, that last part needs an $1 tacked onto the end: 
> https://curator.apache.org/$1

No htaccess is needed, it happens automagically once the TLP dist area
is created.  See vhosts/zzzothers.conf on eos.

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

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

[Daniel Shahaf]

On Mon, Sep 02, 2013 at 10:28:10AM -0400, Suresh Marru wrote:
> We don't need to worry for this vote, but in general relying on voter's
> statement is not a good idea.

+1! (binding)

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

Re: Welcome to the Incubator, Samza community!

[Daniel Shahaf]

On Thu, Aug 15, 2013 at 09:01:52AM -0700, Ross Gardler wrote:
> This discussion about the ombud is going around in circles and we need to
> close it. As an interim step I have edited the wiki to remove reference to
> the non-existent ombud.

+1, thanks.  (Scanned the text too, looks good except for "your on your" typo
on the last line)

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

Re: Welcome to the Incubator, Samza community!

[Daniel Shahaf]

On Thu, Aug 15, 2013 at 09:01:52AM -0700, Ross Gardler wrote:
> In the unlikely event that you are still unable to find a resolution then you
> can escalate to the Apache Board via your regular board reports.  Should the
> matter be urgent feel free to contact the board via bo...@apache.org at any
> time.

Actually, that's precisely the place to remind folks that out-of-cycle reports
are normal/encouraged/etc.

Suggested text:

  In the unlikely event that you are still unable to find a resolution then you
 -can escalate to the Apache Board via your regular board reports.
 +can escalate to the Apache Board by submitting a report for the next monthly
 +Board meeting (even if your project is not normally scheduled to report that 
month).
  Should the matter be urgent feel free to contact the board via
  bo...@apache.org at any time.

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

Re: Welcome to the Incubator, Samza community!

[Daniel Shahaf]

Marvin Humphrey wrote on Wed, Aug 14, 2013 at 19:02:54 -0700:
> *   See  for a practical
> introduction to the Incubator experience.

My favourite part of this is how it first warns that "some of the
documentation may be out-of-date and if you ask about it you may get
a totally different response", and then gives an email address for the
ombudsman (and then warns that there's in fact no ombudsman)...

Irony aside, that's at best a bug in WhatToExpect.  (and at worst the
canary of that page growing all the same problems that existing
documentations have)

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

Re: Moderation of report reminders

[Daniel Shahaf]

On Tue, Jul 16, 2013 at 06:13:28PM +0100, sebb wrote:
> On 13 July 2013 19:28, Daniel Shahaf  wrote:
> > On Sat, Jul 13, 2013 at 10:57:33AM -0700, Marvin Humphrey wrote:
> >> A second possibility might be to consolidate `-allow` lists.  (I'm not sure
> >> whether this is technically feasible -- it came up yesterday on the infra
> >> list, but the discussion was not conclusive.  Perhaps one of the
> >> Infrastructure people on this list could comment.)
> >
> > The root problem is that people don't moderate things that need to be
> > moderated.
> 
> Indeed, but ...
> 
> If a human sends an e-mail to a mailing list and it bounces, they will
> hopefully realise and get the problem fixed.
> 

I don't think it bounces unless a mod emails the -reject address.

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

Re: Moderation of report reminders

[Daniel Shahaf]

On Tue, Jul 16, 2013 at 06:13:28PM +0100, sebb wrote:
> On 13 July 2013 19:28, Daniel Shahaf  wrote:
> > On Sat, Jul 13, 2013 at 10:57:33AM -0700, Marvin Humphrey wrote:
> >> A second possibility might be to consolidate `-allow` lists.  (I'm not sure
> >> whether this is technically feasible -- it came up yesterday on the infra
> >> list, but the discussion was not conclusive.  Perhaps one of the
> >> Infrastructure people on this list could comment.)
> >
> > The root problem is that people don't moderate things that need to be
> > moderated.
> 
> Indeed, but ...
> 
> If a human sends an e-mail to a mailing list and it bounces, they will
> hopefully realise and get the problem fixed.
> 
> However, for automated senders, bounces don't usually do much.

BTW, even if you're right, you could have Marvin use
Return-Path: 

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

Re: Moderation of report reminders

[Daniel Shahaf]

On Sat, Jul 13, 2013 at 10:57:33AM -0700, Marvin Humphrey wrote:
> A second possibility might be to consolidate `-allow` lists.  (I'm not sure
> whether this is technically feasible -- it came up yesterday on the infra
> list, but the discussion was not conclusive.  Perhaps one of the
> Infrastructure people on this list could comment.)

The root problem is that people don't moderate things that need to be
moderated.  Whitelisting no-re...@apache.org just papers over the problem, it
will happen again when infra or comdev or board email the private@ list and
doesn't get moderated through.

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

Re: [PROPOSAL] Mandatory podling exit interviews

[Daniel Shahaf]

On Thu, Jun 20, 2013 at 10:18:16AM +0100, Upayavira wrote:
> 
> 
> On Thu, Jun 20, 2013, at 03:54 AM, Marvin Humphrey wrote:
> > On Sat, Jun 15, 2013 at 8:47 AM, Alan Cabrera 
> > wrote:
> > > Solution: require all podlings to submit anonymous exit interviews as part
> > > of the graduation requirements.  These exit interviews will be suitably
> > > scrubbed and organized by the Incubator Ombudsman; see next proposal.
> > 
> > A few sample questions:
> > 
> > *   What aspect of incubation benefitted your podling the most?
> > *   What advice would you give to future podlings?
> > *   What was the most useful thing you learned?
> > *   What could we have done differently?
> > 
> > I think we should accept the survey in private but publish the results on
> > general@ after scrubbing sections marked  and anything else
> > sensitive
> > at the ombud's discretion.  Author identity should be preserved, because
> > any
> > attempt at anonymization will be dangerously futile.
> 
> As in any such survey, author identity should be optional. Sometimes it
> can be deduced, but not always, and if someone would rather not mention
> their name, we should give them that opportunity.

Only one podling graduated in the last two months.  At this rate, if you really
want anonymity, you'll have to publish the results once per quarter at most.

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

Re: [PROPOSAL] Creation of the Incubator Ombudsman

[Daniel Shahaf]

On Wed, Jun 19, 2013 at 01:44:14PM -0700, Dave Fisher wrote:
> 
> On Jun 19, 2013, at 9:41 AM, Alan Cabrera wrote:
> 
> > I would prefer to use well known names for well known roles.  Ombudsman is 
> > a roll that's been around for quite a while and the person filling that 
> > role for the ASF will be doing roughly the same thing as ombudsman in other 
> > organizations.
> > 
> > With that said, I will agree that if everything is running fine, the 
> > ombudsman is pretty much watching Oprah re-runs.  Hopefully we will all 
> > work hard so this person will have the time to catch up.  ;)
> > 
> > However, I will point out that my proposal has come about from concrete 
> > personal experience and the experiences that others have personally related 
> > to me.  I will also point out that it seems to me that those who are 
> > opposed or, at best, lukewarm to the idea are well established and well 
> > connected individuals in the ASF sphere.
> 
> +1.
> 
> How should we "bless" our Ombudsmen? On private@? Do we have more than one?
> If so what is the limit?

I don't think you have that problem yet -- I don't see a mob banging on the
doors of this thread crying, "Me! Me!".

Personally I suggest KISS.  Set up the alias, have it target 2 people,
advertise it on the web site, move on.  This email took me 200% as long to type
than it would have taken me to set up the actual alias...

ssh -t hermes.apache.org sudo -u apmail tee 
\~apmail/.qmail-incubator-ombudsm\{a,e\}n <<< 
$'w...@apache.org\ndanie...@apache.org\n'


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

Re: Stratos proposal: is it possible to add another initial committer?

[Daniel Shahaf]

On Wed, Jun 19, 2013 at 08:49:55PM -0700, Marvin Humphrey wrote:
> On Tue, Jun 18, 2013 at 4:01 PM, Daniel Shahaf  wrote:
> > On Tue, Jun 18, 2013 at 11:49:51PM +0100, Ross Gardler wrote:
> >> +Once the vote has been called the proposal should be considered fixed.
> >> +  No further changes are accepted.
> >
> > Can I suggest that you make explicit the option to cancel the vote, amend 
> > the
> > proposal, and re-start the vote?  This document is facing "new" people who
> > might otherwise get the false impression that once a vote is started, 
> > that's it
> > --- "sink or swim", based on whatever the proposal was at that point in 
> > time.
> 
> Hi Daniel, I'll volunteer to take point on documenting this issue.
> 

Thanks.

> Therefore, unless there are objections, I plan to strike the material on the
> "Process Description" page, leaving the only copy at the canonical location of
> the proposal guide.

+1 to the idea that policy should exist only at one, canonical location.

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

Re: Stratos proposal: is it possible to add another initial committer?

[Daniel Shahaf]

On Tue, Jun 18, 2013 at 11:49:51PM +0100, Ross Gardler wrote:
> +Once the vote has been called the proposal should be considered fixed.
> +  No further changes are accepted.

Can I suggest that you make explicit the option to cancel the vote, amend the
proposal, and re-start the vote?  This document is facing "new" people who
might otherwise get the false impression that once a vote is started, that's it
--- "sink or swim", based on whatever the proposal was at that point in time.

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

Re: Stratos proposal: is it possible to add another initial committer?

[Daniel Shahaf]

On Tue, Jun 18, 2013 at 01:34:39PM +0100, Ross Gardler wrote:
> However, in this specific case the social norm *should* be to allow the
> change to proceed - that's the most efficient process.

Modifying a vote that has started is a slippery slope.  (The same is true for
reusing version numbers: ANY change to something that has been tagged must get
a new version number - no matter how small the change may be.)  One solution is
to restart the vote.  Another is to run a parallel vote for the delta/amendment.

Concretely, can't you just start a thread on private@ saying "The would-be-PPMC
has consensus on inviting X as a committer"?  This would allow you to invite X
to be a committer shortly after the original vote ends.

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

Re: Redirect of new podling urls

[Daniel Shahaf]

On Mon, Jun 03, 2013 at 06:33:17PM +0200, Christian Grobmeier wrote:
> Redirect Permanent http://onami.incubator.apache.org http://onami.apache.org

That is *supposed* to be handled by httpd.conf.  Follow up w/ infra - onami is
the first http://*.incubator.apache.org/ graduation (congrats).

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

Re: Redirect of new podling urls

[Daniel Shahaf]

On Mon, Jun 03, 2013 at 06:33:17PM +0200, Christian Grobmeier wrote:
> Redirect Permanent http://onami.incubator.apache.org http://onami.apache.org

No need.  The redirect will start working via httpd.conf once /dist/onami gets 
created.

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

Re: Unused OpenOffice source tree in incubator: keep or remove?

[Daniel Shahaf]

On Tue, May 21, 2013 at 09:40:19PM +0200, Andrea Pescetti wrote:
> Is this the recommended configuration or shall we "svn remove" the whole 
> old tree, maybe leaving only a README.txt pointing to the new location? 

Ask infra about arranging a redirect - this might be possible but would have to
be done manually since "ooo" != "openoffice".

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

Re: Writing some tooling

[Daniel Shahaf]

Alan Cabrera wrote on Tue, May 14, 2013 at 08:50:27 -0700:
> 
> On May 10, 2013, at 10:58 AM, Alan Cabrera  wrote:
> 
> > I'm currently writing some tooling to help with the incubation process as 
> > well as mail list moderator tools.
> > 
> > The first thing that I'm writing is a command that will print out who is 
> > the owner of an email alias and what projects they belong to and if they 
> > are ASF members.  This will help me vet subscription requests since people 
> > rarely use their ASF email accounts.
> > 
> > The tools will be written in Python. 
> 
> 
> I'm done with this tool.  It also sends a rejected email to the user 
> informing them that they are not allowed to subscribe.  Things I need in this 
> email are:
> 
> URL of a web page describing out to add an alias to an account

"Alternate email address" field on id.apache.org.  If that's documented
it'll be under http://www.apache.org/dev/.

> URL of a web page describing mailing list membership policies
> 

Members to everything except board-private@, root@, and vp-*@; IPMC
members to all podling lists; PMC chairs to board@.  There's also
a handful of "committers only" lists, and list owners can invite anyone
to subscribe to the list they operate through.

A fairly good approximation is this:
https://whimsy.apache.org/committers/subscribe

though it doesn't implement the "IPMC members can subscribe to any
podling list" rule.  (Patches welcome.)

> If these don't exist I am happy to write them.

Yes please :-)

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

Re: Writing some tooling

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, May 11, 2013 at 13:43:37 +0300:
> Alan Cabrera wrote on Fri, May 10, 2013 at 10:58:24 -0700:
> > The first thing that I'm writing is a command that will print out who
> > is the owner of an email alias and what projects they belong to and if
> > they are ASF members.  This will help me vet subscription requests
> > since people rarely use their ASF email accounts.
> 
> https://id.apache.org/info/MailAlias.txt

Second link is:
https://whimsy.apache.org/roster/committer/

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

Re: Writing some tooling

[Daniel Shahaf]

Alan Cabrera wrote on Fri, May 10, 2013 at 10:58:24 -0700:
> The first thing that I'm writing is a command that will print out who
> is the owner of an email alias and what projects they belong to and if
> they are ASF members.  This will help me vet subscription requests
> since people rarely use their ASF email accounts.

https://id.apache.org/info/MailAlias.txt
https://whimsy.apache.org/committer/roster/

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

[danie...@apache.org: svn commit: r1479414 - /infrastructure/site/trunk/content/dev/infra-contact.mdtext]

[Daniel Shahaf]

New podlings without a website - FYI process change.

See https://www.apache.org/dev/infra-contact#requesting-podling

Daniel


- Forwarded message from danie...@apache.org -

> Reply-To: site-...@apache.org
> Subject: svn commit: r1479414 -
>  /infrastructure/site/trunk/content/dev/infra-contact.mdtext
> Date: Sun, 05 May 2013 22:38:43 -
> To: site-...@apache.org
> From: danie...@apache.org
> 
> Author: danielsh
> Date: Sun May  5 22:38:43 2013
> New Revision: 1479414
> 
> URL: http://svn.apache.org/r1479414
> Log:
> webreq
> 
> Modified:
> infrastructure/site/trunk/content/dev/infra-contact.mdtext
> 
> Modified: infrastructure/site/trunk/content/dev/infra-contact.mdtext
> URL: 
> http://svn.apache.org/viewvc/infrastructure/site/trunk/content/dev/infra-contact.mdtext?rev=1479414&r1=1479413&r2=1479414&view=diff
> ==
> --- infrastructure/site/trunk/content/dev/infra-contact.mdtext (original)
> +++ infrastructure/site/trunk/content/dev/infra-contact.mdtext Sun May  5 
> 22:38:43 2013
> @@ -104,11 +104,7 @@ mail will get delivered to the mailing l
>  
>  1. The podling community sets up a [project site](project-site#intro).
>  
> -1. An ASF Member or PMC chair files a *website creation request*.
> -In the future this will use a webapp[][3], but for now
> -file a jira.  See the "CMS-based sites" or "svnpubsub-based sites" entry in 
> -["Providing needed information"](#what-we-need-to-know)
> -first.
> +1. An ASF Member or PMC chair files a [*website creation request*][3].
>  
>  If additional services need to be created (beyond mailing lists, svn tree, 
> and
>  web site), file one "Create Foo Podling" parent ticket in JIRA and one 
> sub-task
> @@ -203,8 +199,8 @@ involving infra at all.
>  | Create a **podling** | [See above](#requesting-podling) | |
>  | Load **Subversion history** | URL and checksum (or PGP signature) of a 
> dumpfile; proof of [IP rights](/legal/resolved#category-a) | Produce with 
> `svnadmin dump --incremental --deltas` or `svnrdump`. The paths within the 
> dumpfile should be relative to the project root (e.g., to 
> `/repos/asf/incubator/MyPodling`). |
>  | Load **Git history** | URL and of a repository or an export stream; proof 
> of [IP rights](/legal/resolved#category-a) | If linking to a file, provide 
> PGP signature or checksum.  If to a remote repository, you will be asked to 
> review and sign off on the import ("Yes, that is the repository and history 
> we asked to import and have IP rights for") before it will be writable. |
> -| Create a **CMS-based site** | URL of the [layout-compliant](cms#layout) 
> site source, and what build system to use | Build system types include: 
> default (path.pm), shell (build\_cms.sh), maven/ant/forrest. |
> -| Create an **svnpubsub-based site** | SVN URL of the compiled site 
> (directory containing HTML files) | Git is not supported by 
> [svnpubsub](project-site#intro) |
> +| Create a **CMS-based site** | URL of the [layout-compliant](cms#layout) 
> site source, and what build system to use | Build system types include: 
> default (path.pm), shell (build\_cms.sh), maven/ant/forrest. Use the [webreq 
> app][3]. |
> +| Create an **svnpubsub-based site** | SVN URL of the compiled site 
> (directory containing HTML files) | Git is not supported by 
> [svnpubsub](project-site#intro). Use the [webreq app][3]. |
>  | Create an **svnpubsub-based Dist area** | Create or ask to create dist 
> release dir. Specify release area only or release and dev areas. Mailing list 
> for commits to go, if omitted the default is the  project commits list. | Any 
> existing release dir will be blown away (archive releases remain). A release 
> or KEYS/NOTICE file will be asked for upon creation. |
>  | Create a **project blog** | project name, brief one-line description of 
> the project, and Apache usernames (and fullnames) of 1+ editors | |
>  | Create a **blog account** (for an editor) | The Apache username (and 
> fullnames) of the editor | Non-PMC members need to demonstrate PMC consensus 
> too (link to a lazy consensus thread suffices). |
> 
> 

- End forwarded message -

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

Re: svn commit: r1465544 - /infrastructure/site/trunk/content/dev/infra-contact.mdtext

[Daniel Shahaf]

cross...@apache.org wrote on Mon, Apr 08, 2013 at 07:03:56 -:
> Author: crossley
> Date: Mon Apr  8 07:03:56 2013
> New Revision: 1465544
> 
> URL: http://svn.apache.org/r1465544
> Log:
> Link to the Graduation Guide.
> 
> Modified:
> infrastructure/site/trunk/content/dev/infra-contact.mdtext
> 
> Modified: infrastructure/site/trunk/content/dev/infra-contact.mdtext
> URL: 
> http://svn.apache.org/viewvc/infrastructure/site/trunk/content/dev/infra-contact.mdtext?rev=1465544&r1=1465543&r2=1465544&view=diff
> ==
> --- infrastructure/site/trunk/content/dev/infra-contact.mdtext (original)
> +++ infrastructure/site/trunk/content/dev/infra-contact.mdtext Mon Apr  8 
> 07:03:56 2013
> @@ -119,7 +119,7 @@ before filing each ticket.
>  
>  # Requesting podling->TLP graduation # {#requesting-graduation}
>  
> -Please create the following jira tickets:
> +Please follow the [Graduation Guide][7], and then create the following jira 
> tickets:
>  
>  1. Create a "Graduate Foo to TLP" parent ticket.
>  
> @@ -259,3 +259,4 @@ Reminder: this facility is for emergency
>  [4]: http://people.apache.org/committers-by-project.html#infrastructure-root
>  [5]: https://svn.apache.org/repos/private/committers/board/committee-info.txt
>  [6]: http://incubator.apache.org/guides/mentor.html#Overview
> +[7]: http://incubator.apache.org/guides/graduation.html#project-first-steps

4.1 can be striken

4.7(a) can be striken

2.2 did not, ever, work as written.

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

Re: svn commit: r1465541 - /infrastructure/site/trunk/content/dev/infra-contact.mdtext

[Daniel Shahaf]

Reviewing this, the document you added a link to contains bugs.

Specifically,
http://incubator.apache.org/guides/mentor.html#Set+Up+Repository is
wrong (it contradicts 
http://www.apache.org/dev/infra-contact#requesting-podling)
and http://incubator.apache.org/guides/mentor.html#request-mailing-lists
is bitrotted (list addresses in the example are wrong).

I didn't check whether there are other bugs besides these two.

-- 
Not subscribed

cross...@apache.org wrote on Mon, Apr 08, 2013 at 06:51:26 -:
> Author: crossley
> Date: Mon Apr  8 06:51:26 2013
> New Revision: 1465541
> 
> URL: http://svn.apache.org/r1465541
> Log:
> Link to explanation of first steps for new podlings and the metadata summary 
> file.
> 
> Modified:
> infrastructure/site/trunk/content/dev/infra-contact.mdtext
> 
> Modified: infrastructure/site/trunk/content/dev/infra-contact.mdtext
> URL: 
> http://svn.apache.org/viewvc/infrastructure/site/trunk/content/dev/infra-contact.mdtext?rev=1465541&r1=1465540&r2=1465541&view=diff
> ==
> --- infrastructure/site/trunk/content/dev/infra-contact.mdtext (original)
> +++ infrastructure/site/trunk/content/dev/infra-contact.mdtext Mon Apr  8 
> 06:51:26 2013
> @@ -85,7 +85,8 @@ The podling creation process is as follo
>  
>  1. The IPMC vote passes.
>  
> -1. The podling is added to the IPMC's `podlings.xml` file with 
> `status=current`.
> +1. The podling is added to the IPMC's `podlings.xml` summary file with 
> `status=current`.
> +(See [notes][6] about that, and other initial tasks.)
>  
>  1. An ASF Member or PMC chair files [mailing list creation requests][2].
>  
> @@ -257,3 +258,4 @@ Reminder: this facility is for emergency
>  [3]: https://infra.apache.org/officers/webreq
>  [4]: http://people.apache.org/committers-by-project.html#infrastructure-root
>  [5]: https://svn.apache.org/repos/private/committers/board/committee-info.txt
> +[6]: http://incubator.apache.org/guides/mentor.html#Overview
> 
> 

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

Re: all podlings please update and maintain project metadata

[Daniel Shahaf]

Daniel Shahaf wrote on Thu, Mar 21, 2013 at 09:34:24 +0200:
> David Crossley wrote on Thu, Mar 21, 2013 at 17:52:26 +1100:
> > Christian Grobmeier wrote:
> > > Daniel Shahaf wrote:
> > > > Shane Curcuru wrote:
> > > >>
> > > >> Separately, I'd love to hear any comments about how this kind of
> > > >> requirement is expressed in the graduation guides.  I.e. is it clear,
> > > >> even to normal humans (i.e. 99.99% of the world who are not Incubator
> > > >> experts) that these things are required of TLPs before (and after)
> > > >> graduation?
> > > >
> > > > FWIW, https://www.apache.org/dev/infra-contact#requesting-graduation
> > > > seems to be read and followed by most graduating projects.
> > 
> > Ah, maybe we have identified the breakdown. Perhaps they skip
> > the Incubator documentation.
> > 
> > I reckon that we need to link in both directions.
> > 
> 
> Agreed: linking from #requesting-podling to the incubator.a.o page
> documenting the overall process from the podling's POV would make sense.
> Go for it :)

The point applies to both #requesting-podling and #requesting-graduation.

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

Re: all podlings please update and maintain project metadata

[Daniel Shahaf]

David Crossley wrote on Thu, Mar 21, 2013 at 17:52:26 +1100:
> Christian Grobmeier wrote:
> > Daniel Shahaf wrote:
> > > Shane Curcuru wrote:
> > >>
> > >> Separately, I'd love to hear any comments about how this kind of
> > >> requirement is expressed in the graduation guides.  I.e. is it clear,
> > >> even to normal humans (i.e. 99.99% of the world who are not Incubator
> > >> experts) that these things are required of TLPs before (and after)
> > >> graduation?
> > >
> > > FWIW, https://www.apache.org/dev/infra-contact#requesting-graduation
> > > seems to be read and followed by most graduating projects.
> 
> Ah, maybe we have identified the breakdown. Perhaps they skip
> the Incubator documentation.
> 
> I reckon that we need to link in both directions.
> 

Agreed: linking from #requesting-podling to the incubator.a.o page
documenting the overall process from the podling's POV would make sense.
Go for it :)

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

Re: all podlings please update and maintain project metadata

[Daniel Shahaf]

Shane Curcuru wrote on Wed, Mar 20, 2013 at 08:57:55 -0400:
> Separately, I'd love to hear any comments about how this kind of  
> requirement is expressed in the graduation guides.  I.e. is it clear,  
> even to normal humans (i.e. 99.99% of the world who are not Incubator  
> experts) that these things are required of TLPs before (and after)  
> graduation?

FWIW, https://www.apache.org/dev/infra-contact#requesting-graduation
seems to be read and followed by most graduating projects.

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

Re: Proposal for better docs on trademark research (Incubator)

[Daniel Shahaf]

In short: I think your text is good but belong on
www.apache.org/foundation/marks/ rather than on the incubator docs.

I'll reply on private lists with more detail

Christian Grobmeier wrote on Mon, Mar 18, 2013 at 16:40:49 +0100:
> On Mon, Mar 18, 2013 at 2:46 PM, Daniel Shahaf  
> wrote:
> >> > And BTW infra experience tells me info about execuding the PNS
> >> > process (PODLINGNAMESEARCH) should live on www.a.o/foundation/marks/,
> >> > but that might be an issue for another patch.
> >>
> >> Its PODLING name search. Because of this name I was looking in the
> >> incubator docs first.
> >> As long as it is not named "NAMESEARCH" only I think it belongs to the
> >> incubator.
> >
> > If you have a semantic argument (eg: why shouldn't Apache Steve have
> > been expected to run a name search at some point) I'll be glad to hear it.
> 
> afaik Apache Steve didn't go through the incubator, right?
> 
> Probably thats why they didn't do a name search:
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20PODLINGNAMESEARCH
> 
> I do not know if there is a policy for non-incubating
> projects/products to do a podlingnamesearch. If there is one, it makes
> certainly sense to rename the PODLINGNAMESEARCH into NAMESEARCH, move
> my docs out to a better place (trademarks) and communicate the policy
> to the projects (I didn't know much about podlingnamesearch until last
> week - I  know a few people who all thought it would be a "lazy
> consensus" thing).
> 
> That said, this is something which needs to be discussed on
> trademarks. And it will take some time for which i do not have the
> cycles right now.
> 
> My goal is to document what i have learned now in the hope it is of
> help to other podlings which need this information.
> 
> Are you fine with my commit or do you first want to start discussing
> at trademarks?
> 
> Cheers
> Christian
> 
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: [PROPOSAL] Automate Shepherd Assignments

[Daniel Shahaf]

Matt Franklin wrote on Mon, Mar 18, 2013 at 10:00:37 -0400:
> I will have to dig in to figure out how to accomplish this with the
> current infrastructure (any pointers welcome); but, I wanted to get
> buy-in on the concept first.

https://svn.apache.org/repos/private/foundation/board/scripts/assign.py

If you want to reuse that it'll probably be easiest if you move the
report to a .txt file in svn.  Basically mimic the existing board report
procedure for TLPs (except you might want to do that in
a publicly-readable svn tree).

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

Re: Proposal for better docs on trademark research (Incubator)

[Daniel Shahaf]

Christian Grobmeier wrote on Mon, Mar 18, 2013 at 14:00:52 +0100:
> On Mon, Mar 18, 2013 at 11:28 AM, Daniel Shahaf  
> wrote:
> 
> >> +GitHub
> >> +SourceForge.net
> >> +Google Code
> >> +Ohloh
> >> +http://tsdr.uspto.gov";>USPTO
> >> +Google, Bing, Yahoo
> >> + >> href="http://www.trademarkia.com";>Trademarkia
> >
> > Errr.  Isn't this list of resources already available on another page?
> > If so please just point to it, rather than duplicate it.  (There should
> > be exactly one canonical location for such info.)
> 
> I didn't find one,

/me surprised

> thats why I took the time and worked on this docs.
> I extracted the information from the old Jira issues.
> 

Thanks.

> > And BTW infra experience tells me info about execuding the PNS
> > process (PODLINGNAMESEARCH) should live on www.a.o/foundation/marks/,
> > but that might be an issue for another patch.
> 
> Its PODLING name search. Because of this name I was looking in the
> incubator docs first.
> As long as it is not named "NAMESEARCH" only I think it belongs to the
> incubator.

If you have a semantic argument (eg: why shouldn't Apache Steve have
been expected to run a name search at some point) I'll be glad to hear it.

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

Re: Proposal for better docs on trademark research (Incubator)

[Daniel Shahaf]

[ NOTE, crossposted public/private lists ]

Christian Grobmeier wrote on Mon, Mar 18, 2013 at 09:43:46 +0100:
> Hello,
> 
> I would like to commit that. Any objections? (spelling corrections
> welcome, right now or after the commit)
> 
> cheers
> 
> 
> $ svn diff
> Index: content/guides/graduation.xml
> ===
> --- content/guides/graduation.xml (revision 1457669)
> +++ content/guides/graduation.xml (working copy)
> @@ -285,6 +285,33 @@
>and some common-sense hints for
> href="http://apache.org/dev/project-names.html";>Choosing names for ASF
> projects.
>  
> +
> +Before a podling can graduate, a "podling
> suitable names search" must be done. For this, please open
> +a JIRA request in the  href="https://issues.apache.org/jira/browse/PODLINGNAMESEARCH";>Podling
> Suitable Names Searc JIRA space. They should look like:

Search

> +
> +
> + href="https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-26";>Apache
> Open Climate Workbench
> + href="https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-27";>Apache
> Onami
> +
> +
> +
> +Please consider to research at least the following 
> sources:
> +
> +GitHub
> +SourceForge.net
> +Google Code
> +Ohloh
> +http://tsdr.uspto.gov";>USPTO
> +Google, Bing, Yahoo
> + href="http://www.trademarkia.com";>Trademarkia

Errr.  Isn't this list of resources already available on another page?
If so please just point to it, rather than duplicate it.  (There should
be exactly one canonical location for such info.)

And BTW infra experience tells me info about execuding the PNS
process (PODLINGNAMESEARCH) should live on www.a.o/foundation/marks/, 
but that might be an issue for another patch.

> +
> +
> +
> +Note all results in the according JIRA issues.
> When done, inform trademarks @ apache.org that you have finished your
> research. Please wait, until the trademarks team has interpreted your
> findings and theV.P. Branding approves your request. Trademark

It's important that the jira records only facts and not interpretations
of them.  That's one of the reasons you should avoid re-describing the
process, and should instead just link to wherever it's already
documented at.

Also, missing space.  Next time consider running a spellchecker.

> acceptance is not decided by lazy consens.

consensus

> +
> +
> +Onces the name is approved, you can resolve the

Once

> JIRA issue and update your status page.
> +
>  
> 
>  

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

Re: Please publish the incubator website, when did changes

[Daniel Shahaf]

Christian Grobmeier wrote on Wed, Mar 13, 2013 at 07:41:32 +0100:
> It would be better if the person who pushed a change (most often the
> status page) would also publish the website right after. Otherwise the
> next publisher will never knew if publication is desired or not.

(speaking on my experience with the www site, not the incubator site:)

Generally I skim the change and assume it's publishable unless it's
obviously spam (has never happened) or there's hunk at the top of the
diff saying "Don't publish me yet please".

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

Re: Suggested change to the ppmc guide

[Daniel Shahaf]

I believe the change represents current IPMC consensus but it'd be nice
if the change documented the rationale for the policy as well (at least
in the log message).

Daniel
(last week I ran into a 10 years old change that didn't have any
justification anywhere)

Chip Childers wrote on Wed, Mar 06, 2013 at 10:00:10 -0500:
> Hi all,
> 
> After spamming the private@i.a.o list, and being asked to stop it, I'd
> like to suggest the following changes to the PPMC guide:
> 
> 
> Index: content/guides/ppmc.xml
> ===
> --- content/guides/ppmc.xml (revision 1453351)
> +++ content/guides/ppmc.xml (working copy)
> @@ -168,7 +168,8 @@
>[VOTE] Joe Bob as committer. The [VOTE] message should be forwarded
>to the IPMC (mailto:priv...@incubator.apache.org";>
>priv...@incubator.apache.org) to notify them that the
> -  vote is underway
> +  vote is underway. Do not BCC or CC the IPMC on the VOTE thread.
> +  Instead, forward the initial VOTE email.
>  
>To be successful the vote requires at least three +1 votes
>from PPMC members, including at least one +1
> @@ -179,7 +180,8 @@
>a message to the PPMC private alias, and forward it to the IPMC,
>with the subject line of [VOTE][RESULT] Joe Bob as committer.
>The message should include the usual vote tally, indicating which
> -  mentor or IPMC member votes cause it to be valid.
> +  mentor or IPMC member votes cause it to be valid. Do not
> +  BCC or CC the IPMC on the results email.  Instead, forward it.
> 
>  
>
> @@ -229,8 +231,9 @@
>[VOTE] Joe Bob PPMC membership. The [VOTE] message should be forwarded
>to the IPMC (mailto:priv...@incubator.apache.org";>
>priv...@incubator.apache.org) to notify them that the
> -  vote is underway. If the vote is successful, the proposer should send 
> -  a message to the PPMC private alias, with
> +  vote is underway. Do not CC or BCC the IPMC on this thread.  Instead,
> +  forward the initial VOTE email.  If the vote is successful, the 
> proposer 
> +  should send a message to the PPMC private alias, with
>the subject line of [VOTE][RESULT] Joe Bob PPMC membership. The
>message id of the [VOTE][RESULT] message should be preserved for
>the message to the Incubator PMC after Joe Bob accepts. Now, Joe Bob
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Incubator PMC/Board report for Mar 2013 ([ppmc])

[Daniel Shahaf]

David Crossley wrote on Tue, Mar 05, 2013 at 11:40:45 +1100:
> Daniel Shahaf wrote:
> >
> > @(tez|knox).incubator.apache.org lists had been created.
> 
> Thanks. When Clutch detects that messages are flowing to the mbox
> then it flags the list as ready.
> They are not yet at the index page of 
> http://mail-archives.apache.org/mod_mbox/
> 

knox lists will appear on that page 24 hours after there is an email to
them.  tez haven't requested list creation (the "tez.apache.org"
container exists, but I didn't notice earlier that it is empty).

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

Re: No more existing-TLP graduations (was: [PROPOSAL] Curator for the Apache Incubator)

[Daniel Shahaf]

I suppose if a new product + its community want to become part of a PMC,
coding could happen under that PMC (so for example: in a branch of their
repository, releases require 3 +1's by that PMC), but with IPMC or
comdev watching from the sidelines and helping if needed.

Over at Subversion we once solicited comdev input on a community issue
surrounding a potential GSoC volunteer.  That's the same pattern: coding
parts handled by the TLP and advice on community issues by comdev|incubator.

Mattmann, Chris A (388J) wrote on Sat, Mar 02, 2013 at 05:02:37 +:
> Hi Niall, and Greg,
> 
> Just to echo Greg, +1, yes would have preferred it to have happened in the
> existing
> community then.
> 
> Also, agree with Greg -- exceptions can be permitted from time to time,
> but I don't think
> graduation into existing TLP should be an accepted norm.
> 
> Cheers,
> Chris
> 
> On 3/1/13 8:55 PM, "Greg Stein"  wrote:
> 
> >On Mar 1, 2013 8:33 PM, "Niall Pemberton" 
> >wrote:
> >>
> >> On Tue, Feb 26, 2013 at 9:52 PM, Greg Stein  wrote:
> >> > I concur with Chris, and want to strengthen/meta the point. The
> >Incubator
> >> > should not be used for projects which are intended to become part of
> >>an
> >> > existing TLP. The Incubator *creates* Apache-style communities. But...
> >Stop.
> >> >
> >> > For these, we don't want a separate/new community. They are supposed
> >>to
> >be
> >> > *part of* the existing TLP. Thus, they have no business here. They
> >should
> >> > start within the target TLP.
> >>
> >> The incubation of WebWork into Struts is an example where there was an
> >> existing project outside the ASF with an existing bunch of developers
> >> that were not ASF committers. The point of going through the incubator
> >> was for the communities to merge. I guess at the time we could have
> >> just given comitt access to all WebWork devs - but most of us on the
> >> Struts project didn't know them. Is that what you're proposing should
> >> happen in this scenario?
> >
> >Yup.
> >
> >The Incubator doesn't have "staff". It really doesn't make sense to put a
> >community in their hands. Either a community self-builds, or it should
> >become part of an existing community.
> >
> >For the WebWorks case, I would rather have seen them get a branch in
> >Struts. Over time, the features would get integrated from the branch to
> >trunk, and the committers would get expanded commit access.
> >
> >I understand a project may arrive, thinking to become a TLP, but later
> >change their desired exit. But I think it would be best to call that an
> >exception. Instead, we let target communities directly teach the incomers
> >about operating within their (our ASF-style) community.
> >
> >Cheers,
> >-g
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Would you please give me a write access to http://wiki.apache.org/incubator ?

[Daniel Shahaf]

I think you need to edit ContributorsGroup to make the [[username a link]]


Mattmann, Chris A (388J) wrote on Wed, Feb 27, 2013 at 23:06:44 +:
> Hi there Joe,
> 
> I went ahead and granted karma.
> 
> Please let me know if it works. It might not since there are spaces in
> your wiki username,
> so if it doesn't work let me know.
> 
> Cheers,
> Chris
> 
> On 2/27/13 3:04 PM, "H. Joe Lee"  wrote:
> 
> >Hi,
> >
> >  I'd like to work on an incubation proposal through wiki.
> >  Would you please give me a "write" access?
> >
> >  My wiki user name is "H. Joe Lee".
> >
> >  Thanks,
> >
> >--
> >HDF: Software that Powers Science
> >
> >-
> >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >For additional commands, e-mail: general-h...@incubator.apache.org
> >
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Please help us granting rights to a new S4 committer

[Daniel Shahaf]

Sendingasf-authorization-template
Transmitting file data .
Committed revision 851328.

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

Re: Wiki privs

[Daniel Shahaf]

Nick Burch wrote on Wed, Feb 20, 2013 at 11:55:54 +:
> On Tue, 19 Feb 2013, Arun C Murthy wrote:
>> Help, please?
>
> I've added you to this list. Two things though, firstly usernames with  
> spaces in aren't that usual, so you should check it works. Secondly, an  

[[Arun Murthy]] would work (i.e., make it a link).

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Sat, Feb 02, 2013 at 18:06:11 +0100:
> On 02.02.2013 16:29, Daniel Shahaf wrote:
> > Branko Čibej wrote on Sat, Feb 02, 2013 at 11:01:42 +0100:
> >> I'm all for moving this from minotaur to whimsy, and do suggest we
> > whimsy doesn't have the public-arch tree locally.
> 
> Thanks for reminding me again ... silly me.
> 
> >> change the incubator.a.o server config so that the votes table can be
> >> fetched from there.
> >>
> > Not specific enough to comment on.  (Change how?)
> 
> Either:
> 
> LoadModule headers_module /.../mod_headers.so
> 
> I've already put the following in the .htaccess file:
> 
> 
> # Allow remote content from people.apache.org in order to fetch vote 
> status
> Header set Access-Control-Allow-Origin "http://people.apache.org";
> 
> 
> Or:
> 
> ProxyPass /remote/embedded-votes.html 
> http://people.apache.org/~brane/incubator/embedded-votes.html
> 
> and I'll change the URL of the generated table in votes.xml.
> 
> A simple redirect will of course not work, as it triggers the same
> access restriction. The proxy solution doesn't open the door as wide,
> but I expect it's slightly more expensive than adding a header to the
> response. Either way should work.

Thanks for the config snippets, but my opinion is unchanged: if this is
to be available via http://incubator.apache.org/, it should get
committed somewhere.  (This will be consistent with how every docroot on
the www box works)  For your use-case it would be ok have a cron'd
buildbot job that commits directly to the production tree --- that's how
the twitter feed on www.apache.org gets updated.

The alternative would be to leave the code on people.a.o or add some
"rsync minotaur:public-arch/ ./" calls and move it to whimsy.

Or feel free to ask site-dev@ or infra@ for other opinions.

Daniel

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Sat, Feb 02, 2013 at 11:01:42 +0100:
> On 01.02.2013 18:05, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, Feb 01, 2013 at 17:29:45 +0100:
> >> I think updating the httpd config is the more realistic option, since it
> >> doesn't presume a ssh tunnel between minotaur and the site server.
> > The only supported way to get content to the web servers is to commit it
> > to svn and have svnpubsub pull it to them.
> >
> > So, just have a cronjob on minotaur commit the changes.  You can get
> > a username+password for that by asking.
> 
> Surely it doesn't make sense to commit this transient table. If I wanted
> that, I'd be generating (and committing) all of content/votes.xml
> instead. But I really think the voting status page should be updated
> more often than once a day, hence the current architecture that doesn't
> depend on incubator site updated.
> 
> I'm all for moving this from minotaur to whimsy, and do suggest we

whimsy doesn't have the public-arch tree locally.

> change the incubator.a.o server config so that the votes table can be
> fetched from there.
> 

Not specific enough to comment on.  (Change how?)

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

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Fri, Feb 01, 2013 at 17:29:45 +0100:
> I think updating the httpd config is the more realistic option, since it
> doesn't presume a ssh tunnel between minotaur and the site server.

The only supported way to get content to the web servers is to commit it
to svn and have svnpubsub pull it to them.

So, just have a cronjob on minotaur commit the changes.  You can get
a username+password for that by asking.

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

Re: Fwd: [Incubator Wiki] Update of "February2013" by RetoBachmannGmuer

[Daniel Shahaf]

Benson Margulies wrote on Thu, Jan 31, 2013 at 20:21:00 +:
> Can someone please explain this diffs to me?

Probably stripped trailing whitespace.

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Thu, Jan 31, 2013 at 16:40:14 +0100:
> I guess it's best if I ping infra and ask about getting this done (or
> probably file an INFRA ticket). Infra are also in the best position to
> know if we can have the page regenerated more often, e.g., once an hour.

The first issue I see is that your script assumes it has local access to
the public-arch tree, so it can only run on minotaur (or on the
mail-archives.a.o box).

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

Re: Incubator voting status page

[Daniel Shahaf]

David Crossley wrote on Tue, Jan 29, 2013 at 16:12:34 +1100:
> You are striking the same type of problems that Clutch has
> needed to deal with over the years. In general, the state of
> podling metadata is not reliable. That is something that we
> need to get podling developers interested with.
> 

I have a current example.  Flex and Wink haven't updated their
podlings.xml entries to
status="graduated"
, therefore certain infra scripts still consider them podlings rather
than PMCs.

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

Re: Incubator voting status page

[Daniel Shahaf]

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

They seem consistent with the other "new-style" podlings:

minotaur,9:~apmail/public-arch% find . -maxdepth 2 -name \*onami\* 
./onami.apache.org
minotaur,9:~apmail/public-arch% grep -h List-Id onami.apache.org/*/* | uniq
List-Id: 
List-Id: 
List-Id: 

Daniel

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

Re: Incubator voting status page

[Daniel Shahaf]

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

Yes, it is, for all *@p.i.a.o lists.

To your original question: I usually use podlings.xml/[status=current].

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

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

Re: Incubator voting status page

[Daniel Shahaf]

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

All new podlings use that scheme.  Helix was just the first one to use
it, there are already 3 others (and all podlings created from this point
on, too).

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Fri, Jan 25, 2013 at 15:27:25 +0100:
> I changed the vote counting script so that it parses /all/ the incubator
> list archives, not just general@, for vote threads addressed to

Do you also parse the d...@helix.incubator.apache.org archives, which are in
~apmail/public-arch/helix.apache.org/dev/ ?

> general@. This solved the case where, e.g., the Bloodhound vote
> resolution was not noticed.
> 

 251 N   Jan 24 Ryan Ollos  (  96) [RESULT] [VOTE] Release Apache Bloodhound
appears in the general@incubator archives.

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Thu, Jan 24, 2013 at 22:01:32 +0100:
> On 24.01.2013 17:19, Daniel Shahaf wrote:
> > Branko Čibej wrote on Thu, Jan 24, 2013 at 13:40:29 +0100:
> >> On 24.01.2013 13:25, Gary Martin wrote:
> >>> Interestingly, the form that Ryan announced the results means that it
> >>> looks like the Bloodhound vote is still open. I'll guess that markmail
> >>> doesn't take cc's as being on the list or something.
> >> In the meantime I changed the thing to parse the mbox archives directly.
> >> Apparently that vote result is not in the current mbox file, either.
> >> Don't ask me why. But we do seem to have problems with our mail archives.
> > The mbox files on minotaur should be up-to-date at all times.  (The ones
> > on mail-archives are only updated hourly.)  Was it CCed to general@ ?
> 
> It was. And it ended up in the bloodhound-dev archive, but not in the
> general archive.
> 
> I've noticed before that our archives seem to be incomplete, and indeed
> it appears that the mbox files contain only messages To: a list,
> everything that actually gets delivered to subscribers by the list server.
> 

Counterexample:

Message-ID: <20130124161931.GE3874@lp-shahaf.local>
Date: Thu, 24 Jan 2013 18:19:31 +0200
From: Daniel Shahaf 
To: Branko Čibej 
Cc: general@incubator.apache.org
Subject: Re: Incubator voting status page

appears in the mbox archives of this list.


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

Don't forget [CANCELED]...

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

Re: Incubator voting status page

[Daniel Shahaf]

Branko Čibej wrote on Thu, Jan 24, 2013 at 13:40:29 +0100:
> On 24.01.2013 13:25, Gary Martin wrote:
> > Interestingly, the form that Ryan announced the results means that it
> > looks like the Bloodhound vote is still open. I'll guess that markmail
> > doesn't take cc's as being on the list or something.
> 
> In the meantime I changed the thing to parse the mbox archives directly.
> Apparently that vote result is not in the current mbox file, either.
> Don't ask me why. But we do seem to have problems with our mail archives.

The mbox files on minotaur should be up-to-date at all times.  (The ones
on mail-archives are only updated hourly.)  Was it CCed to general@ ?

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

Re: Incubator voting status page

[Daniel Shahaf]

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

~apmail/public-arch/incubator.apache.org/general/

?

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

Re: Citing documentation when critiquing podlings

[Daniel Shahaf]

You mean http://www.producingoss.com/en/growth.html#using-archives ?
(the first paragraphs apply just a well to documentation as to mail archives)

Benson Margulies wrote on Mon, Jan 21, 2013 at 13:54:07 -0500:
> I'd like to float the following idea:
> 
> Any time anyone offers a critique of a podling release (or other
> behavior), include a URL to the documentation that should have told
> them how to do the job.
> 
> If you can't find any document, then say so. If there is one, and you
> don't think it's clear, cite it and say so.
> 
> -
> 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: Clean up users who are members of the "incubator" group and no other?

[Daniel Shahaf]

Benson Margulies wrote on Thu, Jan 10, 2013 at 06:18:19 -0500:
> This is a bit mysterious to me, as I thought that there wasn't one of
> these. I've been following prior precedent and adding people
> individually to the SVN acls for individual projects, not using a
> group at all.
> 

'incubator' group is assigned at account creation.

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

Re: First attempt at January2013 report template

[Daniel Shahaf]

David Crossley wrote on Wed, Jan 02, 2013 at 16:40:11 +1100:
> Jukka Zitting wrote:
> > David Crossley kirjoitti:
> > > 
> > > It all requires podlings to keep the project metadata up-to-date!
> > > Clutch can only use the data that it is fed. The poor state of
> > > the metadata has many ramifications.
> > >
> > > The main laggards are "graduated" projects.
> > >
> > > That behaviour will cause similar issues when they are TLPs.
> > 
> > True, though we should always remember that we are here primarily to write
> > great open source software and help others do so, not to maintain
> > impeccable project metadata.
> >
> > The main beneficiaries of good podling metadata are the IPMC and the tools
> > we use to guide Incubator processes, while the podlings themselves gain
> > little direct value from updating Incubator records.
> 
> I see that main ASF Infra are starting to utlilise the podling
> metadata for setting up the TLP resources.

Infra only uses the status='current' attribute of podlings.xml.

That said, we use it once in a script that podlings need to use when
they enter (mlreq), and once in a script the podlings use when they
graduate (no UI name).  So podlings have an incentive to keep the
'status' attribute up-to-date both at creation and at graduation.

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

Re: [VOTE] Apache Oltu (formerly Apache Amber) graduation resolution

[Daniel Shahaf]

Shane Curcuru wrote on Fri, Dec 21, 2012 at 08:36:58 -0500:
> The bad news is that there is another software project with "Oltu" in  
> the name (google "oltu software", since trademarks are only important  
> within general categories of products).  The good news is it seems to  
> simply be a streaming app for some Turkish (?) radio station - so I'm  
> confident we have nothing to fear from confusion with them.  The point  

Is "Oltu" a Turkish word?  What does it mean?

> is that it's important to include trademarks@ in your podling name 
> searches.

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

Re: Do all releases need to go to /dist?

[Daniel Shahaf]

Benson Margulies wrote on Fri, Dec 21, 2012 at 07:01:03 -0500:
> On Fri, Dec 21, 2012 at 6:58 AM, Marcel Offermans
>  wrote:
> > Well, I don't think it's fine. As long as our release policy states that 
> > all releases must be archived on /dist we should do exactly that. Or change 
> > the policy.
> 
> Give me a URL where this policy is and I'll edit it.

The way to change a policy is to obtain consensus on the new policy, not
to edit the web page that documents the existing policy --- particularly
when someone just expressed an opinion in favour of the documented policy.

You're setting a good counter-example to podlings.

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

Re: PPMC versus commiter

[Daniel Shahaf]

Christian Grobmeier wrote on Thu, Dec 20, 2012 at 05:47:56 +0100:
> On Thu, Dec 20, 2012 at 5:44 AM, Joe Schaefer  wrote:
> > That's just RBD's signature boilerplate for a document he likely started.  
> > Feel free to remove it if you think it detracts from the document.
> >
> 
> I leave the labeling of a document to the people who worked on it

So ask Shane or site-dev@ to remove the label.

(That's assuming you agree the label does not belong on the document ---
ie, that the current text is accurate.)

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

Re: PPMC versus commiter

[Daniel Shahaf]

Ross Gardler wrote on Wed, Dec 19, 2012 at 22:13:17 +:
> Christian, you can review any podling I'm a mentor on, including AOO, to
> see discussion of both models. I'm sure many other projects have discussed
> this too.
> 
> The page you refer to is correct, there are two separate roles as
> recognised by the foundation.
> 
> You do have a point that things can be documented more clearly, they always
> can be, but I don't think the how it works page is at fault. That page
> doesn't describe how someone gets those roles, it merely defines the roles
> the foundation recognises.

http://www.apache.org/foundation/governance/pmcs#merit describes both
modes of operation.

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

Re: PPMC versus commiter

[Daniel Shahaf]

Mattmann, Chris A (388J) wrote on Wed, Dec 19, 2012 at 16:35:51 +:
> Making someone a C without PPMC gives them the power to evolve the code,
> but not to help make decisions about how can maintain it, or when to
> release it. Something about that, I just don't find right.

You _don't need to have commit access_ to do either of those things.

Do you want examples?  One of the reasons Subversion 1.7.0-rc1 did not
become GA is that one of our users pointed out that the new backend was
missing some trait that 1.6 had had.  We pulled the entire new backend
over that, and released rc2 --- and eventually 1.7.0 proper --- without
that backend.

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

Re: PPMC versus commiter

[Daniel Shahaf]

Benson Margulies wrote on Wed, Dec 19, 2012 at 07:43:19 -0500:
> 3. Legally/organizationally, since PPMC members don't have binding
> votes, there's not much practical effect of making a distinction. At
> the end of the day, only Incubator PMC members have binding votes.

The practical differences are:

- Can work on security bug reports (on security@a.o+podling-private@)
- Can vote on new committers/PPMC members
- Is default candidate for PMC membership at graduation

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

Re: Release mirroring

[Daniel Shahaf]

svnpubsub isn't enabled for your dist area.  You need to ask infra to set
that up

Alexander Broekhuis wrote on Sun, Dec 16, 2012 at 20:18:37 +0100:
> Hi all,
> 
> I've added the first celix release to svn using the method described at
> [1]. During the vote the release was under dist/dev, and today I moved it
> to dist/release.
> On [1] it states that the release is mirrored to the master immediately,
> but I can't find the celix release there..
> 
> What did I do wrong?
> 
> [1]: http://www.apache.org/dev/release.html#upload-ci
> 
> -- 
> Met vriendelijke groet,
> 
> Alexander Broekhuis

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

Re: New tool for setting up the monthly report

[Daniel Shahaf]

Benson Margulies wrote on Thu, Dec 13, 2012 at 22:15:37 -0500:
> In 1421649, I've added clutch2report.py. Run this, and out pops
> report.txt, which can then be pasted into the wiki page.
> 

I wonder how complicated it might be to make it also create the say
January2013 wiki page?

(and then to cron it)

> Note that it uses the current date to select the reporting group, so
> it has to be run after the first of the month, unless I or someone
> else tweak that.
> 
> By the way, clutch.py has a number of complaints about the state of
> this and that. I'll be sending emails ...
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Incubator report reminders sent for Dec 2012

[Daniel Shahaf]

On Sat, Dec 01, 2012 at 07:20:35PM +0100, Christian Grobmeier wrote:
> I miss Onami and Ripple from the reminders.
> 

Helix and HDT are also missing; these four are all set up as
${podling}.incubator.apache.org - related?

> But they are listed here:
> http://incubator.apache.org/report-next-month.html#onami
> 
> What do I need to fix to get these reminders?
> I just know the old "wiki"-styled process
> 
> 
> On Sat, Dec 1, 2012 at 4:26 PM, Marvin  wrote:
> >
> >
> > The next board meeting is scheduled for Wed, 19 December 2012, 10:00:00 PST.
> >
> > I have just sent reminder emails to the below addresses, requesting them
> > to supply board reports 2 weeks before the above date (Wed, Dec 5th).
> >
> > Please recall that the Incubator report is due Wed, Dec 12th.
> >
> > Allura Developers   
> > Bloodhound Developers   
> > Blur Developers 
> > cTAKES Developers   
> > Drill Developers
> > Etch Developers 
> > Flex Developers 
> > Hadoop Development Tools Developers 
> > 
> > HCatalog Developers 
> > Kalumet Developers  
> > Openmeetings Developers 
> > S4 Developers   
> > Wave Developers 
> >
> > -
> > To unsubscribe, e-mail: private-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: private-h...@incubator.apache.org
> >
> 
> 
> 
> -- 
> http://www.grobmeier.de
> https://www.timeandbill.de
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Invoke silent consensus rule for podling releases

[Daniel Shahaf]

Make every vote a bugzilla issue, and use the existing script that mails
an issue summary once a week?


Ross Gardler wrote on Sat, Dec 01, 2012 at 14:55:05 +:
> That tool would be useful in more places than the incubator. Great idea.
> I'm looking forward to seeing it ;-)
> 
> Sent from my tablet
> On Dec 1, 2012 2:51 PM, "Branko Čibej"  wrote:
> 
> > On 01.12.2012 15:06, Marvin Humphrey wrote:
> > > On Fri, Nov 30, 2012 at 9:08 PM, Branko Čibej  wrote:
> > >> It's quite frustrating that people find time to write hundreds of mails
> > >> about points of procedure, but can't take time to review a release
> > >> tarball from a podling.
> > > Reviewing a release when you are not directly involved as a developer is
> > > **really hard**.
> > >
> > > As an IPMC member yourself, have you ever reviewed a release for podling
> > you
> > > were not involved with?
> >
> > Yes. In fact, I spent time reviewing AOO incubator releases. Don't
> > recall if I actually voted on one; probably not, since there were so
> > many other active IPMC members all over that.
> >
> > > I hereby propose we extend the silent consensus rule to podling
> > > release votes.
> > > -1
> > >
> > > That's at odds with basic, ASF-wide rules for voting on releases.
> >
> > I know; but it got everyone's attention, didn't it. :)
> >
> > What I'd more seriously like to propose is that we come up with a tool
> > that slurps the general@ archives and pings the list once a week with a
> > reminder about outstanding votes. I'll happily invest my copious free
> > time towards that, if the IPMC agrees such a tool would be useful.
> >
> > -- Brane
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >

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

Re: Formats of SHA/MD5 checksums

[Daniel Shahaf]

Daniel Shahaf wrote on Sat, Dec 01, 2012 at 07:25:54 +0200:
> Jake Farrell wrote on Thu, Nov 29, 2012 at 22:02:16 -0500:
> > That page is part of the Apache CMS and ASF members can edit that page  
> > by using the following http://www.apache.org/dev/cms.html#usage. Non ASF  
> > members can create a ticket within jira under the infra project and  
> > attach a patch for the changes they would like to make.
> >
> 
> Actually, if there's consensus, any ASF member can edit the page
> directly (but not publish the change).

s/member/committer/


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

Re: Formats of SHA/MD5 checksums

[Daniel Shahaf]

Jake Farrell wrote on Thu, Nov 29, 2012 at 22:02:16 -0500:
> That page is part of the Apache CMS and ASF members can edit that page  
> by using the following http://www.apache.org/dev/cms.html#usage. Non ASF  
> members can create a ticket within jira under the infra project and  
> attach a patch for the changes they would like to make.
>

Actually, if there's consensus, any ASF member can edit the page
directly (but not publish the change).

> The repo and file you are looking for is  
> https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/dev/release-signing.mdtext
>
> -Jake
>
>> Roman Shaposhnik 
>> November 29, 2012 9:05 PM
>> +infra
>>
>> Ping! I would really like this annoyance to be resolved one way or the other.
>> Could somebody more experienced with Apache web properties answer
>> the question?
>>
>> 
>>> Question: how do we go about discouraging it then? Do we need a vote
>>> to modify the content of:
>>> http://www.apache.org/dev/release-signing#md5
>>>
>>> Or even more basic question -- where's the source for that
>>> webpage?
>> 
>>
>> Thanks,
>> Roman.
>>
>> On Sun, Nov 25, 2012 at 9:29 PM, Roman Shaposhnik  wrote:
>>> On Tue, Nov 20, 2012 at 3:50 PM, sebb  wrote:
> Personally, I find it difficult to verify the GPG generated checksums.
 Ditto. It's particularly awkward when the hash is wrapped over several 
 lines.

 I ended up writing a Perl script to handle all the variations.

> If I'm not alone perhaps we should discourage the use of this
> format and modify the release FAQ page.
 +1
>>> Question: how do we go about discouraging it then? Do we need a vote
>>> to modify the content of:
>>> http://www.apache.org/dev/release-signing#md5
>>>
>>> Or even more basic question -- where's the source for that
>>> webpage?
>>>
>>> Thanks,
>>> Roman.

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

Re: Formats of SHA/MD5 checksums

[Daniel Shahaf]

Henk P. Penning wrote on Fri, Nov 30, 2012 at 10:08:33 +0100:
>   The reason given "I ended up writing a Perl script" doesn't
>   make sense ; .md5 files come in many forms but the algorithm
>   to verify is the same for all of them (there are no 'variations.') :
>
> verify (checksum md5, .md5-file fff) :
>   -- tmp = lowercase cat fff
>   -- md5 = lowercase cat md5
>   -- squeeze non-hex ([^a-f0-9]) out of tmp (and md5)

md5(1) on FreeBSD produces the literal text "MD5" as part of its output.

md5sum(1) on Linux prints the filename as part of its output.  The
filename usually contains a hex digit (such as the "a" in "tar" or "d"
in "hadoop").

Therefore just stripping non-hex-digits won't work with the standard md5
computation tools on those two platforms.

>   -- match md5 ~ tmp
>
>   HPP
>
>    _
> Henk P. Penning, ICT-beta R Uithof WISK-412  _/ \_
> Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> Budapestlaan 6, 3584CD Utrecht, NLF +31 30 253 4553 \_/ \_/
> http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

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

Re: Formats of SHA/MD5 checksums

[Daniel Shahaf]

Roman Shaposhnik wrote on Thu, Nov 29, 2012 at 18:05:15 -0800:
> +infra
> 
> Ping! I would really like this annoyance to be resolved one way or the other.
> Could somebody more experienced with Apache web properties answer
> the question?
> 
> 
> > Question: how do we go about discouraging it then? Do we need a vote

Don't know.  What's "it" ? 

> > to modify the content of:
> >http://www.apache.org/dev/release-signing#md5

Ask your question in terms of release practices / policies, not in terms
of web pages documenting them, please.

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

New graduation jiras

[Daniel Shahaf]

http://www.apache.org/dev/infra-contact#requesting-graduation
outlines the jira tickets infra would like to see when a project
requests resources migration at TLP graduation.  The biggest change is
that DNS/website/mailinglists are handled by 1 ticket.

Some caveats not documented there are:

- The PMC chair is still responsible for using modify_unix_group as
  appropriate --- we initialise the group membership on a best-guess
  basis, but the chair must check that it's accurate and add/rm people
  as needed.  modify_committee however is initialised directly from the
  Board resolution (thanks mostarda@ for the parsing code).

The under-the-hood is a new set of scripts that parse the board minutes
and automate a few common parts of the graduation process.

That's all --- I think everything else is documented on the link.
Questions?

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

Re: Committership of a podling

[Daniel Shahaf]

Craig L Russell wrote on Thu, Nov 22, 2012 at 14:16:28 -0800:
> If there is a difference between committers and PMC members of a  
> graduating podling, I don't think there is any process for identifying  
> which podling committers are to become new-project committers. It is not 
> in the board resolution. So it's up to the PMC to resolve.

+1

>
> I'd suggest having only the PMC members as initial committers and then  
> have the new PMC vote on adding podling committers to the new project  
> committer list. The vote could be a mass vote if no controversy...

No vote is needed, people simply retain their karmas.

(OT: really, "No vote is needed" is a phrase that needs to be heard
more.  If there is a "[DISCUSS] Joe Citizen for committership" thread
with 10 +1's over three days, there is _no need_ for a [VOTE] thread ---
consensus has been established, just go ahead and send The Invitation.)

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

Re: Committership of a podling

[Daniel Shahaf]

sebb wrote on Fri, Nov 23, 2012 at 00:08:53 +:
> On 22 November 2012 22:16, Craig L Russell  wrote:
> 
> ...
> 
> > If someone wants to scrape a file, I'd suggest adding a script to
> > foundation/board/scripts which would take the date as a parameter and then
> > scrape ../board_minutes_date to find the new projects.
> >
> > The result of scraping the file can include the apache ids of new PMC chairs
> > (for both graduating projects and change of chair) and the names of the new
> > projects and the apache ids of their PMC members. I could really use the
> > former (so I can grant karma to the new PMC chairs).
> 
> 
> that might be easier to achieve by first ensuring committee-info.txt
> is up to date, and then scraping that to compare the chairs against
> the LDAP group.

Personally I'd like to see committee-info.txt generated from LDAP, and
then just query LDAP rather than scrape anything.

Also, I'd like the board agenda to have a file per agenda item and to
have the files in parseable format:

% cat board_agenda_2012_11_21/7A
NEWPMC('ilgrosso', 'syncope', 'managing digital identities')
% 

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

Re: Committership of a podling

[Daniel Shahaf]

sebb wrote on Thu, Nov 22, 2012 at 15:10:50 +:
> On 22 November 2012 12:15, Daniel Shahaf  wrote:
> > sebb wrote on Thu, Nov 22, 2012 at 11:25:48 +:
> >> On 22 November 2012 10:42, Daniel Shahaf  wrote:
> >> > When a podling graduates, their unix group needs to created and
> >> > initialised with the committers of that podling.  Is it possible to get
> >> > that set of availid's programmatically?
> >> >
> >> > Basically, do I have options other than "use the authz file group, if
> >> > such exists".
> >>
> >> The authz file may well be out of date - it may contain dormant users.
> >>
> >> The official list of members of a new TLP is presumably provided in
> >> the board resolution.
> >
> > That list is the initial PMC members, not the initial committers.
> 
> Same thing for just about every new TLP as far as I know.
> The only exception I can think of is OpenOffice.

And Syncope - who happen to be the most recent TLP to file their
graduation jiras.

So, no, I'm not going to assume that PMC==committers.

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

Re: Committership of a podling

[Daniel Shahaf]

sebb wrote on Thu, Nov 22, 2012 at 11:25:48 +:
> On 22 November 2012 10:42, Daniel Shahaf  wrote:
> > When a podling graduates, their unix group needs to created and
> > initialised with the committers of that podling.  Is it possible to get
> > that set of availid's programmatically?
> >
> > Basically, do I have options other than "use the authz file group, if
> > such exists".
> 
> The authz file may well be out of date - it may contain dormant users.
> 
> The official list of members of a new TLP is presumably provided in
> the board resolution.

That list is the initial PMC members, not the initial committers.

> I don't know how easy that is to scrape.

Doable.  Michelle implemented it in Python, and Sam in Ruby.

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

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

Committership of a podling

[Daniel Shahaf]

When a podling graduates, their unix group needs to created and
initialised with the committers of that podling.  Is it possible to get
that set of availid's programmatically?

Basically, do I have options other than "use the authz file group, if
such exists".

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

Re: [DISCUSS] Apache Mayhem proposal

[Daniel Shahaf]

Renaming later (a) creates work for infra, (b) forces the community to
expend effort communicating the rename to the world.  So id'd be better
to settle the name sooner rather than later.

Mohammad Nour El-Din wrote on Tue, Nov 06, 2012 at 20:57:26 +0100:
> Hi Christian...
> 
>Isn't that a step that should be done before graduation, in other words
> this should not stop going with the Incubator acceptance [VOTE] ?
> 
> 
> On Tue, Nov 6, 2012 at 3:23 PM, Christian Grobmeier 
> wrote:
> 
> > Putting trademarks into the loop.
> >
> > Trademark people, any comments to Simones mail? I am not sure if a
> > commonly used word like "Mayhem" can be a matter of an trademark
> >
> > Thanks in advance,
> > Christian
> >
> > On Tue, Nov 6, 2012 at 2:27 PM, Simone Tripodi 
> > wrote:
> > > Good morning President :)
> > >
> > > Gianugo pointed me to the homepage of Make Mayem[1] and I found a
> > > trademarked software[2] which is called Mayhem as well.
> > > Trademarkia shows that more than 10 pages of results of products are
> > > registered with the name "Mayhem", which I suspect is a daily used
> > > word in English language, especially in the US.
> > >
> > > Giving an overview:
> > >
> > >  * _Make Mayhem_ is an application that lets you connect trigger
> > > events to reactions. Unlike writing a program, you simply select an
> > > event and a reaction, and then turn on the connection. Voila! No code
> > > or app required.
> > >
> > >  * _Mayhem_ is a computer software for use in the encryption and
> > > decryption of digital files, including audio, video, text, binary,
> > > still images, graphics and multimedia files
> > >
> > >  * _Apache Mayhem_ aims to create a community focused on the
> > > development and maintenance of a set of Google Guice extensions
> > >
> > > My question - IANAL and don't aim to be :P - is: where the legal
> > > issues comes out? We don't aim to "invade" someone else's domain...
> > > If the Mayhem is a trademark by Grey Heron Technologies, LLC for a
> > > software, aren't Outercurve's guys violating a TM?
> > >
> > > Sorry if asking silly questions, many thanks in advance!
> > > best,
> > > -Simo
> > >
> > > [1] http://www.makemayhem.com/
> > > [2] http://www.trademarkia.com/mayhem-85483903.html
> > > [3] http://www.trademarkia.com/trademarks-search.aspx?tn=Mayhem
> > >
> > > http://people.apache.org/~simonetripodi/
> > > http://simonetripodi.livejournal.com/
> > > http://twitter.com/simonetripodi
> > > http://www.99soft.org/
> > >
> > >
> > > On Tue, Nov 6, 2012 at 2:10 PM, Jim Jagielski  wrote:
> > >> Different topic: Is there a potential naming/trademark
> > >> issue related to a pre-existing project?
> > >>
> > >> http://www.outercurve.org/Galleries/InnovatorsGallery/Mayhem
> > >>
> > >> Thanks!
> > >>
> > >>
> > >> -
> > >> 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
> > >
> >
> >
> >
> > --
> > http://www.grobmeier.de
> > https://www.timeandbill.de
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
> 
> 
> -- 
> Thanks
> - Mohammad Nour
> 
> "Life is like riding a bicycle. To keep your balance you must keep moving"
> - Albert Einstein

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

Re: Anticipating my reign of terror -- new idea for December

[Daniel Shahaf]

Upayavira wrote on Mon, Nov 05, 2012 at 06:48:28 +:
> Having said that, I personally would like to see some kind of separation
> between mentors and the incubator PMC. I think th PMC should be a
> smaller, more active group who take a more active interest in the
> incubator as it is, and perhaps are voted in by proper meritocracy
> rules, and mentors are more interested in justd their project.
> 
> Not sure how to structure this in tems of voting rights though.
> 

What voting rights?  The ability of non-"smaller, more active group"
mentors to cast "PMC +1" votes on releases?

How about simply making those people full-fledged, equal-right PMC
members _for the duration of their mentorship_.  (That is: have them
join the PMC when they start mentoring a podling, and resign from the
PMC when that podling graduates or retires, or they step down from
mentorship.)  We trust them with exactly that power today...

> Upayavira
> 
> On Mon, Nov 5, 2012, at 03:20 AM, Roman Shaposhnik wrote:
> > On Sun, Nov 4, 2012 at 2:29 PM, Benson Margulies 
> > wrote:
> > > I want to thank all of you for the vote(s) of confidence in recommending 
> > > me
> > > as the IPMC chair. While it's always possible that the Board will decline
> > > the suggestion, it doesn't seem too terribly presumptuous to start looking
> > > ahead.
> > >
> > > My goal is to continue along the path blazed by Jukka, and then, like him,
> > > hand over. So, set your egg-timers for a bit more than a year, and think,
> > > please, about stepping up.
> > >
> > > I think that the shepherd system has worked well. At the same time, I 
> > > think
> > > that it was invented to compensate for a problem, and that we could make
> > > additional progress toward resolving that problem.
> > >
> > > Why do we have shepherds? Because we have had mentors who have found it
> > > impractical to exercise detailed supervision on the podlings. Our job as 
> > > an
> > > entire PMC is to supervise the podlings. It seems logical to me that the
> > > mentors of each podling would provide that supervision. Of course, things
> > > happen. Shepherds have been helping to detect holes and compensate for
> > > those things.
> > >
> > > With this idea in mind, for December, I do not want to eliminate 
> > > shepherds.
> > > But I want to float a proposal that might, over time, help us stop needing
> > > them.
> > >
> > > At the bottom of the template for each podling's report, I'd like to have 
> > > a
> > > space for each of the mentors, every month, to reaffirm his or her
> > > involvement in the podling. Thus, instead of (at most) one mentor signing
> > > off on the report, itself, we'd get a reading on how many mentors are in
> > > the game. If the number were less than 3 -- and -- especially, if it were
> > > less than one, we'd be alerted and could make it a priority to find
> > > replacements.
> > >
> > > What do you think?
> > 
> > +1 on the general idea.
> > 
> > Personally, I believe that anything that simplifies the structure of
> > the incubation
> > process is a good thing.
> > 
> > On that same note -- my current understanding is that the mentor
> > assignment is
> > pretty permanent for the duration of the incubation -- if that's
> > indeed the case,
> > perhaps having a more fluid process of mentor checking out and stepping
> > up
> > to help a project would also help us have a more positive experience for
> > the
> > poddlings.
> > 
> > IOW, for any other TLP there's a presumption that a single PMC (or
> > committer)
> > can have a certain amount of down time when, for whatever reason, they
> > may
> > completely go dark as far project involvement is concerned. I'm not sure
> > there's
> > such an option for a mentor.
> > 
> > Thanks,
> > Roman.
> > 
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> > 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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

Re: Release procedural question

[Daniel Shahaf]

Chip Childers wrote on Fri, Nov 02, 2012 at 14:47:33 -0400:
> On Fri, Nov 2, 2012 at 2:44 PM, Daniel Shahaf  wrote:
> > In my experience, 'gpg --verify' sometimes verifies only the first
> > signature in a file.
> 
> It appears to function correctly now:
...
> This is with version: gpg (GnuPG/MacGPG2) 2.0.18 / libgcrypt 1.5.0

Good to know, thanks.

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

Re: Release procedural question

[Daniel Shahaf]

Chip Childers wrote on Fri, Nov 02, 2012 at 14:27:24 -0400:
> On Fri, Nov 2, 2012 at 9:26 AM, Chip Childers  
> wrote:
> > Hi all,
> >
> > In reading the release policy section about the detached signature
> > file and the voting process, there is a mention about allowing (at the
> > RM's discretion) other PMC members (in a podling's case, PPMC members)
> > to concatenate their own signature to the *.asc release artifacts as
> > part of their +1 vote.
> >
> > As the RM for the (currently being voted on) CloudStack release, I
> > have been provided with another PPMC member's detached signature.
> >
> > Can someone please confirm that, after validating that adding the
> > signature to the asc file works, I'm allowed to use the new combined
> > signature file as the final release artifact?  Is there anything that
> > I should be aware of when adding this second signature?
> >

In my experience, 'gpg --verify' sometimes verifies only the first
signature in a file.  Hence:

[[[
% cat ~/bin/gpg-verify-many
#!/bin/sh
# perl -pe 'open STDOUT, "| gpg --verify - subversion-1.7.0-rc1.tar.gz" if 
/BEGIN/' < *rc1*asc

usage() {
  echo "USAGE: $0 \$foo.tar.gz \$foo.tar.gz.asc"
  echo "USAGE: $0 \$foo.tar.gz <\$foo.tar.gz.asc"
}

if [ $# -ge 2 ]; then
  ascfile=""
else
  ascfile="$1.asc"
fi

perl -pe 'BEGIN { $target = shift }  open STDOUT, "| gpg --verify - $target" if 
/BEGIN/' "$@" $ascfile
]]]

I don't know if that's still the case in more recent versions of gpg.

> > Thanks for the support and advice.
> >
> > -chip
> 
> Given the release policy [1] description of adding additional
> signatures to the release, and testing locally to ensure that the
> concatenated signature validates correctly, I will presume that this
> is a normal practice and move forward.
> 

It's normal practice.  Every Subversion release does it.

> Thanks!
> 
> -chip
> 
> [1] http://www.apache.org/dev/release.html#what-must-every-release-contain
> 
> -
> 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: ${podling}.incubator.apache.org

[Daniel Shahaf]

Jukka Zitting wrote on Thu, Oct 18, 2012 at 12:03:43 +0200:
> Hi,
> 
> On Fri, Oct 12, 2012 at 9:31 AM, Daniel Shahaf  
> wrote:
> > Do people mind if web sites (and maybe mailing lists) of new podlings
> > live at domains of the form "${podling}.incubator.apache.org"?
> 
> Sounds like we have consensus that this is a good idea. There were
> some concerns about going directly to ${podling}.apache.org, so let's
> not do that for now.
> 
> I'd like to suggest the new Ripple podling as a candidate for seeing
> how this will work out in practice. In practice I think we'd set up

You're a little late, helix's mailing lists have already been set up
this way.  (The podling hasn't asked for other resources yet.)

> the following resources:
> 
> a separate ripple LDAP group (but no ripple-pmc yet)

What would it be needed for?

> mailing lists as ${list}@ripple.incubator.apache.org (will this
> work with the list request form?)

No, for now request the old-naming-pattern and infra will take care of
adjusting the requests.  (trunk/mlreq/to-piao.sh)

> web site at http://ripple.incubator.apache.org/ (backed by
> /repos/asf/ripple/site)
> git repository at https://git-wip-us.apache.org/repos/asf/ripple.git
> 

I was assuming svn, git, and dist spaces remain "incubator/helix"
/ "incubator-helix.git".

> Any objections or corrections?
> 
> BR,
> 
> Jukka Zitting
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

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