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: [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: [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: 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: [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

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

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

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

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

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]

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]

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: 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: 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: Code of conduct

[Christopher]

At first glance, a big +1. This is one of the better Code of Conduct
policies that I've seen.


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

On Tue, Nov 18, 2014 at 8:53 AM, Rich Bowen  wrote:

> As many of you are no doubt aware, we have had on our website, for at
> least 8 years, and, I think probably much longer, "Code of conduct, coming
> soon!" Long enough, in fact, that I had completely forgotten about it.
>
> It was brought to my attention this morning, and I decided, unilaterally,
> that it was appropriate for me to JFDI, and that I'd ask for forgiveness
> rather than permission.
>
> I have stolen, wholesale, the code of conduct of the CouchDB project [1]
> which has discussed this extensively, and borrowed heavily from other
> communities that have discussed it extensively. So this isn't original
> content, but, rather, standing on the shoulders of giants.
>
> I honestly can't figure out why we didn't just do this years ago, other
> than expecting that someone else would.
>
> So, without further ado: http://www.apache.org/
> foundation/policies/conduct.html
>
> Patches welcome.
>
> I've also asked Noah Slater, who was very instrumental in crafting that
> document, to speak up here, so that:
>
> * Patches to one document will propagate to the other, where appropriate
> * ComDev can have a boilerplate document that we can recommend that ASF
> projects that don't have such a code, can adopt
>
> Please do speak up if you have any objections to my taking this initiative
> without discussion. But we've been discussing it, on and off, for many,
> many years.
>
> [1] http://couchdb.apache.org/conduct.html
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>

Re: Volunteering in schools

[Christopher]

I might be interested in volunteering (though, I won't be in Austin).


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

On Wed, Jan 7, 2015 at 2:59 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> I know we have a bunch of people who already volunteer to teach in
> schools. I know that this has a great deal of impact at many levels. I'm
> looking for volunteers to help with a potential new initiative.
>
> In the run-up to ApacheCon Sally will be running a campaign around the
> 15th Anniversary of the foundation. It will look at the legacy of the ASF
> and to the future. It will focus on the ASF as being a place of innovation
> and excitement.
>
> I've recently had confirmation that a representative of TEALS, an
> organization that trains volunteers to teach in high schools in 20 states.
> These students take a rigorous college level CS class (UC Berkeley CS10 or
> UW CSE142/143 AP) in schools that might otherwise have no IT component at
> all.
>
> 40% of the schools are Title 1 schools (as a Brit I had to look this up,
> in short it's about improving academic achievements of the disadvantaged
> [1]) and a dozen or so are in very rural areas. Furthermore, 25% of their
> students are girls and 25% are from minority groups (in other words this
> has an impact on diversity).
>
> My ask of the ComDev PMC is for us to run a BOF at ApacheCon to figure out
> how we might enable ASF community members to assist with the work that
> TEALS (and similar) organizations do. I'm happy to help drive this, but
> ideally there will be a couple of volunteers here who are interested enough
> to take ownership.
>
> I'm working with Sally to find other valuable folks to participate and
> hope to have more than just TEALS represented. What I would like to do, in
> a perfect world, is announce a partnership at ApacheCon. Failing that I
> would like to develop the outline of a partnership at ApacheCon itself.
>
> So, please step forward if you are interested in volunteering (there's no
> need for you to be present in Austin, though that would be great).
>
> Ross
>
>
> [1] http://www2.ed.gov/policy/elsec/leg/esea02/pg1.html
>
> Microsoft Open Technologies, Inc.
> A subsidiary of Microsoft Corporation
>
>

Re: Volunteering in schools

[Christopher]

On Wed, Jan 7, 2015 at 4:59 PM, Ross Gardler (MS OPEN TECH) <
ross.gard...@microsoft.com> wrote:

> Cool, thanks Chris. Keep an eye on this list. I'll keep you informed here
> (and may ping you privately if there is something specific I think you can
> help with).
>
> In the meantime, do you have any experience already?
>
>
I've done some tutoring, but nothing like this.
(Also, friendly note: I prefer "Christopher" :) )

I'll keep an eye on the list.


> Microsoft Open Technologies, Inc.
> A subsidiary of Microsoft Corporation
>
> -Original Message-
> From: Christopher [mailto:ctubb...@apache.org]
> Sent: Wednesday, January 7, 2015 1:22 PM
> To: dev@community.apache.org
> Subject: Re: Volunteering in schools
>
> I might be interested in volunteering (though, I won't be in Austin).
>
>
> --
> Christopher L Tubbs II
> http://gravatar.com/ctubbsii
>
> On Wed, Jan 7, 2015 at 2:59 PM, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
> > I know we have a bunch of people who already volunteer to teach in
> > schools. I know that this has a great deal of impact at many levels.
> > I'm looking for volunteers to help with a potential new initiative.
> >
> > In the run-up to ApacheCon Sally will be running a campaign around the
> > 15th Anniversary of the foundation. It will look at the legacy of the
> > ASF and to the future. It will focus on the ASF as being a place of
> > innovation and excitement.
> >
> > I've recently had confirmation that a representative of TEALS, an
> > organization that trains volunteers to teach in high schools in 20
> states.
> > These students take a rigorous college level CS class (UC Berkeley
> > CS10 or UW CSE142/143 AP) in schools that might otherwise have no IT
> > component at all.
> >
> > 40% of the schools are Title 1 schools (as a Brit I had to look this
> > up, in short it's about improving academic achievements of the
> > disadvantaged
> > [1]) and a dozen or so are in very rural areas. Furthermore, 25% of
> > their students are girls and 25% are from minority groups (in other
> > words this has an impact on diversity).
> >
> > My ask of the ComDev PMC is for us to run a BOF at ApacheCon to figure
> > out how we might enable ASF community members to assist with the work
> > that TEALS (and similar) organizations do. I'm happy to help drive
> > this, but ideally there will be a couple of volunteers here who are
> > interested enough to take ownership.
> >
> > I'm working with Sally to find other valuable folks to participate and
> > hope to have more than just TEALS represented. What I would like to
> > do, in a perfect world, is announce a partnership at ApacheCon.
> > Failing that I would like to develop the outline of a partnership at
> ApacheCon itself.
> >
> > So, please step forward if you are interested in volunteering (there's
> > no need for you to be present in Austin, though that would be great).
> >
> > Ross
> >
> >
> > [1] http://www2.ed.gov/policy/elsec/leg/esea02/pg1.html
> >
> > Microsoft Open Technologies, Inc.
> > A subsidiary of Microsoft Corporation
> >
> >
>

Re: Managing zyz.apache.org (was RE: WELCOME to dev@community.apache.org)

[Christopher]

Perhaps a better mechanism for things like javadocs, would be to support
some javadoc viewer which serves javadocs directly from javadoc jars? That
way, you just upload the jars you build with maven or ant, which are
already compressed. That should work well enough with svn or the CMS
external build feature. (And would also have the added benefit of only
needing to update the viewer when there's a javadoc security vulnerability,
rather than require every project to patch their javadocs, as I seem to
remember was recently the case.)


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

On Thu, Jan 8, 2015 at 4:28 AM, Robert Metzger  wrote:

> I think there is a performance difference between git and svn because with
> git, you are syncing repositories, not files. Git is usually compressing
> the repository before sending it over the network.
> I did a little test with our website directory and pushed it to github:
>
> git add : 7 seconds (17k files)
> git repo size: 58 MB (du -sh in ".git" dir)
> git push to github : 35 seconds (using the same internet connection as with
> the svn)
>
> I think we can achieve the same performance at apache using git for the
> websites.
>
> I agree with you that I should probably take a closer look into the CMS
> external build feature. Using svn or git for 17k files is certainly wrong.
> In particular because we add generated files (javadocs, documentation) to
> the VCS which doesn't have any value.
>
> I'll get in touch with Infra on a separate thread to resolve our website
> issues.
>
>
>
> On Thu, Jan 8, 2015 at 10:01 AM, Daniel Gruno 
> wrote:
>
> >
> > On 2015-01-08 09:55, Robert Metzger wrote:
> >
> >> Hi,
> >>
> >>  If there is sufficient demand, however, that could change - the code
> that
> >>>
> >> would make this possible does exist.
> >>
> >> I would like to express demand from the Flink project. svn is a pain to
> >> use
> >> (since we host javadocs and our documentation on our website, the upload
> >> usually runs for 6+ hours. Probably because its so many files).
> >>
> > How is that in any way related to svn? svn or git, if you have that many
> > files, it's going to take ages to upload regardless of which repository
> > system you use.
> >
> > If it makes it easier, you might peruse http://www.apache.org/dev/
> > cmsref.html#external-build and see if you can't use an external build job
> > for you site - that way, you just commit the changes to your template/raw
> > docs, and the CMS system builds the javadoc for you.
> >
> >
> >
> >> Almost all incoming incubator projects are using git nowadays. Many of
> >> them
> >> use GitHub and the "gh-pages" hosting feature. I guess a lot of them
> would
> >> appreciate a similar feature from the ASF infra.
> >>
> >>
> >>
> >> On Wed, Jan 7, 2015 at 9:42 PM, Daniel Gruno 
> >> wrote:
> >>
> >>  Hi Jay,
> >>> It sounds like you have the CMS setup that is quite common in the ASF.
> >>> If you would rather have straight-up svnpubsub, you can ask for it.
> That
> >>> way, whatever static content you push to svn will instantly be shown on
> >>> your web site without having to publish through the UI first.
> >>>
> >>> The main reason we do not support git in this workflow is that git does
> >>> not enable single-file checkouts, and that we haven't properly tested
> >>> gitwcsub (a git version of svnwcsub which is the frontend for
> svnpubsub)
> >>> for web sites yet. If there is sufficient demand, however, that could
> >>> change - the code that would make this possible does exist.
> >>>
> >>> With regards,
> >>> Daniel.
> >>>
> >>>
> >>> On 2015-01-07 21:29, jay vyas wrote:
> >>>
> >>>  thanks daniel...
> >>>>
> >>>>here at bigtop we are 100% git based.  so having an svn account ,
> >>>> just
> >>>> to
> >>>> push changes to a site, seems to slow us down alot.
> >>>>
> >>>> is SVN required  ? or is there another way?
> >>>>
> >>>> right now we have a system that uses maven, followed by svn and then
> we
> >>>> have to approve the changes in the web ui.
> >>>>
> >>>> would rather just push static html pages to our git repo , the way we
> >>>> push
> >>>> everything else.
&g

Re: Managing zyz.apache.org (was RE: WELCOME to dev@community.apache.org)

[Christopher]

On Thu, Jan 8, 2015 at 11:24 AM, Roman Shaposhnik 
wrote:

> On Wed, Jan 7, 2015 at 12:42 PM, Daniel Gruno 
> wrote:
> > The main reason we do not support git in this workflow is that git does
> not
> > enable single-file checkouts, and that we haven't properly tested
> gitwcsub
> > (a git version of svnwcsub which is the frontend for svnpubsub) for web
> > sites yet. If there is sufficient demand, however, that could change -
> the
> > code that would make this possible does exist.
>
> FWIW: I see quite a bit of demand for that on the poddling side. Every
> single
> poddling I've onboarded in the last year opted out for Git and had to
> 'grok'
> why is there a bit of SVN thingy sticking out as a sore thumb in otherwise
> 100% Git workflow they've picked.
>
> Thanks,
> Roman.
>

Don't they also have to use SVN for pushing releases to the dists/mirrors?
How do those newly onboarded projects view that? Do they understand that
more, because it's less often updated than the site?

Re: Mailinglists - a tool from the 90s?

[Christopher]

On Sun, Jan 18, 2015 at 7:34 AM, Benedikt Ritter  wrote:
[snip]

> Now I'm curious: Does anybody here really like the use of mailing lists? Or
> do we all simply go through the struggle of setting up filters etc. just
> because this is the way it has always been?
>
>
I absolutely loathe mailing lists:

1. They *feel* like spam (Google often incorrectly identifies ASF mailing
list activity as spam).
2. They are difficult to parse (visually) and triage/categorize (subject
line conventions help to some degree).
3. They are often full of pages and pages of text, which could be more
easily conveyed by a more succinct means, with the best option to provide a
link to an external resource (which creates a slight burden on the
composer).
4. Long conversations often get forked, and are difficult to follow (esp.
in tools like GMail which doesn't thread conversations natively). Even when
not forked, they can be difficult to determine whom one is responding to
when replies are interspersed.
5. Outages and late-subscribers can get messages at different times, and
dealing with backlog is not so easy.
6. The archives are profoundly difficult to navigate and reference (though,
that's specific to ASF archives, not necessarily generally true).
7. Filters are useful, but have limited ability to address all the issues.
8. Client-side identity management is a pain, when you have multiple email
addresses for different purposes, and the mailing lists expose you to spam.
9. Replying is inefficient and ugly, with different community conventions
(top-posting, bottom-posting, inline-posting) on mailing lists.
10. Message sizes when replying is often inefficient. Most people quote the
entire previous message, including any previously quoted messages,
indenting and wrapping, sending and storing redundant bits which are
difficult to read anyway.
11. Validating authenticity is a problem. GPG is great, but most email
users use web-based email nowadays, and there is limited-to-zero browser
support for adding digital signatures to messages.
12. HTML is bulky, but there's limited other options for pretty-printing
messages (email clients don't often... or ever... support markdown or
asciidoc or similar markup).

That said, I don't think it's that they are used "just because this is the
way it has always been". There's plenty of important (and useful) reasons
why we use them. Still, I do think it's an archaic and outdated system,
which could be pleasantly replaced with an alternative. Aside from the fact
that some people still prefer the mailing lists (my opinion may be in the
minority), the problem seems to be that there is no simple replacement
system which can be substituted.

Of the mass communication forums out there, I think email and message
boards had some good bits, but the modern social network (G+, FB, etc.)
seems to have a reasonable hybrid approach to mass conversations, which
allows threaded conversations, direct linking to topics, easily linked
external resources (with preview), integration with other tools
(email/SMS-to-post/reply), easily linking to an individual to whom one is
replying, easily searched and categorized (hashtags), low burden to
subscribe/unsubscribe, better identity management, integrated blogging,
built-in individual and group chat, two-factor authentication, etc., etc.,
etc.

While email may still have its pros, I *do* think it is archaic and lacking
features which inhibit productivity. I think there are better solutions,
and it'd be great if we had the resources to think about them and
experiment with implementing them for the ASF.

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

Re: Apache Reporter Service

[Christopher]

Pretty cool.

A couple of suggestions:

1) if the release dates could be kept up-to-date from versions marked in
JIRA as "released" with a date (
https://issues.apache.org/jira/browse/ACCUMULO/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel),
that'd be really cool.

2) If the system could send a reminder about upcoming report deadlines,
that'd be cool, too (maybe even expose them as ical, so we can see them in
any calendar app).

3) It'd be really neat if one could fill in the missing bits into a field,
and click "submit" to email directly from the interface.


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

On Tue, Mar 3, 2015 at 5:50 AM, Daniel Gruno  wrote:

> Hi folks,
> as some of you will have noticed, either by the commits I just made or
> conversations going on elsewhere, I have started work on a new helper
> system for PMCs called the Apache Reporter Service. This is sort of an
> external addition to Whimsy, and shows various statistics and data for
> projects, designed to aid chairs (and other lurkers) in viewing and
> compiling data for board reports.
>
> The system is now live at: https://reporter.apache.org - you will need to
> be a PMC member of a project to view this site, and you will - in general -
> only be shown data for projects where you are on the PMC.
>
> The system will show you:
> - Your next report date and the chair of the project
> - PMC and committership changes over the past 3 months, as well as latest
> additions if >3 months ago
> - The latest releases done this quarter (if added by RMs)
> - Mailing list statistics: number of subscribers as well as number of
> emails sent this quarter and the previous
> - JIRA tickets opened/closed this quarter (if correctly mapped within the
> system)
> - A mock-up of a board report, with the above data compiled into it (to be
> edited heavily by the chair!)
>
> Quick-navigation (hot-links) can be done by using the LDAP name of a
> project in the URL, for instance: https://reporter.apache.org/?apr would
> navigate directly to the Apache Portable Runtime project if you are on that
> PMC (or a member of the foundation).
>
> The report mock-up is meant as a help only, not a canonical template for
> board reports. Vital items, such as community activity and board issues are
> intentionally left for the reporter (chair) to fill out, and heaven help
> the woman/man who submits a report with these fields left as default ;).
>
> Later today, I plan to enable the distribution watching part of this
> service, which will send reminders to anyone who pushes a release, that
> they should (not required, but if they want to!) add their release data to
> the system, so as to help others using the system to get an overview of the
> status of any given project.
>
> I have already gotten a lot of really useful feedback, but if you see
> something you'd like to change, either shoot me an email here on the comdev
> list, or commit a change to the system in svn.
>
> With regards,
> Daniel.
>

