[jira] [Commented] (COMDEV-545) Reporter should self-host the files from FontAwsome

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17852925#comment-17852925
 ] 

Christopher Tubbs commented on COMDEV-545:
--

A lot of projects would benefit from having these hosted in a central area for 
all of apache.org, for any project website to use, along with jquery and 
bootstrap static website assets, and in a layout to support multiple versions 
of each because not all projects will use the current version.

> Reporter should self-host the files from FontAwsome
> ---
>
> Key: COMDEV-545
> URL: https://issues.apache.org/jira/browse/COMDEV-545
> Project: Community Development
>  Issue Type: Bug
>  Components: Reporter Tool
>Reporter: Sebb
>Priority: Major
>
> The code current downloads fonts from FontAwsome.
> We don't (and won't) have a DPA with them, so this is not allowed.
> The fonts need to be hosted locally.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

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

Re: "Maintainer" as an alias of PMC Member?

[Christopher]

On Sat, Mar 23, 2024 at 6:06 PM Gary Gregory  wrote:
>
> On Sat, Mar 23, 2024 at 4:59 PM Christopher  wrote:
> >
> > Delegate implies designated authority/responsibility, more than
> > "maintainer" or "member", I think. The PMC role is delegated by the
> > ASF Board (usually lazily, upon notice by existing PMC members). So, I
> > think the word technically works here, but I won't argue that it's
> > that much better than "PMC member", but I'll point out that "member"
> > on its own has similar questions: member of what?
>
> Uh? Member of the PMC!

Based on this response, I'm not sure I was clear. My point was that
you could answer the question similarly for member as you could for
delegate:
1. Member of what? the PMC
2. Delegate to what? the PMC

It's not exactly identical... maybe "delegate" raises more
questions... I don't know what other people think when they hear that
word. My point was that it was kind of similar... if used on its own.
But used in conjunction with "PMC", it's not really unclear: "PMC
Member" vs. "PMC Delegate" seems pretty much equivalent to me. Perhaps
that's not the case for others. I can only speak to what happens in my
own brain.

In any case, like I said, I'm not particularly fond of it either. So
I'll leave it to others to debate. It was just a suggestion.

>
> Gary
>
> The main argument
> > I'll make is that we don't use the word delegate in any other context,
> > so it's less likely to cause confusion.
> >
> > Others to consider might be: associate (PMC-A) or representative (PMC
> > Rep, or PMC-R).
> >
> > I thought "maintainer" was okay, because it implies some
> > responsibility for the project... rather than merely somebody who
> > occasionally contributes. But the wording is a bit confusing, because
> > you're not exactly a "PMC maintainer" or "somebody who maintains the
> > PMC". A maintainer would maintain the project, not the PMC for the
> > project. So, it's more accurate to say a "PMC member" is a " > name> maintainer". So, it doesn't quite work to replace the word
> > "member", which I think is part of the goal.
> >
> > Personally, I'm not particularly fond of any of these... I don't have
> > a problem using the more explicit "PMC Member" either...  but these
> > are suggestions that might work if somebody were to really champion
> > one of them to help reduce confusion for non-native English speakers,
> > or anybody who tends to prefer nominative uses of language over
> > descriptive uses and needs an unambiguous shortname.
> >
> > On Sat, Mar 23, 2024 at 4:34 PM Gary Gregory  wrote:
> > >
> > > Delegate from what to what?
> > >
> > > "member" is fine IMO.
> > >
> > > Gary
> > >
> > > On Sat, Mar 23, 2024, 4:14 PM Christopher  wrote:
> > >
> > > > Delegate?
> > > >
> > > > On Sat, Mar 23, 2024 at 3:42 PM Gary Gregory 
> > > > wrote:
> > > > >
> > > > > I don't like "maintainer" here, a PMC member has a LOT more
> > > > > responsibility than the name implies IMO.
> > > > >
> > > > > "Maintainer" and "Contributor" feel almost interchangeable where a
> > > > > contributor might be a one-off and a maintainer more active. But we're
> > > > > splitting hair here IMO.
> > > > >
> > > > > Gary
> > > > >
> > > > > On Sat, Mar 23, 2024 at 3:17 PM Craig Russell 
> > > > wrote:
> > > > > >
> > > > > > I totally get the problem. I think if we can find a suitable title 
> > > > > > for
> > > > PMC Member we could socialize it in a few years. Should have done this
> > > > years ago.
> > > > > >
> > > > > > But "Maintainer" does not do it for me. Keep looking...
> > > > > >
> > > > > > Craig
> > > > > >
> > > > > > > On Mar 23, 2024, at 01:47, tison  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Random thought.
> > > > > > >
> > > > > > > You may find people not a native English speaker keep calling a 
> > > > > > > PMC
> > >

Re: "Maintainer" as an alias of PMC Member?

[Christopher]

Delegate implies designated authority/responsibility, more than
"maintainer" or "member", I think. The PMC role is delegated by the
ASF Board (usually lazily, upon notice by existing PMC members). So, I
think the word technically works here, but I won't argue that it's
that much better than "PMC member", but I'll point out that "member"
on its own has similar questions: member of what? The main argument
I'll make is that we don't use the word delegate in any other context,
so it's less likely to cause confusion.

Others to consider might be: associate (PMC-A) or representative (PMC
Rep, or PMC-R).

I thought "maintainer" was okay, because it implies some
responsibility for the project... rather than merely somebody who
occasionally contributes. But the wording is a bit confusing, because
you're not exactly a "PMC maintainer" or "somebody who maintains the
PMC". A maintainer would maintain the project, not the PMC for the
project. So, it's more accurate to say a "PMC member" is a " maintainer". So, it doesn't quite work to replace the word
"member", which I think is part of the goal.

Personally, I'm not particularly fond of any of these... I don't have
a problem using the more explicit "PMC Member" either...  but these
are suggestions that might work if somebody were to really champion
one of them to help reduce confusion for non-native English speakers,
or anybody who tends to prefer nominative uses of language over
descriptive uses and needs an unambiguous shortname.

On Sat, Mar 23, 2024 at 4:34 PM Gary Gregory  wrote:
>
> Delegate from what to what?
>
> "member" is fine IMO.
>
> Gary
>
> On Sat, Mar 23, 2024, 4:14 PM Christopher  wrote:
>
> > Delegate?
> >
> > On Sat, Mar 23, 2024 at 3:42 PM Gary Gregory 
> > wrote:
> > >
> > > I don't like "maintainer" here, a PMC member has a LOT more
> > > responsibility than the name implies IMO.
> > >
> > > "Maintainer" and "Contributor" feel almost interchangeable where a
> > > contributor might be a one-off and a maintainer more active. But we're
> > > splitting hair here IMO.
> > >
> > > Gary
> > >
> > > On Sat, Mar 23, 2024 at 3:17 PM Craig Russell 
> > wrote:
> > > >
> > > > I totally get the problem. I think if we can find a suitable title for
> > PMC Member we could socialize it in a few years. Should have done this
> > years ago.
> > > >
> > > > But "Maintainer" does not do it for me. Keep looking...
> > > >
> > > > Craig
> > > >
> > > > > On Mar 23, 2024, at 01:47, tison  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Random thought.
> > > > >
> > > > > You may find people not a native English speaker keep calling a PMC
> > Member
> > > > > of Apache Foo "Foo PMC".
> > > > >
> > > > > We correct it so many times and spread the knowledge on list. But
> > the trend
> > > > > I observed doesn't change and IMO it's hopeless to change.
> > > > >
> > > > > Since people tend to use a short ref and "committer" gives a one-word
> > > > > identifier first image, I'm trying to propose officially alias "PMC
> > Member"
> > > > > as "Maintainer" so that our wording is aligned.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Best,
> > > > > tison.
> > > >
> > > > Craig L Russell
> > > > c...@apache.org
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >

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

Re: "Maintainer" as an alias of PMC Member?

[Christopher]

Delegate?

On Sat, Mar 23, 2024 at 3:42 PM Gary Gregory  wrote:
>
> I don't like "maintainer" here, a PMC member has a LOT more
> responsibility than the name implies IMO.
>
> "Maintainer" and "Contributor" feel almost interchangeable where a
> contributor might be a one-off and a maintainer more active. But we're
> splitting hair here IMO.
>
> Gary
>
> On Sat, Mar 23, 2024 at 3:17 PM Craig Russell  wrote:
> >
> > I totally get the problem. I think if we can find a suitable title for PMC 
> > Member we could socialize it in a few years. Should have done this years 
> > ago.
> >
> > But "Maintainer" does not do it for me. Keep looking...
> >
> > Craig
> >
> > > On Mar 23, 2024, at 01:47, tison  wrote:
> > >
> > > Hi,
> > >
> > > Random thought.
> > >
> > > You may find people not a native English speaker keep calling a PMC Member
> > > of Apache Foo "Foo PMC".
> > >
> > > We correct it so many times and spread the knowledge on list. But the 
> > > trend
> > > I observed doesn't change and IMO it's hopeless to change.
> > >
> > > Since people tend to use a short ref and "committer" gives a one-word
> > > identifier first image, I'm trying to propose officially alias "PMC 
> > > Member"
> > > as "Maintainer" so that our wording is aligned.
> > >
> > > What do you think?
> > >
> > > Best,
> > > tison.
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: [POLL] Should we ask Infra to change the defaults used to generate GitHub integration email subjecs?

[Christopher]

Loophole question: can we start a campaign to complain just to get free
beer?

On Fri, Sep 29, 2023, 15:25 Craig Russell  wrote:

> I thought that a few folks responded to sebb earlier in the thread.
> Repeating an earlier post does not make it a new post.
>
> Changing defaults will not affect people who have changed their own
> project settings. And if they are happy with the defaults to the extent
> that they complain about the defaults changing for the better, I will split
> the bar tab with you
>
> Craig
>
> > On Sep 29, 2023, at 09:09, Christofer Dutz 
> wrote:
> >
> > As it was pointed out that nobody responded to this, let me do so:
> >
> > We have provided docs for quite some time … nothing really has changed
> as many projects are on a steep decline on using their lists.
> > These proposes changes have seen a very dominant support by most people
> who expressed their thoughts here.  You are currently the only person
> actively objecting.
> >
> > We are trying to improve things.
> > We are also not forcing anything on anyone … whoever wants things to
> stay the way they were, we provided all the information upfront to how they
> can keep things the way they were.
> >
> > Let’s make a one-sided bet: if there are more people complaining about
> the change after it happened than are expressing to be happy with them,
> I’ll invite you to a beer?
> >
> > Chris
> >
> >
> >
> > Von: sebb 
> > Datum: Freitag, 4. August 2023 um 11:21
> > An: dev@community.apache.org 
> > Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> > NAK - I don't think the defaults should be changed; instead provide
> > docs on how to do so
> > Don't force projects to change if they don't want to
> >
> > On Wed, 2 Aug 2023 at 07:46, Christofer Dutz 
> wrote:
> >>
> >> Well,
> >>
> >> stating the obvious, I’ll add my +1 ;-)
> >>
> >> And yes Craig, I said the defaults … if you have explicitly configured
> your .asf.yaml subjects, they are left unchanged.
> >>
> >> Chris
> >>
> >>
> >> Von: Richard Zowalla 
> >> Datum: Mittwoch, 2. August 2023 um 08:10
> >> An: dev@community.apache.org 
> >> Betreff: Re: [POLL] Should we ask Infra to change the defaults used to
> generate GitHub integration email subjecs?
> >> +1
> >>
> >> Am 2. August 2023 07:47:25 MESZ schrieb Jarek Potiuk  >:
> >>> +1
> >>>
> >>> On Wed, Aug 2, 2023 at 2:15 AM Craig Russell 
> wrote:
> 
>  Hi Christofer,
> 
>  As long as projects with their own settings can continue to use them,
> I'm
> 
>  +1
> 
>  to change the defaults for all projects. If the projects don't like
> being able to use their lists again, they can always go back to what they
> had before.
> 
>  Thanks,
>  Craig
> 
> > On Aug 1, 2023, at 05:16, Christofer Dutz 
> wrote:
> >
> > Starting a new thread as the last one sort of dried up and didn’t
> quite form anything actionable.
> >
> > Being subscribed to many of our mailing-lists and most recently
> looking into every project, dev-lists when reviewing board reports, I have
> seen many of our lists literally being rendered useless.
> >
> > Useless, because it’s almost impossible to follow these lists, as a
> large percentage of the emails are:
> >
> > *   Generated emails and the way they are currently generated makes
> it impossible for email clients to correctly display them as threads.
> > *   Contain so much redundant information, that the actual start of
> the header that I’m interested in reading is usually not readable on mobile
> phones.
> > *   Most discussions have been moved away from the lists
> (notifications@, commits@), having left over only skeletons in which
> every now and then a vote is being handled.
> >
> > My proposal is to change the default settings for auto-generated
> GitHub emails for all projects (not just the new ones) to be a much more
> condensed version.
> >
> > With these changes, all existing lists, that haven’t manually
> configured the format of the emails, instantly get readable lists again.
> >
> > Some would argue that there might be projects that could object
> these changes, but I would on the other hand bet that more projects would
> be in favor of such a change than not.
> > Those who don’t want a change, can simply go back to the old format,
> by specifying it in one commit for which we can even provide a default
> .asf.yaml snippet.
> >
> > Some people expressed the wish to have longer prefixes, such as
> “[ISSUE]”, “[PULL-REQUEST]” or “[DISCUSSION]” however do these not add much
> information to the email that “[I]”, “[PR]” and “[D]” don’t and the shorter
> version allows displaying more of the subject on mobile email clients.
> >
> > Here’s an example of a project list before the changes:
> >
> https://lists.apache.org/list?d...@streampipes.apache.org:dfr=2023-1-9|dto=2023-1-15
> > Here’s an example 

Re: Centralise DOAPs?

[Christopher]

I think many projects already have their doap files on their website, do
that's not really improving anything. It doesn't make much difference
editing the fields embedded in HTML or in its own separate file.

On Fri, Sep 8, 2023, 05:41 Bertrand Delacretaz 
wrote:

> Hi,
>
> On Fri, Sep 8, 2023 at 12:26 AM sebb  wrote:
> > ...I think it would be worth considering setting up a central store for
> DOAPs...
>
> As we require our projects to have a website anyway, wouldn't it be
> better to get that information from the project's homepage instead of
> a separate file ?
>
> As you mention, I think it's only the fields that rarely change that
> are actually useful: the project's description, a few useful URLs,
> programming language, communications channel URLs, project category,
> code repository and download URLs, that's probably all we need ?
>
> That info can be embedded in HTML, for example using  elements,
> Open Graph [1] maybe, with some ASF-specific extensions such as
> og:asf:category ?
>
> This would put the information in a natural place for projects to
> maintain it, and Open Graph metadata has other benefits.
>
> OTOH this means writing a conversion layer that, starting from a list
> of *.apache.org subdomain names, grabs that data and converts it to a
> format that's useful for projects.a.o.
>
> Another option would be to embed the current DOAP format using a
> 

Re: Centralise DOAPs?

[Christopher]

I love this idea! +1

On Thu, Sep 7, 2023, 18:26 sebb  wrote:

> I think it would be worth considering setting up a central store for DOAPs.
> This was suggested in the past, but was rejected, I think mainly
> because PMCs were expecting to have to make regular updates to DOAPs,
> e.g. when releases are made, so wanted to keep them with the code.
>
> It's a pain keeping the releases section of DOAPs up to date (even if
> they are local to code).
> Now that there is an automated releases listing, I wonder whether
> there is any point keeping the info in the DOAP as well?
>
> The rest of the fields in a DOAP rarely change, so it matters less if
> the DOAP is stored in a different repo from the code to which it
> relates.
>
> If DOAPs were moved to a shared GitHub repo, I think it would be much
> easier for maintenance purposes. Some issues such as fixing an
> incorrect repo URL or download page link could be dealt with by anyone
> with suitable karma.
>
> Just a thought.
>
> Sebb
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Changing the defaults for GitHub generated email titles?

[Christopher]

I think this would be really great. I'm not a big fan of the [I] and [D]
topics, though. I think I'd rather see [ISSUE] and [DISCUSSION], but either
way, the ability to group emails is a big improvement. I'd also prefer to
always include [GH] as a topic tag, so for example, [GH][ISSUE], so if
people don't redirect them to another list, I can filter them out more
easily. The reason for that is that I will still prefer to manage my
notification subscriptions directly with GitHub, and prefer to suppress
those on the lists by default.

On Fri, Jun 30, 2023, 03:50 Christofer Dutz 
wrote:

> Hi all,
>
> So, we have made it possible to “integrate” GitHub PRs, Issues and now
> even Discussions by having infra auto-generate emails.
> However, is the default setting for these just completely useless (in my
> opinion).
>
> Without taking action currently there are only the following options:
>
>   *   A project just redirects the emails to another lists (commits@ or
> notifications@ or whatever)
>   *   A project gets a totally human-unreadable dev-list.
>
> As I see my role as a director in actually having a look at all of our
> mailinglists this has become more and more painful over time.
> But it got me thinking: If I’m having problems being able to see what a
> project is up to – so will others.
>
> Some of the projects will have received many comments from me over the
> past few months, as I’m trying to make dev-lists usable again.
> Infra did add the ability to customize the default templates for the
> subjects of auto-generated emails. And last month a PR of mine got merged,
> that also allowed the customization of GitHub Discussions.
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
>
> I had many discussions with folks at infra about changing the defaults,
> but generally met opposition. The general argument was, that there would be
> bots that automatically consume these emails and these would be confused if
> we changed the defaults.
>
> However, I think at the ASF we should be optimizing for people and not for
> bots. Right now we have many projects where following the list is very
> difficult and therefore we’re losing a big part of our transparency.
>
> I’m bringing this here as I think Comdev is where such discussions should
> be had.
>
> So in general, I would like to change the defaults used by the GitHub
> tooling to the ones I proposed in
> https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent
> . Quite a number of projects have adopted these settings:
> Like StreamPipes:
> https://lists.apache.org/list?d...@streampipes.apache.org:lte=4M
>
> What do you folks think?
>
> Chris
>
>

Re: [jira] [Commented] (COMDEV-416) make reporter wizard send notifications to private@

[Christopher Willis]

I've been hàvcked

On Tue, Feb 21, 2023, 1:43 AM Herve Boutemy (Jira)  wrote:

>
> [
> https://issues.apache.org/jira/browse/COMDEV-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691434#comment-17691434
> ]
>
> Herve Boutemy commented on COMDEV-416:
> --
>
> in fact, publishing the report works well: the need here is to ease a PMC
> review/contribution before publishing
>
> > make reporter wizard send notifications to private@
> > ---
> >
> > Key: COMDEV-416
> > URL: https://issues.apache.org/jira/browse/COMDEV-416
> > Project: Community Development
> >  Issue Type: Improvement
> >  Components: Reporter Tool
> >Reporter: Herve Boutemy
> >Priority: Major
> >
> > Reporter wizard is awesome to help the PMC chair prepare and submit
> board reports.
> > The only key missing step is sending drafts and/or final submitted
> report to the PMC, for review or just info
>
>
>
> --
> This message was sent by Atlassian Jira
> (v8.20.10#820010)
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Contribution to open source projects

[Christopher Willis]

I need help getting started myself I was just thrown into this without
knowledge of anything

On Sat, Jan 28, 2023, 4:47 PM Dhanyashree M 
wrote:

> Hello Sir/Mam,
> I am Dhanyashree, a 2nd year Engineering student, coding enthusiast and a
> newbie to open source contributions .I have recently got to know about the
> open source projects and those which you provide and I am curious to learn
> and build some of the projects and I would love to contribute to the open
> source and develop community, but I don't know how to begin with .I know
> programming languages like Java,C and C++. Can you please point me out in
> the right direction to choose a relevant project for a newbie like me?
>
> Regards
> Dhanyashree M
>

Request to Join Community

[Strickland, Christopher]

Hello! This is a request to join your community.

Thanks,
Chris

Re: The projects.apache.org site confuses basic principles

[Christopher]

(Dropped press@ from reply)

I don't find the wording there too confusing if you know that "Projects"
includes both top-level and sub-projects. This seems obvious to me when the
site says "199 committees managing 351 projects", but that could be
clarified further by having it say "199 project management committees
(PMCs) managing 351 top-level projects and their sub-projects".
The part of the site that says "Committees evolution (also called PMCs or
Top Level Projects)" makes it clear that there's a 1-to-1 mapping of PMCs
and top-level projects. But that could be further clarified as "PMC
evolution (one for each top-level project)".

This is the breakdown I understand:

1. PMCs (project management 'committees' - committees that each manage one
or more projects)
2. Projects (includes top-level projects and their sub-projects)
3. Releases (individual artifacts distributed from each project)

I actually find the use of the word "product" to be more confusing because
the "P" in "PMC" stands for "Project", not "Product". PMCs are neither
projects themselves nor committees that manage products. Rather, they are
committees that manage projects: one top-level each and any number of
sub-projects. So, the main confusing point I find in the page is the use of
the phrase "also called" to equate "Committee" with "Top Level Projects". A
PMC is not "also called" a "Top Level Project". Rather, it *manages* a top
level project.

On Fri, Feb 4, 2022 at 11:03 AM Dave Fisher  wrote:

> As I understand the ASF governance there are:
>
> 1. Project Management Committees -> Projects. For example: Apache Logging.
> 2. Products which are named artifacts from projects. For example: Apache
> Log4J
> 3. Releases which are released artifacts of a project’s product. For
> example: Apache Log4J 2.17.1
>
> But on the https://projects.apache.org website the corresponding three
> items are called:
>
> 1. Committees.
> 2. Projects.
> 3. Releases.
>
> I suspect that this “confusion” is due to a combination of the split of
> the PRC committee and the former time of supper projects like Apache
> Jakarta.
>
> This ought to be adjusted somehow because it leads to misunderstanding
> about responsibility.
>
> All The Best,
> Dave
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Issue Management in Apache Projects