GitHub Pages

[Christopher]

All,

Has any thought been put into leveraging GitHub pages for project
documentation, static site hosting? A lot of www.apache.org is simple
static content, as are project pages. Since a lot of projects are now using
git, and we mirror projects in GitHub, perhaps we can help the individual
projects maintain their site's static content by simply committing to a
gh-pages branch for their project?

Since it's just static content which is still hosted and controlled by ASF,
but simply placed in a way that GitHub can render it from the mirrors, I
don't think there's too many issues of concern, but wasn't sure if
anybody's put any thought into it. I know it would certainly be easier for
some projects than using the existing CMS system with SVN (especially those
otherwise developing exclusively with Git).

It might "just work" today, but I haven't tried it. I'd be willing to work
with INFRA to help experiment with it, though (especially if we wanted to
try out the CNAME feature).

More info: https://pages.github.com/

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

Re: GitHub Pages

[Christopher]

On Wed, Mar 4, 2015 at 4:06 PM, Christopher  wrote:

> All,
>
> Has any thought been put into leveraging GitHub pages for project
> documentation, static site hosting? A lot of www.apache.org is simple
> static content, as are project pages. Since a lot of projects are now using
> git, and we mirror projects in GitHub, perhaps we can help the individual
> projects maintain their site's static content by simply committing to a
> gh-pages branch for their project?
>
> Since it's just static content which is still hosted and controlled by
> ASF, but simply placed in a way that GitHub can render it from the mirrors,
> I don't think there's too many issues of concern, but wasn't sure if
> anybody's put any thought into it. I know it would certainly be easier for
> some projects than using the existing CMS system with SVN (especially those
> otherwise developing exclusively with Git).
>
> It might "just work" today, but I haven't tried it. I'd be willing to work
> with INFRA to help experiment with it, though (especially if we wanted to
> try out the CNAME feature).
>
> More info: https://pages.github.com/
>
>
Even more information:
https://help.github.com/categories/github-pages-basics/