[Christopher]

Hi Erik,

Do you have a good understanding of *why* there are more issues being
opened than being closed? If so, that might hint at some possible
solutions.

For example, if you just don't have enough people to write code, then
the PMC could focus on inviting new committers to try to grow the
community, or mentoring new developers.

If, on the other hand, the quality of the issues is poor, such that
they aren't very actionable, you could ask for more information from
the reporter, and add a label that shows its status, such as "waiting
on reporter". If no response is given in a reasonable time, you can
close old issues. You can also try to address issue quality using
GitHub issue templates:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository

You could also set up something to auto-close very old issues that
haven't been updated in a long time, under the premise that they are
probably not relevant anymore. If they are, they can always be
re-opened.

You can also use GitHub "projects" (which I see you're already using:
https://github.com/apache/superset/projects) to help organize related
tasks, so they can be closed when the overall project is done.

If the problem is that your committers aren't paying attention to open
issues, you can try to ping your community's dev@ list to remind
people of how many issues are outstanding, as a way of encouraging
people to help triage, close, and bring down the number. You could try
to find other ways to "gamify" the count, too. But, ultimately, it
comes down to volunteer effort.

If the problem is that your committers are having trouble tracking the
activity on GitHub, you can double check your mailing list
configuration to ensure activity gets copied to a notifications@ or
issues@ list that your committers can track (you can also configure
them to go to dev@, but that tends to get spammy and redundant,
especially for your committers who are happy seeing the notification
dots and/or emails directly from GitHub).

Ultimately, you'll need to figure out why the situation is the way it
is, and address it accordingly. You won't be able to force volunteer
community members to participate to bring the number down, but perhaps
there's ways to encourage them, depending on why it's happening in the
first place.

On Thu, Jul 8, 2021 at 5:04 PM Erik Ritter  wrote:
>
> Hi all,
>
> I'm a PMC member for Apache Superset, and we've recently been struggling
> with the number of issues reported in our Github repo. We're currently at >
> 800 open issues, and are having trouble keeping up with responding and
> addressing all the user issues and feedback. We were curious if any other
> Apache projects had a way of managing Github issues that works for them. We
> were considering setting up a bot that assigns new issues to a random
> committer/PMC member, but are open to other ideas too. Thanks for your help
> and advice!
>
> Best,
> Erik Ritter

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

Re: Please redirect automated GitBox emails to different list

[Christopher]

On Tue, Jul 6, 2021 at 1:10 PM Dave Fisher  wrote:
[SNIP]
> Tell me why a split discussion is good for the community?

I feel like I didn't do a good enough job of responding to this point,
so to clarify further:

My answer is that it's *not*. However, that problem already exists
with any issue tracker. Discussions happen on JIRA today, as well as
on GitHub pull requests, or ReviewBoard, or Slack. We can moderate the
notifications list to prevent additional discussions from occurring
there, so this wouldn't create a new forum for discussions to be split
across. That's a misunderstanding of what I'm proposing.

The purpose of this change isn't to split up discussions further.
Rather, it's intent is to make it easier to *find* discussions to
participate in. One way it does this is by removing redundant spammy
notifications if users are already being notified by GitHub directly
because they have subscribed to the repo there. Reducing this spam on
the dev@ list makes finding the remaining discussions on the list
easier, because there's less noise to wade through. It also makes it
easier to find discussions happening on GitHub, even if you aren't
subscribed, because if you choose to subscribe to the second list to
receive notifications that way, filtering your mail in your email
client is much more reliably done with a "list-id:" header that is
unique for each mailing list than it is with only pattern-matching on
a "subject:" line.

I hope that helps clarify the intent here.

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

Re: Please redirect automated GitBox emails to different list

[Christopher]

Great discussion, everybody! Here's some thoughts in response to some
of the questions/concerns raised:

People should *not* have to subscribe to the other list in order to
participate in discussions. It should just be for automated notices.
The best practice is, like commits@, have it moderated and
automatically reject anything not from "apache.org" to virtually
eliminate any moderation effort. If you need to discuss, the best
practice is to reply to it on the dev@ list to start a new discussion
thread there.

The reason not to use commits@ directly is because it's nice to have
actual commit activity, for archival purposes, in its own dedicated
list. Many projects have a jira@, notifications@, or issues@ list for
automated notices from their issue tracker. That's all I'm suggesting
here.

I noticed that COMDEV JIRA notifications are also going to dev@. If
you want to use the same notifications@ list for the COMDEV JIRA, I'd
be in favor of that as well, but that's a separate issue that I wasn't
intending to raise here. It has its own pros and cons. To configure
that, it's not done in .asf.yaml, it's done at
https://issues.apache.org/jira/plugins/servlet/project-config/COMDEV/notifications
or by submitting a JIRA ticket to INFRA. Therefore, it's outside the
scope of my PR to address the GitHub notifications.

I also understand the concern raised about the difficulty of having
discussions on dev@ because of GitHub's ease-of-use. However, I don't
think forcing redundant notifications on GitHub users is the right
solution, as it will discourage GitHub users from participating in the
mailing lists... which is the opposite of what you want. The reason
for GitHub users to participate in the mailing lists will be because
they get value out of the mailing lists other than what they get from
using GitHub directly.

As for the comment regarding whether or not a destination should be
set for `issues:`, GitHub considers pull requests to be a type of
issue, so its important to set this value, even if you have issues
disabled on GitHub, because (I believe) commenting on a pull request
triggers the same notification as commenting on an issue. I believe
`pullrequests:` is triggered for newly created PRs, but `issues:` is
still used for notifications of any comments or code reviews on a pull
request, as though it were any other issue.

On Tue, Jul 6, 2021 at 1:16 PM Joe Brockmeier  wrote:
>
> First, I feel like I have to respond given the Truman State University sig.
> It's rare I run into other Truman grads in the wild, though we wouldn't
> have crossed paths on campus... (1998 grad here...)
>
> If the PRs appear here on this list, it makes it slightly easier to have a
> discussion on list about the PRs. It also doesn't require people to go
> upstream to subscribe to github or a second list.
>
> I wouldn't go so far as to say it's "unreasonable" to have a second list, I
> just am not convinced it's desirable.
>
> As to the suggestion to discussing the PRs on the other list - then we have
> to ask people to subscribe to both or miss some of the conversations about
> the site development. Creating a filter for the GitBox notices +
> subscribing to a new list are both about the same amount of work. If you
> filter by sender or something like that you still can see discussions here
> if anybody decides to go deeper on a specific commit. If you have to track
> both lists, then that means a subset of the community is not going to see
> those discussions either. (Either by omission or they just filter
> everything and then see something six months later... ask me how I know...)
>
> Best,
>
> jzb
>
> On Tue, Jul 6, 2021 at 12:37 PM Brian Thompson  wrote:
>
> > I don't think asking for a new mailing list for GitHub notifications is
> > unreasonable.  In fact, I would go as far to say that having a GitHub
> > notifications mailing list makes more sense than having those
> > notifications being sent to the "dev" mailing list.  Shouldn't the dev
> > mailing list be used for discussion about the development rather than
> > individual PRs?  Those discussions can still be had on the other
> > mailining list, if so desired.
> >
> > --
> > Best regards,
> >
> > Brian T
> > B.S. Computer Science 2014 (Truman State University)
> >   Minor Stasitics
> >   Minor Chemistry
> >   Minor Mathematics
> >
>
>
> --
> Joe Brockmeier
> Vice President Marketing & Publicity
> j...@apache.org

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

Re: Please redirect automated GitBox emails to different list

[Christopher]

Sorry, I have a slight correction on my response. I meant to write:
'"OPT-IN" makes so much more sense here.' Sorry for any confusion.

On Tue, Jul 6, 2021 at 10:45 AM Christopher  wrote:
>
> To respond to your questions:
>
> On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen  wrote:
> >
> > May I be the contrary voice and ask why?
>
> I put two points of justification in the PR, but to repeat here:
>
> 1. These automated notices are redundant if somebody is already watching
> the relevant notices for the repo on GitHub. So, sending these to
> another list allows users more flexibility in receiving them or not,
> and whether they prefer to receive them as an email or as a notice
> directly from watching the repo in GitHub.
> 2. These automated notices spam the dev@ list which many more people
> follow for the human discussions here on community development across
> the ASF. Sending them to another list ensures the dev@ list is
> reserved for human-to-human conversations, and keeps people from
> unsubscribing and connected to the community due to frustration with
> spam.
>
> > Why do we not want to know what's being committed in our name?
>
> I don't understand this question. This doesn't prevent anybody from
> watching any of the activity. It just gives more flexibility on how
> they are able to follow it, removing redundant notifications for
> people following the repos on GitHub, and providing a mechanism that
> is equivalent to today if people prefer to follow a mailing list.
>
> > It's not like this list gets a lot of traffic,
>
> True, but that's probably why there are as many subscribers as there
> are. The quantity is low, but the quality is very high. With the
> automated emails landing here, the quality is lowered, and the
> quantity is increased. The degree to which this has happened may be in
> question, but the fact that automated emails are of lower quality than
> human-written emails shouldn't be in question. These make it more
> likely people will unsubscribe, as more activity on the list is less
> relevant to their participation.
>
> > and those very emails that you want to banish to another
> > list were what reminded me that we have PRs that have been languishing
> > for several months.
>
> "Banish" seems harsh. I would characterize it as "organize". I don't
> think email activity is the cause of languishing PRs. By organizing
> these on a separate list, all options you had before to watch for
> these and react to them will still be available to you. You can still
> watch notifications on GitHub directly, or follow the other list. But,
> it lowers the bar for other people (especially non-committers who
> follow the list) to organize the lists they follow.
>
> >
> > Granted, if this is enacted, I'll just filter that email to the same
> > folder, but I don't think that this solves a real problem, and, indeed,
> > that it will further reduce engagement.
>
> I don't think it has an impact on engagement, because no notifications
> are being removed. Only organized. Keep in mind that many people
> following ComDev are not committers, and follow this list for the
> discussions of community development at the ASF, and *not* for
> maintaining ComDev's website or other code (if there is any).
>
> And, because I know somebody will raise this point: email can be
> filtered both ways. However, I think it's easier for committers to
> follow two lists (assuming they prefer the email notifications rather
> than the notifications in GitHub's UI in the first place), than it is
> for casual followers interested in ComDev discussions on this list to
> set up email filters to suppress the notifications. I'd prefer to
> cater to the casual followers, to lower the bar to contributing.
>
> Furthermore, I also follow the INFRA list, and this GitBox spam seems
> to be a frequent source of frustration for many casual contributors
> since projects were moved to GitBox from the old git-wip, many
> submitting requests for INFRA to help them "unsubscribe" from it, and
> many uncertain how they are getting it in the first place. Yet, I
> never see any complaints that users have to subscribe to a second list
> to get jira@, issues@, or notifications@ messages in their projects.
> So, I think it makes sense to put these notifications in a separate
> list, making them "OPT-IN", rather than "OPT-OUT".
>
> Also, remember, even for users who *want* to follow this activity,
> they don't necessarily want these messages, because many are already
> following the activity on GitHub. "OPT-OUT" makes so muc

Re: Please redirect automated GitBox emails to different list

[Christopher]

To respond to your questions:

On Tue, Jul 6, 2021 at 10:06 AM Rich Bowen  wrote:
>
> May I be the contrary voice and ask why?

I put two points of justification in the PR, but to repeat here:

1. These automated notices are redundant if somebody is already watching
the relevant notices for the repo on GitHub. So, sending these to
another list allows users more flexibility in receiving them or not,
and whether they prefer to receive them as an email or as a notice
directly from watching the repo in GitHub.
2. These automated notices spam the dev@ list which many more people
follow for the human discussions here on community development across
the ASF. Sending them to another list ensures the dev@ list is
reserved for human-to-human conversations, and keeps people from
unsubscribing and connected to the community due to frustration with
spam.

> Why do we not want to know what's being committed in our name?

I don't understand this question. This doesn't prevent anybody from
watching any of the activity. It just gives more flexibility on how
they are able to follow it, removing redundant notifications for
people following the repos on GitHub, and providing a mechanism that
is equivalent to today if people prefer to follow a mailing list.

> It's not like this list gets a lot of traffic,

True, but that's probably why there are as many subscribers as there
are. The quantity is low, but the quality is very high. With the
automated emails landing here, the quality is lowered, and the
quantity is increased. The degree to which this has happened may be in
question, but the fact that automated emails are of lower quality than
human-written emails shouldn't be in question. These make it more
likely people will unsubscribe, as more activity on the list is less
relevant to their participation.

> and those very emails that you want to banish to another
> list were what reminded me that we have PRs that have been languishing
> for several months.

"Banish" seems harsh. I would characterize it as "organize". I don't
think email activity is the cause of languishing PRs. By organizing
these on a separate list, all options you had before to watch for
these and react to them will still be available to you. You can still
watch notifications on GitHub directly, or follow the other list. But,
it lowers the bar for other people (especially non-committers who
follow the list) to organize the lists they follow.

>
> Granted, if this is enacted, I'll just filter that email to the same
> folder, but I don't think that this solves a real problem, and, indeed,
> that it will further reduce engagement.

I don't think it has an impact on engagement, because no notifications
are being removed. Only organized. Keep in mind that many people
following ComDev are not committers, and follow this list for the
discussions of community development at the ASF, and *not* for
maintaining ComDev's website or other code (if there is any).

And, because I know somebody will raise this point: email can be
filtered both ways. However, I think it's easier for committers to
follow two lists (assuming they prefer the email notifications rather
than the notifications in GitHub's UI in the first place), than it is
for casual followers interested in ComDev discussions on this list to
set up email filters to suppress the notifications. I'd prefer to
cater to the casual followers, to lower the bar to contributing.

Furthermore, I also follow the INFRA list, and this GitBox spam seems
to be a frequent source of frustration for many casual contributors
since projects were moved to GitBox from the old git-wip, many
submitting requests for INFRA to help them "unsubscribe" from it, and
many uncertain how they are getting it in the first place. Yet, I
never see any complaints that users have to subscribe to a second list
to get jira@, issues@, or notifications@ messages in their projects.
So, I think it makes sense to put these notifications in a separate
list, making them "OPT-IN", rather than "OPT-OUT".

Also, remember, even for users who *want* to follow this activity,
they don't necessarily want these messages, because many are already
following the activity on GitHub. "OPT-OUT" makes so much more sense
here.


>
> On 7/6/21 9:26 AM, Christopher wrote:
> > Hi ComDev,
> >
> > I'm probably not the only one who has noticed the flurry of emails on
> > the main dev@community.apache.org due to GitHub activity on the
> > comdev-site repo.
> >
> > To help deal with that, I created a pull request:
> > https://github.com/apache/comdev-site/pull/64
> > For more information, see
> > https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories
> >
> > The

Please redirect automated GitBox emails to different list

[Christopher]

Hi ComDev,

I'm probably not the only one who has noticed the flurry of emails on
the main dev@community.apache.org due to GitHub activity on the
comdev-site repo.

To help deal with that, I created a pull request:
https://github.com/apache/comdev-site/pull/64
For more information, see
https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#Git.asf.yamlfeatures-Notificationsettingsforrepositories

The PMC must create a new notificati...@community.apache.org list for
this change, if they decide to accept my proposed change.

Thanks!

- Christopher

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

Re: ASF-wide community support files on GitHub

[Christopher]

Right, but putting it in the special ".github" repository would make
it visible in the GitHub UI for all ASF projects on GitHub, so every
project doesn't have to do the same.

I've created an INFRA ticket at
https://issues.apache.org/jira/browse/INFRA-21897 to request the
repository.

On Tue, May 18, 2021 at 9:03 AM Tomasz Urbaszek  wrote:
>
> In Apache Airflow and Kibble we simply link to ASF COC:
> https://github.com/apache/airflow/blob/master/CODE_OF_CONDUCT.md
> https://github.com/apache/kibble/blob/master/CODE_OF_CONDUCT.md
>
> Tomek
>
> On Mon, 17 May 2021 at 23:46, Christopher  wrote:
> >
> > On Mon, May 17, 2021 at 4:54 AM Bertrand Delacretaz
> >  wrote:
> > >
> > > On Sat, May 1, 2021 at 6:02 PM Christopher  wrote:
> > > > ...Initially, it could just include a `.github/CODE_OF_CONDUCT.md` file
> > > > that contains the same content as
> > > > https://www.apache.org/foundation/policies/conduct ...
> > >
> > > Instead of copying that text I would prefer that CODE_OF_CONDUCT.md
> > > mentions that this repository belongs to a project of the Apache
> > > Software Foundation to which
> > > https://www.apache.org/foundation/policies/conduct applies. We tend to
> > > have too much duplicated information already.
> > >
> > > -Bertrand
> > >
> >
> > That seems reasonable to me. Maintain the content in one place.
> > Either way, the https://github.com/apache/.github repository would
> > need to be created before any content can be added.
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: ASF-wide community support files on GitHub

[Christopher]

On Mon, May 17, 2021 at 4:54 AM Bertrand Delacretaz
 wrote:
>
> On Sat, May 1, 2021 at 6:02 PM Christopher  wrote:
> > ...Initially, it could just include a `.github/CODE_OF_CONDUCT.md` file
> > that contains the same content as
> > https://www.apache.org/foundation/policies/conduct ...
>
> Instead of copying that text I would prefer that CODE_OF_CONDUCT.md
> mentions that this repository belongs to a project of the Apache
> Software Foundation to which
> https://www.apache.org/foundation/policies/conduct applies. We tend to
> have too much duplicated information already.
>
> -Bertrand
>

That seems reasonable to me. Maintain the content in one place.
Either way, the https://github.com/apache/.github repository would
need to be created before any content can be added.

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

ASF-wide community support files on GitHub

[Christopher]

Recently, a user contributed a pull request for Accumulo to add
.github/CODE_OF_CONDUCT.md
I can see this being useful so that the ASF Code of Conduct is
presented in the GitHub UI. However, I don't think every project needs
to do this.

I propose ComDev work with INFRA to create
https://github.com/apache/.github repository to host such common
files, as described in
https://github.blog/changelog/2019-02-21-organization-wide-community-health-files/
; projects can, of course, override these default files.

The main annoyance I think is that it wouldn't quite fit the normal
repository naming convention, so it would have to be a special case.
I'm proposing this here, because I think ComDev might be the most
appropriate "owner" of the content of that repository.

Initially, it could just include a `.github/CODE_OF_CONDUCT.md` file
that contains the same content as
https://www.apache.org/foundation/policies/conduct
Other files, like `.github/SUPPORT.md` can be added later if there's
something appropriate to put there.

An example in action: https://github.com/revelc/.github/tree/main/.github

Thoughts?

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

Re: (FOSDEM) booth

[Christopher]

On Wed, Feb 3, 2021 at 5:29 AM Claude Warren  wrote:
>
> Sorry I am so late to the party, but life has kept me busy.
>
> I have update the wiki to indicate that I will be manning" ("personing"?)
> the booth.

Peopling. Occupying. Staffing. Crewing. Operating. Working. Defending.
Fortifying. Soldiering. Colonizing. Whiling. :)

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

[jira] [Commented] (COMDEV-340) Surprising categories on "Projects by category" page

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050636#comment-17050636
 ] 

Christopher Tubbs commented on COMDEV-340:
--

Since you don't know (and I don't know), it's probably best to not add possibly 
incorrect information to the guidelines. If somebody were to have time to 
figure it out, though, it'd be a nice improvement to those guidelines.

> Surprising categories on "Projects by category" page
> 
>
> Key: COMDEV-340
> URL: https://issues.apache.org/jira/browse/COMDEV-340
> Project: Community Development
>  Issue Type: Improvement
>  Components: Projects Tool
>Reporter: Piotr Zygielo
>Priority: Minor
> Attachments: apache-categories.png
>
>
> Page https://projects.apache.org/projects.html?category lists Kafka and 
> Commons-RNG under surprising categories:
> "https://projects.apache.org/projects.html?category#big-data";
> and
> "https://projects.apache.org/projects.html?category#library";



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

[jira] [Commented] (COMDEV-340) Surprising categories on "Projects by category" page

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17050589#comment-17050589
 ] 

Christopher Tubbs commented on COMDEV-340:
--

[~sebb] Does 'http' vs. 'https' matter for the category names? Can you update 
the guidelines to clarify whether that matters for the syntax?

> Surprising categories on "Projects by category" page
> 
>
> Key: COMDEV-340
> URL: https://issues.apache.org/jira/browse/COMDEV-340
> Project: Community Development
>  Issue Type: Improvement
>  Components: Projects Tool
>Reporter: Piotr Zygielo
>Priority: Minor
> Attachments: apache-categories.png
>
>
> Page https://projects.apache.org/projects.html?category lists Kafka and 
> Commons-RNG under surprising categories:
> "https://projects.apache.org/projects.html?category#big-data";
> and
> "https://projects.apache.org/projects.html?category#library";



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Re: [VOTE] Move community.a.o site from CMS/SVN to Hugo/Git

[Christopher]

+1 (non-binding) to switching to a git-based website
+0 (non-binding) to switching to Hugo

While I'm more familiar with Jekyll than Hugo, the switch to a
git-based website creates a *super* low bar to contribute to now for
Apache Accumulo, the primary project I contribute to at Apache, that I
think all projects should do it. It's now so easy that any committer
can easily and automatically stage updates to our site by merely
merging a pull request on GitHub. Publish from staging to production
is trivial with a one-liner git command
(https://github.com/apache/accumulo-website/blob/master/README.md#publishing).
My main concern for ComDev here is for the use of Hugo over Jekyll,
because 1) I'm not familiar with Hugo at all (though I know it is
still Markdown-based), and 2) I don't know if INFRA supports automated
Hugo builds like it does for Pelican and now Jekyll. If INFRA's
.asf.yaml buildbot features can support the Hugo build automation like
Pelican or Jekyll, I'm wholeheartedly in favor of ComDev leveraging
it. Otherwise, I'd recommend using Pelican or Jekyll instead.

On Sat, Feb 22, 2020 at 6:11 AM Roy Lenferink  wrote:
>
> Hi all,
>
> After this week's proposal [1] I'd like to start a formal vote on moving over 
> community.a.o from the
> current Apache CMS/SVN to Hugo/Git.
>
> Involved steps:
> - Create a comdev-site gitbox repository which will be synced with the 
> current comdev-site repo on
> GitHub.
> - Rename 'trunk' to 'master' and set 'master' as default branch (git repo)
> - Create a Jenkins job which generates the actual site to the 'asf-site' 
> branch
> - Move serving of community.a.o from svn to git
> - Remove 'community' from the CMS
> - Add a MOVED_TO_GIT file to the svn repo making clear the the directory 
> contents have moved
> to git.
>
> Please vote:
> [ ] +1 for moving over from the CMS/svn to Hugo/git.
> [ ] -1 for not moving over, in this case please explain why
>
> Best,
> Roy
>
> [1] 
> https://lists.apache.org/thread.html/r338baf731f509c6ae833600469c2b247cafe02022c1687a705a66012%40%3Cdev.community.apache.org%3E
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

[jira] [Commented] (COMDEV-340) Surprising categories on "Projects by category" page

[Christopher Tubbs (Jira)]

[ 
https://issues.apache.org/jira/browse/COMDEV-340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17025641#comment-17025641
 ] 

Christopher Tubbs commented on COMDEV-340:
--

I think the correct configuration in their respective DOAP files should be:

{{http://projects.apache.org/category/big-data"/>}}

and

{{http://projects.apache.org/category/library"/>}}

But this is probably not a COMDEV issue. It's probably a problem with the 
responsible TLP, who maintain their own DOAP files.

> Surprising categories on "Projects by category" page
> 
>
> Key: COMDEV-340
> URL: https://issues.apache.org/jira/browse/COMDEV-340
> Project: Community Development
>  Issue Type: Improvement
>  Components: Projects Tool
>Reporter: Piotr Zygielo
>Priority: Minor
> Attachments: apache-categories.png
>
>
> Page https://projects.apache.org/projects.html?category lists Kafka and 
> Commons-RNG under surprising categories:
> "https://projects.apache.org/projects.html?category#big-data";
> and
> "https://projects.apache.org/projects.html?category#library";



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

Re: Please add Apache Maven logo to RedBubble

[Christopher]

On 19/08/2019 09:12, Karl Heinz Marbaise wrote:
> Hi,
>
> could also please add the Apache Maven Project.
>
> https://www.apache.org/logos/?#maven

That updated logo to use the two feathers is brilliant. I never
noticed before. :)

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

Re: [Lazy Consensus] Changing the default reporter tool

[Christopher]

On Tue, Aug 6, 2019 at 2:04 AM Daniel Gruno  wrote:
>
> On 8/6/19 2:54 AM, Christopher wrote:
> > The new reporter wizard helps folks create a board report, but it
> > doesn't seem to have any of the other features of the current
> > reporeter.a.o tool. For example, helping them to manage recorded
> > releases (https://reporter.apache.org/addrelease.html?), view
> > community health score (https://reporter.apache.org/chi.py#),
> > quickly view JIRA stats and PMC/committer changes, etc.
> >
> > Are all of those features available elsewhere, or will they be
> > replaced by the new tool?
>
> Hi Christopher,
> I am wondering if you are perhaps looking at an older cached version of
> the tool? Or maybe I am misunderstanding what you mean by having the
> information available, but I'll attempt to answer in any case.
>
> PMC/committer changes should still very much be in the editor, under
> "Membership data", including new information bits such as the age of the
> project and the ratio between committers and pmc members.
>
> JIRA stats and a whole bunch of new stats, are available in the
> Community Health section, though they are not inserted into the report
> itself by default, as the board have expressed countless times that they
> do not wish to just see these figures, but rather a description of the
> significance of the numbers. When you are in the community health
> section, the right hand panel will display statistics such as:
> - jiras opened/closed
> - github prs/issues opened/closed
> - emails sent
> - commits done, committers active
>
> It will also allow you to see the most discussed issues/emails, and as a
> new thing, it will display how tickets/code/committer figures relate to
> the previous quarter.
>
> The 'Project activity' section lists recent releases or, in the case of
> no such things found, the last three releases, and has a link to
> managing the release data.
>
> As for the CHI score, we can have that displayed in the toolbut,
> it's a rather arbitrary figure that I made up, and it has caused some
> confusion in the past. Perhaps that warrants a longer discussion :)
>

The score may be arbitrary, but it's still useful to view
upward/downward trends of the score in the context of a single
project not so useful to compare to other projects.

> If, instead, you mean something along the lines of "I don't want help
> writing a report, I just want to casually look at the data available",
> perhaps what we could do is display that on a separate page that has the
> same information as the wizard, but just displays all the data on one
> big page?
>

Yes, that's basically what I'm getting at. As far as I can tell,
https://reporter.apache.org is useful to 3 groups of people:

1. PMC Chairs preparing board reports (the bottom "Report template" section)
2. Release managers (recording new releases -- probably the most
frequent visitors)
3. Viewing of the informational content (charts, graphs, list of
historical releases, stats, etc., to include use of "Members-only
Quick-nav" button)

As far as I can tell, the wizard is only a substitute for the "Report
template" section of the site, satisfying the first use case, but not
the other two. The second use case is easily satisfied with a few
links ("Add a release", "Fetch releases from JIRA", "Manage release
versions", or some equivalent set). The third use case seems to be the
focus of the current site, based on the layout, and the significant
space the different information takes up (colorful charts and fonts,
use of italics and bold, section headers to this various information).
It is this third use case that seems at greatest risk of being lost if
the site is replaced by the wizard (as is). If the wizard view were to
add these things, or if they were available on whimsy, then I think it
could replace the current view. But if the wizard were to replace the
site right now, it looks like those features would simply go away.

> With regards,
> Daniel.
>
> >
> > On Mon, Aug 5, 2019 at 4:41 AM Daniel Gruno  wrote:
> >>
> >> Hi folks,
> >> I would like to change the default reporter.a.o[1] to be the new wizard
> >> tool[2]. I think it's a good overall improvement and honestly do not see
> >> any downsides to switching. So I'm calling a lazy consensus "vote" for
> >> this change. If there are people that strongly prefer the old one,
> >> please do let me know, and please elaborate on what you'd like to see
> >> changed in the new tool for it to become the

Re: [Lazy Consensus] Changing the default reporter tool

[Christopher]

The new reporter wizard helps folks create a board report, but it
doesn't seem to have any of the other features of the current
reporeter.a.o tool. For example, helping them to manage recorded
releases (https://reporter.apache.org/addrelease.html?), view
community health score (https://reporter.apache.org/chi.py#),
quickly view JIRA stats and PMC/committer changes, etc.

Are all of those features available elsewhere, or will they be
replaced by the new tool?

On Mon, Aug 5, 2019 at 4:41 AM Daniel Gruno  wrote:
>
> Hi folks,
> I would like to change the default reporter.a.o[1] to be the new wizard
> tool[2]. I think it's a good overall improvement and honestly do not see
> any downsides to switching. So I'm calling a lazy consensus "vote" for
> this change. If there are people that strongly prefer the old one,
> please do let me know, and please elaborate on what you'd like to see
> changed in the new tool for it to become the default.
>
> I'll let this run for a few days and see if anyone objects :)
>
> With regards,
> Daniel.
>
> [1] https://reporter.apache.org/
> [2] https://reporter.apache.org/wizard/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: New board report wizard, feedback welcome!

[Christopher]

Pretty neat.

Could add a send draft to list feature (private@ or dev@ for community review).
Does it support editing by multiple people? Can one person resume a
draft saved by another?
Would be nice to have questions from the previous board feedback
auto-populated to be answered in the current report.

On Wed, Jul 31, 2019 at 3:34 PM Daniel Gruno  wrote:
>
> Hi folks,
> I've been working on a new board report tool to help address some of the
> most common issues with the current tool (mainly that it favors
> auto-inserted metrics over the story and doesn't guide people very well)
> and have thus far come up with this new wizard:
>
> https://reporter.apache.org/wizard/
>
> It's open to all committers to review, though easiest if you're on a PMC
> of some sort. There are some ideas being brewed, and some features that
> aren't complete (such as the draft/publish buttons and additional helper
> text).
>
> I'd like people to take a look, and provide some feedback. I am stringly
> contemplating either replacing the existing reporter tool with this (but
> keeping the getjson.py which powers both), or a link from the old to the
> new.
>
> Anyway, feedback is most welcome!
> Things will probably change as we go along and feedback comes in.
>
> With regards,
> Daniel.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Please add your release data for 'yetus'

[Christopher]

According to https://www.apache.org/foundation/glossary.html, a
"release" is "a package offered to the general public by The Apache
Software Foundation". By adding the artifact to the public mirrors
(which is what you do when you commit the files to the dist SVN), you
are releasing. So, in my opinion, the date should be the date you
uploaded the file to the dist SVN, regardless of when you announce or
upload your website, because that's the date you are offering the file
to the general public.

On Thu, Jan 17, 2019 at 10:27 AM Allen Wittenauer
 wrote:
>
>
> Dear dev@community:
>
> I would (and even went to reporter first), but reporter has a bug:  I can’t 
> set the date for tomorrow when we will actually announce the release… which 
> will be 24 hours after the initial upload.
>
>
> > On Jan 17, 2019, at 10:14 AM, Apache Reporter Service 
> >  wrote:
> >
> > Hi,
> > This is an automated email from reporter.apache.org.
> > I see that you just pushed something to our release repository for the 
> > 'yetus' project
> > in the following commit:
> >
> > r32015 at 2019-01-17 15:12:31 + (Thu, 17 Jan 2019)
> > Publish Apache Yetus 0.9.0
> >
> > If you are a PMC member of this project, we ask that you log on to:
> > https://reporter.apache.org/addrelease.html?yetus
> > and add your release data (version and date) to the database.
> >
> > If you are not a PMC member, please have a PMC member add this information.
> >
> > NOTE:
> > This task is entirely optional and your release does NOT depend on it.
> >
> > While not a requirement, we kindly ask that you still add this data to the
> > reporter database, so that people using the Apache Reporter Service will be
> > able to see the latest release data for this project.
> >
> > Also, please ensure that you remove [1] any older releases.
> >
> > With regards,
> > The Apache Reporter Service.
> >
> > [1] http://www.apache.org/dev/release.html#when-to-archive
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Upcoming event "ad" needed

[Christopher]

The dates on the graphic differ from the events website.
On Tue, Dec 4, 2018 at 4:03 PM Rich Bowen  wrote:
>
> On 11/12/18 7:47 AM, Rich Bowen wrote:
> > We still need someone to create the ad images for the upcoming Apache
> > Roadshow. Project sites are still displaying the ad for Apachecon
> > Montreal. If anybody has the skill and time to do this, it would be
> > great if we could get that done this week.
>
> FWIW, I've updated these images. They don't look great, but at least
> they're correct now.
>
> Volunteers who know their way around image creation still welcome to
> make them look better.
>
> http://apache.org/events/README.txt
>
> --Rich
>
>
> --
> Rich Bowen - rbo...@rcbowen.com
> http://rcbowen.com/
> @rbowen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)

[Christopher]

On Mon, Nov 5, 2018 at 12:44 PM Dave Fisher  wrote:
>
>
>
> > On Nov 5, 2018, at 8:35 AM, Christopher  wrote:
> >
> > On Mon, Nov 5, 2018 at 3:49 AM Bertrand Delacretaz
> >  wrote:
> >>
> >> Hi,
> >>
> >> On Fri, Nov 2, 2018 at 7:02 PM Christopher  wrote:
> >>> ...it would be a mistake if ASF were to try to impose a more spammy
> >>> workflow to dev@ onto every PMC, as a requirement...
> >>
> >> FWIW I didn't suggest imposing anything like that - my only concern is
> >> that it should be possible to follow the action of any of our projects
> >> just by subscribing to their dev list.
> >>
> >
> > That problem is not specific to GitHub. Are you equally concerned
> > about JIRA activity going to notifications@ and SVN activity going to
> > commits@ (especially with commit-then-review) ?
> >
> >> Watching GitHub repositories is fine but some of our projects have
> >> many repositories and just finding out which ones to watch depending
> >> on what one's interested in can be problematic, IMO.
> >>
> >> -Bertrand
> >>
> >
> > A weekly summary of active issues/PRs for all of that project's repos,
> > posted to the dev@ list might be useful, but it could also be too
> > large to be useful.
> >
> > It might also be useful to contributors to have an automated monthly
> > email from INFRA to remind the project of all INFRA resources used by
> > the project, such as mailing lists, git repos, git mirrors, reserved
> > svn paths, issue trackers, Maven staging profiles, etc. That way,
> > newcomers can be made aware of all resources in use by the project (in
> > case they missed that info on the project website), so they can have
> > an opportunity to subscribe to them as they choose, or ask questions
> > about them on the dev@ list.
>
> The Whimsy Roster for a PMC has most of this information. It might be nice to 
> have a public version of the project information.
>
> Links
> Mailing Lists
> Committers
> PMC
> Prior Reports

I think Bertrand was specifically concerned about making more
information about project activity locations available to dev@
subscribers. In my opinion, that information should already be on the
project's website, so Whimsy making that public is redundant. But, a
periodic reminder to dev@ subscribers might be useful to communicate
to dev@ subscribers directly.

>
> Regards,
> Dave
>
>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)

[Christopher]

On Mon, Nov 5, 2018 at 3:49 AM Bertrand Delacretaz
 wrote:
>
> Hi,
>
> On Fri, Nov 2, 2018 at 7:02 PM Christopher  wrote:
> >...it would be a mistake if ASF were to try to impose a more spammy
> > workflow to dev@ onto every PMC, as a requirement...
>
> FWIW I didn't suggest imposing anything like that - my only concern is
> that it should be possible to follow the action of any of our projects
> just by subscribing to their dev list.
>

That problem is not specific to GitHub. Are you equally concerned
about JIRA activity going to notifications@ and SVN activity going to
commits@ (especially with commit-then-review) ?

> Watching GitHub repositories is fine but some of our projects have
> many repositories and just finding out which ones to watch depending
> on what one's interested in can be problematic, IMO.
>
> -Bertrand
>

A weekly summary of active issues/PRs for all of that project's repos,
posted to the dev@ list might be useful, but it could also be too
large to be useful.

It might also be useful to contributors to have an automated monthly
email from INFRA to remind the project of all INFRA resources used by
the project, such as mailing lists, git repos, git mirrors, reserved
svn paths, issue trackers, Maven staging profiles, etc. That way,
newcomers can be made aware of all resources in use by the project (in
case they missed that info on the project website), so they can have
an opportunity to subscribe to them as they choose, or ask questions
about them on the dev@ list.

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

Re: Discussions in pull requests vs. dev list (was: The Apache Way and good developers...)

[Christopher]

In Accumulo and Fluo, we route to notifications@ also. If these went
to dev@, it would be too spammy, and I suspect even fewer people would
participate on important dev@ threads than they do now. Letting it go
to notifications@, people can subscribe to all activity there, if they
wish... or they can go to GitHub and subscribe/unsubscribe to GitHub
notifications for the entire repo ("Watch"), or per-thread, based on
their individual desires. They can also unsubscribe from
notifications@ to avoid duplicate notices if they are already
subscribed to GitHub's notifications (which, to be honest, are far
more useful, easier to read, and better formatted, than emails from
ASF with the same content; you can also automatically avoid notices
from your own activity... something you can't do on list). Using
notifications@ instead of dev@ and users choosing (or not) to get
notifications from GitHub is the best of both worlds and provides
maximal user choice.

There may be room for suggested improvements and best practices, but I
think it would be a mistake if ASF were to try to impose a more spammy
workflow to dev@ onto every PMC, as a requirement. I understand the
utility and universality of mailing lists... but there comes a point
where our reliance on them for all activity, becomes a deterrent to
ASF participation, especially for younger contributors who expect more
convenience than threaded walls of text in their email inbox.
On Fri, Nov 2, 2018 at 1:46 PM Joan Touzet  wrote:
>
> We also use them successfully on CouchDB and I don't see the problem here.
> We do route these notifications to notifications@, not dev@.
> My email client properly threads multiple comments on the same PR.
>
> Another option is to use the GitHub "watch" functionality on a repository, 
> which can provide better formatted emails than the ASF Infra solution 
> currently does. They also seem to thread better for some.
>
> It's important to note that our process forces PRs for all changes to master 
> or any release branch (R-T-C, not C-T-R), and that PRs cannot be merged 
> unless our full test suite passes. This is automatically enforced by GitHub 
> for us.
>
> Automating an email to dev@ with what PRs have opened/merged/closed with 
> numerical counts sounds useful, but not mandatory. People that care can just 
> use GitHub's "watch" function, then put filters in their mail client to 
> highlight the things they care about (for instance, UI changes, or changes to 
> a specific file or directory).
>
> -Joan
> - Original Message -
> From: "Christofer Dutz" 
> To: dev@community.apache.org
> Sent: Friday, November 2, 2018 1:30:47 PM
> Subject: Re: Discussions in pull requests vs. dev list (was: The Apache Way 
> and good developers...)
>
> Hi,
>
> Well in the PLC4X project we are using GitHub pull requests. All comments are 
> forwarded to the list and this is fine. You are able to follow what's going 
> on without much problems.
>
> However when it comes to the PR reviews, things tend to get it of hand. Every 
> now and then I open my mail client to find 50 new emails and all of these are 
> related to a single PR and each mail being a single comment. This is 
> extremely annoying
>
> Chris
>
> Outlook for Android herunterladen
>
> From: Dave Fisher 
> Sent: Friday, November 2, 2018 4:59:43 PM
> To: dev@community.apache.org
> Subject: Re: Discussions in pull requests vs. dev list (was: The Apache Way 
> and good developers...)
>
> HI Bertrand,
>
> YES! This is the big issue with GitHub based projects/podlings.
>
> > On Nov 2, 2018, at 9:14 AM, Bertrand Delacretaz  
> > wrote:
> >
> > Hi,
> >
> > I'd like to address this specifically as I think it's a common issue
> > in many of our projects today.
> >
> > On Fri, Nov 2, 2018 at 4:31 PM Craig Russell  wrote:
> >> ...One potential problem is the work flow using the github tools, which 
> >> can have the effect
> >> of dialog "off-list" between the submitter and the other devs...
> >
> > I agree with that - in a project where most of the action happens on
> > GitHub (*) it can be hard or impossible to follow the action by just
> > subscribing to the project's dev list.
> >
> > I don't think there's anything wrong with discussions happening in
> > pull requests (PRs), that's the natural way of working in GitHub and
> > their tools are extremely convenient and efficient.
> >
> > However I think we need to stick to the principle that someone who's
> > just reading the dev list isn't missing out on anything. It is what
> > puts part-time contributors on an equal footing with people who work
> > full time on our projects which is IMO a key aspect of the Apache Way.
> >
> > So, how do we fix this? Blindly copying all GitHub PR comments to a
> > mailing list won't work IMO, as the result is not easy nor convenient
> > to follow. Copying is required for archival purposes (**) but not
> > practical for us humans IMO so I recommend copying to an "activity" or
> > "commits" l

Re: [DISCUSSION] Running another ASF Committer Diversity Survey

[Christopher]

Agreed. It should not be significantly longer. Even without being
longer or differently scoped, it occurs to me that an "Annual
Community Survey" may just be better branding and may elicit more
responses.

I'd be happy to try to help with reviewing and providing feedback on
question wording and survey length.
On Tue, Oct 2, 2018 at 3:09 PM Joan Touzet  wrote:
>
> One problem with such an approach is that by lengthening the survey, you
> end up with more "drop-outs," i.e., people who don't finish the complete
> survey. This means that you have a reduced sample set. I believe the 2016
> survey didn't count any partial responses, which is typically good
> practice from a quantitative standpoint.
>
> I'm not opposed to a couple of questions, but we shouldn't take what was
> an 8-ish question survey and turn it into a 20-ish question survey. The
> 13% response rate we had would likely be halved, if not worse.
>
> -Joan
>
> - Original Message -
> > From: "Christopher" 
> > To: "ComDev" 
> > Sent: Tuesday, October 2, 2018 1:52:44 PM
> > Subject: Re: [DISCUSSION] Running another ASF Committer Diversity Survey
> >
> > Would it be possible to widen the survey's scope to a broader
> > "Community Survey", while still retaining the diversity questions as
> > one component, but also including other non-diversity questions
> > pertaining to the ASF community at large?
> >
> > This suggestion comes from some conversations in Montreal, where some
> > of us discussed the desire to have some additional feedback from our
> > community. For example, one question I remember being discussed in
> > particular was something like "If the ASF had more money, what should
> > it do with it?" (possible answers: marketing materials provided to
> > PMCs, hire more INFRA, provide EC2 credits to PMCs or INFRA for CI,
> > publish educational/outreach materials for distribution, other). I'm
> > sure we could come up with additional questions for the non-diversity
> > component to the survey as well.
> >
> > Does broadening the scope of this survey to include diversity and
> > non-diversity components make sense?
> > On Mon, Oct 1, 2018 at 5:30 AM Sharan Foga  wrote:
> > >
> > > Hi All
> > >
> > > It’s been nearly 2 years since we ran our ASF Committer Diversity
> > > Survey so I think it's about time that we looked at running it
> > > again to see if things are changing. For those of you who haven't
> > > seen the details or the results from our 2016 ASF Committer
> > > Diversity Survey then you can find them at the link below:
> > >
> > > https://s.apache.org/lV9h
> > >
> > > Our original 2016 survey was run to:
> > >
> > >   -  help us get a picture of our existing diversity as all our
> > >   committers are linked to all ASF projects, and also;
> > >  -   to create a baseline measure so we can see if we see if we are
> > >  improving or not in our diversity efforts.
> > >
> > > So I think that it would also be good to discuss and review the
> > > survey questions to see if we can improve them or the phrasing to
> > > better capture the data. Also if anyone is interested in helping
> > > out then please let me know.
> > >
> > > Thanks
> > > Sharan
> > >
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > For additional commands, e-mail: dev-h...@community.apache.org
> > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Post-Apachecon volunteers needed

[Christopher]

I would like to suggest somebody update the image at:
https://www.apache.org/events/current-event-234x60.png
and modify the redirect from
https://www.apache.org/events/current-event.html to go to
https://events.apache.org

Every PMC was requested to put one of these images on their front
page, linking to that link, and now all projects that did have an
out-of-date logo. It'd be useful to fix it in one place, rather than
every project modify their home page again. :)

See https://whimsy.apache.org/site/check/events for the Whimsy check
related to this.

On Mon, Oct 1, 2018 at 4:31 PM Rich Bowen  wrote:
>
> Oh, and we also need someone to update all the moving parts of
> http://apache.org/events/README
>
> Again, if nobody gets to it, I will eventually, of course, but these are
> places where any of you can step up if you have the time.
>
> On 10/1/18 8:40 AM, Rich Bowen wrote:
> > In the days following ApacheCon, I need some folks to step up to do a
> > few things. Here's a partial list. I'm sure there will be more.
> >
> >
> > * Update archives.apachecon.com
> >
> > * Update Apachecon.com site to reflect upcoming events
> >
> > * Twitter schedule for session recordings - specifically, take the list
> > of session recordings from http://feathercast.apache.org/, and put them
> > into a Hootsuite import csv format, or at least into a spreadsheet that
> > I can turn into one.
> >
> > * Promote videos of keynotes, and LTs, via social media.
> >
> > * Create timestamp index of lightning talk video -
> > https://youtu.be/FTROCvmhXko - with the start of each individual
> > lightning talk.
> >
> > Please raise your hand for one of the above tasks, but only if you
> > actually have time for it. No licked cookies, please.
> >
> >
>
> --
> Rich Bowen - rbo...@rcbowen.com
> http://rcbowen.com/
> @rbowen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: [DISCUSSION] Running another ASF Committer Diversity Survey

[Christopher]

Would it be possible to widen the survey's scope to a broader
"Community Survey", while still retaining the diversity questions as
one component, but also including other non-diversity questions
pertaining to the ASF community at large?

This suggestion comes from some conversations in Montreal, where some
of us discussed the desire to have some additional feedback from our
community. For example, one question I remember being discussed in
particular was something like "If the ASF had more money, what should
it do with it?" (possible answers: marketing materials provided to
PMCs, hire more INFRA, provide EC2 credits to PMCs or INFRA for CI,
publish educational/outreach materials for distribution, other). I'm
sure we could come up with additional questions for the non-diversity
component to the survey as well.

Does broadening the scope of this survey to include diversity and
non-diversity components make sense?
On Mon, Oct 1, 2018 at 5:30 AM Sharan Foga  wrote:
>
> Hi All
>
> It’s been nearly 2 years since we ran our ASF Committer Diversity Survey so I 
> think it's about time that we looked at running it again to see if things are 
> changing. For those of you who haven't seen the details or the results from 
> our 2016 ASF Committer Diversity Survey then you can find them at the link 
> below:
>
> https://s.apache.org/lV9h
>
> Our original 2016 survey was run to:
>
>   -  help us get a picture of our existing diversity as all our committers 
> are linked to all ASF projects, and also;
>  -   to create a baseline measure so we can see if we see if we are improving 
> or not in our diversity efforts.
>
> So I think that it would also be good to discuss and review the survey 
> questions to see if we can improve them or the phrasing to better capture the 
> data. Also if anyone is interested in helping out then please let me know.
>
> Thanks
> Sharan
>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Two problems (and suggested fixes) in projects.apache.org

[Christopher]

The first issue is not really with p.a.o, but with Whimsy:

In https://whimsy.apache.org/public/committee-info.json, the webpages are
listed as http:// instead of https:// (or unqualified), which causes them
to be imported into projects.apache.org with the insecure link with no
way for the PMC to override this to ensure their site uses https:// there.

I can manually update projects.apache.org by modifying files in
https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/site/json/foundation/
(especially
committees.json), but I'm pretty sure a cron job will undo the changes.

Suggested fix: use the value of the committee's RDF in
data/committees/.rdf file's  field's "rdf:resource"
attribute instead.
Alternatively, just use https:// everywhere by default.


The second issue is that repositories.json is out of date:

There does not appear to be any cron scripts or README explaining how this
file is updated. It doesn't appear to be updated at all, since repositories
which don't exist in https://git.apache.org are still listed here
(incubator repos which have graduated are notable ones). Also, nothing from
https://gitbox.apache.org/repos/asf is listed in this file, even though
they should be.

Suggested fix: have a cron job regularly scrape both https://git.apache.org and
https://gitbox.apache.org/repos/asf to update repositories.json


Thanks,

Christopher

Re: Is DOAP still a thing?

[Christopher]

On Wed, Apr 18, 2018 at 7:03 PM Hervé BOUTEMY  wrote:

> Le jeudi 19 avril 2018, 00:05:01 CEST Christopher a écrit :
> [...]
> > > > Yeah. That's great, but as I pointed out, it's useless to do so if
> they
> > > > aren't utilized for any other purpose.
> > >
> > > As I keep saying, the DOAPs *ARE* used to build the p.a.o pages.
> >
> > Okay, okay. Sorry, Sebb. You're right. It does seem to still be in use
> for
> > building some portions of p.a.o. I just didn't see any evidence of that,
> > and could not find any documentation on *how* it is used to build them.
> perhaps I should just add that PMC RDF data files are used to build
> Committees
> pages: https://projects.apache.org/committees.html (Committee is a
> synonym
> here for PMC)
> and projects DOAP files are used to build Projects pages:
> https://projects.apache.org/projects.html
>
>
Who maintains the "PMC RDF data files" which are "used to build Committees
pages", and where are those stored?


> it's not so obvious since the difference between Committe and Project is
> not
> so obvious
>
> I'm happy to have some feedback on the documentation written, that I'm not
> sure many people read: I'll be happy to improve it given on the feedback
>
> >
> > You are right. I was mistaken. I had not spent enough time on the site to
> > understand how it is used, and it was not obvious to me that any
> > functionality was missing when the DOAP file was missing. Sorry for the
> > misunderstanding on my part.
> >
> > After some more time spent on the site, I was able to see some portions
> > which don't work if the DOAP is missing. Specifically, I can now see that
> > it is used for grouping projects by language, by category, and listing
> > releases (which is the information I was asking for, and which would be
> > useful to add to [2], along with any other way it is used that I did not
> > observe.)
> >
> > I do think it is preferred that p.a.o get release information from
> > reporter.a.o instead... it would make maintaining DOAP simpler, and
> reduce
> > the burden on developers to maintain a duplicate dataset.
> I confess that Branko's remark about "Semantic Web aficionados appear to
> have
> vanished into the space between microservices" seems relevant...
> the idea behind using some universal format, and not just Apache internal
> tooling, was appealing: everything that is done magically by internal
> tooling
> has drawbacks.
> But for sure, the release part is the most hard to manually maintain part.
>
>
The problem with this universal format is the pain to maintain. If
"(whimsy|reporter|projects)[.]apache[.]org", or another tool provided a
good UI to generate the universal format... I don't think maintenance would
be an issue. Over the last few years, I keep encountering what I think is
probably some sort of universal truth: the problems with nearly any process
or workflow is lack of adequate tooling.


> > Thank you for your persistence in educating me. I did eventually get
> there.
> > Sorry if my confusion and ignorance caused any unnecessary strife. :)
> It's good to have feedback and interest, even if the interest contains
> criticism: it's constructive feedback
>
>
Indeed. Which is why I only apologize for the strife which is
"unnecessary". :)