Re: GitHub Pages

[Christopher]

I think I remember the same thing... but in that case, the content was
hosted exclusively in GitHub. This suggestion is that the content is hosted
in ASF repos, and it just happens to be mirrored in GitHub, which
conveniently does rendering. Ultimately, the value to be gained is:

1) better looking sites, with modern themes and tools for maintenance
2) less burden on INFRA and more ease of projects to update their sites
3) enhance the communication between projects and their users

The CNAME features could be used to make sure the URL is ".
apache.org" or "projects.apache.org/" or similar, so that it's
still clear that it's official ASF content being presented (remember, we'd
still control the content in ASF infrastructure, because we control the
repos). Another possibility, if we have concerns about GitHub altering our
official content (or whatever legal reasons we have) is that ASF could
provide a similar/compatible mechanism to render these branches in our
infrastructure as an alternative to CMS. That seems like more work for
INFRA, though.


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

On Wed, Mar 4, 2015 at 6:23 PM, Jay Vyas 
wrote:

> I like the idea. Anything to avoid requiring svn to update project sites.
>
> But... Iirc I started a similar thread before and was told that forwarding
> Apache.org to github static site was against the rules ?Maybe I
> misinterpreted ...
>
>
>
> > On Mar 4, 2015, at 4:06 PM, Christopher  wrote:
> >
> > All,
> >
> > Has any thought been put into leveraging GitHub pages for project
> > documentation, static site hosting? A lot of www.apache.org is simple
> > static content, as are project pages. Since a lot of projects are now
> using
> > git, and we mirror projects in GitHub, perhaps we can help the individual
> > projects maintain their site's static content by simply committing to a
> > gh-pages branch for their project?
> >
> > Since it's just static content which is still hosted and controlled by
> ASF,
> > but simply placed in a way that GitHub can render it from the mirrors, I
> > don't think there's too many issues of concern, but wasn't sure if
> > anybody's put any thought into it. I know it would certainly be easier
> for
> > some projects than using the existing CMS system with SVN (especially
> those
> > otherwise developing exclusively with Git).
> >
> > It might "just work" today, but I haven't tried it. I'd be willing to
> work
> > with INFRA to help experiment with it, though (especially if we wanted to
> > try out the CNAME feature).
> >
> > More info: https://pages.github.com/
> >
> > --
> > Christopher L Tubbs II
> > http://gravatar.com/ctubbsii
>