> Regards,
>
> Hervé
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Is DOAP still a thing?

[Christopher]

On Tue, Apr 17, 2018 at 8:12 PM sebb  wrote:

> On 17 April 2018 at 22:00, Christopher  wrote:
> > On Tue, Apr 17, 2018 at 4:16 PM sebb  wrote:
> >
> >> On 17 April 2018 at 20:05, Christopher  wrote:
> >> > On Tue, Apr 17, 2018 at 2:48 PM sebb  wrote:
> >> >
> >> >> On 17 April 2018 at 19:04, Christopher  wrote:
> >> >> > I've noticed some TLPs don't have DOAP files, and many others are
> not
> >> >> > well-maintained.
> >> >>
> >> >> True
> >> >>
> >> >> > As I understand it, these were once used to populate
> >> projects.apache.org
> >> >> [1]
> >> >> > But, I do not think they have any current use. (please correct me
> if
> >> I'm
> >> >> > wrong)
> >> >>
> >> >> They *are* still used for projects.a.o, as per the About page:
> >> >> [2] https://projects.apache.org/about.html
> >> >>
> >> >>
> >> > It is certainly the case that the documentation *says* they are still
> >> used,
> >> > but I think that's a case of the documentation being wrong or
> outdated.
> >> >
> >> > Projects without them seem to be listed just as well as projects which
> >> have
> >> > them.
> >>
> >> I think you are confusing projects with PMCs.
> >>
> >>
> > No. I definitely mean "projects", as in TLP ("Top Level Project"), "
> > projects.apache.org", and DOAP ("description of a project").
> >
> > The *project* is missing the DOAP, because their *PMC* did not create
> one.
> > Yet, nothing seems to be broken.
>
> It seems not to be broken because the website creates minimal project
> pages for each PMC.
> This assumes that the project name is the same as the name of the PMC.
> Perhaps it should not do that.
>
> >
> >> >
> >> >> > The premise of the file ("to be listed on this site") is certainly
> >> false,
> >> >> > at the very least.
> >> >>
> >> >> [1] is a page from the original projects site and may need tweaking.
> >> >>
> >> >>
> >> > As far as I can tell, it is the *only* place where DOAP files are
> >> > documented for purpose, structure, and the process to make use of
> them.
> >> > The about page in [2] does not substitute for any of this
> documentation.
> >>
> >> Why not?
> >>
> >
> > [2] is not a substitute for [1], because it does not have any of the
> > content contained in [1].
> >
> >
> >> Where should it be documented?
> >>
> >>
> > I don't know... you were the one who pointed to that page, not me. I
> never
> > said [2] should be a substitute for [1]. I'm just trying to figure out if
> > [1] or [2] (or any other DOAP documentation) is relevant *AT ALL*. [1]
> > describes the original purpose, etc., but it does not seem relevant
> > anymore, and no other page describes its current relevance.
>
> I have already written that the DOAPs are used to flesh out the Project
> pages.
>
> >
> >> > So, if [1] is out of date, then there is no current documentation for
> >> > purpose, structure, or process to make use of them.
> >>
> >> [2]
> >>
> >>
> > No. [2] doesn't have any of that content. It merely mentions that they
> > exist and that the PMC is responsible for them.
>
> It also implies that the DOAPs are used to build the p.a.o pages.
>
> >
> >> >
> >> >> > And, despite the numerous site checks Whimsy does, checking for
> DOAP
> >> does
> >> >> > not appear to be one of them, though it does provide a link, if it
> >> exists
> >> >> > for a project.
> >> >>
> >> >> Projects.a.o validates them.
> >> >>
> >> >>
> >> > Okay. But, just as a spellcheck of an email which is never sent is
> >> useless,
> >> > so too is validation of an RDF file which is never utilized.
> >>
> >> projects.a.o validates all the DOAPs that it is told about as per [2]
> >>
> >>
> > Yeah. That's great, but as I pointed out, it's useless to do so if they
> > aren't utilized for any other purpose.
>
> As I keep saying, the DOAPs *ARE* used to build the p.a.o pages.
&

Re: Is DOAP still a thing?

[Christopher]

On Tue, Apr 17, 2018 at 4:16 PM sebb  wrote:

> On 17 April 2018 at 20:05, Christopher  wrote:
> > On Tue, Apr 17, 2018 at 2:48 PM sebb  wrote:
> >
> >> On 17 April 2018 at 19:04, Christopher  wrote:
> >> > I've noticed some TLPs don't have DOAP files, and many others are not
> >> > well-maintained.
> >>
> >> True
> >>
> >> > As I understand it, these were once used to populate
> projects.apache.org
> >> [1]
> >> > But, I do not think they have any current use. (please correct me if
> I'm
> >> > wrong)
> >>
> >> They *are* still used for projects.a.o, as per the About page:
> >> [2] https://projects.apache.org/about.html
> >>
> >>
> > It is certainly the case that the documentation *says* they are still
> used,
> > but I think that's a case of the documentation being wrong or outdated.
> >
> > Projects without them seem to be listed just as well as projects which
> have
> > them.
>
> I think you are confusing projects with PMCs.
>
>
No. I definitely mean "projects", as in TLP ("Top Level Project"), "
projects.apache.org", and DOAP ("description of a project").

The *project* is missing the DOAP, because their *PMC* did not create one.
Yet, nothing seems to be broken.


> >
> >> > The premise of the file ("to be listed on this site") is certainly
> false,
> >> > at the very least.
> >>
> >> [1] is a page from the original projects site and may need tweaking.
> >>
> >>
> > As far as I can tell, it is the *only* place where DOAP files are
> > documented for purpose, structure, and the process to make use of them.
> > The about page in [2] does not substitute for any of this documentation.
>
> Why not?
>

[2] is not a substitute for [1], because it does not have any of the
content contained in [1].


> Where should it be documented?
>
>
I don't know... you were the one who pointed to that page, not me. I never
said [2] should be a substitute for [1]. I'm just trying to figure out if
[1] or [2] (or any other DOAP documentation) is relevant *AT ALL*. [1]
describes the original purpose, etc., but it does not seem relevant
anymore, and no other page describes its current relevance.


> > So, if [1] is out of date, then there is no current documentation for
> > purpose, structure, or process to make use of them.
>
> [2]
>
>
No. [2] doesn't have any of that content. It merely mentions that they
exist and that the PMC is responsible for them.


> >
> >> > And, despite the numerous site checks Whimsy does, checking for DOAP
> does
> >> > not appear to be one of them, though it does provide a link, if it
> exists
> >> > for a project.
> >>
> >> Projects.a.o validates them.
> >>
> >>
> > Okay. But, just as a spellcheck of an email which is never sent is
> useless,
> > so too is validation of an RDF file which is never utilized.
>
> projects.a.o validates all the DOAPs that it is told about as per [2]
>
>
Yeah. That's great, but as I pointed out, it's useless to do so if they
aren't utilized for any other purpose.


> >
> >> > My questions are:
> >> > Is a DOAP file required?
> >> > If so, by what policy
> >>
> >> No idea
> >>
> >> > and for what purpose?
> >>
> >> See [2]
> >>
> >>
> > That does not explain purpose. It simply mentions the fact that they
> exist
> > and who is responsible for maintaining them. It does link to a cwiki page
> > which describes itself as containing "historical information", which
> > further suggests they have no current use (or at least, no currently
> > documented use).
>
> [2] says:
>
> How The Code Works
> ... from various data sources ...
> 3. Project DOAP files listed in
>
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml
>
>
Yeah, I know what it says. But it's not true. It doesn't say how it is
used, it doesn't say what purpose it serves currently, and if a project
doesn't have one, nothing seems to be broken.

So, my questions still stand:

Are they still required?
If so, by what policy and for what purpose? (not the original purpose,
documented at [1]... but the *current* purpose, which in spite of being
mentioned on [2], does not actually appear to exist).


> >
> >> >
> >> > Thanks,
> >> >
> >> > Christopher
> >> >
> >> > [1]: https://projects.apache.org/create.html
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Is DOAP still a thing?

[Christopher]

On Tue, Apr 17, 2018 at 2:48 PM sebb  wrote:

> On 17 April 2018 at 19:04, Christopher  wrote:
> > I've noticed some TLPs don't have DOAP files, and many others are not
> > well-maintained.
>
> True
>
> > As I understand it, these were once used to populate projects.apache.org
> [1]
> > But, I do not think they have any current use. (please correct me if I'm
> > wrong)
>
> They *are* still used for projects.a.o, as per the About page:
> [2] https://projects.apache.org/about.html
>
>
It is certainly the case that the documentation *says* they are still used,
but I think that's a case of the documentation being wrong or outdated.

Projects without them seem to be listed just as well as projects which have
them.


> > The premise of the file ("to be listed on this site") is certainly false,
> > at the very least.
>
> [1] is a page from the original projects site and may need tweaking.
>
>
As far as I can tell, it is the *only* place where DOAP files are
documented for purpose, structure, and the process to make use of them.
The about page in [2] does not substitute for any of this documentation.
So, if [1] is out of date, then there is no current documentation for
purpose, structure, or process to make use of them.


> > And, despite the numerous site checks Whimsy does, checking for DOAP does
> > not appear to be one of them, though it does provide a link, if it exists
> > for a project.
>
> Projects.a.o validates them.
>
>
Okay. But, just as a spellcheck of an email which is never sent is useless,
so too is validation of an RDF file which is never utilized.


> > My questions are:
> > Is a DOAP file required?
> > If so, by what policy
>
> No idea
>
> > and for what purpose?
>
> See [2]
>
>
That does not explain purpose. It simply mentions the fact that they exist
and who is responsible for maintaining them. It does link to a cwiki page
which describes itself as containing "historical information", which
further suggests they have no current use (or at least, no currently
documented use).


> >
> > Thanks,
> >
> > Christopher
> >
> > [1]: https://projects.apache.org/create.html
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Is DOAP still a thing?

[Christopher]

I've noticed some TLPs don't have DOAP files, and many others are not
well-maintained.
As I understand it, these were once used to populate projects.apache.org[1]
But, I do not think they have any current use. (please correct me if I'm
wrong)
The premise of the file ("to be listed on this site") is certainly false,
at the very least.
And, despite the numerous site checks Whimsy does, checking for DOAP does
not appear to be one of them, though it does provide a link, if it exists
for a project.

My questions are:
Is a DOAP file required?
If so, by what policy and for what purpose?


Thanks,

Christopher

[1]: https://projects.apache.org/create.html

Re: reporter.apache.org improvements

[Christopher]

On Thu, Apr 12, 2018 at 10:30 AM sebb  wrote:

> On 12 April 2018 at 15:11, Christopher  wrote:
> > Regarding the release date in the future, the release date is the date it
> > was uploaded to the mirror distribution channel. It can't be in the
> future
> > if you're responding to the email reminder.
>
> Also, IMO release dates should not be published before the software is
> actually released.
>
>
+1 to that. A reasonable automated process might be something like:

svn mv   && curl
 reporter.apache.org