Re: GitHub Pages

[Christopher]

While I'm interested in the idea of deploying GitLab (I've used it, it's
nice enough), I think it's a separate issue than this thread about pages.
Unless it strongly relates to the idea of pages, could we please discuss
that in a separate thread, so we can give that topic it's own focus?


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

On Wed, Mar 4, 2015 at 8:10 PM, Stian Soiland-Reyes 
wrote:

> I would love to see a GitLab trial at Apache infrastructure - I feel
> uncomfortable at directing other developers to look at
> http://git-wip-us.apache.org/ - the rendering of a repository does not
> even tell you where to clone from!
>
> GitLab Installation is fairly easy, there's also a GitLab docker image
> that is pretty easy to test:
>
> https://registry.hub.docker.com/u/genezys/gitlab/
>
> On 5 March 2015 at 00:14, Niclas Hedhman  wrote:
> > On this note;  Git without Github is like sex without a partner,
> sufficient
> > but not very satisfactory. Github option has been explored in the past,
> and
> > due to various reasons, it was not possible to achieve.
> > But, during my last 2-3 year absence, has the GitLab[1] option been
> > discussed and/or tried? GitLab is open sourced, can run on our infra and
> > has many of the essential features of Github.
> > But perhaps people are satisfied enough with the Github mirroring that is
> > already in place, but with GitLab in house, we could (in theory) add
> > features around licensing (like ICLA style assurance, similar to Jira),
> and
> > non-committers could(!) be allowed a direct route to the horse's mouth...
> >
> > Although the Enterprise system cost money, my guess is that GitLab would
> be
> > happy to waive fees and give us access to EE.
> >
> >
> > Just a thought.
> >
> > [1] https://about.gitlab.com/features/
> >
> > // Niclas
> >
> >
> >
> > On Thu, Mar 5, 2015 at 5:06 AM, Christopher  wrote:
> >
> >> All,
> >>
> >> Has any thought been put into leveraging GitHub pages for project
> >> documentation, static site hosting? A lot of www.apache.org is simple
> >> static content, as are project pages. Since a lot of projects are now
> using
> >> git, and we mirror projects in GitHub, perhaps we can help the
> individual
> >> projects maintain their site's static content by simply committing to a
> >> gh-pages branch for their project?
> >>
> >> Since it's just static content which is still hosted and controlled by
> ASF,
> >> but simply placed in a way that GitHub can render it from the mirrors, I
> >> don't think there's too many issues of concern, but wasn't sure if
> >> anybody's put any thought into it. I know it would certainly be easier
> for
> >> some projects than using the existing CMS system with SVN (especially
> those
> >> otherwise developing exclusively with Git).
> >>
> >> It might "just work" today, but I haven't tried it. I'd be willing to
> work
> >> with INFRA to help experiment with it, though (especially if we wanted
> to
> >> try out the CNAME feature).
> >>
> >> More info: https://pages.github.com/
> >>
> >> --
> >> Christopher L Tubbs II
> >> http://gravatar.com/ctubbsii
> >>
> >
> >
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating)
> http://orcid.org/-0001-9842-9718
>

Re: [VOTE] Replace projects.apache.org with projects-new.apache.org

[Christopher]

+1, with two comments:

1. the projects page on the new site has a link to "Contributors", which is
broken.
2. there's some information linked on the old site about DOAP files and
RSS/Atom feeds, which do not exist (or are not obvious) on the new site.


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

On Fri, Mar 6, 2015 at 11:52 AM, Rich Bowen  wrote:

> I'd like for us to go ahead and replace projects.apache.org with
> projects-new.apache.org. It now has all the functionality that
> projects.a.o has, and much more, and there's no reason to have two sites
> up. If you object to moving forward with this, please say so.
>
> [ ] +1, do it
> [ ] +0, whatevs
> [ ] -1, No (and say why, so we can address the problem)
>
> --Rich
>
> --
> Rich Bowen - rbo...@redhat.com
> OpenStack Community Liaison
> http://rdoproject.org/
>

Re: GitLab?

[Christopher]

On Thu, Mar 5, 2015 at 10:12 AM, David Nalley  wrote:

> On Wed, Mar 4, 2015 at 10:24 PM, Niclas Hedhman 
> wrote:
> > Opening a new thread...
> >
> > Git without Github is like sex without a partner, sufficient but not very
> > satisfactory. Github option has been explored in the past, and due to
> > various reasons, it was not possible to achieve.
> >
> > But, during my last 2-3 year absence, has the GitLab[1] option been
> > discussed and/or tried? GitLab is open sourced, can run on our infra and
> > has many of the essential features of Github.
> > But perhaps people are satisfied enough with the Github mirroring that is
> > already in place, but with GitLab in house, we could (in theory) add
> > features around licensing (like ICLA style assurance, similar to Jira),
> and
> > non-committers could(!) be allowed a direct route to the horse's mouth...
> >
> > Although the Enterprise system cost money, my guess is that GitLab would
> be
> > happy to waive fees and give us access to EE.
> >
> >
> > Just a thought.
> >
> > [1] https://about.gitlab.com/features/
> >
> > --
> > Niclas Hedhman, Software Developer
> > http://www.qi4j.org - New Energy for Java
>
>
> Infrastructure (at least in the short term) won't deploy Gitlab. The
> reasoning is this:
> 1. Most of our demand from projects is for Github, and truthfully, if
> we could resolve one or two nagging problems, Infra would love to no
> longer run and administer several hundred git repositories and instead
> offload that work to Github.
> 2. There is a lot of infrastructure built up around the existing git
> infrastructure. Deploying Gitlab or Allura or anything else would
> require us to figure out authorization, backups, integration with
> Github, Jira, BZ, svn mirroring, etc; that's a lot of work. IF we were
> going to tackle such a project it would need to be for all projects,
> not just a few, and it would be significantly lower on the priority
> list than a lot of the work we are currently doing.
>
> My current thinking (though not yet Foundation policy) is that there
> is the canonical repository must be managed by Infra, and I suspect
> that will be in the proposed policy that gets submitted to the board.
>
>
I have a question about this part. Does INFRA's management over the Apache
organization in GitHub (github.com/apache) satisfy this requirement? In
other words, would it be out of the question to foresee managing project
teams in GitHub directly at some point in the future, working on the
canonical repositories directly in GitHub, rather than simply treating it
as a mirror-hosting service? (since GitHub has all those integrated
features, like bug-tracking, etc., already, which INFRA has to maintain
separately today).

It seems to me that the biggest hurdle for using GitHub for canonical
repository hosting is authentication (since authentication is done via
GitHub, not ASF). Providing users the ability to specify their GitHub
username in id.apache.org before getting added to a "team" in a GitHub
project could solve that, though.

I personally like GitLab... it's nice software (haven't tried Allure). I'm
just not sure there's a real need for INFRA to manage any separate git
hosting service so long as GitHub exists and we can easily mirror/copy
anything pushed to it. I don't see it as much different than paying for
server hosting for other parts of our infrastructure (like EC2, or wherever
our servers currently reside).

Re: GitHub Pages

[Christopher]

On Thu, Mar 5, 2015 at 10:07 AM, Benedikt Ritter  wrote:

> 2015-03-05 15:42 GMT+01:00 Sebastien Goasguen :
>
> > So FWIW, I never thought about using github pages for our website.
> > I just tried it.
> >
> > Created an orphaned gh-pages in our repo, pushed that. It got mirrored
> > right away and now we have:
> > http://apache.github.io/cloudstack/
> >
> > Based off of:
> > https://github.com/apache/cloudstack/tree/gh-pages
> >
>

Neat! That's exactly the kind of test I was going to try. The next thing to
try would be to see if we could get http://cloudstack.apache.org to point
to http://apache.github.io/cloudstack ; that's the part that's somewhat
questionable for me.

Perhaps we could also do something like: make a project called "
apache.github.io" and mirror it to http://github.com/apache/apache.github.io
and create a CNAME from projects.apache.org to point to apache.github.io.
Then we could maintain the projects site inside git also. Another CNAME
would work just as well (maybe code.apache.org).


> > Loving it,
> >
>
> Usually you have to activate github pages in the repository configuration.
> Are github pages activated by default for ASF mirrors or did you request
> that from infra?
>

gh-pages are enabled by default in GitHub these days. I don't even know if
they can be disabled (except by not having a branch with that name).

Regarding some of the other comments about jekyll... it's not true that you
need jekyll. You can publish plain HTML or Markdown also.

The other consideration somebody pointed out to me is the question of
"staging". CMS does that well today. But, that seems pretty easy, too,
because you can view the rendering in your personal fork before pushing to
the Apache repo's gh-pages branch to be mirrored and rendered.

Re: [VOTE] Replace projects.apache.org with projects-new.apache.org

[Christopher]

On Fri, Mar 6, 2015 at 5:35 PM, Shane Curcuru  wrote:

> Question: is there any plan to redirect old URLs?
>
> The old projects.a.o certainly is clunky, but there may well be a few
> people who have linked to various parts of the site.
>
> Similarly, are we still using DOAP files?  I could imagine that there
> are others who were also referring to individual DOAPs or to the
> projects.a.o/feeds content.
>
> These may not be widely used features, but if we're nuking them we
> should be explicit about that and provide some notice about them being
> gone.
>
>
+1; it'd be nice to know that we don't have to update them anymore, if
that's the case.

Re: GitHub Pages

[Christopher]

On Wed, Mar 11, 2015 at 12:55 PM, David Nalley  wrote:

> SSL
> Specifically - apache.org sites are in https-everywhere. Those sites
> can't provide SSL.
>
>
Yeah, I've been trying to think of how to deal with that. The only thing I
could think of is if GitHub offered server-certs for the sub-domains it
hosts (which they don't) or if we could provide one for them to use for the
sub-domain (which there is no mechanism to do that with).


> None of the current TLP web sites are being served from Apache
> hardware though - it's all VMs in 2-3 different cloud providers.
>
>
I figured it was something like that.


> --David
>
> On Wed, Mar 11, 2015 at 12:51 PM, Mike Kienenberger 
> wrote:
> > The github pages I've worked on have all been in Markdown, so they're
> portable.
> >
> > I also don't see any reason why we can't host pages elsewhere since we
> > control the source repositories.
>

To satisfy SSL needs, it seems we'd probably have to do that anyway. It'd
be nice if we could stand up similar rendering service as an alternative to
CMS (or even if CMS could be altered to use a git branch). If it were
GH-compatible, that'd be best, because people could test/stage in their
personal forks if they wish. Alternatively, this service could render a
staging site from a different branch.

I'm sure such a service would be very low priority right now (CMS is
working well enough).


> >
> > On Wed, Mar 11, 2015 at 12:45 PM, Ross Gardler (MS OPEN TECH)
> >  wrote:
> >> Is it really necessary for our web pages to be served from Apache
> hardware? If so, why?
> >>
> >> I understand why we want to control the canonical source, but do we
> really need to own web server?
> >>
> >> A concern, for me, would be if hosting on GitHub Pages meant that we
> could not easily switch to another host.
> >>
>

I share this concern. I wonder if there's already a GH-compatible rendering
service out in the open source which would be easy enough to deploy.


> >> Ross
> >>
> >> -Original Message-
> >> From: Ted Dunning [mailto:ted.dunn...@gmail.com]
> >> Sent: Wednesday, March 11, 2015 9:40 AM
> >> To: dev@community.apache.org
> >> Subject: Re: GitHub Pages
> >>
> >> Chris,
> >>
> >> The easy summary is that Apache would like to keep apache sites being
> served by apache controlled hardware.
> >>
> >> Github serving pages fails that test.
> >>
> >>
> >>
> >> On Wed, Mar 11, 2015 at 9:37 AM, Christopher 
> wrote:
> >>
> >>> On Fri, Mar 6, 2015 at 6:41 PM, Ted Dunning 
> wrote:
> >>>
> >>> >
> >>> > I think those other comments about Jekyll had to do with keeping all
> >>> > of the site storage on apache servers.
> >>> >
> >>> >
> >>> I'm not sure I understand how Jekyll affects that. Are we concerned
> >>> that GitHub will not render the site's source accurately? And, if so,
> >>> wouldn't that concern extend to non-Jekyll static sources also?
> >>>
> >>>
> >>> > There have been objections in this thread about using github.io
> >>> > based sites even with site name masquerading.
> >>> >
> >>> >
> >>> Does anybody wish to summarize those? I think it would be helpful.
> >>>
> >>>
> >>> > Sent from my iPhone
> >>> >
> >>> > > On Mar 6, 2015, at 14:36, Christopher  wrote:
> >>> > >
> >>> > > Regarding some of the other comments about jekyll... it's not true
> >>> > > that
> >>> > you
> >>> > > need jekyll. You can publish plain HTML or Markdown also.
> >>> >
> >>>
>

Re: GitHub Pages

[Christopher]

On Fri, Mar 6, 2015 at 6:41 PM, Ted Dunning  wrote:

>
> I think those other comments about Jekyll had to do with keeping all of
> the site storage on apache servers.
>
>
I'm not sure I understand how Jekyll affects that. Are we concerned that
GitHub will not render the site's source accurately? And, if so, wouldn't
that concern extend to non-Jekyll static sources also?


> There have been objections in this thread about using github.io based
> sites even with site name masquerading.
>
>
Does anybody wish to summarize those? I think it would be helpful.


> Sent from my iPhone
>
> > On Mar 6, 2015, at 14:36, Christopher  wrote:
> >
> > Regarding some of the other comments about jekyll... it's not true that
> you
> > need jekyll. You can publish plain HTML or Markdown also.
>

Re: Why are committers accounts never terminated?

[Christopher]

Perhaps we can create a procedure that *isn't* a giant hurdle?

On Thu, Mar 12, 2015, 11:39 Kevin A. McGrail  wrote:

> On 3/12/2015 11:31 AM, Pierre Smits wrote:
> > Including community dev as it seems appropriate.
> >
> > Offboarding is equally important as onboarding. The solution as
> > described by Emmanuel and applied by Apache Directory project is a
> > good one. If the PMC of project FOO wants to have done it differently,
> > then it is their prerogative.
> We will have to agree to disagree because to me it's an apache way that
> volunteers can step away and step back without giant hurdles. This isn't
> about removing from a PMC but more about removing commit access seems
> like an extraordinary step that should be done in rare situations.
>
> Regards,
> KAM
>

Re: Why are committers accounts never terminated?

[Christopher]

The gain, of course, is security... Because inactivity could indicate lack
of control over the account, as previously indicated. Whether this is a
significant enough risk to do something about is the question.

On Thu, Mar 12, 2015, 12:24 Kevin A. McGrail  wrote:

> On 3/12/2015 12:19 PM, Christopher wrote:
> > Perhaps we can create a procedure that *isn't* a giant hurdle?
> I don't see the gain from doing so.  We've had no issues identified that
> this actual solves and it actively goes against my understanding of the
> pro-volunteer nature of the ASF.
>
> regards,
> KAM
>

Re: Google Code shutting down Jan 2016

[Christopher]

I don't know the reasons for choosing SF, but I'd highly recommend
putting serious consideration into GitHub. It's quite pleasant to work
with, and although I'm not a part of the apache-extras, I think those
who are would be quite satisfied with it (that's just my personal
opinion, of course).

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