> > On Thu, Apr 12, 2018, 05:53 Julian Foad  wrote:
> >
> >> About https://reporter.apache.org:
> >>
> >> 1) What is the policy for suggesting and committing changes to the
> >> source code? Should I discuss here and then go ahead and commit if there
> >> is consensus? Are there separate "live" and "development"/"staging"
> >> versions?
> >>
> >> 2) Automation. As the current release manager for Apache Subversion I
> >> would like to automate the sending of release data to this tool. Is
> >> there any more automation currently possible for adding a release than
> >> the "/addrelease.html?subversion" selector that the reminder email
> >> already gives me?
> >>
> >> I found the following note:
> >>
> >>"site/addrelease.py?json=true&committee=xxx&version=xxx&date=xxx"
> >>
> >> right at the end of
> >>
> >>
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk/README.txt
> >>
> >> Can I access that functionality as an end user?
> >>
> >> 3) Future dates. When I publish a release, 24h in advance of release
> >> date, I get a reminder email to report it here, but then when I try to
> >> fill in the data here, with a release date of tomorrow, it errors with
> >> "date is in the future" which is true but should not be an error. Please
> >> could we change this? I think it would be ideal to allow releases to be
> >> notified up to something like 31 days in advance, while still catching
> >> far-future dates that are more likely to be errors.
> >>
> >> [[[
> >> Index: site/js/addrelease.js
> >> ===
> >> --- site/js/addrelease.js   (revision 1828957)
> >> +++ site/js/addrelease.js   (working copy)
> >> @@ -25,4 +25,4 @@
> >> var now = (new Date().getTime())/1000
> >> -  if (nn >= now) {
> >> -alert("The date is in the future!")
> >> +  if ((nn - now) > 60*60*24*31) {
> >> +alert("The date is more than a month in the future!")
> >>   return false
> >> ]]]
> >>
> >> 4) The bugs/issues link is broken, both on the footer of
> >> https://reporter.apache.org/addrelease.html :
> >>
> >>"The Issue tracker is at [JIRA COMDEV, component Reporter]."
> >>
> >> and on https://reporter.apache.org/about.html :
> >>
> >>"Bugs ... [COMDEV project, component Reporter]."
> >>
> >> I am not sure what the correct URL would be.
> >>
> >>
> >> Thanks in advance for your comments.
> >>
> >> - Julian
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: reporter.apache.org improvements

[Christopher]

Regarding the release date in the future, the release date is the date it
was uploaded to the mirror distribution channel. It can't be in the future
if you're responding to the email reminder.

On Thu, Apr 12, 2018, 05:53 Julian Foad  wrote:

> About https://reporter.apache.org:
>
> 1) What is the policy for suggesting and committing changes to the
> source code? Should I discuss here and then go ahead and commit if there
> is consensus? Are there separate "live" and "development"/"staging"
> versions?
>
> 2) Automation. As the current release manager for Apache Subversion I
> would like to automate the sending of release data to this tool. Is
> there any more automation currently possible for adding a release than
> the "/addrelease.html?subversion" selector that the reminder email
> already gives me?
>
> I found the following note:
>
>"site/addrelease.py?json=true&committee=xxx&version=xxx&date=xxx"
>
> right at the end of
>
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk/README.txt
>
> Can I access that functionality as an end user?
>
> 3) Future dates. When I publish a release, 24h in advance of release
> date, I get a reminder email to report it here, but then when I try to
> fill in the data here, with a release date of tomorrow, it errors with
> "date is in the future" which is true but should not be an error. Please
> could we change this? I think it would be ideal to allow releases to be
> notified up to something like 31 days in advance, while still catching
> far-future dates that are more likely to be errors.
>
> [[[
> Index: site/js/addrelease.js
> ===
> --- site/js/addrelease.js   (revision 1828957)
> +++ site/js/addrelease.js   (working copy)
> @@ -25,4 +25,4 @@
> var now = (new Date().getTime())/1000
> -  if (nn >= now) {
> -alert("The date is in the future!")
> +  if ((nn - now) > 60*60*24*31) {
> +alert("The date is more than a month in the future!")
>   return false
> ]]]
>
> 4) The bugs/issues link is broken, both on the footer of
> https://reporter.apache.org/addrelease.html :
>
>"The Issue tracker is at [JIRA COMDEV, component Reporter]."
>
> and on https://reporter.apache.org/about.html :
>
>"Bugs ... [COMDEV project, component Reporter]."
>
> I am not sure what the correct URL would be.
>
>
> Thanks in advance for your comments.
>
> - Julian
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Updated checksum policy doc update

[Christopher]

The recently updated checksum policy from infra means more people should be
using tools like sha512sum or shasum (or even sha1sum) instead of md5sum,
but the instructions for users to verify releases:
https://www.apache.org/info/verification only mention md5sum tools. They
should be updated to include mention of tools for checking SHA-1 and SHA-2
hashes. This page is so old and out of date, that it even still mentions
textutils, which was rolled into coreutils 15 years ago.

I'm not sure who can update this page, but it definitely needs some
attention. Otherwise, projects will have to provide their own, possibly
inconsistent, verification instructions (rather than link to this page, as
many do now).

Re: new committer email template question

[Christopher]

On Thu, Mar 8, 2018 at 7:42 AM Rich Bowen  wrote:

>
>
> On 12/11/2017 02:21 PM, Christopher wrote:
> > Hi ComDev, quick question: [1] suggests committers should be signed up
> for
> > the private mailing list. However, [2] indicates it's a PMC-only mailing
> > list. The latter makes more sense, since voting on committers to join the
> > PMC could result in a socially awkward situation if said committer is
> > subscribed to the private list. Obviously, this only matters if
> committers
> > != PMC.
> >
> > Should the template be corrected?
> >
> > [1]:
> https://community.apache.org/newcommitter.html#committer-done-template
> > [2]: https://www.apache.org/dev/pmc.html#who-can-be-on-private
> >
>
> I would suggest that that paragraph be wrapped in a conditional, such as
>
> [If your project automatically adds committers to the PMC]
> ...
> [/If]
>
> Many projects do.
>
> I have made this change in r1826213.
>
>
Thanks Rich! Makes more sense now! (CC fluo private list, where question
originated, for closure)




> --Rich
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: new committer email template question

[Christopher]

I never got a response to this inquiry. I think the docs are still
inconsistent.

On Mon, Dec 11, 2017 at 2:21 PM Christopher  wrote:

> Hi ComDev, quick question: [1] suggests committers should be signed up for
> the private mailing list. However, [2] indicates it's a PMC-only mailing
> list. The latter makes more sense, since voting on committers to join the
> PMC could result in a socially awkward situation if said committer is
> subscribed to the private list. Obviously, this only matters if committers
> != PMC.
>
> Should the template be corrected?
>
> [1]:
> https://community.apache.org/newcommitter.html#committer-done-template
> [2]: https://www.apache.org/dev/pmc.html#who-can-be-on-private
>
>

new committer email template question

[Christopher]

Hi ComDev, quick question: [1] suggests committers should be signed up for
the private mailing list. However, [2] indicates it's a PMC-only mailing
list. The latter makes more sense, since voting on committers to join the
PMC could result in a socially awkward situation if said committer is
subscribed to the private list. Obviously, this only matters if committers
!= PMC.

Should the template be corrected?

[1]: https://community.apache.org/newcommitter.html#committer-done-template
[2]: https://www.apache.org/dev/pmc.html#who-can-be-on-private

Re: Tracking Someone's First Contribution

[Christopher]

That's exactly what we are doing in Fluo. We ask if it's okay to tweet
about their contribution, and what their Twitter handle is, if it is okay.

On Thu, Nov 9, 2017, 06:02 sebb  wrote:

> I think you should ask the person first.
> Not all will want such publicity.
>
> On 9 November 2017 at 09:48, Jacques Le Roux
>  wrote:
> > +1 Great idea!
> >
> > Jacques
> >
> >
> >
> > Le 09/11/2017 à 10:38, Ignasi Barrera a écrit :
> >>
> >> I think it is a great way to encourage people to contribute.
> >>
> >> In Apache jclouds we always tweet about new contributors and also
> >> about significant contributions made to the code base. We've found
> >> this always motivates the contributor.
> >> We also have a "Credits" section in our release notes pages for all
> >> those new and significant contributors, as a recognition for their
> >> effort and help with the project.
> >>
> >>
> >> I.
> >>
> >> On 9 November 2017 at 10:34, Sharan Foga  wrote:
> >>>
> >>> Hi All
> >>>
> >>> I've contacted the Apache Fluo project because I've seen that
> >>> consistently on Twitter they highlight someone's first contribution to
> the
> >>> project. This is something that could be quite interesting for
> projects to
> >>> promote so I've sent them a message to ask how they are doing it!
> >>>
> >>> Are any other projects currently tracking first contributions?
> >>>
> >>> Thanks
> >>> Sharan
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Whimsy site check for events?

[Christopher]

On Thu, Aug 10, 2017 at 3:49 PM Shane Curcuru  wrote:

> Christopher wrote on 8/10/17 3:45 PM:
> > Hi all,
> >
> > I noticed that Whimsy is doing some helpful QA checks for project sites,
> > and has a check for "Event" (https://whimsy.apache.org/site/check/events
> ).
> > This seems to be a check for a link/image to current events. However, the
> > "current" event image is for the last ApacheCon in Miami (
> > http://www.apache.org/events/current-event-125x125.png). If I'm trying
> to
> > update a project's site to be all green in Whimsy... I'm not sure I want
> to
> > add a link/image to a "current" event which is not actually "current".
> > Should this image just be updated to something generic, or the next
> > upcoming event?
>
> Excellent point - since we do not have a next ApacheCon scheduled, we
> don't necessarily have an event-related image (yet) that we want all
> projects to display.
>
> This is more a question for Rich as VP, Conferences, and for the Whimsy
> PMC at dev@whimsical.  This raises the excellent Whimsy feature point of
> how to display site-check "best practices" rather than "requirements" so
> you can still feel good about updating your website even in this case.
>
>

Regardless of whether it's "best practice" or a "requirement", my main
concern here is that it reflects badly on individual projects which follow
it, because it makes their sites look out-of-date and poorly maintained. I
want to make sure that somebody at ASF is actually taking responsibility
for the content of the image at that location (and any corresponding links
which wrap it) up-to-date, and it isn't getting lost into the infinite well
of forgetting :)

Even a simple change, like replacing it with a transparent image or a
generic image for "ASF Events" (same size image, of course) keeps the
project pages from looking stale when visited.



> Thanks for the question!
>
> --
>
> - Shane
>   https://www.apache.org/foundation/marks/resources
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Whimsy site check for events?

[Christopher]

Hi all,

I noticed that Whimsy is doing some helpful QA checks for project sites,
and has a check for "Event" (https://whimsy.apache.org/site/check/events).
This seems to be a check for a link/image to current events. However, the
"current" event image is for the last ApacheCon in Miami (
http://www.apache.org/events/current-event-125x125.png). If I'm trying to
update a project's site to be all green in Whimsy... I'm not sure I want to
add a link/image to a "current" event which is not actually "current".
Should this image just be updated to something generic, or the next
upcoming event?

Re: Introducing code owners

[Christopher]

s/coffee/code/

On Fri, Jul 7, 2017, 08:37 Christopher  wrote:

> The feature doesn't seem all that different to me than automatic
> assignment to component owners in JIRA or other bug trackers, which are
> useful for distributing triage. I'm not sure how I feel about requiring
> coffee reviews from owners, as a hard prerequisite, though.
>
> On Fri, Jul 7, 2017, 04:19 Greg Stein  wrote:
>
>> Ugh. I suggest that ComDev write up some text explaining why this is a
>> horrible idea :-(
>>
>> https://github.com/blog/2392-introducing-code-owners
>>
>

Re: Introducing code owners

[Christopher]

The feature doesn't seem all that different to me than automatic assignment
to component owners in JIRA or other bug trackers, which are useful for
distributing triage. I'm not sure how I feel about requiring coffee reviews
from owners, as a hard prerequisite, though.

On Fri, Jul 7, 2017, 04:19 Greg Stein  wrote:

> Ugh. I suggest that ComDev write up some text explaining why this is a
> horrible idea :-(
>
> https://github.com/blog/2392-introducing-code-owners
>

Re: New reporter UI

[Christopher]

Looks good.

One suggestion: please fix the time zone translation for the release dates.
The browser is converting the timezone to its local time zone, but these
dates are date/times, they are just dates, and should not be converted
based on time zone. This is annoying because different viewers in time
zones west of UTC will show release dates that are one day earlier than the
actual release date.

This was fixed in the "Manage release versions" page, but it was never
fixed in the "Last release was X.Y.Z, released on ddd MMM DD " part or
in the "Releases" section of the "Report template". I'm not sure the exact
fix, but it seems like it just needs to always present as UTC (since that's
the zone assumed when the raw date string is parsed), regardless of the
browser's time zone.

The only other place a date appears to be shown is "Next report date", and
it looks like that's correctly not doing any time zone translation.

It's not a serious issue, but it's annoying. :)


On Sun, Jun 18, 2017 at 4:07 AM Daniel Gruno  wrote:

> Hi folks,
> I've been working on a new UI for the reporter tool today, and I think
> it's coming together nicely. The new UI can be seen at
> https://reporter.apache.org/ng.html and should prove to be less
> clunky/flashy compared to the old one.
>
> Unless I hear otherwise, I'll change this to be the default UI for the
> reporter tool in a few days. Comments, feedback etc is of course very
> welcome!
>
> With regards,
> Daniel.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Possible ApacheCon BarCamp topic

[Christopher]

Unfortunately, I won't be flying in early enough to attend the BarCamp in
Miami, but I wanted to suggest a possible topic, if anybody attending
wishes to pick it up for discussion there:

Topic:
Establishing and strengthening relationships with downstream packaging

The premise:
Official ASF releases are source artifacts. Some users build from source or
use "convenience binaries" published by ASF projects, but many (maybe
most?) users experience Apache projects through a vendor or through their
operating system software repositories (RHEL/CentOS, Fedora, Ubuntu,
Homebrew, MacPorts, PyPI, RubyGems, etc.). Downstream typically falls into
one of three categories: the DIY user, a commercial vendor supporting many
users, or a community packager supporting many users. "Convenience
binaries" produced within the ASF fall into the third category (one of many
in that category). Though they may have different requirements, each of
these categories have a similar relationship to our upstream software
developer communities, and they are all important for project growth (the
importance each plays in a particular community can vary significantly). I
refer to all three of these as "downstream packagers" or simply "packagers".

Some ideas for discussion:
1. How can we approach packagers to make our software available to their
users?
2. How can we support packaging to ensure a positive experience for both
packagers and end-users?
3. How can we grow our upstream community by encouraging contributions from
packagers?
4. How can we build our software with build- and runtime-flexibility, to
support the different target environment requirements of many packagers
(rather than just a few)?
5. How can we work with packagers to deal with "dependency hell"?
6. How can we simplify/modernize build systems to make it easier for
non-committers to build from source?
7. Which responsibilities are that of the upstream project, and which
should be deferred to downstream?
8. How do new packaging/distribution technologies, such as Docker, Mesos,
and Yarn, change the traditional relationship with packagers?

Conclusion:
Some ASF projects (such as httpd, subversion, ant, and perhaps now maven)
seem have had a lot of success via these downstream community packaging
routes (as have other non-ASF open source projects, like Firefox, MySQL,
PHP, Ruby, etc.). Other ASF projects, however, may still be unclear how to
relate to downstream and what that relationship can bring to the project's
upstream community.  So, I think this could be a potentially valuable topic
to discuss.

Extra:
As both a Fedora packager and an Apache contributor, as well as an
occasional HomeBrew, and frequent DIY user, I find this topic fascinating.
Whether or not it gets discussed at the BarCamp, feel free to reach out to
me during ApacheCon. I'd love to discuss these (or any other) topics over
drinks or lunch or between talks.

P.S. For those unfamiliar, Apache even it's own "downstream" packager
project known as BigTop, that I encourage checking out (and possibly
contributing to).

Re: Apache and Java

[Christopher]

I think you've got the question backwards. The ASF does not really create
projects. Projects create development communities at ASF. So, I think the
real question should be: what makes Apache so appealing to Java-based
projects?

I think the answer to that question is probably "the same things that make
it appealing to any other project". I don't think the ASF is particularly
suited for Java projects over any other language. The prevalence of Java
here is probably mostly historical, with some projects following the build
tooling (ant, ivy, maven) and dependencies (tomcat, commons), because
they've seen the success of those projects they depend on here.

Java itself also probably has something to do with it... Java is a popular
language and it's going to have a high representation in any sufficiently
large community. Java is also prone to modularization with a high number of
smaller projects than fewer larger ones.

It's also possible that Java is just an easier language to build a
community around?

In short, it's probably not just coincidence; there's probably some causal
reasons, but I don't think it matters much, because the ASF doesn't
prescribe languages.

On Sun, Mar 19, 2017, 04:33 Spaghetti Roulette 
wrote:

> Why do Apache projects use Java so extensively? It looks to me that a lot
> of projects, if not most of them, are written in Java, and I can't get my
> head around this fact. Is there any reason, perhaps technical, or is it
> just coincidence?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Gamifying user lists

[Christopher]

Fedora has "Badges"[1][2] you can earn for various levels of participation,
performing reviews, building a package, committing a bugfix, testing, etc.
You even earn silly badges for making mistakes... like pushing a change
which breaks a build. Contributors can propose new badges. It all ties into
a centralized notification system, and you can track where you are compared
to others on how many badges you've earned.

Something like that would really have to be ASF-wide, rather than
project-specific, but projects could create their own custom badges, based
on contributions to their project. ASF-wide badges could be for
participation in multiple projects, and special badges could be for serving
on the board, or chairing a project, mentoring GSoC, hosting a hackathon or
key signing party, presenting at ApacheCon, etc. The number of badges could
be very small to start (becoming a committer, committer on multiple
projects, etc.) and could grow over time.

[1]: https://badges.fedoraproject.org/
[2]: https://github.com/fedora-infra/tahrir

On Fri, Feb 10, 2017 at 9:34 PM Joan Touzet  wrote:

> CouchDB tried AdvocateHub for a while. It's not the best solution but
> it is something like what you're asking for.
>
> -Joan
> - Original Message -
> > From: "Denis Magda" 
> > To: dev@community.apache.org
> > Sent: Friday, February 10, 2017 7:35:46 PM
> > Subject: Gamifying user lists
> >
> > Dear Apache Foundation members,
> >
> > Writing to you in hope to get an advice or to learn more from your
> > experience.
> >
> > As a member of Apache Ignite community I see that a number of
> > questions posted to Ignite's user list steadily grows. This is
> > exciting, for sure. However, it’s not that easy to encourage
> > experienced and active contributors/committers to keep scanning the
> > questions replying in reasonable amount of time. As a result,
> > majority of the questions are either answered by a specific group of
> > people or left unanswered for a while.
> >
> > Has any of you tried to apply gamification techniques for user lists
> > of your Apache community? I’m looking for a platform/tool that can
> > be easily integrated with the user list enriching the latter with
> > ranking charts, most responsive contributors charts, etc. All the
> > communication must keep going on the user list while a tool should
> > gamify the list in background.
> >
> > —
> > Denis
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
> --
Christopher

ApacheCon NA and Big Data dates

[Christopher]

Can anybody tell me what the dates are for ApacheCon NA and Apache: Big
Data?
Last time I looked, it seemed these were co-located back-to-back
conferences at the same venue.
However, now they both show May 16-18.

http://events.linuxfoundation.org/events/apachecon-north-america
http://events.linuxfoundation.org/events/apache-big-data-north-america

What are the correct dates? And, for the purposes of traveling, does
anybody know if there's going to be any evening-before or day-after events
planned?

Thanks.
-- 
Christopher

Re: Profile photos and ASF values

[Christopher]

dths. The
> > Nazi
> >
> > > > one
> >
> > > > > was also at an angle.
> >
> > > > >
> >
> > > > > We all know that in this instance, there is no malignant intent,
> and
> >
> > > > should
> >
> > > > > not require any action.
> >
> > > > >
> >
> > > > > And we have not had any case of "red and black" and "something
> needs
> > to
> >
> > > > be
> >
> > > > > said" as far as I know.
> >
> > > > >
> >
> > > > > But the 'solution' is relatively simple; ASF is a non-political
> >
> > > > > organization, and expression of political views (such as showing
> >
> > > > political
> >
> > > > > allegiance, berating political figures, commenting on political
> >
> > > activity,
> >
> > > > > and so on) is not acceptable, regardless if that is a hate
> > organization
> >
> > > > > like the Nazis or more moderate political statements that many may
> >
> > > agree
> >
> > > > > with, say recent elections in the world or outbreaks of war. We
> > should
> >
> > > > not
> >
> > > > > be involved, I think we are even obliged by Law to not be involved.
> >
> > > > >
> >
> > > > > Cheers
> >
> > > > > Niclas
> >
> > > > >
> >
> > > > >> On Wed, Feb 1, 2017 at 7:58 AM, Andrew Palumbo <
> ap@outlook.com>
> >
> > > > wrote:
> >
> > > > >>
> >
> > > > >> I am pretty new around here and don't know if this is a more
> private
> >
> > > > room
> >
> > > > >> for ASF members .. but my .02:  of it is in red and black, then
> >
> > > > something
> >
> > > > >> needs to be said.
> >
> > > > >>
> >
> > > > >>
> >
> > > > >>
> >
> > > > >> Sent from my Verizon Wireless 4G LTE smartphone
> >
> > > > >>
> >
> > > > >>
> >
> > > > >>  Original message 
> >
> > > > >> From: Ted Dunning 
> >
> > > > >> Date: 01/31/2017 3:50 PM (GMT-08:00)
> >
> > > > >> To: dev@community.apache.org
> >
> > > > >> Subject: Re: Profile photos and ASF values
> >
> > > > >>
> >
> > > > >> Yeah... I twitched when I saw that.
> >
> > > > >>
> >
> > > > >> My suspicion is that this is being used in the ancient, pre-nazi
> >
> > > sense.
> >
> > > > >>
> >
> > > > >> It is hard to believe that somebody is ignorant of the impact it
> > must
> >
> > > > have
> >
> > > > >> on some readers.
> >
> > > > >>
> >
> > > > >>
> >
> > > > >>
> >
> > > > >>> On Tue, Jan 31, 2017 at 3:47 PM, Christopher <
> ctubb...@apache.org>
> >
> > > > wrote:
> >
> > > > >>>
> >
> > > > >>> Hi all,
> >
> > > > >>>
> >
> > > > >>> It is surprising to me that a certain individual participant in
> ASF
> >
> > > > >> forums
> >
> > > > >>> seems to be using a swastika as their Google profile photo. The
> >
> > > impact
> >
> > > > of
> >
> > > > >>> this is that ASF users which use GMail to interact with the
> mailing
> >
> > > > >> lists,
> >
> > > > >>> are presented with this swastika whenever reading or interacting
> > with
> >
> > > > ASF
> >
> > > > >>> forums using GMail.
> >
> > > > >>>
> >
> > > > >>> To be clear, this symbol can have alternate meanings, and it may
> > not
> >
> > > be
> >
> > > > >>> intentionally being used as Nazi symbol. Additionally, even if
> this
> >
> > > > >>> individual holds to certain ideologies which may be antithetical
> to
> >
> > > ASF
> >
> > > > >>> community inclusive values, they may act entirely professional
> and
> > in
> >
> > > > >>> accordance with ASF code of conduct on Apache forums. So, I don't
> >
> > > want
> >
> > > > to
> >
> > > > >>> imply that the profile photo is indicative of their ASF
> >
> > > interactions...
> >
> > > > >> it
> >
> > > > >>> may be an entirely separate thing.
> >
> > > > >>>
> >
> > > > >>> My main inquiry here is to question whether or not there is a
> >
> > > concern,
> >
> > > > >>> because the use of such profile photos may actually have
> > consequences
> >
> > > > of
> >
> > > > >>> deterring potential new committers, because Apache may be
> indicted
> > by
> >
> > > > >>> association.
> >
> > > > >>>
> >
> > > > >>> Is there something we wish to do about this? Is it a non-issue? I
> >
> > > > really
> >
> > > > >>> don't know. All I know, is my gut tells me that I'm bothered
> when I
> >
> > > see
> >
> > > > >> it
> >
> > > > >>> (I use GMail). But, I don't want to overreact, or start a witch
> > hunt.
> >
> > > > I'm
> >
> > > > >>> genuinely curious if this is something we want to address at all.
> >
> > > > >>>
> >
> > > > >>> If the profile photo is used on ASF infrastructure (JIRA,
> > affiliated
> >
> > > > as a
> >
> > > > >>> member of the Apache org on GitHub, etc.), then I think we
> probably
> >
> > > do
> >
> > > > >> want
> >
> > > > >>> to address it in the Code of Conduct. However, unrelated services
> >
> > > like
> >
> > > > >>> Google profile photos... that may not be something we want to
> >
> > > address,
> >
> > > > >>> because the web mail client users use is not related to ASF
> > services
> >
> > > > >> (even
> >
> > > > >>> if it were know for user that it impacted ASF community by
> > deterring
> >
> > > > >>> potential new community members).
> >
> > > > >>>
> >
> > > > >>> In any case, I don't raise this issue to demean the individual
> > whose
> >
> > > > >>> profile photo came to my attention... this is not an attack on
> > them.
> >
> > > > >> Again,
> >
> > > > >>> this is not a witch hunt.
> >
> > > > >>> --
> >
> > > > >>> Christopher
> >
> > > > >>>
> >
> > > > >>
> >
> > > > >
> >
> > > > >
> >
> > > > >
> >
> > > > > --
> >
> > > > > Niclas Hedhman, Software Developer
> >
> > > > > http://polygene.apache.org <http://zest.apache.org> - New Energy
> for
> >
> > > > Java
> >
> > > >
> >
> > > > -
> >
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> >
> > > >
> >
> > > >
> >
> > >
> >
> >
>
-- 
Christopher

Re: Profile photos and ASF values

[Christopher]

I agree. I think it's used in the traditional Hinduism (or derivatives)
sense in the specific case that I saw. Hence, the emphasis on this not
being a witch hunt. This discussion isn't necessarily about their specific
use, but more a general question about the impact on the community, and
whether we want to discourage the use of symbols that carry such weight.

On Tue, Jan 31, 2017 at 6:50 PM Ted Dunning  wrote:

> Yeah... I twitched when I saw that.
>
> My suspicion is that this is being used in the ancient, pre-nazi sense.
>
> It is hard to believe that somebody is ignorant of the impact it must have
> on some readers.
>
>
>
> On Tue, Jan 31, 2017 at 3:47 PM, Christopher  wrote:
>
> > Hi all,
> >
> > It is surprising to me that a certain individual participant in ASF
> forums
> > seems to be using a swastika as their Google profile photo. The impact of
> > this is that ASF users which use GMail to interact with the mailing
> lists,
> > are presented with this swastika whenever reading or interacting with ASF
> > forums using GMail.
> >
> > To be clear, this symbol can have alternate meanings, and it may not be
> > intentionally being used as Nazi symbol. Additionally, even if this
> > individual holds to certain ideologies which may be antithetical to ASF
> > community inclusive values, they may act entirely professional and in
> > accordance with ASF code of conduct on Apache forums. So, I don't want to
> > imply that the profile photo is indicative of their ASF interactions...
> it
> > may be an entirely separate thing.
> >
> > My main inquiry here is to question whether or not there is a concern,
> > because the use of such profile photos may actually have consequences of
> > deterring potential new committers, because Apache may be indicted by
> > association.
> >
> > Is there something we wish to do about this? Is it a non-issue? I really
> > don't know. All I know, is my gut tells me that I'm bothered when I see
> it
> > (I use GMail). But, I don't want to overreact, or start a witch hunt. I'm
> > genuinely curious if this is something we want to address at all.
> >
> > If the profile photo is used on ASF infrastructure (JIRA, affiliated as a
> > member of the Apache org on GitHub, etc.), then I think we probably do
> want
> > to address it in the Code of Conduct. However, unrelated services like
> > Google profile photos... that may not be something we want to address,
> > because the web mail client users use is not related to ASF services
> (even
> > if it were know for user that it impacted ASF community by deterring
> > potential new community members).
> >
> > In any case, I don't raise this issue to demean the individual whose
> > profile photo came to my attention... this is not an attack on them.
> Again,
> > this is not a witch hunt.
> > --
> > Christopher
> >
>
-- 
Christopher

Profile photos and ASF values

[Christopher]

Hi all,

It is surprising to me that a certain individual participant in ASF forums
seems to be using a swastika as their Google profile photo. The impact of
this is that ASF users which use GMail to interact with the mailing lists,
are presented with this swastika whenever reading or interacting with ASF
forums using GMail.

To be clear, this symbol can have alternate meanings, and it may not be
intentionally being used as Nazi symbol. Additionally, even if this
individual holds to certain ideologies which may be antithetical to ASF
community inclusive values, they may act entirely professional and in
accordance with ASF code of conduct on Apache forums. So, I don't want to
imply that the profile photo is indicative of their ASF interactions... it
may be an entirely separate thing.

My main inquiry here is to question whether or not there is a concern,
because the use of such profile photos may actually have consequences of
deterring potential new committers, because Apache may be indicted by
association.

Is there something we wish to do about this? Is it a non-issue? I really
don't know. All I know, is my gut tells me that I'm bothered when I see it
(I use GMail). But, I don't want to overreact, or start a witch hunt. I'm
genuinely curious if this is something we want to address at all.

If the profile photo is used on ASF infrastructure (JIRA, affiliated as a
member of the Apache org on GitHub, etc.), then I think we probably do want
to address it in the Code of Conduct. However, unrelated services like
Google profile photos... that may not be something we want to address,
because the web mail client users use is not related to ASF services (even
if it were know for user that it impacted ASF community by deterring
potential new community members).

In any case, I don't raise this issue to demean the individual whose
profile photo came to my attention... this is not an attack on them. Again,
this is not a witch hunt.
-- 
Christopher

Re: Use of MD5 and SHA1 for download verification

[Christopher]

To be clear, those "trusted signatures" should be using strong hash
algorithms themselves. (As well as sufficiently long keys.)
I raised the issue of weak hashes in GPG signatures for Maven projects at
ASF with https://issues.apache.org/jira/browse/MPOM-118 , but non-Maven
projects which manually sign releases should probably take care to ensure
their signatures are adequate. I consider this a release-voting quality
assurance step, and encourage projects to examine the signatures attached
to their release candidates as part of their release process.

On Thu, Jan 26, 2017 at 2:27 PM Ted Dunning  wrote:

> SHA1 and MD5 have been individually compromised, but a combined hash has
> not been.
>
> Regardless, Sebb's comment that hashes are worthless for authentication and
> tamper-detection is spot-on. You have to look to trusted signatures for
> that.
>
>
>
> On Thu, Jan 26, 2017 at 10:20 AM, Mike Lissner <
> mliss...@michaeljaylissner.com> wrote:
>
> > I filed a bug about this already, but I've been directed to email here
> > instead. The bug I filed is:
> > https://issues.apache.org/jira/browse/INFRA-12626
> >
> > Basically, on download pages we provide obsolete hashes for our downloads
> > (MD5 and SHA1). These are meant, as I understand it, to serve two
> purposes.
> > First, they allow you to make sure that your download succeeded. Second,
> > they allow you to ensure that your download wasn't tampered with.
> >
> > For the first purpose: Great. They work. For the second purpose, however,
> > we need to move away from MD5 and SHA1 hashes, both of which can now be
> > attacked with relatively modest hardware.
> >
> > Browsers are moving away from SHA1 at a very fast pace. See:
> >
> > https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html
> >
> > And:
> >
> > https://blog.mozilla.org/security/2014/09/23/phasing-
> > out-certificates-with-sha-1-based-signature-algorithms/
> >
> > I don't know who's responsible for this, but my bug was closed because
> it's
> > not the infrastructure team, and so I'm trying here.
> >
> > I suggest we move to SHA2 hashes for all verification purposes.
> >
> > Thanks,
> >
> > Mike
> >
>
-- 
Christopher

Re: Web page describing ASF-wide mailing lists?

[Christopher]

You can see a full list at https://lists.apache.org/list.html?apache.org
Click "Other Lists" to see a dropdown of those which don't fit in the top
bar.

On Tue, Jan 24, 2017 at 5:44 PM sebb  wrote:

> What has happened to the page describing the various ASF-wide mailing
> lists?
>
> For example: committers, announce, press, etc?
>
> I thought there used to be such a list but I cannot find it now.
>
> Anyone know where it is now?
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
> --
Christopher

Re: [QUESTION] Is Maven Central part of the ASF infrastructure?

[Christopher]

I think my question was lost in the details. It makes sense that Maven
defaults to using repo.maven.apache.org for the reasons stated.

However, I was wondering why
  repo.maven.apache.org points to repo.apache.maven.org / 151.101.32.215
(currently non-canonical*)
instead of
  repo.maven.apache.org pointing to repo1.maven.org / 151.101.32.209,
(currently canonical*)

Looking at DNS alone, these are separate destinations. However, for all I
know, Sonatype considers them equivalent internally and load-balances
between them. The inconsistency with the resolution of the default and the
resolution of what is documented is still confusing, though, to anybody
looking at the DNS entries.

* canonical according to Sonatype; in practice, whatever
repo.maven.apache.org points to could be considered canonical "central"
repo.

On Tue, Dec 6, 2016 at 2:22 PM Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> One of the reasons why we have maven point to repo.maven.apache.org is
> such
> that if "the worst" happened, and sonatype was no longer providing the
> service *and* there were delays transferring the maven.org domains then
> the
> Maven PMC would be able to re-point the domain under our control
> immediately to one of the other non-sonatype replicas and allow continuity
> of service for users.
>
> We do not envision this being required, but we have plans in place just in
> case
>
> HTH
>
> On Fri 2 Dec 2016 at 16:35, Mark Struberg 
> wrote:
>
> > No that's perfectly fine as is.
> >
> > Apache Maven uses the maven.apache.org domain. It *currently* points to
> > maven.org, which is co-operated by Sonatype and the Apache Maven PMC.
> > Sonatype hosts the maven.org domain and pays the servers and all the
> > bandwith (which would cost the ASF quite a lot). Otoh Sonatype gained a
> lot
> > of impact and data and thus I'm pretty sure it indirectly pays off for
> > them. There is a MOU on file between the ASF and Sonatype. It took us
> quite
> > a bit of discussions to reach this agreement and it proved to be a good
> > compromise as far as I can tell.
> >
> > LieGrue,
> > strub
> >
> > > Am 02.12.2016 um 10:41 schrieb Christopher :
> > >
> > > I wonder if ASF should update its CNAMEs to point to repo1.maven.org
> > > instead of repo.apache.maven.org, since Sonatype lists repo1.maven.org
> > as
> > > Central's canonical location.
> > >
> > > On Fri, Dec 2, 2016 at 4:17 AM Mark Struberg  >
> > > wrote:
> > >
> > >> This is the domain Apache Maven uses as default repository.
> > >> It is a CNAME dns entry currently pointing to maven.org.
> > >>
> > >> LieGrue,
> > >> Strub
> > >>
> > >>> Am 02.12.2016 um 09:39 schrieb Jacques Le Roux <
> > >> jacques.le.r...@les7arts.com>:
> > >>>
> > >>> Thanks Roman, Manfred,
> > >>>
> > >>> It's clear now. Just a last question, what is exactly
> > >> http://repo.maven.apache.org/maven2/ <
> > http://repo.maven.apache.org/maven2/>
> > >> ?
> > >>>
> > >>> Jacques
> > >>>
> > >>>
> > >>>> Le 01/12/2016 à 23:24, Manfred Moser a écrit :
> > >>>> Correct. There are a number of other large repositories that also
> feed
> > >> into the Central Repo and the ASF has some control over all of it from
> > all
> > >> I know.
> > >>>>
> > >>>> Manfred
> > >>>>
> > >>>> Roman Shaposhnik wrote on 2016-12-01 14:23:
> > >>>>
> > >>>>> On Thu, Dec 1, 2016 at 1:53 PM, Jacques Le Roux
> > >>>>>  wrote:
> > >>>>>> I'm new to the Maven world (through Gradle), and I wonder: is
> Maven
> > >> Central
> > >>>>>> part of the ASF infrastructure?
> > >>>>> No. But it does mirror all of the artifacts released by ASF. The
> > >>>>> official ASF Maven repository is at:
> > >>>>>  http://repository.apache.org
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Roman.
> > >>>>>
> > >>>>>
> -
> > >>>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > >>>>> For additional commands, e-mail: dev-h...@community.apache.org
> > >>>>>
> > >>>>
> > >>>>
> -
> > >>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > >>>> For additional commands, e-mail: dev-h...@community.apache.org
> > >>>>
> > >>>>
> > >>>
> > >>
> > >>
> > >> -
> > >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > >> For additional commands, e-mail: dev-h...@community.apache.org
> > >>
> > >>
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> > --
> Sent from my phone
>

Re: [QUESTION] Is Maven Central part of the ASF infrastructure?

[Christopher]

I wonder if ASF should update its CNAMEs to point to repo1.maven.org
instead of repo.apache.maven.org, since Sonatype lists repo1.maven.org as
Central's canonical location.

On Fri, Dec 2, 2016 at 4:17 AM Mark Struberg 
wrote:

> This is the domain Apache Maven uses as default repository.
> It is a CNAME dns entry currently pointing to maven.org.
>
> LieGrue,
> Strub
>
> > Am 02.12.2016 um 09:39 schrieb Jacques Le Roux <
> jacques.le.r...@les7arts.com>:
> >
> > Thanks Roman, Manfred,
> >
> > It's clear now. Just a last question, what is exactly
> http://repo.maven.apache.org/maven2/ 
> ?
> >
> > Jacques
> >
> >
> >> Le 01/12/2016 à 23:24, Manfred Moser a écrit :
> >> Correct. There are a number of other large repositories that also feed
> into the Central Repo and the ASF has some control over all of it from all
> I know.
> >>
> >> Manfred
> >>
> >> Roman Shaposhnik wrote on 2016-12-01 14:23:
> >>
> >>> On Thu, Dec 1, 2016 at 1:53 PM, Jacques Le Roux
> >>>  wrote:
>  I'm new to the Maven world (through Gradle), and I wonder: is Maven
> Central
>  part of the ASF infrastructure?
> >>> No. But it does mirror all of the artifacts released by ASF. The
> >>> official ASF Maven repository is at:
> >>>   http://repository.apache.org
> >>>
> >>> Thanks,
> >>> Roman.
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >>> For additional commands, e-mail: dev-h...@community.apache.org
> >>>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: [QUESTION] Is Maven Central part of the ASF infrastructure?

[Christopher]

The ASF-owned domains: {repo,repo1,repo2}.maven.apache.org
are all CNAMEs (aliases) for the Sonatype-owned domain:
repo.apache.maven.org, which is a CNAME for maven.map.fastly.net,
which is (apparently) Sonatype's CDN service provider.

The Sonatype-owned domains: {repo1,repo2}.maven.org
are CNAMEs for Sonatype's central.maven.org, which is a CNAME for
sonatype.map.fastly.net, which is (again) their CDN service provider.

These two groups resolve to two different IP addresses. At a glance, both
appear to serve the same content, but Sonatype defines the canonical
location for Maven Central to be at repo1.maven.org, which is in the second
group (specifically https://repo1.maven.org/maven2). See
http://central.sonatype.org/pages/consumers.html

repository.apache.org and oss.sonatype.org run instances of Sonatype's
Nexus Repository Manager, which (possibly among others) feed into Maven
Central (I believe, but am not certain, that Sonatype provides the ASF with
a free license for its enterprise version of Nexus)

repository.apache.org is part of ASF infrastructure, and available for ASF
projects to stage and release artifacts.
oss.sonatype.org is made available to the larger open source community by
Sonatype (see http://central.sonatype.org/pages/ossrh-guide.html) so other
open source projects have an easy way to publish their artifacts to Maven
Central.

Maven Central is searchable at https://search.maven.org (domain owned by
Sonatype).


On Fri, Dec 2, 2016 at 3:39 AM Jacques Le Roux 
wrote:

> Thanks Roman, Manfred,
>
> It's clear now. Just a last question, what is exactly
> http://repo.maven.apache.org/maven2/ 
> ?
>
> Jacques
>
>
> Le 01/12/2016 à 23:24, Manfred Moser a écrit :
> > Correct. There are a number of other large repositories that also feed
> into the Central Repo and the ASF has some control over all of it from all
> I know.
> >
> > Manfred
> >
> > Roman Shaposhnik wrote on 2016-12-01 14:23:
> >
> >> On Thu, Dec 1, 2016 at 1:53 PM, Jacques Le Roux
> >>  wrote:
> >>> I'm new to the Maven world (through Gradle), and I wonder: is Maven
> Central
> >>> part of the ASF infrastructure?
> >> No. But it does mirror all of the artifacts released by ASF. The
> >> official ASF Maven repository is at:
> >>http://repository.apache.org
> >>
> >> Thanks,
> >> Roman.
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> >> For additional commands, e-mail: dev-h...@community.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
>

Re: reporter.apache.org off-by-one

[Christopher]

Confirmed fixed on my end (after clearing browser cache). Thanks!

On Thu, Sep 8, 2016 at 5:02 PM sebb  wrote:

> On 8 September 2016 at 21:54, sebb  wrote:
> > On 8 September 2016 at 17:18, sebb  wrote:
> >> On 8 September 2016 at 01:59, Christopher  wrote:
> >>> On Wed, Sep 7, 2016 at 8:51 PM Lefty Leverenz  >
> >>> wrote:
> >>>
> >>>> Is this a timezone problem?
> >
> > Yes.
> >
> >>>>
> >>>>
> >>> Possibly. I tried changing my JIRA timezone to UTC+0, just in case,
> but it
> >>> had no effect. I don't think JIRA stores the timezone with these
> dates, so
> >>> it might be assumed to be midnight when reporter translates it to
> whatever
> >>> it considers local time. If the local time reporter is translating it
> to is
> >>> east of UTC+0, then that would make sense. It should probably parse the
> >>> JIRA dates as UTC+0, and then display them as UTC+0, since there's no
> way
> >>> for it to know the intended time zone from JIRA if JIRA isn't storing
> that
> >>> (even if it does store it, the UI doesn't allow you to specify, so it's
> >>> going to default to midnight).
> >>>
> >>
> >> JIRA stores the dates as -MM-DD; no time at all. Or at least that
> >> is the data that reporter.a.o sees.
> >>
> >> This is converted to seconds since the epoch, and assumes local time.
> >> I think the TZ is UTC on reporter.a.o.
> >>
> >> The epoch time must be converted back again for display.
> >> I suspect this is where the issue lies (given that r.a.o uses UTC)
> >>
> >> I see the following Accumulo dates:
> >>
> >> - 1.8.0: Tue Sep 06 2016
> >> - 1.7.2: Wed Jun 22 2016
> >> - 1.7.1: Fri Feb 26 2016
> >>
> >> which agree (for me) with the JIRA dates.
> >
> > However if I change my local timezone to EDT I see dates one day earlier.
> >
> >> I assume you are seeing one day earlier for each of those?
> >> What is your local timezone?
> >>
> >> In which case it's just a case of finding where the epoch time is
> >> converted for display and ensuring that UTC is used.
> >>
> >
> > The dates are displayed using Javascript Date.toDateString() which
> > uses the local timezone.
> > I can fix that.
>
> Should be OK now.
>
> >>>
> >>>> -- Lefty
> >>>>
> >>>> On Wed, Sep 7, 2016 at 8:48 PM, Christopher 
> wrote:
> >>>>
> >>>> > On Wed, Sep 7, 2016 at 7:19 PM sebb  wrote:
> >>>> >
> >>>> > > On 6 September 2016 at 23:38, Christopher 
> wrote:
> >>>> > > > Why does reporter use 1 day earlier than JIRA when I use the
> "Fetch
> >>>> > > > releases from JIRA" feature?
> >>>> > >
> >>>> > > What exactly do you mean by that?
> >>>> > >
> >>>> >
> >>>> > What I mean is that when I put the release date in JIRA as
> 06/Sep/2016,
> >>>> and
> >>>> > then use the sync feature in reporter.apache.org, the one in
> reporter
> >>>> > shows
> >>>> > Mon Sep 05 2016, which is one day earlier than what is stored in
> JIRA. It
> >>>> > does this for all the releases.
> >>>> >
> >>>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: reporter.apache.org off-by-one

[Christopher]

On Thu, Sep 8, 2016 at 4:54 PM sebb  wrote:

> On 8 September 2016 at 17:18, sebb  wrote:
> > On 8 September 2016 at 01:59, Christopher  wrote:
> >> On Wed, Sep 7, 2016 at 8:51 PM Lefty Leverenz 
> >> wrote:
> >>
> >>> Is this a timezone problem?
>
> Yes.
>
> >>>
> >>>
> >> Possibly. I tried changing my JIRA timezone to UTC+0, just in case, but
> it
> >> had no effect. I don't think JIRA stores the timezone with these dates,
> so
> >> it might be assumed to be midnight when reporter translates it to
> whatever
> >> it considers local time. If the local time reporter is translating it
> to is
> >> east of UTC+0, then that would make sense. It should probably parse the
> >> JIRA dates as UTC+0, and then display them as UTC+0, since there's no
> way
> >> for it to know the intended time zone from JIRA if JIRA isn't storing
> that
> >> (even if it does store it, the UI doesn't allow you to specify, so it's
> >> going to default to midnight).
> >>
> >
> > JIRA stores the dates as -MM-DD; no time at all. Or at least that
> > is the data that reporter.a.o sees.
> >
> > This is converted to seconds since the epoch, and assumes local time.
> > I think the TZ is UTC on reporter.a.o.
> >
> > The epoch time must be converted back again for display.
> > I suspect this is where the issue lies (given that r.a.o uses UTC)
> >
> > I see the following Accumulo dates:
> >
> > - 1.8.0: Tue Sep 06 2016
> > - 1.7.2: Wed Jun 22 2016
> > - 1.7.1: Fri Feb 26 2016
> >
> > which agree (for me) with the JIRA dates.
>
> However if I change my local timezone to EDT I see dates one day earlier.
>
> > I assume you are seeing one day earlier for each of those?
> > What is your local timezone?
> >
> > In which case it's just a case of finding where the epoch time is
> > converted for display and ensuring that UTC is used.
> >
>
> The dates are displayed using Javascript Date.toDateString() which
> uses the local timezone.
> I can fix that.
>
>
Awesome. That makes sense, because neither JIRA nor reporter handle time
input in the UI, so it makes sense to just display the date without the
timezone conversion in the browser. Thanks!

Re: reporter.apache.org off-by-one

[Christopher]

On Wed, Sep 7, 2016 at 8:51 PM Lefty Leverenz 
wrote:

> Is this a timezone problem?
>
>
Possibly. I tried changing my JIRA timezone to UTC+0, just in case, but it
had no effect. I don't think JIRA stores the timezone with these dates, so
it might be assumed to be midnight when reporter translates it to whatever
it considers local time. If the local time reporter is translating it to is
east of UTC+0, then that would make sense. It should probably parse the
JIRA dates as UTC+0, and then display them as UTC+0, since there's no way
for it to know the intended time zone from JIRA if JIRA isn't storing that
(even if it does store it, the UI doesn't allow you to specify, so it's
going to default to midnight).



> -- Lefty
>
> On Wed, Sep 7, 2016 at 8:48 PM, Christopher  wrote:
>
> > On Wed, Sep 7, 2016 at 7:19 PM sebb  wrote:
> >
> > > On 6 September 2016 at 23:38, Christopher  wrote:
> > > > Why does reporter use 1 day earlier than JIRA when I use the "Fetch
> > > > releases from JIRA" feature?
> > >
> > > What exactly do you mean by that?
> > >
> >
> > What I mean is that when I put the release date in JIRA as 06/Sep/2016,
> and
> > then use the sync feature in reporter.apache.org, the one in reporter
> > shows
> > Mon Sep 05 2016, which is one day earlier than what is stored in JIRA. It
> > does this for all the releases.
> >
>

Re: reporter.apache.org off-by-one

[Christopher]

On Wed, Sep 7, 2016 at 7:21 PM sebb  wrote:

> On 7 September 2016 at 22:44, Christopher  wrote:
> > Also noticed that it says "It's not possible to amend release details",
> but
> > that's not true. If you give a different day for the same version, it
> > overwrites.
>
> I think amend is being used in the sense of edit.
> Editing a file is not the same as overwriting it.
>
>
This could be an example of poor wording. From the user perspective, the
entry is clearly amended. Further, it explicitly says that one should
"delete the incorrect entry (as above) and add the correct one", and that
is clearly not the case, so I'm guessing the behavior was improved at some
point, but this instruction was not updated to reflect the new behavior.

Re: reporter.apache.org off-by-one

[Christopher]

On Wed, Sep 7, 2016 at 7:19 PM sebb  wrote:

> On 6 September 2016 at 23:38, Christopher  wrote:
> > Why does reporter use 1 day earlier than JIRA when I use the "Fetch
> > releases from JIRA" feature?
>
> What exactly do you mean by that?
>

What I mean is that when I put the release date in JIRA as 06/Sep/2016, and
then use the sync feature in reporter.apache.org, the one in reporter shows
Mon Sep 05 2016, which is one day earlier than what is stored in JIRA. It
does this for all the releases.

Re: reporter.apache.org off-by-one

[Christopher]

Also noticed that it says "It's not possible to amend release details", but
that's not true. If you give a different day for the same version, it
overwrites.

On Tue, Sep 6, 2016 at 6:38 PM Christopher  wrote:

> Why does reporter use 1 day earlier than JIRA when I use the "Fetch
> releases from JIRA" feature?
>
>

reporter.apache.org off-by-one

[Christopher]

Why does reporter use 1 day earlier than JIRA when I use the "Fetch
releases from JIRA" feature?

Help with task: Make our event calendar less US centric

[Christopher Allgood]

I would like to help out with the task listed at
https://helpwanted.apache.org/task.html?3c264f0f

Re: No Unicode Feather?

[Christopher]

Ha. Okay, then. I guess I was just surprised there wasn't a feather of some
sort in the set already. I can understand if the ASF wouldn't want to
petition for it, of course.

On Tue, May 24, 2016 at 7:54 PM Benson Margulies 
wrote:

> Please, no. Emoji are a giant embarrassment to the UTC. Does the ASF
> really want to lump itself in with the people demanding characters for
> 'poop'?
>
> But if you insist, I can send you the process.
>
>
> On Tue, May 24, 2016 at 7:52 PM, Christopher  wrote:
> > This is a somewhat serious question (but only somewhat).
> >
> > Does anybody know what the process would be like to petition for a
> feather
> > (ASF or otherwise) emoji in unicode? Has anybody tried doing this?
>

No Unicode Feather?

[Christopher]

This is a somewhat serious question (but only somewhat).

Does anybody know what the process would be like to petition for a feather
(ASF or otherwise) emoji in unicode? Has anybody tried doing this?

Re: SHA512 by default for GPG sigs

[Christopher]

On Thu, May 19, 2016 at 2:43 AM Stian Soiland-Reyes 
wrote:

> In principle +1, a PGP signature based on sha1 is not cryptographically
> strong.
>
> Obviously blindly checking a PGP signature, even after importing the KEYS
> from https://www.apache.org/dist, that is also not any proof you got the
> intended release, just an artifact by someone who previously signed some
> ASF release. (If you are paranoid and/or work my for a three-letter
> government institution, then you probably want more proof of exactly which
> version you are downloading)
>
>
Agreed. That's why folks also are encouraged to grow their web of trust.
Frankly, though, I'm generally content with any valid signature from a key
in a PMC's managed KEYS file, at least for the purposes of verifying
releases. That's because I have a reasonable confidence in the Apache
infrastructure to secure the published KEYS files, and that the release
managers are using their keys to act in the interest of their respective
PMCs (or at least, not using them to act against it by falsifying
unofficial releases).

A GPG signature doesn't attest that "content X came from entity E". It
attests that "the content whose hash is X came from entity E". So, that
attestation is only as strong as the hash algorithm. Weaker algorithms are
subject to "pre-image" attacks (maybe still a long way off for SHA-1, but
we still should avoid it).


> I think the convenience of the old standard .sha1 and .md5 files is that
> they can also be included in this VOTE emails, forming a distributed
> evidence in list archives of which release was approved. (although I see
> many projects now being made more lax about this and just refer to a
> transient Maven step repo). In addition to being easy to check, they are
> also easy to inline say in a Dockerfile, so I would not get rid of those
> even if the .asc is improved.
>
>
Agreed. I also wouldn't get rid of those. They have their own utility. This
is just about making the *.asc detached signature files stronger.


> Are there any compatibility issues for downstream users with your proposed
> default change? What about for Maven deployment? I assume a newer gpg is
> needed; what would be the new version requirement, and how does this match
> what is available in typical distros and OS installs?
> On 18 May 2016 7:55 p.m., "Christopher"  wrote:
>
>
It's possible, but I think very unlikely that this would cause any problems
for anybody. GnuPG added support for SHA512 in early 2003, and all the tags
in GnuPG's git repo seem to support it. Old versions of OpenPGP didn't
support it, but that's a dead project (AFAICT), and in any case, this is
the maven-gpg-plugin, not the maven-openpgp-plugin. All tags in the gnupg
git repo seem to support SHA512. Anything installed today should support
it. If there are concerning compatibility issues, then those issues would
already be a problem for the documented ASF advice at
https://www.apache.org/dev/openpgp

This doesn't affect Maven deployments at all, except to make the signatures
emitted in the release profile's activation of maven-gpg-plugin stronger.

This really should be transparent. How rare it is to get more security
without having to trade anything of value for it... but it seems to me
that's what we have in this situation.

Re: SHA512 by default for GPG sigs

[Christopher]

Yes, that is correct. I'm referring to the ASF-wide parent pom.

If I understand the situation correctly, releases of that POM are managed
by the Maven PMC, but because of it's utility throughout the ASF, Hervé
Boutemy had commented on MPOM-118 that it should be brought to the
attention of a larger audience. This thread is the result of his
observation. :)

But there is no harm done. Thanks for providing an opportunity to clarify.

On Wed, May 18, 2016 at 3:26 PM Greg Trasuk  wrote:

> Whoops.  Sorry about that.
>
> Greg
>
> > On May 18, 2016, at 2:50 PM, Benson Margulies 
> wrote:
> >
> > Greg, the proposal is for the _Default ASF POM_ to be set up so that
> > _all_ projects would use SHA-512. This is not a question for the Maven
> > PMC.
> >
> > On Wed, May 18, 2016 at 1:58 PM, Greg Trasuk 
> wrote:
> >>
> >> Hi Christopher:
> >>
> >> Thanks for your involvement.  Apache Maven is one of many projects at
> the Apache Software Foundation.  Each project has its own mailing lists.
> So your discussion should probably go to d...@maven.apache.org, which I’ve
> cc’d on this response.  If you’re not subscribed to that list, you probably
> should do that as well - check the Apache Maven web site (
> http://maven.apache.org) for more info.
> >>
> >> Thanks again,
> >>
> >> Greg Trasuk
> >>
> >>> On May 18, 2016, at 1:45 PM, Christopher  wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I'm not sure a better list to get feedback on, but I wanted to bring
> >>> attention to the proposal here:
> >>> https://issues.apache.org/jira/browse/MPOM-118
> >>>
> >>> Essentially this is a suggestion to configure the maven-gpg-plugin to
> sign
> >>> using SHA512 as its digest algorithm in the ASF Parent POM, used by
> many
> >>> Maven/Java-based projects within ASF. This configuration takes affect
> >>> during software releases when this plugin is activated (typically
> prior to
> >>> a release candidate vote, and staging a release in Nexus for
> distribution
> >>> to Maven Central).
> >>>
> >>> This would only affect the hash algorithm used to generate GPG
> signatures
> >>> for releases, and not any separate SHA/MD hashes published separately
> by
> >>> any project, which can be weaker (SHA1, MD5) for convenience, and don't
> >>> convey the strong authenticity statement that digital signatures
> provide.
> >>>
> >>> For background, gpg uses SHA1 by default, unless the signing key or gpg
> >>> configuration has a preference to use another algorithm (as described
> on
> >>> https://www.apache.org/dev/openpgp).
> >>>
> >>> This proposed configuration change wouldn't force the use of SHA512 (it
> >>> could still be overridden by a project), but it would make it the
> default,
> >>> which helps improve the security of releases in the case where release
> >>> managers have failed to keep their configuration up-to-date with the
> best
> >>> recommendations for using gpg.
> >>>
> >>> Thoughts? +1s? Discuss here or on the JIRA please.
> >>>
> >>> Thank you.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: dev-h...@maven.apache.org
> >>
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> > For additional commands, e-mail: dev-h...@maven.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

SHA512 by default for GPG sigs

[Christopher]

Hi all,

I'm not sure a better list to get feedback on, but I wanted to bring
attention to the proposal here:
https://issues.apache.org/jira/browse/MPOM-118

Essentially this is a suggestion to configure the maven-gpg-plugin to sign
using SHA512 as its digest algorithm in the ASF Parent POM, used by many
Maven/Java-based projects within ASF. This configuration takes affect
during software releases when this plugin is activated (typically prior to
a release candidate vote, and staging a release in Nexus for distribution
to Maven Central).

This would only affect the hash algorithm used to generate GPG signatures
for releases, and not any separate SHA/MD hashes published separately by
any project, which can be weaker (SHA1, MD5) for convenience, and don't
convey the strong authenticity statement that digital signatures provide.

For background, gpg uses SHA1 by default, unless the signing key or gpg
configuration has a preference to use another algorithm (as described on
https://www.apache.org/dev/openpgp).

This proposed configuration change wouldn't force the use of SHA512 (it
could still be overridden by a project), but it would make it the default,
which helps improve the security of releases in the case where release
managers have failed to keep their configuration up-to-date with the best
recommendations for using gpg.

Thoughts? +1s? Discuss here or on the JIRA please.

Thank you.

Jenkins Views cleanup?

[Christopher]

So,

I've noticed that Jenkins views are getting kinda crazy.
https://builds.apache.org/

You might not be able to see all the tabs and craziness until you log on.
(I believe Jenkins uses LDAP for authentication).

In short, we used to have tabs for:
"A-F", etc.

Then, some of those sections got too big, so it was changed to:
"A-D", etc.

This broke anybody linking to a particular view.

Now, some projects have started creating their own top-level tabs, which
get mixed in with the "A-D", "E-G", etc. (Example, "Brooklyn", "Tika",
"directory").

To future-proof links to particular views, and to clean up the current
views, I would like to propose (and am soliciting volunteers to help
accomplish this, if there's not a good automated way to configure these)
that we standardize on separate tabs for each of the 26 letters in the
English alphabet "A", "B", ..., "Z". If we have any builds/projects which
don't start with one of these characters, they can have their own group.
Any special views, like the "PreCommit Builds" and "Most Recent Builds" can
be left alone, or moved into a "Special" nested view.

I tried to get started with an "A" group and a "B" group, but it's a lot of
tedious work.

(Note, the "A" group is a "Nested View", and the specific project views
underneath this are "List View" type. Once the first "List View" is
created, the "Nested View" it is in can be configured to have a default
view, which can be set to the first project, to make the tabs work as
expected.)

I also noticed that many views use different naming conventions and
filters. I think that can really be deferred to the individual projects,
but I found this particular pattern to work well for a stable "Regular
Expression Job Filter":
(?i)(incubator-)?projectname-.*

This filter works well if projects stick to naming builds starting with
either of the following patterns:
projectname-
incubator-projectname-

The first part is for case-insensitivity. Some projects, like "Ant" might
need a more complicated filter: (?i)(incubator-)?((easy)?ant|ivy)-.*

Honestly, I don't really care about filters that much, or how projects
choose to name their builds. Mostly, I just want predictable tabs with
stable links, so I can find and link to builds reliably, without navigating
through clutter. I just found that filter and naming convention to be
useful. There is a risk that if people don't use consistent naming
conventions, that they might lose track of builds which keep running,
taking up valuable Jenkins resources when they are no longer needed, but I
think that risk is probably pretty low unless they're not generating
notifications to their community mailing lists (or being ignored when they
are).

Thoughts?

Re: Should we update /policies/anti-harassment for Apache events?

[Christopher]

Other than the outdated reference, are there specific updates you feel
should be made?

On Mon, Apr 11, 2016 at 1:39 PM Shane Curcuru  wrote:

> We have a posted anti-harassment policy focused on behavior at in-person
> events, but it's looking a bit outdated since it references ConCom [1]...
>
>   http://www.apache.org/foundation/policies/anti-harassment.html
>
> With the recent questions about our event branding policy, and the many
> Apache projects that are running their own Meetups or other smaller
> events, is it time to update this policy as well, and either require or
> suggest it's adopted by events?
>
> Note that ApacheCon and other major events are covered by
> anti-harassment policies by their producers (LinuxFoundation in many
> cases).
>
> - Shane
>
> [1] Conferences Committee, the second PMC created at the ASF in 1999
> after the HTTP Server PMC, but disbanded a few years back with the
> changes in how ApacheCon was produced.
>

Re: Please help to unsubscribe Apache Community..

[Christopher]

Unsubscribe by sending an email to dev-unsubscr...@community.apache.org from
the address you are registered.

On Sun, Mar 27, 2016 at 12:25 PM Esegba Patrick  wrote:

> Pls my names are Patrick Esegba. l am no longer interested on apache
> dev. Community . Unsubscribe me.
>  Thanks
> Pk.
>
> On 3/25/16, Jim Jagielski  wrote:
> > https://helpwanted.apache.org
> >
> > is a nice 1st step...
> >
> >> On Mar 24, 2016, at 12:30 PM, Mark Thomas  wrote:
> >>
> >> On 21/03/2016 14:05, Pravu Mishra wrote:
> >>> Hi ,
> >>>
> >>>
> >>> I am interested to join the Apache community and contribute.
> >>>
> >>>
> >>> Please let me introduce me. My name is Pravu Mishra and I have around
> 18
> >>> years of experience in IT industry and currently I am in Chennai,
> India.
> >>>
> >>>
> >>> Could you please help me in joining the Apache community.
> >>>
> >>>
> >>> Appreciate for a quick reply.
> >>
> >> Pick an Apache project that interests you, join the project's mailing
> >> lists, learn about the project and then start contributing (helping
> >> users, writing docs, improving the web site, writing test cases for bug
> >> reports, writing patches, etc.).
> >>
> >> Mark
> >
> >
>

Re: GSOC 2016:COMDEV 192

[Christopher]

It will stop if you unsubscribe by sending an email to
dev-unsubscr...@community.apache.org

On Tue, Mar 15, 2016, 20:27 Henry Martinez  wrote:

> Please stop emailing mee.
>
> On Tuesday, March 15, 2016, Thamali Wijewardhana <
> thamaliw...@cse.mrt.ac.lk>
> wrote:
>
> > Hi,
> > I am an undergraduate at Department of Computer Science and engineering,
> > University of Moratuwa, Sri lanka.I am interested with working with
> apache.
> > I have worked a lot with apache spark ml library during my internship. I
> > like to work with apache HTrace. I am interested in this project and I
> > would like to work with this project in GSOC 2016. Please kindly give me
> > further information on how I could proceed.
> >
> > Thanks
> >
>

Re: HyperKitty?

[Christopher]

I initially sent this suggestion to both infrastructure and comdev.
humbedooh responded on the infra list with some insights (basically, it has
some shortcomings which make it unsuitable for ASF), and he gave me the
link to the https://pony-poc.apache.org site, which I thought was great and
essentially equivalent to the HyperKitty suggestion, but which I hadn't
known about before.

On Sat, Mar 12, 2016 at 8:35 AM Andy Wenk  wrote:

> Andy, this is awesome. Thanks for the pointer. I can remember that someone
> mentioned it, but I always used MarkMail - and to be honest - it still
> works well ;-)
>
> Cheers
>
> Andy
> --
> Andy Wenk
> Hamburg - Germany
> RockIt!
>
> GPG public key:
> https://pgp.mit.edu/pks/lookup?op=get&search=0x4F1D0C59BC90917D
>
>
>
>
> > On 12 Mar 2016, at 14:31, Andy Seaborne  wrote:
> >
> > On 11/03/16 22:17, Christopher wrote:
> >> I'm not sure if it would work with our mailing lists, but if it does,
> it'd
> >> be really nice to run HyperKitty. It's a great front-end for mailman
> lists,
> >> allows linking directly to threads, searching, managing subscriptions,
> >> navigating by dates and threads, finding people across lists, and even
> >> participating from the website (with authentication).
> >>
> >> Fedora runs it in their infrastructure and I've really grown to love it
> >> there (here's an example thread:
> >>
> https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ANCVPVCKSZBUPXH24DLH6ZK5KUPKCC37/
> >> ).
> >>
> >> It shames mail-archives.apache.org's mod_mbox, which is really showing
> its
> >> age lately.
> >>
> >> It's GPL3 (I know, I know, dislike and all the hate, but shouldn't be a
> >> problem to just run it in our infrastructure, right? I'm sure our
> >> infrastructure runs other GPL3 tools) and developed at
> >> https://gitlab.com/mailman/hyperkitty and might be worth considering in
> >> some future mailing list archive modernization effort.
> >>
> >> Anyway, just a thought.
> >>
> >
> > There is:
> >
> > https://pony-poc.apache.org/
> >
> >   Andy
> >
>
>

HyperKitty?

[Christopher]

I'm not sure if it would work with our mailing lists, but if it does, it'd
be really nice to run HyperKitty. It's a great front-end for mailman lists,
allows linking directly to threads, searching, managing subscriptions,
navigating by dates and threads, finding people across lists, and even
participating from the website (with authentication).

Fedora runs it in their infrastructure and I've really grown to love it
there (here's an example thread:
https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/thread/ANCVPVCKSZBUPXH24DLH6ZK5KUPKCC37/
).

It shames mail-archives.apache.org's mod_mbox, which is really showing its
age lately.

It's GPL3 (I know, I know, dislike and all the hate, but shouldn't be a
problem to just run it in our infrastructure, right? I'm sure our
infrastructure runs other GPL3 tools) and developed at
https://gitlab.com/mailman/hyperkitty and might be worth considering in
some future mailing list archive modernization effort.

Anyway, just a thought.

Re: Automated ASF GPG signing

[Christopher]

On Thu, Feb 25, 2016 at 2:10 PM Shane Curcuru  wrote:

> Christopher wrote on 2/25/16 1:47 PM:
> > I'm not sure where exactly this discussion should fit, but I know people
> > have brought up questions about ASF-wide signing of artifacts before, so
> > I'll just mention it on this list.
> >
> > Fedora infrastructure has built a project called sigul:
> > https://fedorahosted.org/sigul/
> > which they use as part of their infrastructure to automate signing of
> RPMs
> > and ISOs and such.
> >
> > ASF could set up a similar service for ASF-wide release signing.
> >
> > This particular project looks like it has a GPL2 license on it, and I'm
> not
> > sure what the policy is for Fedora infrastructure, but for Fedora
> > packagers, contributions (under their ICLA) are MIT, so it's possible
> that
> > if we wanted to use this, and provide ASF-wide release signing, the
> Fedora
> > community would be willing to re-license under MIT if that were necessary
> > for us to consider using it.
> >
> Interesting point.  The first question is: what Apache projects want to
> do something like this?  While volunteers can work on whatever new ideas
> people like working on, we don't tend to build officially supported
> services (especially security-related ones!) unless there are some
> specific PMCs that ask for it.
>
>
I think the main reason why we would want to use something like this has
been expounded before, but in short, the idea is that it makes it easier
for downstream users to trust ASF releases, rather than being required to
trust individual developers's code-signing key. This would improve user
confidence in a release.

On the other hand, using centralized keys would increase the impact of a
key compromise if such a thing were to occur. But, at least we could
mitigate and prevent key compromise a bit better than what most users are
probably doing today.


> Once there's some interest from projects, it's a question of figuring
> out a draft plan and seeing if the security and maintenance are
> something the ASF and our small but awesome infrastructure team would be
> willing to host.
>
> Also, have you read through the Apache release policy and signing
> details to see exactly how this would fit?
>
>   http://www.apache.org/dev/release.html
>   http://www.apache.org/dev/release-signing.html
>
>
I think the idea would be that if we were to do something like this, it
would run as an authenticated service, and return a signature for files
uploaded to it upon request. It would replace the need for individuals to
generate and use their own GPG keys.

The tricky part would be to establish policy and enforcement of its use for
ASF-releases only. It would probably have to be used for release candidates
also. It would obviously have to be locked down to release managers, but
who are the authorized release managers (PMC, committers, other?), and how
does one tell what is an authorized release artifact? Trust of the system
might have to rely on audit logs and policy, rather than strict
enforcement, which isn't idea.

A related service could possibly be set up, so instead of pushing directly
to the mirrors, uploading to dist would trigger signing? We'd also probably
need to address uploading to the Maven Central staging repositories. For
Maven projects, a maven plugin could easily be written which uses this
service and replaces the maven-gpg-plugin. It could also be done on deploy,
en route to the staging repositories.

An alternative implementation would be that this service would escrow keys
not just for ASF-wide, but also for per-project(PMC), so there could be a
single trusted key per project.

The ASF does have a central code signing service for Windows binaries
> and JARs supported by Symantec, although it's not widely used yet:
>
>   https://reference.apache.org/pmc/codesigning
>
>
This would wouldn't replace those, but it would provide a similar
centralized trust mechanism for GPG signatures which would be suitable to
replace the existing release-signing practices. It'd probably be cheaper to
provide than the Symantec service, and would perhaps limit the number of
users who have an interest (but not an essential requirement) for that
service.

Automated ASF GPG signing

[Christopher]

I'm not sure where exactly this discussion should fit, but I know people
have brought up questions about ASF-wide signing of artifacts before, so
I'll just mention it on this list.

Fedora infrastructure has built a project called sigul:
https://fedorahosted.org/sigul/
which they use as part of their infrastructure to automate signing of RPMs
and ISOs and such.

ASF could set up a similar service for ASF-wide release signing.

This particular project looks like it has a GPL2 license on it, and I'm not
sure what the policy is for Fedora infrastructure, but for Fedora
packagers, contributions (under their ICLA) are MIT, so it's possible that
if we wanted to use this, and provide ASF-wide release signing, the Fedora
community would be willing to re-license under MIT if that were necessary
for us to consider using it.

Re: Making license adjustment tools publicly available

[Christopher]

It might be relevant that that both of those tools appear to be licensed
under ASL 2.0, which explicitly permits redistribution (presumably outside
the private area?). I would think it confusing to have an open source
license on software which is expected to remain private, or otherwise
restricted from redistribution. As such, it seems prudent to move them to a
more appropriate area. That's my opinion, anyway.

On Thu, Feb 4, 2016 at 7:14 PM Roman Shaposhnik  wrote:

> Hi!
>
> a podling recently asked me why:
> https://svn.apache.org/repos/private/committers/relicense/
> https://svn.apache.org/repos/private/committers/tools/copy2license.pl
> are only available to commiters. I see
> no reason why, but of course I'm appreciative
> of the warning here:
> https://svn.apache.org/repos/private/committers/README
>
> Two questions:
>1. Is there any disagreement that making this tool publically
> available would be a 'good thing' ?
> 2. Who should bless the svn mv if we all agree?
>
> Thanks,
> Roman.
>

Re: What is the legal basis for enforcing release policies at ASF?

[Christopher]

On Fri, Aug 21, 2015 at 9:58 AM, Bertrand Delacretaz
 wrote:
> On Fri, Aug 21, 2015 at 3:54 PM, Shawn Heisey  wrote:
>> ...Their changes do mean that when people come to the solr-user mailing
>> list looking for help, we sometimes have to refer them to the downstream
>> maintainers, because we can't make any sense of where things are
>
> To me this is clearly a case that requires those maintainers to change the 
> name.
>
> Based on your description their code is clearly a fork of Apache Solr,
> and we shouldn't allow people to keep our names for such external
> forks.
>
> -Bertrand

Are you sure? I would think it's quite common for file locations to
change by a downstream packager, to support the downstream packaging
requirements/conventions. Accumulo has this issue sometimes with
Cloudera and/or Hadoop packaging of Accumulo. We get questions about
errors which don't exist anywhere in Accumulo's source code, or about
classpath problems which apply to the users environment, but not the
vanilla upstream packages we provide from the official source release.

At what point are we growing our community and promoting our
respective projects/brands by encouraging sharing and integration, and
at what point does a downstream packager's action cause us to consider
it a "fork" with the requirement to change the name? If we took a hard
line on this, things would get really crazy... almost no package in a
downstream distro, like Fedora or Ubuntu, would match its upstream
origins (because they are all forked to some extent to make it work in
that environment). And, that would be detrimental. On the other hand,
if we're too soft on this, then substantial forks begin to reflect
badly on the upstream project.

In the case of Solr, it might be the case that it's a substantial
external fork, in need of rebranding. But, if it's just file locations
being moved around to match a distro filesystem layout requirements,
or to do typical distro dependency convergence, backport patches, and
the like, that seems pretty much norm, and it might be a bit too
aggressive to require them to rebrand.

Re: What is the legal basis for enforcing release policies at ASF?

[Christopher]

It sounds to me like you're saying that the license under which code is
offered (to anybody who encounters it) is independent of the license
declaration attached to the project.

This makes sense to me, presuming that we still agree that the license
declaration (header or license file) is the best way to communicate the
license under which the code is offered.

It seems to follow, then, that were saying that there are sometimes errors
in the declaration, where it doesn't reflect what license the code is
actually offered under (if any). Further, we're saying that this is
hopefully less likely in a release, which has been vetted with greater
scrutiny.

Is that right?

If so, then it seems to me that the question really becomes: is it
sufficiently communicated by the very fact of being a snapshot (any state
of the code other than in a release), that errors are possible in the
license? I would think the answer is yes, personally. However, I'm not sure
it really means much, because it's still reasonable for people to assume
the license declaration is correct, until shown otherwise.

It seems to me that the very fact that any license declaration is attached
to the code at all, regardless of its state as a release or snapshot,
shifts the burden of responsibility to actually demonstrate that the
license does not apply. This is the reverse of the case when no obvious
license declaration is made. The burden in that case is to show that the
license does apply. Isn't that why we explicitly put headers on each file,
in addition to the LICENSE file? To explicitly shift this burden to us in
order to encourage free use of our software by others?

On Thu, Aug 20, 2015, 21:19 William A Rowe Jr  wrote:

> On Aug 20, 2015 7:39 PM, "Alex Harui"  wrote:
> >
> >
> >
> > On 8/20/15, 5:27 PM, "William A Rowe Jr"  wrote:
> >
> > >It is generally AL code all the time.  I don't know where you invented a
> > >'kick-in' concept, but unless the committers are violating their
> > >ICLA/CCLA,
> > >nothing could be further from the truth.
> >
> > Committers sometimes make mistakes.  IIRC, Justin recently caught a
> > mistake where some files accidentally got their non-AL headers replaced
> > with AL headers.
> >
> > Large codebase contributions, especially initial podling code grants
> might
> > be messy as well until scrubbed and approved for an official ASF release.
> > I know from experience.
>
> We don't disagree on this point.  Sometimes, they are caught through the
> release process, or by peer review.  Other times, we must retract the claim
> we offered.
>
> Nothing changes the fact that code is either offered under the AL 2.0 or
> another license, unless the author/licensor changes their license
> retroactively.
>

Re: What is the legal basis for enforcing release policies at ASF?

[Christopher]

On Thu, Aug 20, 2015 at 10:23 AM, Benson Margulies
 wrote:
> On Thu, Aug 20, 2015 at 9:52 AM, Jim Jagielski  wrote:
>> Coming in late.
>>
>> A snapshot is not a release. Licenses "kick in" at distribution/
>> release.
>
> Are you sure? When you have a public source control repo, with a
> LICENSE file at the top, I would think that this counts as a legal
> 'publication' under the terms of the license.
>
> if not, just what is the legal status of source code snipped from our
> repositories?
>

I was thinking a similar thing. If a user encounters software, in any
state (released, or whatever), in a repo with a LICENSE attached, it
seems to me that they have every reasonable expectation that they are
in their right to take actions granted by that license (modification,
redistribution).

Re: GitHub Pages

[Christopher]

+1

On Mon, Aug 3, 2015 at 10:12 PM, jay vyas  wrote:
> agreed niclas that tools are secondary;   but deploying websites is just a
> hassle that steals cycles from that heroic group of folks who would rather
> be spending their time writing awesome docs  :)
>
> On Mon, Aug 3, 2015 at 9:30 PM, Niclas Hedhman  wrote:
>
>> We (developers) always discuss tools for making documentation easier. But
>> we (developers) will always cite another hurdle (with tools) for not
>> contributing more to documentation. In a lot of cases, it doesn't matter
>> how easy the tools become, it is still the same heroic lot of people whoc
>> write the docs. Doesn't matter if that is HTML, xdoc. Anakia, docbook,
>> Maven text, Asciidoc, CMSes, Wiki, Jekyll or gh-pages. The unwilling will
>> always be able to raise a reason why he can't contribute...
>>
>> And as a rather active doc writer, I am happy when receiving contributions
>> in any form, such as email on mailing list, big or small, and I'll gladly
>> put that in myself. I'd probably be happy with an audio contribution as
>> well. It isn't the typing that is the hard part, it is coming up with the
>> accurate Content.
>>
>> My 2 cents to this never ending debate... ;-)
>>
>> Cheers
>> Niclas
>>
>> On Tue, Aug 4, 2015 at 12:23 AM, Christopher  wrote:
>>
>> > On Mon, Aug 3, 2015 at 11:51 AM, Owen O'Malley 
>> wrote:
>> > > On Mon, Aug 3, 2015 at 8:22 AM, Stian Soiland-Reyes 
>> > > wrote:
>> > >
>> > >> This looks good.
>> > >>
>> > >> So do I understand any of the commiters editing the site would still
>> > >> need to run Jekyll manually and push (how?), or is there a GitHub like
>> > >> autobuild?
>> > >>
>> > >
>> > > It is manual, so it isn't as easy as github pages. However, I find that
>> > > generally I want to run jekyll locally first anyways to debug my
>> changes.
>> > >
>> >
>> > FWIW, GitHub pages is pretty easy to debug (non-local): push to
>> > gh-pages in a fork, before doing a PR against the gh-pages branch. If
>> > ASF ever did provide automated rendering, this is one reason I'd want
>> > it to be gh-pages compatible (because users who don't/can't have the
>> > build tools locally, can still make helpful contributions).
>> >
>>
>>
>>
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>
> --
> jay vyas