On Thu, Mar 12, 2015 at 5:37 PM, David Nalley  wrote:
> It is my understanding that moving to SF from Google Code is a ComDev
> decision. I have interacted with SF and then brought the PoCs they've
> done here, but AFAIK, no decision has been made.
>
> --David
>
> On Thu, Mar 12, 2015 at 4:55 PM, Ross Gardler (MS OPEN TECH)
>  wrote:
>> Ahhh... I see no that's just code for I don't have time, but these folks 
>> have shown interest ;-)
>>
>> I'm happy to help make sure we hit this deadline, but I'm not driving it.
>>
>> Ross
>>
>> -Original Message-
>> From: Ulrich Stärk [mailto:u...@spielviel.de]
>> Sent: Thursday, March 12, 2015 1:50 PM
>> To: dev@community.apache.org
>> Subject: Re: Google Code shutting down Jan 2016
>>
>> *Really* moving board@ to BCC ;)
>>
>> You said you put people in contact with each other so I was under the 
>> impression you were actively part of a group driving this.
>>
>> Jim, do you have any updates on the current status?
>>
>> Cheers,
>>
>> Uli
>>
>> On 2015-03-12 21:40, Ross Gardler (MS OPEN TECH) wrote:
>>> Moving board@ to BCC
>>>
>>> I am *not* working on it. I have no idea who said I was (I do hope it
>>> wasn't me!)
>>>
>>> All I know is that Jim, David and Roberto are working on it, I don't
>>> know how actively but it is now a priority.
>>>
>>> I believe Jim is involved wearing his ComDev hat so (with his
>>> agreement) you can look to him for those updates. David is wearing his 
>>> infra hat and Roberto wears his SF hat.
>>>
>>> Ross
>>>
>>> Microsoft Open Technologies, Inc. A subsidiary of Microsoft
>>> Corporation
>>>
>>> -Original Message- From: Ulrich Stärk
>>> [mailto:u...@spielviel.de] Sent: Thursday, March 12,
>>> 2015 1:36 PM To: dev@community.apache.org Cc: bo...@apache.org
>>> Subject: Re: Google Code shutting down Jan 2016
>>>
>>> We reported about apache extras in September and November and both
>>> times we were told that Jim, Ross, David and Roberto were working on
>>> it. Some time in October David asked for feedback on a proof of concept, no 
>>> news since then.
>>>
>>> Can you shed some light on who is driving this atm?
>>>
>>> Cheers,
>>>
>>> Uli
>>>
>>> On 2015-03-12 21:22, Ross Gardler (MS OPEN TECH) wrote:
>>>> Today Google announced that Google Code will be shutting down Jan 25, 2016.
>>>>
>>>> We need to create a replacement for Apache-extras. Can we please make
>>>> sure that progress on this is reported in the ComDev board report each 
>>>> quarter.
>>>>
>>>> I suggest the starting point should be to expand discussions with
>>>> SourceForge, they have offered neighborhoods in the past. David, with
>>>> his infra hat, has been exploring options for download provision already 
>>>> (I'm not sure of the current status).
>>>>
>>>> (and as a reminder, this is why we don't like to use services
>>>> provided by external companies)
>>>>
>>>> Ross
>>>>
>>>> Microsoft Open Technologies, Inc. A subsidiary of Microsoft
>>>> Corporation
>>>>
>>>>

Re: Google Code shutting down Jan 2016

[Christopher]

On Thu, Mar 19, 2015 at 7:22 AM, Stian Soiland-Reyes  wrote:
> +1 for GitHub  - as Apache Extras are easily mini-communities of one
> or two people and not as clear way in to contribute.
>
>
> GitHub should seriously be considered. Making an apache-extras
> organization there should be straight forward.
[snip]

I just took the 2 seconds to do this, to reserve the name. If
anybody's interested, I'll transfer it.

Re: ApacheCon Twitter account

[Christopher]

You can just sign in to tweetdeck in the browser, without a special
app: http://tweetdeck.twitter.com/

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


On Tue, Mar 24, 2015 at 10:53 AM, Santiago Gala  wrote:
> I would be interested in helping with twitter, but I can't find a way to
> use tweetdeck with linux, and I don't use windows (or OS/X). Is there a way
> to use tweetdeck without proprietary OSes?
>
> El dom., 22 de marzo de 2015 a las 14:00, Rich Bowen ()
> escribió:
>
>>
>>
>> On 03/21/2015 01:29 PM, Roman Shaposhnik wrote:
>> > On Thu, Mar 19, 2015 at 6:46 AM, Rich Bowen  wrote:
>> >> Twitter just posted the following blog post:
>> >> https://blog.twitter.com/2015/introducing-tweetdeck-teams
>> >
>> > Interesting! On a related subject: should we promote the usage of this
>> > for managing all of our project @ASFxxx accounts?
>>
>> It seems preferred over handing out username/password to a bunch of
>> people, certainly. This way, one person (perhaps even a designated
>> comdev officer?) has the main password, and can delegate to other
>> people? It's an interesting idea.
>>
>> --
>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> http://apachecon.com/ - @apachecon
>>

Re: https://apache.org

[Christopher]

FWIW, my opinion is that the vender should reissue with the SAN.

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


On Fri, May 22, 2015 at 7:59 AM, Kevin A. McGrail  wrote:
> The cert in use is for *.apache.org and does not have a Subject Alternate
> Name for just apache.org without a subdomain.
>
> This leaves 2 primary course of actions:
>
> - request the vendor we got our cert from (Symantec) add the SAN and
> reissue.  They sometimes will do so.
> - buy and install a cert for apache.org for the website without www. and
> redir to the www.apache.org website
>
> Other courses of action:
>
> - remove the DNS entry for A/CNAME for apache.org so it doesn't resolve to
> anything
> - ignore the issue (it's been reported a few times already and likely won't
> stop)
>
> Regards,
> KAM
>
> On 5/22/2015 12:36 AM, vamsi katepalli wrote:
>>
>> Hi,
>>
>> This Url works for me https://www.apache.org but it gives the same error
>> for https://apache.org <https://apache.org/>
>>
>> On Thu, May 21, 2015 at 11:03 PM, Niclas Hedhman > <mailto:nic...@hedhman.org>> wrote:
>>
>> I am not sure who should be contacted, but https://apache.org
>> doesn't match
>> the *.apache.org <http://apache.org> SSL Certificate and one gets
>> a big fat warning in modern
>> browsers that the site shouldn't be trusted.
>>
>> I think it needs to be corrected...
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>>
>

Re: The @PlanetApache Twitter feed is now following individual Apache Committers

[Christopher]

Neat. @ctubbsii

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


On Tue, Jun 9, 2015 at 6:25 PM, James Taylor  wrote:
> Great! Please follow me @JamesPlusPlus
>
> On Tuesday, June 9, 2015, Sally Khudairi  wrote:
>
>> Greetings, Apache Committers!
>>
>> I'm happy to announce that we now administer the @PlanetApache Twitter
>> account and will begin to follow individual Twitter accounts of Apache
>> Committers there.
>>
>> If you would like to be followed, please drop me a note.
>>
>> Warm regards,
>> Sally
>>
>> Vice President Marketing & Publicity
>> The Apache Software Foundation
>>
>> = = = = =
>> vox +1 617 921 8656
>> off2 +1 646 583 3362
>> skype sallykhudairi
>>

Re: Format for project data: DOAP/JSON/other (was: Is https://projects-new.apache.org/ ready for prime time?)

[Christopher]

On Sun, Jun 21, 2015 at 11:29 AM, sebb  wrote:
> [Starting thread with new subject]
>
> On 21 June 2015 at 16:03, Hervé BOUTEMY  wrote:
>> Le dimanche 21 juin 2015 15:54:29 jan i a écrit :
>>> On 21 June 2015 at 15:48, Daniel Gruno  wrote:
>>> > I think the site is ready for a more prominent role, but I find this
>>> > discussion confusing, and I find it somewhat sad that we're gonna stick
>>> > with something as arcane as DOAP.
>>>
>>> +100 !!
>>>
>>> DOAP == Dead On Arrival Permanently :-) JSON == Jump Simply On New
>>> (but I know I am only 1 voice).
>> step by step, please: this will avoid confusion between independant topics
>>
>> switching without disturbing current conventions/knowledge is something that
>> already takes a long time and energy: I know it because I put a lot of energy
>> on it for a few monthes now!
>>
>> We started a discussion on this source format topic during april, and AFAIK
>> nobody worked on it.
>>
>> What I'd like now is to switch: we can discuss later on what we want to 
>> change
>> (and communication to every comittees this requires).
>> With the new site, we'll be able to change formats if we want, the only
>> requirement is to have json files for the visualization
>
> Some PMCs are very responsive to requests to maintain DOAP files;
> others take months and multiple reminders even for a simple fix. This
> does not directly affect the format used to hold the data. However it
> does mean that changing to a new format is likely to take a lot of
> time and involve a lot of work. Meanwhile the code will need to
> continue to support the old format.
>
> It would however be an opportunity to make some improvements. For example:
> - we could be more specific about the data that really needs to be
> maintained by PMCs
> - we could require that the files are stored in a well-known place,
> rather than requiring an index file to find them.

Personally, I'd like to see a nice web interface for a project's
"profile", akin to social media profiles or one's personal profile at
nearly every site on the web. Whatever file format is used behind the
scenes shouldn't matter for PMCs. I think projects-new started us off
in the right direction, essentially doing this for release
information, but really everything about a project could be contained
in a profile managed by a web interface of this type.

I don't think adding requirements to these files (like a well-known
location) are going to make them more maintainable for PMCs. It's just
going to be one more thing for them to remember to get right for
something which is relatively rarely edited. It'd be much easier to
make projects.apache.org be for projects what id.apache.org is for
committers.

For comparison, Fedora seems to do a decent job of providing a
consistent web view of all aspects of a project:
https://apps.fedoraproject.org/packages/java-1.8.0-openjdk . There's
actually several different views, but in general, there's links to
contributors, upstream project page, builds, bug tracker, "updates"
(analogous to releases), source, etc. I realize Apache projects aren't
as homogeneous as package management in Fedora, which makes things a
bit difficult for us, but I do think there's probably some lessons to
be gained. For one, most of those web views are auto-generated, based
on maintainer and user actions (like triggering an update, filing a
bug, applying a patch, or retiring a package). As such, these
interfaces tend not to be editable. However, one can pretty easily
imagine similar project profile pages which are editable by a PMC.

However, I'm not really all that familiar with the historical need for
DOAP files, what tools actually use them, or the historical
preferences for maintaining them. So, I admittedly may not fully grasp
the scope of the problem/changes being discussed. I'm just thinking
that if we can get rid of the requirement for PMCs to maintain them
(in favor of a web-interface way for PMCs to describe all aspects of
their projects), then I'd like that.

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

Re: Better specifying the scope of our Code of Conduct

[Christopher]

+1

On Tue, Jun 30, 2015, 07:01 Bertrand Delacretaz 
wrote:

> Hi,
>
> Someone mentioned to me that they find the first paragraph of
> http://www.apache.org/foundation/policies/conduct.html overly broad,
> and I tend to agree.
>
> That paragraph says "this code of conduct governs how we behave in any
> forum and whenever we will be judged by our actions" which implies
> that it also applies outside of "ASF territory" - I don't think that's
> appropriate. The next paragraph mentions "spaces managed by the Apache
> Software Foundation" which I find much more appropriate, maybe
> expanded with "and whenever we represent the ASF".
>
> The reasoning is that we can only speak about our own territory.
>
> As a simple example, putting your hand on someone's shoulder while
> talking to them is totally welcome in some cultures while considered
> "unwelcome sexual attention" (to reuse the words of that document) in
> others. We might ask people to refrain from doing that in our
> multi-cultural environment where we need to go down to some common
> denominator of acceptable behavior, but we can't blame them for doing
> that where it's culturally acceptable and even expected. The same goes
> with profanity, where the acceptable level varies immensely between
> cultures.
>
> So I think it's good to restrict our code of conduct to our own territory.
>
> I suggest reworking the first few paragraphs as follows, to clarify that:
>
> *** reworked code of conduct intro section ***
> This code of conduct applies to all spaces managed by the Apache
> Software Foundation, including IRC, all public and private mailing
> lists, issue trackers, wikis, blogs, Twitter, and any other
> communication channel used by our communities. A code of conduct which
> is specific to in-person events (ie., conferences) is codified in the
> published ASF anti-harassment policy.
>
> We expect this code of conduct to be honored by everyone who
> participates in the Apache community formally or informally, or claims
> any affiliation with the Foundation, in any Foundation-related
> activities and especially when representing the ASF, in any role.
>
> This code is not exhaustive or complete(unchanged from here on)
> *** reworked code of conduct intro section ***
>
> What do people think?
> -Bertrand
>

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?

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: 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: 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: 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: 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: 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: 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: 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 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: 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.
>

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: 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.

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

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: 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: 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.
>

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?

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.

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
>
>

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.

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: 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?
>

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?

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?
>
>

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]

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 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 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]

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: [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: [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]

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

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

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

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

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
>
>

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

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

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

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
>
>

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

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
>
>

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

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
>
>

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

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
>
>