Re: GitHub Pages

[Christopher]

On Mon, Aug 3, 2015 at 11:51 AM, Owen O'Malley  wrote:
> On Mon, Aug 3, 2015 at 8:22 AM, Stian Soiland-Reyes 
> wrote:
>
>> This looks good.
>>
>> So do I understand any of the commiters editing the site would still
>> need to run Jekyll manually and push (how?), or is there a GitHub like
>> autobuild?
>>
>
> It is manual, so it isn't as easy as github pages. However, I find that
> generally I want to run jekyll locally first anyways to debug my changes.
>

FWIW, GitHub pages is pretty easy to debug (non-local): push to
gh-pages in a fork, before doing a PR against the gh-pages branch. If
ASF ever did provide automated rendering, this is one reason I'd want
it to be gh-pages compatible (because users who don't/can't have the
build tools locally, can still make helpful contributions).

Re: Flume Error: Unable to deliver event.

[Christopher]

You probably want to ask people on the Flume mailing lists:
http://flume.apache.org/mailinglists.html

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Jul 13, 2015 at 9:23 PM, Nikhil Gs  wrote:
> Hello Apache team,
>
> I am new to hadoop flume environment and I am currently working on flume. I
> am getting an error. Below, I have posted my config file and also log error
> that I am facing. Please guide me with my bug. Thanks in advance for your
> help.
>
>
> *flume.config.file*
>
> # Please paste flume.conf here. Example:
>
> # Sources, channels, and sinks are defined per
> # agent name, in this case 'pnm'.
> pnm.sources  = SPOOL
> pnm.channels = MemChannel
> pnm.sinks= AVRO
>
> # For each source, channel, and sink, set
> # standard properties.
> pnm.sources.SPOOL.type  = spooldir
> pnm.sources.SPOOL.spoolDir  = /home/s_sdldalplhdxxxedh/pnm-poll-results
> pnm.sources.SPOOL.channels  = MemChannel MemChannel2
> pnm.sources.SPOOL.fileHeader= true
> pnm.sources.SPOOL.deletePolicy  = immediate
> pnm.sources.SPOOL.consumeOrder  = oldest
> pnm.sources.SPOOL.batchSize = 1
>
> pnm.sources.SPOOL.interceptors = time
> pnm.sources.SPOOL.interceptors.time.type =
> org.apache.flume.interceptor.TimestampInterceptor$Builder
> pnm.sources.SPOOL.deserializer  =
> com.suddenlink.flume.WholeFileDeserializer$Builder
>
> pnm.sinks.AVRO.type = avro
> pnm.sinks.AVRO.channel  = MemChannel
> pnm.sinks.AVRO.hostname = sdldalplhdw01.suddenlink.cequel3.com
> pnm.sinks.AVRO.port = 40001
> pnm.sinks.AVRO.batchSize = 1
>
> # Other properties are specific to each type of
> # source, channel, or sink. In this case, we
> # specify the capacity of the memory channel.
>
> pnm.channels.MemChannel.capacity = 100
> pnm.channels.MemChannel.type   = memory
>
>
> *Log Error*
>
> 7:30:45.575 PMERRORorg.apache.flume.SinkRunner
>
> Unable to deliver event. Exception follows.
> org.apache.flume.EventDeliveryException: Failed to send events
> at 
> org.apache.flume.sink.AbstractRpcSink.process(AbstractRpcSink.java:392)
> at 
> org.apache.flume.sink.DefaultSinkProcessor.process(DefaultSinkProcessor.java:68)
> at org.apache.flume.SinkRunner$PollingRunner.run(SinkRunner.java:147)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.apache.flume.EventDeliveryException: NettyAvroRpcClient
> { host: sdldalplhdw01.suddenlink.cequel3.com, port: 40001 }: Failed to
> send batch
> at 
> org.apache.flume.api.NettyAvroRpcClient.appendBatch(NettyAvroRpcClient.java:315)
> at 
> org.apache.flume.sink.AbstractRpcSink.process(AbstractRpcSink.java:376)
> ... 3 more
> Caused by: org.apache.flume.EventDeliveryException: NettyAvroRpcClient
> { host: sdldalplhdw01.suddenlink.cequel3.com, port: 40001 }: Handshake
> timed out after 2ms
> at 
> org.apache.flume.api.NettyAvroRpcClient.appendBatch(NettyAvroRpcClient.java:359)
> at 
> org.apache.flume.api.NettyAvroRpcClient.appendBatch(NettyAvroRpcClient.java:303)
> ... 4 more
> Caused by: java.util.concurrent.TimeoutException
> at java.util.concurrent.FutureTask.get(FutureTask.java:201)
> at 
> org.apache.flume.api.NettyAvroRpcClient.appendBatch(NettyAvroRpcClient.java:357)
> ... 5 more
>
>
>
> Regards,
> Nikhil
> Illinois, USA.

Re: Moving Apache Extras

[Christopher]

Okay, that's fine. Thanks. I'm sure I can find stuff in the archives.
I just wasn't sure what the final reasoning was. NBD.

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Jul 9, 2015 at 4:15 PM, Ross Gardler  wrote:
> That discussion has been had a number of times. We're not opening it again 
> since we are ready to pull the trigger on SF. The archives have the 
> discussion (sorry, not got the time to search them and find links right now).
>
> -Original Message-
> From: Christopher [mailto:ctubb...@apache.org]
> Sent: Thursday, July 9, 2015 12:52 PM
> To: ComDev
> Subject: Re: Moving Apache Extras
>
> It seems to me that moving to GitHub would be easier, since Google put a 
> "Export to GitHub" button on each project page, and I've used it and it works 
> well.
> Perhaps I missed it, but was there a reason why SourceForge was chosen over 
> GitHub? (Just curious... since I have no personal stake in this
> endeavor.)
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
>
> On Thu, Jul 9, 2015 at 2:42 PM, Daniel Gruno  wrote:
>> Hiya folks,
>>
>> I'm the "lucky person" in charge of moving the some 350 projects from
>> Google Code to SourceForge.
>> This will happen over the course of next week, save some freak
>> accident occurs, however, SourceForge is not Google Code, and as such,
>> there are a few things we need to consider:
>>
>> - I will create an admin account that will initially own all the
>> imported projects. This can/will be shared with the ComDev PMC.
>> - Someone (not me!!) will have to step up and help out with delegating
>> read/write access to the new repos on SourceForge.
>> - Preferably, someone will have to go through the giant list of
>> projects, and select those we'll import. This is not strictly
>> necessary, but if someone volunteers for this, that'd be super duper.
>>
>> The most important thing is that we are able to delegate write access
>> to the devs (and do so!), so this does not simply become a big data
>> dump that just sits there. If any of you are interested in taking on
>> that task (preferably more than one person), please do speak up :)
>>
>> With regards,
>> Daniel.

Re: Moving Apache Extras

[Christopher]

It seems to me that moving to GitHub would be easier, since Google put
a "Export to GitHub" button on each project page, and I've used it and
it works well.
Perhaps I missed it, but was there a reason why SourceForge was chosen
over GitHub? (Just curious... since I have no personal stake in this
endeavor.)

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Thu, Jul 9, 2015 at 2:42 PM, Daniel Gruno  wrote:
> Hiya folks,
>
> I'm the "lucky person" in charge of moving the some 350 projects from Google
> Code to SourceForge.
> This will happen over the course of next week, save some freak accident
> occurs, however, SourceForge is not Google Code, and as such, there are a
> few things we need to consider:
>
> - I will create an admin account that will initially own all the imported
> projects. This can/will be shared with the ComDev PMC.
> - Someone (not me!!) will have to step up and help out with delegating
> read/write access to the new repos on SourceForge.
> - Preferably, someone will have to go through the giant list of projects,
> and select those we'll import. This is not strictly necessary, but if
> someone volunteers for this, that'd be super duper.
>
> The most important thing is that we are able to delegate write access to the
> devs (and do so!), so this does not simply become a big data dump that just
> sits there. If any of you are interested in taking on that task (preferably
> more than one person), please do speak up :)
>
> With regards,
> Daniel.

Re: [reporter.apache.org] Using SVN to record current deployed code

[Christopher]

On Mon, Jul 6, 2015 at 2:21 PM, sebb  wrote:
> On 6 July 2015 at 19:16, Christopher  wrote:
>> I think the content on disk should reflect what's in SCM.
>
> Well yes, but that's not what I'm asking.
> I want to get agreement on the proposed layout.
>
>> However,
>> would it make sense to move to git instead of SVN instead of moving to
>> trunk subdir?
>
> One thing at a time please.

In that case, the proposed layout makes sense to me.

Re: [reporter.apache.org] Using SVN to record current deployed code

[Christopher]

I think the content on disk should reflect what's in SCM. However,
would it make sense to move to git instead of SVN instead of moving to
trunk subdir?

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii


On Mon, Jul 6, 2015 at 2:11 PM, sebb  wrote:
> The reporter.apache.org code on disk has diverged from the copy in SVN.
> There are several files that are not in SVN, and there a several
> differences from the ones that are.
>
> One approach to this might be to copy  the current sources into SVN
> into a new folder.
> Then we can look at merging the current code and redeploying.
>
> I was thinking of using an SVN tag for the deployed source, but the
> SVN directory for reporter.a.o does not use tags/trunk. I could use a
> new directory name like
>
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org-ondisk
>
> but this is not the normal way to use SVN, and might prove confusing later.
>
> So I would like to start by moving the current code under
>
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org
> to
> https://svn.apache.org/repos/asf/comdev/reporter.apache.org/trunk
> (i.e. drop it down a level)
> and then use tags/disk-2015-07-06 (or whatever) to record the current setup
>
> Note that the generated data files (*.json) don't need to be stored in SVN.
>
> Thoughts?