Re: "incubator-netbeans" on Project Statistics page

[sebb]

On Mon, 10 Jun 2019 at 09:12, Geertjan Wielenga  wrote:
>
> Hi all,
>
> Now that NetBeans has left the incubator and is a top level project, can
> 'incubator-netbeans' be changed to 'netbeans' on this page:
>
> https://projects.apache.org/statistics.html
>
> If I need to request this in a different way, please let me know.

Please raise a COMDEV Jira issue to better keep track of this.

> See: https://issues.apache.org/jira/browse/INFRA-18354
>
> Thanks,
>
> Geertjan (Apache NetBeans PMC Chair)

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

Re: Feedback requested: New committer invitation template

[sebb]

On Sun, 30 Dec 2018 at 18:24, Daniel Gruno  wrote:
>
> On 12/30/18 6:41 PM, Matt Sicker wrote:
> > I like this template suggestion. It may also be helpful to note that the
> > Apache ids must be letters and numbers only as some people request special
> > characters in their ids.
>
> Not to toot my own horn too much, but we also have
> https://asf.icla.online/ which simplifies the print-type-sign-scan-email
> routine for Apache ICLAs (and does verify that user ID is both available
> and matches our syntax). Could be an idea to point to that for easy ICLA
> work :)
>

Who is responsible for maintaining the site?
I could find no contact details, and no information on how to report
errors/request enhancements.

What happens to the generated ICLA?
This contains private information, but I could not find a privacy statement.

> >
> > On Sun, Dec 30, 2018 at 09:24, Craig Russell  wrote:
> >
> >> Hi Hugo,
> >>
> >> The intent is for the PMC member sending the invitation to do the check
> >> before sending the mail and edit the mail so the candidate only sees the
> >> appropriate option.
> >>
> >> I'll try to make this more clear in the instructions on the page that
> >> contains the sample email. [I originally had three different sample emails
> >> but they were all the same except for the paragraph B.]
> >>
> >> Thanks for the feedback.
> >>
> >> Craig
> >>
> >>> On Dec 29, 2018, at 9:32 PM, Hugo Louro  wrote:
> >>>
> >>> Hi Craig,
> >>>
> >>> +1 for the overall proposal. There is only one thing that I would like
> >> to clarify. Do you plan to have a custom email for each of the three cases
> >> (already have an Apache id, already filed an ICLA, and have not filed an
> >> ICLA), and research ahead of time to which case the person applies, or have
> >> an email that covers all the cases. If the later, my suggestion is that the
> >> email should clearly direct the recipient to choose specifically the case
> >> that applies to her/himself. I mean, have written something along the
> >> lines: If you already have an Apache is, follow these instructions, if
> >> already filed an ICLA follow these other instructions, otherwise follow
> >> this instead.
> >>>
> >>> Thanks,
> >>> Hugo
> >>>
>  On Dec 29, 2018, at 3:29 PM, Craig Russell 
> >> wrote:
> 
>  Hi,
> 
>  In order to simplify the process of granting new committers write
> >> access to a project's repository, I'd like to propose a change in the
> >> invitation letter sent to candidates after the PMC has voted to accept them
> >> as committers.
> 
>  The original is at
> >> https://community.apache.org/newcommitter.html#committer-invite-template
> 
>  It does not distinguish among these three cases: already have an Apache
> >> id, already filed an ICLA, and have not filed an ICLA. There are many cases
> >> where unnecessary work is done because of improper guidance.
> 
>  
>  To: joeblo...@foo.net
>  Cc: private@[PROJECT].apache.org
>  Subject: Invitation to become [PROJECT] committer: Joe Bloggs
> 
>  Hello [invitee name],
> 
>  The [Project] Project Management Committee] (PMC)
>  hereby offers you committer privileges to the project
>  [as well as membership in the PMC]. These privileges are
>  offered on the understanding that you'll use them
>  reasonably and with common sense. We like to work on trust
>  rather than unnecessary constraints.
> 
>  Being a committer enables you to more easily make
>  changes without needing to go through the patch
>  submission process. [Being a PMC member enables you
>  to guide the direction of the project.]
> 
>  Being a committer does not require you to
>  participate any more than you already do. It does
>  tend to make one even more committed.  You will
>  probably find that you spend more time here.
> 
>  Of course, you can decline and instead remain as a
>  contributor, participating as you do now.
> 
>  A. This personal invitation is a chance for you to
>  accept or decline in private.  Either way, please
>  let us know in reply to the [priv...@project.apache.org]
>  address only.
> 
>  [check http://people.apache.org/committer-index.html]
>  [B. If you accept, since you already have an Apache id,
>  the PMC will grant you write access to the repository.
>  ]
> 
>  [check http://people.apache.org/unlistedclas.html]
>  [B. If you accept, since you already have an iCLA on file,
>  the PMC will request an Apache id for you. In your response,
>  please choose an id that is not already in use. See
>  http://people.apache.org/committer-index.html
>  ]
> 
>  [B. If you accept, the next step is to register an iCLA:
> 1. Details of the iCLA and the forms are found
> through this link: http://www.apache.org/licenses/#clas
> 
> 

GSoC2018 and earlier

[sebb]

Can anything be done to close the COMDEV GSoC entries that have expired?
i.e. GSoC 2018 and earlier?

There seems little point in keeping them open now.

S.

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

Should comdev and GSoC use different JIRA ids?

[sebb]

As the subject says.

It might be easier to manage the issues if there were separate JIRAs
for COMDEV and GSOC.

S.

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

Re: Shared service for Websites?

[sebb]

On Wed, 18 Sep 2019 at 21:35, Christofer Dutz  wrote:
>
> Hi all,
>
> well we technically have a site up and running nicely. It's content is part 
> of the project itself. It's automatically built and deployed by Jenkins.
> We use asciidoctor and the maven-site-plugin to generate the content for it.
> The problem is that is just doesn't look so great.
> http://plc4x.apache.org/
>
> So it's more the art part of web-design and/or the art of texting we could 
> need some help with ;-)

That sounds like a job for Central Services.
Try contacting them on centralservi...@apache.org

> We've got the technical base well covered.
>
> Chris
>
> Am 18.09.19, 21:33 schrieb "Roy Lenferink" :
>
> Recently Celix migrated from the Apache CMS to hosting the website through
> the gitpubsub system as well.
> For Celix we're using Hugo meaning our content is written in markdown.
>
> If you want to have a look please do here: http://celix.apache.org/
> The source exists here: https://github.com/apache/celix-site
>
> Roy
>
> Op wo 18 sep. 2019 om 16:33 schreef Owen O'Malley 
> :
>
> > Since all of the Apache projects have their websites checked in, find 
> one
> > you like and copy the style and start from there. That is how Calcite
> > 's page ended up looking at lot like ORC
> > 's.
> > ..Owen
> >
> >
> > On Wed, Sep 18, 2019 at 6:16 AM Christofer Dutz 
>  > >
> > wrote:
> >
> > > Hi all,
> > >
> > > I just wanted to ask if there is any “shared service” or nice person 
> that
> > > could help the PLC4X Website.
> > > It’s sort of looked the same since I initiated the project and I think
> > > it’s not quite in a state that will make people get interested in what
> > > we’re doing.
> > > As I really suck greatly at web-design, I just wanted to ask if there 
> is
> > > any shared service or someone willing to help us with improving it.
> > >
> > > Would be happy for some positive feedback,
> > > Chris
> > >
> >
>
>

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

Re: svn commit: r1865230 - /comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py

[sebb]

On Thu, 15 Aug 2019 at 17:09, Daniel Gruno  wrote:
>
> Thanks!
> I've reloaded the WSGI (pkill -HUP -f gunicorn3) so it's using the new
> paths now. I'll look into installing it as a service through puppet, so
> we can do something like `service rapp reload` and possibly reload on
> change...

There was a problem in the crontab; it was set to start gunicorn using
port 8000; I have fixed that.

> On 8/15/19 5:00 PM, s...@apache.org wrote:
> > Author: sebb
> > Date: Thu Aug 15 15:00:57 2019
> > New Revision: 1865230
> >
> > URL: http://svn.apache.org/viewvc?rev=1865230&view=rev
> > Log:
> > Another kibble token reference
> >
> > Modified:
> >  comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py
> >
> > Modified: comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py
> > URL: 
> > http://svn.apache.org/viewvc/comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py?rev=1865230&r1=1865229&r2=1865230&view=diff
> > ==
> > --- comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py (original)
> > +++ comdev/reporter.apache.org/trunk/scripts/rapp/kibble.py Thu Aug 15 
> > 15:00:57 2019
> > @@ -7,7 +7,7 @@ import re
> >   import os
> >
> >   RAO_HOME = '/var/www/reporter.apache.org'
> > -TOKEN = open('%s/data/kibble-token.txt' % RAO_HOME).read().strip()
> > +TOKEN = open('/usr/local/etc/tokens/kibble.txt').read().strip()
> >
> >   def stats(project, jira = [], mlid = None):
> >   BEFORE = int(time.time() - (91*86400))
> >
> >
>
>
> -
> 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: projects.apache.org urls showing in some projects categories

[sebb]

On Thu, 24 Oct 2019 at 23:30, Nick Burch  wrote:
>
> Hi All
>
> I've spotted what looks like a data bug, but might be a code bug, on
> projects.apache.org. For some projects, they are being shown not against
> their proper category (eg library), but against a category that's prefixed
> with the https://projects.a.o link for their category
>
> For example, Apache Tika is showing as a category of
> https://projects.apache.org/projects.html?category#library instead of just
> library. You can see that at
> https://projects.apache.org/projects.html?category#https://projects.apache.org/projects.html?category#library

That is a data bug.

See https://projects.apache.org/guidelines.html for category syntax.

> Thanks
> Nick
>
> -
> 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: projects.apache.org urls showing in some projects categories

[sebb]

On Mon, 28 Oct 2019 at 10:56, Christofer Dutz  wrote:
>
> Hi,
>
> Well as far as I understood it, this data is provided by the RDF files 
> projects maintain themselves.

Yes, projects maintain their own DOAP files.

If the project data file is wrong, then the output is likely to be wrong also.

I suppose it might be possible to do some more validation on the DOAP
files, but I'm not sure the effort would be worth it.

> I too noticed some time ago the "iot" category was only used by Apache Camel, 
> so I fixed this at least for Apache PLC4X.
> We integrated this into our code-repo and the site-generation:
> https://github.com/apache/plc4x/blob/develop/src/site/resources-filtered/plc4x-doap.rdf
>
> And I just noticed it is slightly out of date with respect to our latest 
> releases.
>
> Chris
>
>
> Am 25.10.19, 01:26 schrieb "sebb" :
>
> On Thu, 24 Oct 2019 at 23:30, Nick Burch  wrote:
> >
> > Hi All
> >
> > I've spotted what looks like a data bug, but might be a code bug, on
> > projects.apache.org. For some projects, they are being shown not against
> > their proper category (eg library), but against a category that's 
> prefixed
> > with the https://projects.a.o link for their category
> >
> > For example, Apache Tika is showing as a category of
> > https://projects.apache.org/projects.html?category#library instead of 
> just
> > library. You can see that at
> > 
> https://projects.apache.org/projects.html?category#https://projects.apache.org/projects.html?category#library
>
> That is a data bug.
>
> See https://projects.apache.org/guidelines.html for category syntax.
>
> > Thanks
> > Nick
> >
> > -
> > 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: [VOTE] Move community.a.o site from CMS/SVN to Hugo/Git

[sebb]

+1

I suggest taking a snapshot of the current website (e.g. tag SVN) so
the page names/content can be compared with the new site.

On Mon, 24 Feb 2020 at 14:57, Rich Bowen  wrote:
>
>
>
> On 2/22/20 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
>
> +1
>
> I am not a fan of git, but am not going to get in the way of people who
> are doing (have already done) the work.
>
> --
> Rich Bowen - rbo...@rcbowen.com
> http://rcbowen.com/
> @rbowen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: [ALC] Discussion about ALC WebSite

[sebb]

On Sat, 7 Mar 2020 at 14:05, Tomasz Urbaszek
 wrote:
>
> I think alc.apache.org will be enough. Each chapter can have its own
> subpage like alc.apache.org/beijing :)

+1

The advantage of subpages is that they can use the same SSL certificate.
Also they don't need extra DNS entries.

Subdomains generally require an extra certificate and a DNS entry.

S.
> T.
>
>
> On Sat, Mar 7, 2020 at 2:06 PM 适兕  wrote:
> >
> > +1 for the ALC website.
> >
> > But I have a question, we need define domain name too. i.e
> > beijing.alc.apache.org.
> > is this possible? second level domain name of apache.org?
> >
> > On Fri, Mar 6, 2020 at 11:29 PM Aditya Sharma 
> > wrote:
> >
> > > +1 for the ALC website! Thanks for your initiative.
> > >
> > >  > How about we just put our effort on ALC website?
> > >  > It could be great that  ALC Chapters to contribute all the contents to
> > >  > ALC website, we could have a blog section to host these freestyle
> > >  > articles, and we can also a directory on the website to the ALC
> > >  > Chapters event there.
> > >
> > > +1
> > > Initially, we can start with a single ALC website and evolve things with
> > > time.
> > >
> > > Thanks and Regards,
> > > Aditya Sharma
> > >
> > > On Fri, 6 Mar 2020 at 19:52, Jarek Potiuk  wrote:
> > > >
> > > > +1. One repo with separate sections /tabs per ALC would be great!
> > > >
> > > > And with the workflow where we can simply make PRs to the common repo is
> > > > everything we need. Hugo is certainly the way to go. For Apache Airflow
> > > we
> > > > also do a lot on Hugo and happy with it.
> > > >
> > > > On Fri, Mar 6, 2020 at 2:33 PM Tomasz Urbaszek 
> > > wrote:
> > > >
> > > > > +1 for ALC website! We can have separate sections/tabs for each ALC
> > > > > but the whole content like blogs / events can be shared and tagged.
> > > > >
> > > > > T.
> > > > >
> > > > >
> > > > > On Fri, Mar 6, 2020 at 1:27 PM Swapnil M Mane  > > >
> > > > > wrote:
> > > > > >
> > > > > > Hi Willem,
> > > > > >
> > > > > > On Fri, Mar 6, 2020 at 2:29 PM Willem Jiang 
> > > > > wrote:
> > > > > > >
> > > > > > > Hi Swapnil
> > > > > > >
> > > > > > > For the ALC Beijing website, we just want to put some Chinese
> > > pages to
> > > > > > > introduce ASF and ALC.
> > > > > > > Thanks for the inputs. I agree we will have bunch of ALC Chapters,
> > > it
> > > > > > > could be a nightmare for management if each Chapter has it's own
> > > > > > > website.
> > > > > > > How about we just put our effort on ALC website?
> > > > > > > It could be great that  ALC Chapters to contribute all the
> > > contents to
> > > > > > > ALC website, we could have a blog section to host these freestyle
> > > > > > > articles, and we can also a directory on the website to the ALC
> > > > > > > Chapters event there.
> > > > > >
> > > > > > This seems a great and cleaner approach to me.
> > > > > > Let's wait for inputs from other members.
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Cheers,
> > > > > > >
> > > > > > > Willem Jiang
> > > > > > >
> > > > > > > Twitter: willemjiang
> > > > > > > Weibo: 姜宁willem
> > > > > > >
> > > > > > > On Fri, Mar 6, 2020 at 2:40 PM Swapnil M Mane <
> > > swapnilmm...@apache.org>
> > > > > wrote:
> > > > > > > >
> > > > > > > > Thanks Willem for the proposal and details.
> > > > > > > > Below are my inputs on the ALC Website (#1) and ALC Chapter
> > > specific
> > > > > > > > website (#2).
> > > > > > > >
> > > > > > > > #1.)
> > > > > > > > +1 to have ALC Website.
> > > > > > > > As ALC is ComDev initiative, we can have the ALC website at
> > > > > > > > https://community.apache.org/alc
> > > > > > > > like Solr project have its website under Lucene domain
> > > > > > > > https://lucene.apache.org/solr/
> > > > > > > > We have complete content available on https://s.apache.org/alc,
> > > we
> > > > > can
> > > > > > > > use it to prepare the ALC website.
> > > > > > > >
> > > > > > > > #2.)
> > > > > > > > I am not sure about having ALC Chapter specific website because
> > > we
> > > > > may
> > > > > > > > have many ALCs in the future.
> > > > > > > > Still, we need to figure out how the ALC Chapter specific
> > > content can
> > > > > > > > be managed, should we have a section for each ALC Chapters on 
> > > > > > > > the
> > > > > main
> > > > > > > > ALC website, this was just input, not proposing anything.
> > > > > > > > Maybe ComDev experts here can help us and share their inputs.
> > > > > > > >
> > > > > > > > Best regards,
> > > > > > > > Swapnil M Mane,
> > > > > > > > www.apache.org
> > > > > > > >
> > > > > > > >
> > > > > > > > On Fri, Mar 6, 2020 at 5:16 AM Willem Jiang <
> > > willem.ji...@gmail.com>
> > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > > As you know, it's not a good time to host the f2f meetup due
> > > to the
> > > > > > > > > COVID-19. So we are think about write some articles and host 
> > > > > > > > > an
> > > > > online
> > > > > > > > > meetup to grow the local community.
> > > > > > > >

Re: Setting Project's language

[sebb]

On Tue, 10 Mar 2020 at 09:36, Jarek Potiuk  wrote:
>
> I've just looked at http://projects.apache.org/ and notices that Apache
> Airlfow is not marked as Python project (and it is almost 100% python) .
> It's missing from the list here:
> https://projects.apache.org/projects.html?language#Python
>
> How do I change that :)?

Create the project DOAP and add it to projects.xml

https://projects.apache.org/about.html

> J.

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

Re: Data inconsistency in projects.apache.org

[sebb]

On Fri, 27 Mar 2020 at 13:44, Rich Bowen  wrote:
>
> I'm trying to understand the twisty maze of data sources that fuel
> projects.apache.org and either I'm confused, or there's some
> inconsistency in how this all fits together.
>
> I'll start with just one data source for now, so that I don't muddle
> multiple things together.
>
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/committees.xml
>
>
> This file has a list of rdf files which are supposed to be in the
> committees/ subdirectory. The file itself says:
>
> This list should agree with the files in the directory committees/
>
> However, in addition to the entries that look like:
>
>committees/any23.rdf
>
> there are also lines that look like:
>
>http://flex.apache.org/pmc_Flex.rdf
>
> (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez)
>
> Is that correct? Or is that not how the data is supposed to be stored?

Most PMC RDF files are stored locally, but the app does allow for
projects to store the files elsewhere.

> Meanwhile, committees.xml contains 209 projects:
>
> grep location committees.xml| grep -vc Retired
> 209
>
> while the committees/ directory contains just 206 rdf files:
>
> ls committees/*.rdf| wc -l
> 206
> (Note, one of those files is _template.rdf, so it's really 205, and 205
> + 4 = 209, so at least everything else matches up.)

Some PMCs have multiple projects.

There is a cron job that reports an error if there is a new PMC
without a corresponding RDF file.
I tend to create the the PMC RDF to silence the error.
However, it is up to the PMC to create the DOAP(s), so it's possible
that a PMC has no DOAPs.

I suspect that the PMC RDF files could be eliminated - I think the
only useful info they contain is the charter.
The charter is now also maintained in:
https://svn.apache.org/repos/private/committers/board/committee-info.yaml

If any changes are made, I strongly recommend centralising the data files.
DOAP files maintained in project data areas often get moved, and the
project forgets to update the entry in projects.xml
Also, sometimes edits to DOAP files have syntax errors.
My experience is that it can be very hard work getting projects to fix
errors, whereas if DOAPs were centrally located, anyone could fix
errors.

>
>
> --
> Rich Bowen - rbo...@rcbowen.com
> http://rcbowen.com/
> @rbowen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Data inconsistency in projects.apache.org

[sebb]

On Fri, 27 Mar 2020 at 18:04, Rich Bowen  wrote:
>
>
>
> On 3/27/20 1:13 PM, sebb wrote:
> > On Fri, 27 Mar 2020 at 13:44, Rich Bowen  wrote:
> >> there are also lines that look like:
> >>
> >> http://flex.apache.org/pmc_Flex.rdf
> >>
> >> (4 of them, for whatever that's worth - flex, ofbiz, plc4x, and tez)
> >>
> >> Is that correct? Or is that not how the data is supposed to be stored?
> >
> > Most PMC RDF files are stored locally, but the app does allow for
> > projects to store the files elsewhere.
>
> Awesome. So it's just an "error" in the comment in the file, not in the
> way things are done. Thanks. That helps.
>
> > If any changes are made, I strongly recommend centralising the data files.
> > DOAP files maintained in project data areas often get moved, and the
> > project forgets to update the entry in projects.xml
> > Also, sometimes edits to DOAP files have syntax errors.
> > My experience is that it can be very hard work getting projects to fix
> > errors, whereas if DOAPs were centrally located, anyone could fix
> > errors.
>
> So, while to me that seems like an obvious and enormous improvement, my
> understanding is that this was proposed before and someone (I understood
> it was you?) vetoed the change. So I'm a teensy bit confused.

Not me.
I have always been in favour of centralising the files.

> --
> Rich Bowen - rbo...@rcbowen.com
> http://rcbowen.com/
> @rbowen
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Data inconsistency in projects.apache.org

[sebb]

On Fri, 27 Mar 2020 at 20:01, Hervé BOUTEMY  wrote:
>
> Le vendredi 27 mars 2020 20:29:14 CET, vous avez écrit :
> > On 3/27/20 3:07 PM, Hervé BOUTEMY wrote:
> > > It's good to see some interest back on DOAP files content ad organisation,
> > > now that the projects.apache.org rendering makes them really useful: a
> > > few years ago, trying to open any discussion on that was deemed to
> > > failure. But any change is hard, since every PMC will have to be
> > > involved.
> >
> > What if we - and I'm perfectly prepared to be told "You can't do that
> > because ..." - fetched remote (ie, project-hosted) doap files, a few at
> > a time, and move them to the central repo, and as we do that, we go talk
> > to projects individually, telling them that we're doing it, and why, and
> > what the new process is for updating. Yes, I'm volunteering to do that
> > outreach.
> you can, but I don't see the benefit of this hard work
>
> >
> > That way, over time, we'd eventually have all of those files in one
> > place, making them easier to find and update.
> find = 2 files (1 for committees, 1 for projects)

May be more than one for projects.
e.g. Commons.

> >
> > I'm leaving the file format question for someone else entirely. I am far
> > less concerned about that, than about ensuring that the files are easily
> > found and updated.
> my point about "PMC RDF files" vs "projects DOAP files" is not a question of 
> format, but a question of amount of data and who would have real knowledge to 
> update content:
> - PMC RDF files are very light, rarely updated, and contain data that are 
> really foundation-centric
> - projects DOAP files contain a lot more data, can/should be often updated, 
> with data that are really to be delegated to PMCs given they are more 
> technical details on code
>
> That's why I really think keeping centralised PMC RDF files and decentralised 
> projects DOAP files is a good idea.
>
> IMHO, centralising project DOAP files would be a hard task with low benefit, 
> and even counter productive effect on having every PMC responsible for the 
> content, that is technical.
>
> On letting PMC RDF files go outside the centralised approach, I'd be curious 
> to check if the 4 PMCs that chose to host outside of projects.a.o did that to 
> fill more data, or if they just felt that they'd host this file the same way 
> they did with project DOAP file.

I suggest dropping them entirely.

> Regards,
>
> Hervé
>
> >
> > --Rich
>
>
>
>
>
> -
> 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: Triage role on Github

[sebb]

On Sat, 22 Aug 2020 at 14:32, Rob Tompkins  wrote:
>
>
>
> > On Aug 20, 2020, at 9:34 AM, Rob Tompkins  wrote:
> >
> >
> >
> >> On Aug 20, 2020, at 7:06 AM, Mark Thomas  wrote:
> >>
> >> If you mean "grant the triage role to anyone with a GitHub account" then 
> >> +1.
> >
> > +1 as well here. Or anyone that minimally shows any interest. We should 
> > proactively ask people that are contributing if they would like such status.
>
> To slow the number of “triage” users and stem spamming, might we necessitate 
> only a CLA being signed as a barrier to entry? That way people have to do 
> something to get the status, but still anyone can sign a CLA.

That could be a lot of work for the Secretarial team.
I don't think a CLA is necessary here.

If there is to be some barrier to entry, it needs to be managed at
project level to spread the workload.

> -Rob
>
> >
> > -Rob
> >
> >>
> >> If you mean create a new level between contributor (i.e. anyone) and
> >> committer then -1.
> >>
> >> If you go back (quite a few years) to when Bugzilla was the main issue
> >> tracker for ASF projects it was (and still is for those projects that
> >> use it - httpd, Tomcat etc) configured so that any user with an account
> >> could open, edit, label, close etc any bug.
> >>
> >> Over time many projects seem to have adopted a more restrictive approach
> >> to issue management. I think that is partly due to the tools being used
> >> being more restrictive by default and partly due to a more corporate
> >> mindset prevailing in some projects that prefers technical barriers to
> >> social barriers.
> >>
> >> I am strongly of the view that social barriers are better for
> >> communities than technical barriers. A lot of my early contributions to
> >> Tomcat were around triaging open issues. I could only do that because
> >> access to BZ issues was managed via social controls rather than
> >> technical ones.
> >>
> >> Experience with BZ suggests that opening up the Github triage role to
> >> all will attract a few idiots from time to time but they can easily be
> >> banned and the benefits of attracting new contributors far outweigh the
> >> costs of idiot management.
> >>
> >> Mark
> >>
> >>
> >> On 20/08/2020 10:20, Paul Angus wrote:
> >>> Hi Members,
> >>>
> >>> One of our (CloudStack) comitters has come with a great idea to increase
> >>> project contributions...
> >>>
> >>> Traditionally Github has been very binary, you're either a commiter and 
> >>> you
> >>> can write to a Repo and perform Issue and Pull Request admin (like add
> >>> labels, change status, etc), or you aren't a comitter and 'sucks to be 
> >>> you'.
> >>>
> >>> Githib has introduced a 'Triage' role which bridges the gap.  The Triage
> >>> role, allows issue and pull request admin, but still blocks writing to the
> >>> actual code. [1]
> >>>
> >>> I guess we'd need a mechanism to control/add contributors to the Triage
> >>> team per project, kinda like Karma for Confluence.
> >>>
> >>> I think that would be a great stepping stone for contributors to get more
> >>> involved in projects, so I'd like to gather support from other projects 
> >>> and
> >>> the ASF 'elders' for the principle.
> >>>
> >>> Many thanks
> >>>
> >>> Paul Angus
> >>>
> >>> [1]
> >>> https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization
> >>>
> >>
> >>
> >> -
> >> 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

Unclear/ambiguous statement in Maturity Model - RE30

[sebb]

What does "and/or" in RE30 really mean?
Is it intentional?

-
RE30
Releases are signed and/or distributed along with digests that can be
reliably used to validate the downloaded archives.
-

Expanding the and/or, I read this two ways:

1) Releases are signed and distributed along with digests that can be
reliably used to validate the downloaded archives.

2) Releases are signed or distributed along with digests that can be
reliably used to validate the downloaded archives.

Statement 1 seems clear to me.

Statement 2 appears to imply that releases don't have to be signed --
if it means anything.

Sebb.

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

Re: FOAF sync towards "Nearby Apache People"

[sebb]

On Fri, 16 Apr 2021 at 18:43, Nick Burch  wrote:
>
> On Fri, 16 Apr 2021, Richard Zowalla wrote:
> > is the sync for https://community.zones.apache.org/map.html offline?
> > I added a FOAF file to SVN a few days ago (according to [1]) but the
> > content seems to be static. In addition, it seems, that the google map
> > requires verification.
>
> I think that service has effectively died due to a lack of interest. There
> had been talk of providing an easier way to maintain and share the info
> than editing DOAP + FOAF files (which seems to be too high a barrier to
> gain widespread participation), but volunteer energy ran out before
> anything was ever developed...
>
> If you are interested in the service, the ASF infra team would love
> someone to help get the code onto a new box, properly defined and
> automated, before it finally dies! The code and docs are at
> https://svn.apache.org/repos/asf/comdev/nearby_people .
>
> Equally if you have ideas on better ways to let people list and de-list
> themselves, to present the data etc, new volunteers are needed! :)

This is intrinsically PII data, so there probably ought to be checks
to ensure that the person providing the data fully understands how it
is going to be used and published.

We should warn people that whilst (I assume) they can remove data from
our public servers, it will likely live on in 3rd party archives.

Also it likely won't be possible to eliminate all copies from ASF
repositories, depending on how the data is stored and backed up.

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

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

Re: ASF and Healthcare initiative

[sebb]

How about using the Wiki for collecting the information?

Easier to set up and easy to maintain.

If the content eventually outgrows the wiki it could be moved later
(with redirects added).

On Fri, 30 Apr 2021 at 06:22, Javi Roman  wrote:
>
> Probably cTakes PMC could be interesting in requesting the resources to
> INFRA:
>
> 1. health.apache.org
> 2. hea...@apache.org
>
> So this PMC may be the clear owner (I would like to do it by myself, but
> unfortunately I'm a PPMC of Incubator retired project).
>
> --
> Javi Roman
>
> On Thu, Apr 29, 2021 at 3:42 PM Bertrand Delacretaz 
> wrote:
>
> > Hi,
> >
> > On Thu, Apr 29, 2021 at 3:24 PM Rich Bowen  wrote:
> > > ...I would encourage you to
> > > talk with Infra, next, regarding the hostname, email address, and a VM
> > > to run a site on. I expect that if you have a few PMC members backing
> > > it, and don't expect Infra to provide you any services...
> >
> > From an oversight point of view I think it's good for an existing PMC
> > to "own" a new website that might be created at health.apache.org. It
> > can be any of the interested PMCs and to me the goal is just to make
> > sure that website has a clear owner at the Foundation level.
> >
> > So the simplest is probably for one of those PMCs to request creation
> > of the new website, with the understanding that they will welcome
> > contributions from other PMCs.
> >
> > -Bertrand
> >

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

Re: ASF and Healthcare initiative

[sebb]

On Sat, 1 May 2021 at 08:40, Javi Roman  wrote:
>
> Sebb, that's a good idea, the wiki space could be a beginning.
>
> I'm going to request (INFRA) a Wiki space for this initiative:
> https://cwiki.apache.org/confluence/display/HEALTH/Home
>
> and a mailing list for discussing:
> hea...@apache.org
>
> Please let me know if I have your support to request these resources from
> INFRA (linking the JIRA tickets to this conversation).

I suggest these resources are requested under the community.a.o project.

We should not be asking for more top-level resources unless absolutely
necessary.

Existing TLPs such as community can use https://selfserve.apache.org/
to create mailing lists and Confluence spaces without involving Infra,
who are already very busy.

> --
> Javi Roman
>
> Twitter: @javiromanrh
> GitHub: github.com/javiroman
> Linkedin: es.linkedin.com/in/javiroman
> Big Data Blog: dataintensive.info
>
>
> On Fri, Apr 30, 2021 at 11:44 AM sebb  wrote:
>
> > How about using the Wiki for collecting the information?
> >
> > Easier to set up and easy to maintain.
> >
> > If the content eventually outgrows the wiki it could be moved later
> > (with redirects added).
> >
> > On Fri, 30 Apr 2021 at 06:22, Javi Roman  wrote:
> > >
> > > Probably cTakes PMC could be interesting in requesting the resources to
> > > INFRA:
> > >
> > > 1. health.apache.org
> > > 2. hea...@apache.org
> > >
> > > So this PMC may be the clear owner (I would like to do it by myself, but
> > > unfortunately I'm a PPMC of Incubator retired project).
> > >
> > > --
> > > Javi Roman
> > >
> > > On Thu, Apr 29, 2021 at 3:42 PM Bertrand Delacretaz <
> > bdelacre...@apache.org>
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Thu, Apr 29, 2021 at 3:24 PM Rich Bowen  wrote:
> > > > > ...I would encourage you to
> > > > > talk with Infra, next, regarding the hostname, email address, and a
> > VM
> > > > > to run a site on. I expect that if you have a few PMC members backing
> > > > > it, and don't expect Infra to provide you any services...
> > > >
> > > > From an oversight point of view I think it's good for an existing PMC
> > > > to "own" a new website that might be created at health.apache.org. It
> > > > can be any of the interested PMCs and to me the goal is just to make
> > > > sure that website has a clear owner at the Foundation level.
> > > >
> > > > So the simplest is probably for one of those PMCs to request creation
> > > > of the new website, with the understanding that they will welcome
> > > > contributions from other PMCs.
> > > >
> > > > -Bertrand
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >

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

Re: ASF and Healthcare initiative

[sebb]

On Mon, 3 May 2021 at 13:15, Rich Bowen  wrote:
>
> Fwiw I think creating content in a wiki and then having to move and
> reformat and redirect that content seems like an unnecessary duplication of
> work. I'm unclear why you'd want to do this work twice.
>
> On Sat, May 1, 2021, 08:31 sebb  wrote:
>
> >
> > I suggest these resources are requested under the community.a.o project.
> >
>
>
> What? Why? That's not where anyone is going to look for this.

Because it is a community matter.

> >
> > We should not be asking for more top-level resources unless absolutely
> > necessary.
> >
>
>
> Whyever not? They don't cost any more.

Huh? Of course they cost - in time at least.
They also require DNS and name resources.

>
> > Existing TLPs such as community can use https://selfserve.apache.org/
> > to create mailing lists and Confluence spaces without involving Infra,
> > who are already very busy.
> >

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

Re: Comdev web pages for our communities of interests?

[sebb]

On Tue, 4 May 2021 at 08:46, Bertrand Delacretaz  wrote:
>
> Hi,
>
> Recent discussions around a website for our projects which are in the
> healthcare "space" make me think that it would be useful to provide a
> space for such "project groups" which share common goals.
>
> How about providing web pages, under the oversight of the Comdev PMC,
> for such things?
>
> We could have community.apache.org/c/healthcare,
> community.apache.org/c/osgi, community.apache.org/c/buildtools, etc.,
> reserving community.apache.org/c as the root for that (as in
> "communities").
>
> Our website is very easy to manage, see
> https://github.com/apache/comdev-site, it should be easy for
> interested people to provide pull requests for those pages.
>
> The advantage compared to individual websites such as
> healthcare.apache.org (as discussed in another thread here) is that
> it's very easy to create a new page under community.apache.org/c and
> the Comdev PMC stays in charge in case such pages become stale or
> orphaned over time.
>
> These communities can then request other resources such as mailing
> lists if desired, using https://selfserve.apache.org/ in most cases,
> those pages are only meant to be used as homepages, with a description
> of the corresponding community and links to the interested projects
> and other places of interest.
>
> What do people think?

+1

This is probably better than using the Wiki, and just as easy to
manage using GitHub.
It likewise means Infra don't need to do any work, and no extra
top-level resources are used.

> -Bertrand
>
> -
> 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: Update to ICLA to include github id

[sebb]

Note that LDAP currently allows for multiple githubUsername entries,
as does Whimsy.

There are over 60 people with more than 1 entry listed.

On Sun, 9 May 2021 at 05:16, Justin Mclean  wrote:
>
> https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/merging-multiple-user-accounts
>
> On Sun, 9 May 2021, 2:10 pm Roman Shaposhnik,  wrote:
>
> > On Sat, May 8, 2021 at 7:21 PM Craig Russell  wrote:
> > >
> > > Hi Roman,
> > >
> > > I understand that GitHub now recommends (not enforced) that people use a
> > single
> > > GitHub id for all of their interactions on the service, and to
> > specifically delete all
> > > accounts except for the one account. They can then merge the deleted
> > accounts
> > > to their one account.
> >
> > Where is this coming from? Do you have a URL? I'm simply asking because it
> > goes
> > directly against most employer's recommendations that I know of.
> >
> > > [So this is different from Google mail accounts, which Google encourages
> > folks to have multiple accounts for different purposes.]
> > >
> > > If people have multiple GitHub accounts, the one on the ICLA would be
> > the one that they plan to have associated with their Apache id in future.
> > >
> > > Apache will only allow an Apache id to be associated with one GitHub id
> > so I think we are ok there. Happy to have operations verify this.
> >
> > There's a LOT of things to unpack here, but I'm still not sure what
> > problem are we trying to solve.
> >
> > 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: Please redirect automated GitBox emails to different list

[sebb]

Does it really make sense to use the same list for development
discussions amongst the ComDev community, and discussions with the
general public?

At present this single list is acting as both developer and user list.
[Many projects would also have commits, issues and notifications lists]

It may not be an issue for the ComDev community to disentangle the
emails, but it must be confusing for the general public trying to find
answers to their questions on how the ASF works.

It also means that the mail archives are less useful for people trying
to see how the ASF community works rather than how ComDev itself
functions.

It has always seemed strange to me that discussions on ComDev tools
are mixed in with questions from someone on how to get started with
the ASF.

Sebb.
On Tue, 6 Jul 2021 at 22:01, Brian Thompson  wrote:
>
> On Tue, Jul 06, 2021 at 01:16:19PM -0400, 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...)
>
> Wow, this is a first for me, too.  Glad to see some fellow Truman grads
> in technology.
>
> >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...)
>
> That is true.  I guess I am just used to having more mailing lists
> (I am mostly active on the Debian mailing lists) to choose from so that
> the mailing lists themselves act as filters.
>
> It's not a big deal to me either way; having a new mailing list or
> keeping it consolidated.  Whatever the community decides I will go along
> with.  It's not a battle I will choose to fight.
>
> --
> Best regards,
>
> Brian T
> B.S. Computer Science 2014 (Truman State University)
>   Minor Stasitics
>   Minor Chemistry
>   Minor Mathematics

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

Re: New committer invitation template proposal

[sebb]

On Tue, 20 Jul 2021 at 03:08, Craig Russell  wrote:
>
> Hi,
>
> I would like to suggest how we can improve the new committer onboarding  
> process by changing the standard committer invitation email. This is after 
> the new committer has been voted on and if PMC membership is offered, after 
> the board has been notified with 72 hour notice.
>
> This will eventually become a patch to
> https://github.com/apache/comdev-site/blob/master/source/newcommitter.md
>
> The big change is that the committer is asked to tell the PMC if they are 
> already a committer or if they have already submitted an ICLA. This should 
> reduce the back-n-forth among PMC-committer-secretary-root.
>
> Please let me know what you think. If this seems like a good idea, we can ask 
> PMCs to update their onboarding processes.
>
> Craig
>
> ### Committer Invite Template
> This is the suggested invitation email to send to the newly elected committer,
> sent after a positive result from the PMC vote for a new committer.
>
> 
> To: joeblo...@foo.net
> Cc: private@[PROJECT].apache.org
> Subject: Invitation to become [PROJECT] committer: Joe Bloggs
>
> Hello [invitee name],
>
> The [Project] Project Management Committee] (PMC)
> hereby offers you committer privileges to the project
> [as well as membership in the PMC]. These privileges are
> offered on the understanding that you'll use them
> reasonably and with common sense. We like to work on trust
> rather than unnecessary constraints.
>
> Being a committer enables you to more easily make
> changes without needing to go through the patch
> submission process. [Being a PMC member enables you
> to guide the direction of the project.]

A PMC member involves a lot more than just guiding the direction of the project.

The prospective member needs to be told what is expected of PMC
members so they can make
an informed decision.

> Being a committer does not require you to
> participate any more than you already do. It does
> tend to make one even more committed.  You will
> probably find that you spend more time here.

Being a PMC member DOES require additional participation ...

> Of course, you can decline and instead remain as a
> contributor, participating as you do now.
>
> A. This personal invitation is a chance for you to
> accept or decline in private.  Either way, please
> let us know in reply only to the [priv...@project.apache.org]

"in reply only" does not read well.

> address.
>
> B. If you accept, the next step is to get an Apache id:
> • If you are already a committer on another project, reply to this 
> message and let us know your Apache id and we will set you up with commit 
> privileges [and put you on the PMC roster].

"let us know" - who is "us" ?

> • If you have earlier submitted an ICLA, reply to this message and 
> let us know the Public name under which you submitted your ICLA. We will then 
> request your account. If the email address you entered on the ICLA is no 
> longer appropriate, submit a new ICLA with the new email address. See the 
> next bullet for details.

The Public Name is not necessarily unique. It would be better to ask
for the email address.

> • If you have not yet submitted an ICLA, reply to this message 
> indicating your acceptance and plans to submit your ICLA.
>
> Then, forward this message to secret...@apache.org and attach your ICLA 
> document. Do not cc: the project, as this unnecessarily exposes your 
> Personally Identifiable Information.
> This will allow the Secretary to easily verify that you have been invited to 
> become a committer. Be sure to put your requested Apache id and the project 
> name on the ICLA form. This will allow the Secretary to request your account 
> and notify the project directly. Within a few days you will receive 
> instructions for logging in and changing your password.
>
> Details of the iCLA and instructions for submitting the forms are found here: 
> https://www.apache.org/licenses/#clas
> https://www.apache.org/licenses/contributor-agreements.html#submitting
>
> C. When creation of your account is noted, you will receive a follow-up 
> message with next steps.
>
>
> Craig L Russell
> c...@apache.org
>

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

community website fails branding checks

[sebb]

The community website currently fails most branding checks:

https://github.com/apache/comdev-site

Sebb

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

Re: community website fails branding checks

[sebb]

On Mon, 13 Sept 2021 at 14:45, Bertrand Delacretaz
 wrote:
>
> Hi Sebb,
>
> On Sat, Sep 11, 2021 at 3:40 PM sebb  wrote:
> > The community website currently fails most branding checks:
> > https://github.com/apache/comdev-site ..
>
> you mean these tests, right?
> https://whimsy.apache.org/site/project/comdev

Sorry, yes.

> -Bertrand
>
> -
> 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: Proposal to add "release requirements" check

[sebb]

AFAICT there is only one case to handle.

The reporter tool lists recent releases.
Each such release must have an associated download page.

Whether there are multiple download pages or a shared one does not
matter in this context.

On Sun, 7 Nov 2021 at 20:20, Jarek Potiuk  wrote:
>
> Yep. Those are all valid concerns and I will look into how we could
> handle those complexities. Hopefully there will be only a handful of
> various cases :D
>
> On Sun, Nov 7, 2021 at 9:17 PM Craig Russell  wrote:
> >
> > Hi Jarek,
> >
> > I think that updating the reporter tool to check for a conformant 
> > download(s) page is a great idea. I encourage you to see how to incorporate 
> > that check into the tool.
> >
> > I agree with you that sending out mass mailings is probably not going to 
> > result in changes in behavior. Only targeted messages are likely to work.
> >
> > One challenge will be to handle projects with multiple "independent" 
> > sub-projects like db that has jdo and derby with not much in common. They 
> > have completely independent web sites. So the tool will have to be told 
> > about all of the projects. The tool also needs to handle projects like 
> > Airflow which IIUC has multiple sub-projects that share a few common 
> > download pages and scripts.
> >
> > Warm regards,
> > Craig
> >
> > > On Nov 4, 2021, at 5:57 AM, Jarek Potiuk  wrote:
> > >
> > > Hello Everyone @devcom,
> > >
> > > I am following up after the discussion  at users@infra.a.o:
> > > https://lists.apache.org/thread/skswflvf0q8lbgkmxo18v19s62hkqf3j. This is
> > > not a public mailing list and maybe not everyone here is subscribed so let
> > > me summarise the context and the proposal. BTW. That's my view on the 
> > > state
> > > of the discussion we had and conclusions/proposals I drew from that.
> > >
> > > Context:
> > >
> > > We seem to have some of the projects that do not follow all the important
> > > requirements when it comes to publishing GA releases for their projects.
> > > The requirements are pretty firm and documented here:
> > > https://www.apache.org/legal/release-policy.html#host-GA and in the
> > > following paragraphs. They boil down to :
> > >
> > > a) have an installation page where you can verify releases with:
> > > * signatures and checksums (links to those should be directly do
> > > downloads.apache.org
> > > * packages - links to those should use closer.lua scripts (which are then
> > > automatically mapped to CDN currently - previously to mirroring sites)
> > >
> > > b) Have they releases archived appropriately (i.e. only last version from
> > > the development "branch"  should remain in downloads@a.o
> > >
> > > Proposal:
> > >
> > > I think the best way to get this solved permanently (rather than sending
> > > reminder emails to everyone) is to add a check in the reporter tool (
> > > https://reporter.apache.org/about.html) to verify those two aspects, so
> > > that they could be verified by projects themselves and the board  - seems
> > > that this is a very important aspect that ASF is very concerned about, so
> > > making it part of the board review makes sense and gives the opportunity 
> > > of
> > > individual flagging when the project does not follow it, It has happened
> > > with our project - Airflow at the last board review, and we fixed all 
> > > that,
> > > but the idea is that the ASF has an easy to use tool that will add such
> > > checks and flags
> > >
> > > Point b) is quite easy it seems. Airflow already has simple Python script
> > > that does that can be adjusted or rewritten to handle multiple "lines" of
> > > development (with some per-project specifics likely) :
> > > https://github.com/apache/airflow/blob/main/dev/provider_packages/remove_old_releases.py.
> > > It can also be used to actually help with clean-up (we use it for that
> > > purpose as we have ~40/50 packages to release every month).
> > >
> > > Point  a) also should not be difficult as long as each project will submit
> > > their installation page links, we can scrape them and see if the pages
> > > contain signature/ascii direct links and closer.lua links for packages.
> > >
> > > Do you think it is a good idea? I just wanted to run it by the community 
> > > to
> > > see what you think of it, whether you see any potential
> > > problems/limitations/concerns?
> > >
> > > Just one request please - without yet getting into technical details and
> > > discussing HOWs. We will have time for that.
> > >
> > > If there is a community (and board :) buy-in, I am happy to
> > > implement/lead/introduce it. It would dramatically help if others -
> > > especially people from various projects that might have some special cases
> > > - could help with testing/piloting it.
> > >
> > > J.
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@com

Re: Proposal to add "release requirements" check

[sebb]

On Sun, 7 Nov 2021 at 21:21, Jarek Potiuk  wrote:
>
> I (and Craig I guess) were discussing the  whole solution - which also
> includes cleaning download artifacts.

Purging old releases needs at least two data sources:
- the list of files on downloads.apache.org (or the dist.a.o source).
This is trivial to obtain.
- the list of current versions for each release. This is the most
difficult part.

Not only does it vary between PMCs, there are different release
strategies for different products.
For example Commons DBCP has multiple releases for different versions
of JDBC, whereas most other Commons components have one active
release.

Furthermore, the number of active releases for a product may change
from time to time.

Also products sometimes get retired.

I think you are going to need more than just a download page link to
enable accurate reporting of unpurged releases.

By the way, how are you going to let people know about the changes to
the reporter tool?

> J.
>
> On Sun, Nov 7, 2021 at 9:32 PM sebb  wrote:
> >
> > AFAICT there is only one case to handle.
> >
> > The reporter tool lists recent releases.
> > Each such release must have an associated download page.
> >
> > Whether there are multiple download pages or a shared one does not
> > matter in this context.
> >
> > On Sun, 7 Nov 2021 at 20:20, Jarek Potiuk  wrote:
> > >
> > > Yep. Those are all valid concerns and I will look into how we could
> > > handle those complexities. Hopefully there will be only a handful of
> > > various cases :D
> > >
> > > On Sun, Nov 7, 2021 at 9:17 PM Craig Russell  wrote:
> > > >
> > > > Hi Jarek,
> > > >
> > > > I think that updating the reporter tool to check for a conformant 
> > > > download(s) page is a great idea. I encourage you to see how to 
> > > > incorporate that check into the tool.
> > > >
> > > > I agree with you that sending out mass mailings is probably not going 
> > > > to result in changes in behavior. Only targeted messages are likely to 
> > > > work.
> > > >
> > > > One challenge will be to handle projects with multiple "independent" 
> > > > sub-projects like db that has jdo and derby with not much in common. 
> > > > They have completely independent web sites. So the tool will have to be 
> > > > told about all of the projects. The tool also needs to handle projects 
> > > > like Airflow which IIUC has multiple sub-projects that share a few 
> > > > common download pages and scripts.
> > > >
> > > > Warm regards,
> > > > Craig
> > > >
> > > > > On Nov 4, 2021, at 5:57 AM, Jarek Potiuk  wrote:
> > > > >
> > > > > Hello Everyone @devcom,
> > > > >
> > > > > I am following up after the discussion  at users@infra.a.o:
> > > > > https://lists.apache.org/thread/skswflvf0q8lbgkmxo18v19s62hkqf3j. 
> > > > > This is
> > > > > not a public mailing list and maybe not everyone here is subscribed 
> > > > > so let
> > > > > me summarise the context and the proposal. BTW. That's my view on the 
> > > > > state
> > > > > of the discussion we had and conclusions/proposals I drew from that.
> > > > >
> > > > > Context:
> > > > >
> > > > > We seem to have some of the projects that do not follow all the 
> > > > > important
> > > > > requirements when it comes to publishing GA releases for their 
> > > > > projects.
> > > > > The requirements are pretty firm and documented here:
> > > > > https://www.apache.org/legal/release-policy.html#host-GA and in the
> > > > > following paragraphs. They boil down to :
> > > > >
> > > > > a) have an installation page where you can verify releases with:
> > > > > * signatures and checksums (links to those should be directly do
> > > > > downloads.apache.org
> > > > > * packages - links to those should use closer.lua scripts (which are 
> > > > > then
> > > > > automatically mapped to CDN currently - previously to mirroring sites)
> > > > >
> > > > > b) Have they releases archived appropriately (i.e. only last version 
> > > > > from
> > > > > the development "branch"  should remain in downloads@a.o
> > > > >
> > > > > Proposal:
> > > > 

Re: Proposal to add "release requirements" check

[sebb]

On Mon, 8 Nov 2021 at 00:49, Justin Mclean  wrote:
>
> Hi,
>
> > Purging old releases needs at least two data sources:
> > - the list of files on downloads.apache.org  
> > (or the dist.a.o source).
> > This is trivial to obtain.
> > - the list of current versions for each release. This is the most
> > difficult part.
>
> The check dist area script I wrote attempts to do this. [1] It get the list 
> of released version from the download page and matches them up with what is 
> in the dist area.

However that assumes that you know where to find the download page(s).
It also assumes that projects update their download page(s) to only
show current releases.

Once you have that information, the rest is relatively easy (unless
the download page uses Javascript)

> To be complete you also need to look in the archives (which I’ve not done 
> yet).  It does have some of the issues you mention but it’s a start and 
> worked for abut 90% of Incubating projects. having something that works for 
> project project is probably a good start and it can be refined from there.
>
> Kind Regards,
> Justin
>
> 1. https://github.com/justinmclean/ReleaseChecker/blob/main/checkdistarea.py

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

Re: Proposal to add "release requirements" check

[sebb]

On Mon, 8 Nov 2021 at 11:19, Justin Mclean  wrote:
>
> Hi,
>
> > However that assumes that you know where to find the download page(s).
> > It also assumes that projects update their download page(s) to only
> > show current releases.
>
> It does indeed assume that, and a few other things. Currently policy doesn't 
> specify what the download page URL should be, but once known I would guess it 
> wouldn’t change often.

If only.

Several projects use a different URL for each release. For example
https://daffodil.apache.org/releases/
https://db.apache.org/derby/derby_downloads.html
https://guacamole.apache.org/releases/

Some projects use different pages for source and binaries, e.g.
https://ant.apache.org/bindownload.cgi

> Kind Regards,
> Justin
>
>
>
> -
> 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: Proposal to add "release requirements" check

[sebb]

On Mon, 8 Nov 2021 at 11:29, Hans Van Akelyen
 wrote:
>
> Hi,
>
> I think a certain level of uniformity would not be bad for this.
> Having a fixed path to the downloads for each project makes it simpler for
> the users to "shop" for Apache projects.
>
> Having .a.o/download/ as a link that should point to the resources
> makes it simpler for everyone.

I agree, but expect a lot of complaints if you try to get this enforced.
(and there's not much point unless it is enforced).

> Kind Regards,
> Hans
>
> On Mon, 8 Nov 2021 at 12:19, Justin Mclean  wrote:
>
> > Hi,
> >
> > > However that assumes that you know where to find the download page(s).
> > > It also assumes that projects update their download page(s) to only
> > > show current releases.
> >
> > It does indeed assume that, and a few other things. Currently policy
> > doesn't specify what the download page URL should be, but once known I
> > would guess it wouldn’t change often.
> >
> > Kind Regards,
> > Justin
> >
> >
> >
> > -
> > 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: Proposal to add "release requirements" check

[sebb]

On Mon, 8 Nov 2021 at 17:11, Jarek Potiuk  wrote:
>
> Yeah. We will have different URLs especially as more artifacts are
> produced (airflow has 3 of those each with different download pages).
>
> But this should be straightforward when you can add the url when
> registering the release (as Sebb proposed). According to the release
> process you should register each such "release type" separately and
> adding a URL there will do the job nicely. And initially it can be
> optional and once we figure out how to communicate it best and maybe
> try with some projects first we can make it obligatory at release
> registration. We could make it convenient - for example an easy way to
> copy a previously added URL from selected previous release or
> autocomplete from previous entries - making the process of entry as
> smooth (or even smoother) than it is today.

Or you could just ask for the URL if the release is not already on a
download page.
This would mean parsing the page of course, but could be used to
provide immediate feedback if the page is non-conforming.

Asking for the page might also nudge projects to move to generic pages
rather than one per release.

However this does not solve the issue of stale download pages: how do
you know when a release version is no longer supported?

> J.
>
>
> On Mon, Nov 8, 2021 at 4:19 PM sebb  wrote:
> >
> > On Mon, 8 Nov 2021 at 11:29, Hans Van Akelyen
> >  wrote:
> > >
> > > Hi,
> > >
> > > I think a certain level of uniformity would not be bad for this.
> > > Having a fixed path to the downloads for each project makes it simpler for
> > > the users to "shop" for Apache projects.
> > >
> > > Having .a.o/download/ as a link that should point to the 
> > > resources
> > > makes it simpler for everyone.
> >
> > I agree, but expect a lot of complaints if you try to get this enforced.
> > (and there's not much point unless it is enforced).
> >
> > > Kind Regards,
> > > Hans
> > >
> > > On Mon, 8 Nov 2021 at 12:19, Justin Mclean  
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > > However that assumes that you know where to find the download page(s).
> > > > > It also assumes that projects update their download page(s) to only
> > > > > show current releases.
> > > >
> > > > It does indeed assume that, and a few other things. Currently policy
> > > > doesn't specify what the download page URL should be, but once known I
> > > > would guess it wouldn’t change often.
> > > >
> > > > Kind Regards,
> > > > Justin
> > > >
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > > > For additional commands, e-mail: dev-h...@community.apache.org
> > > >
> > > >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>

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

Re: Proposal to add "release requirements" check

[sebb]

On Mon, 8 Nov 2021 at 17:49, Jarek Potiuk  wrote:
>
> > However this does not solve the issue of stale download pages: how do
> you know when a release version is no longer supported?
>
> What do you mean?
>
> Is there a requirement for that that I missed? I believe the
> requirement is only about removing artifacts from "downloads.a.o" and
> this is a completely different issue.

That *is* what I am referring to.
In order to remove artifacts from downloads.a.o, it needs to be
established whether or not the release is still supported.

If a release does not appear in any download page, then it is a
candidate for removal (unless it is brand new).

However if it does appear as a link to downloads.a.o in a download
page, that does not necessarily mean that it is still a supported
release.

This is because projects don't always keep their download pages up to
date, especially where there are individual pages for each release.

For example, Airflow has download pages for 2.2.1 and 2.2.0; these
both link to files on downloads.a.o.

I suppose it is possible that there are plans to support updates to
2.2.0 separately from 2.2.1, but that seems unlikely, assuming that
the project uses semantic versioning or something similar.

> On Mon, Nov 8, 2021 at 6:42 PM sebb  wrote:
> >
> > On Mon, 8 Nov 2021 at 17:11, Jarek Potiuk  wrote:
> > >
> > > Yeah. We will have different URLs especially as more artifacts are
> > > produced (airflow has 3 of those each with different download pages).
> > >
> > > But this should be straightforward when you can add the url when
> > > registering the release (as Sebb proposed). According to the release
> > > process you should register each such "release type" separately and
> > > adding a URL there will do the job nicely. And initially it can be
> > > optional and once we figure out how to communicate it best and maybe
> > > try with some projects first we can make it obligatory at release
> > > registration. We could make it convenient - for example an easy way to
> > > copy a previously added URL from selected previous release or
> > > autocomplete from previous entries - making the process of entry as
> > > smooth (or even smoother) than it is today.
> >
> > Or you could just ask for the URL if the release is not already on a
> > download page.
> > This would mean parsing the page of course, but could be used to
> > provide immediate feedback if the page is non-conforming.
> >
> > Asking for the page might also nudge projects to move to generic pages
> > rather than one per release.
> >
> > However this does not solve the issue of stale download pages: how do
> > you know when a release version is no longer supported?
> >
> > > J.
> > >
> > >
> > > On Mon, Nov 8, 2021 at 4:19 PM sebb  wrote:
> > > >
> > > > On Mon, 8 Nov 2021 at 11:29, Hans Van Akelyen
> > > >  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I think a certain level of uniformity would not be bad for this.
> > > > > Having a fixed path to the downloads for each project makes it 
> > > > > simpler for
> > > > > the users to "shop" for Apache projects.
> > > > >
> > > > > Having .a.o/download/ as a link that should point to the 
> > > > > resources
> > > > > makes it simpler for everyone.
> > > >
> > > > I agree, but expect a lot of complaints if you try to get this enforced.
> > > > (and there's not much point unless it is enforced).
> > > >
> > > > > Kind Regards,
> > > > > Hans
> > > > >
> > > > > On Mon, 8 Nov 2021 at 12:19, Justin Mclean  
> > > > > wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > > However that assumes that you know where to find the download 
> > > > > > > page(s).
> > > > > > > It also assumes that projects update their download page(s) to 
> > > > > > > only
> > > > > > > show current releases.
> > > > > >
> > > > > > It does indeed assume that, and a few other things. Currently policy
> > > > > > doesn't specify what the download page URL should be, but once 
> > > > > > known I
> > > > > > would guess it wouldn’t change often.
> > > > > >
> > > > > > Kind Regards

Re: How to get started with contribution

[sebb]

On Fri, 19 Nov 2021 at 13:38, Paulo Motta  wrote:
>
> Good call Hans - I guess we should make that point to dev@community?

Would it not be better to point to students@ ?

Also the 'Mailing List' link on that page points to
https://apache.org/foundation/mailinglists.html
which is a general page about how mailing lists operate. Not what I expected.

The page needs a bit of TLC.

> Also
> perhaps we should make IRC Channel point to https://the-asf.slack.com/ ?
>
> Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
> hans.van.akel...@gmail.com> escreveu:
>
> > The contact email on the GSoC is mentors@a.o
> >
> >
> > https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
> >
> > On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik 
> > wrote:
> >
> > > Afaik there is students@community
> > > Potential gsoc participants would like to follow shortest path to mentors
> > > .
> > >
> > >
> > > from mobile (sorry for typos ;)
> > >
> > >
> > > On Fri, Nov 19, 2021, 20:11 Paulo Motta 
> > wrote:
> > >
> > > > I wonder why so many students are reaching out to the mentors list
> > asking
> > > > for information about GSoC. Perhaps we should create a specific list
> > for
> > > > GSoC students or maybe make it more explicit that students should reach
> > > out
> > > > to dev@community.apache.org to announce interest in participating or
> > ask
> > > > questions about GSoC ?
> > > >
> > > > Cheers,
> > > >
> > > > Paulo
> > > >
> > > > Em sex., 19 de nov. de 2021 às 03:02, Maxim Solodovnik <
> > > > solomax...@gmail.com>
> > > > escreveu:
> > > >
> > > > > Hello Suhel,
> > > > >
> > > > > mentors@ is the list for mentors, not for students :)
> > > > > I can recommend you to check this page:
> > > > > https://community.apache.org/gsoc.html
> > > > >
> > > > > Then find the project you would like to participate in here:
> > > > > https://projects.apache.org/projects.html?
> > > > > language#Java
> > > > >
> > > > > Additionally you can search for the GSOC label in JIRA :)
> > > > >
> > > > > Please send any additional questions to the dev@community
> > mailing-list
> > > > > or better to the dev@ list of the particular Apache project you
> > would
> > > > > like to contribute :)
> > > > >
> > > > > > -- Forwarded message --
> > > > > > From: Suhel Kapadia
> > > > > > Cc:
> > > > > > Bcc:
> > > > > > Date: Fri, 19 Nov 2021 01:58:31 +0530
> > > > > > Subject: How to get started with contribution
> > > > > > Respected Sir/Madam,
> > > > > > I am Suhel Kapadia, a 2nd year CSE undergrad.
> > > > > > I am new to open source contributions but I am well versed in c and
> > > > c++.
> > > > > I also have some experience with javascript and python.
> > > > > > I would really appreciate it if you could guide me on how to start
> > > > > contributing to your organization
> > > > > > Hoping to hear from you soon
> > > > > > Regards
> > > > > > Suhel.
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Best regards,
> > > > > Maxim
> > > > >
> > > > > -
> > > > > 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: How to get started with contribution

[sebb]

On Fri, 19 Nov 2021 at 15:19, Paulo Motta  wrote:
>
> > Would it not be better to point to students@ ?
>
> Perhaps not if we want mentors to have visibility of prospective students, 
> since that list is restricted only to students afaik.

There have not been many posts [1], but they are publicly archived so
I doubt it is restricted to students. It was created in June 2013 [2]

If the list name were promoted on the webpage it might help to revive
the list, otherwise it should perhaps be shut down.

Sebb
[1] https://lists.apache.org/list?stude...@community.apache.org
[2] https://issues.apache.org/jira/browse/INFRA-6397

> Em sex., 19 de nov. de 2021 às 12:04, sebb  escreveu:
>>
>> On Fri, 19 Nov 2021 at 13:38, Paulo Motta  wrote:
>> >
>> > Good call Hans - I guess we should make that point to dev@community?
>>
>> Would it not be better to point to students@ ?
>>
>> Also the 'Mailing List' link on that page points to
>> https://apache.org/foundation/mailinglists.html
>> which is a general page about how mailing lists operate. Not what I expected.
>>
>> The page needs a bit of TLC.
>>
>> > Also
>> > perhaps we should make IRC Channel point to https://the-asf.slack.com/ ?
>> >
>> > Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
>> > hans.van.akel...@gmail.com> escreveu:
>> >
>> > > The contact email on the GSoC is mentors@a.o
>> > >
>> > >
>> > > https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
>> > >
>> > > On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik 
>> > > wrote:
>> > >
>> > > > Afaik there is students@community
>> > > > Potential gsoc participants would like to follow shortest path to 
>> > > > mentors
>> > > > .
>> > > >
>> > > >
>> > > > from mobile (sorry for typos ;)
>> > > >
>> > > >
>> > > > On Fri, Nov 19, 2021, 20:11 Paulo Motta 
>> > > wrote:
>> > > >
>> > > > > I wonder why so many students are reaching out to the mentors list
>> > > asking
>> > > > > for information about GSoC. Perhaps we should create a specific list
>> > > for
>> > > > > GSoC students or maybe make it more explicit that students should 
>> > > > > reach
>> > > > out
>> > > > > to dev@community.apache.org to announce interest in participating or
>> > > ask
>> > > > > questions about GSoC ?
>> > > > >
>> > > > > Cheers,
>> > > > >
>> > > > > Paulo
>> > > > >
>> > > > > Em sex., 19 de nov. de 2021 às 03:02, Maxim Solodovnik <
>> > > > > solomax...@gmail.com>
>> > > > > escreveu:
>> > > > >
>> > > > > > Hello Suhel,
>> > > > > >
>> > > > > > mentors@ is the list for mentors, not for students :)
>> > > > > > I can recommend you to check this page:
>> > > > > > https://community.apache.org/gsoc.html
>> > > > > >
>> > > > > > Then find the project you would like to participate in here:
>> > > > > > https://projects.apache.org/projects.html?
>> > > > > > language#Java
>> > > > > >
>> > > > > > Additionally you can search for the GSOC label in JIRA :)
>> > > > > >
>> > > > > > Please send any additional questions to the dev@community
>> > > mailing-list
>> > > > > > or better to the dev@ list of the particular Apache project you
>> > > would
>> > > > > > like to contribute :)
>> > > > > >
>> > > > > > > -- Forwarded message --
>> > > > > > > From: Suhel Kapadia
>> > > > > > > Cc:
>> > > > > > > Bcc:
>> > > > > > > Date: Fri, 19 Nov 2021 01:58:31 +0530
>> > > > > > > Subject: How to get started with contribution
>> > > > > > > Respected Sir/Madam,
>> > > > > > > I am Suhel Kapadia, a 2nd year CSE undergrad.
>> > > > > > > I am new to open source contributions but I am well versed in c 
>> > > > > > > and
>> > > > > c++.
>> > > > > > I also have some experience with javascript and python.
>> > > > > > > I would really appreciate it if you could guide me on how to 
>> > > > > > > start
>> > > > > > contributing to your organization
>> > > > > > > Hoping to hear from you soon
>> > > > > > > Regards
>> > > > > > > Suhel.
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Best regards,
>> > > > > > Maxim
>> > > > > >
>> > > > > > -
>> > > > > > 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: How to get started with contribution

[sebb]

On Tue, 11 Jan 2022 at 23:54, Mohammad Noureldin
 wrote:
>
> Hi,
>
> I've followed up on some of these emails that have been sent to mentors@
> asking the senders to give us feedback on where on the Apache Community
> Development website [1] they have found that they need to/should send an
> email to mentors@.
>
> IMHO we better 1st understand that before creating another mailing list. It
> could be that we only need to rephrase some information on that website or
> make it more clear where they should go with their questions/inquiries.

Maybe have a single section with all email addresses and what their purpose is.

If an email address is mentioned in isolation, the temptation is to
just use that without reading the surrounding text carefully.
And even if the list does not appear to be quite right, if one has not
found any other address then one might assume it is OK to use.

When the addresses are listed together, it's much easier to choose the
correct list.

> [1] https://community.apache.org
>
>
> On Tue, Jan 11, 2022 at 8:37 PM Paulo Motta 
> wrote:
>
> > Hi everyone,
> >
> > I would like to follow-up on this topic, given the recent student seeking
> > GSoC information in the mentors list .
> >
> > I would like to hear your opinions on creating a mixed student and mentors
> > list  for ASF-wide mentors to advertise
> > projects
> > to potentially interested students, as well as taking general questions
> > about ASF participation in GSoC.
> >
> > If there's interest I can volunteer to set up the list with ASF Infra, and
> > work with Maxim to set it as a point of contact in ASF's GSoC page (<
> >
> > https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648
> > >).
> >
> > Kind regards,
> >
> > Paulo
> >
> >
> >
> > Em sex., 19 de nov. de 2021 às 13:32, sebb  escreveu:
> >
> > > On Fri, 19 Nov 2021 at 15:19, Paulo Motta 
> > > wrote:
> > > >
> > > > > Would it not be better to point to students@ ?
> > > >
> > > > Perhaps not if we want mentors to have visibility of prospective
> > > students, since that list is restricted only to students afaik.
> > >
> > > There have not been many posts [1], but they are publicly archived so
> > > I doubt it is restricted to students. It was created in June 2013 [2]
> > >
> > > If the list name were promoted on the webpage it might help to revive
> > > the list, otherwise it should perhaps be shut down.
> > >
> > > Sebb
> > > [1] https://lists.apache.org/list?stude...@community.apache.org
> > > [2] https://issues.apache.org/jira/browse/INFRA-6397
> > >
> > > > Em sex., 19 de nov. de 2021 às 12:04, sebb 
> > escreveu:
> > > >>
> > > >> On Fri, 19 Nov 2021 at 13:38, Paulo Motta 
> > > wrote:
> > > >> >
> > > >> > Good call Hans - I guess we should make that point to dev@community
> > ?
> > > >>
> > > >> Would it not be better to point to students@ ?
> > > >>
> > > >> Also the 'Mailing List' link on that page points to
> > > >> https://apache.org/foundation/mailinglists.html
> > > >> which is a general page about how mailing lists operate. Not what I
> > > expected.
> > > >>
> > > >> The page needs a bit of TLC.
> > > >>
> > > >> > Also
> > > >> > perhaps we should make IRC Channel point to
> > > https://the-asf.slack.com/ ?
> > > >> >
> > > >> > Em sex., 19 de nov. de 2021 às 10:31, Hans Van Akelyen <
> > > >> > hans.van.akel...@gmail.com> escreveu:
> > > >> >
> > > >> > > The contact email on the GSoC is mentors@a.o
> > > >> > >
> > > >> > >
> > > >> > >
> > >
> > https://summerofcode.withgoogle.com/archive/2021/organizations/5149287498907648/
> > > >> > >
> > > >> > > On Fri, 19 Nov 2021 at 14:17, Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > >> > > wrote:
> > > >> > >
> > > >> > > > Afaik there is students@community
> > > >> > > > Potential gsoc participants would like to follow shortest path
> > to
> > > mentors
> > > >> > > > .
> > > >> > > >
> > > >

Out of date GitHub mirror

[sebb]

The GitHub read-only mirror at
https://github.com/apache/comdev-helpwanted
is cracked (out of date), and cannot be fixed except by starting again [1]

Do we really need it?
I don't see the point of a read-only GH mirror, especially a broken one.

I suggest Infra are asked to drop it before it confuses more people.

Sebb
[1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git

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

Re: Out of date GitHub mirror

[sebb]

Ping: does anyone want to keep the mirror in its current state?
It no longer tracks changes to SVN, so I don't see the point of it.


On Tue, 5 Apr 2022 at 19:41, sebb  wrote:
>
> The GitHub read-only mirror at
> https://github.com/apache/comdev-helpwanted
> is cracked (out of date), and cannot be fixed except by starting again [1]
>
> Do we really need it?
> I don't see the point of a read-only GH mirror, especially a broken one.
>
> I suggest Infra are asked to drop it before it confuses more people.
>
> Sebb
> [1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git

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

Re: Out of date GitHub mirror

[sebb]

OK, I've requested it be removed:

https://issues.apache.org/jira/browse/INFRA-23181

It can always be set up afresh later if there is a need.

On Tue, 12 Apr 2022 at 14:08, sebb  wrote:
>
> Ping: does anyone want to keep the mirror in its current state?
> It no longer tracks changes to SVN, so I don't see the point of it.
>
>
> On Tue, 5 Apr 2022 at 19:41, sebb  wrote:
> >
> > The GitHub read-only mirror at
> > https://github.com/apache/comdev-helpwanted
> > is cracked (out of date), and cannot be fixed except by starting again [1]
> >
> > Do we really need it?
> > I don't see the point of a read-only GH mirror, especially a broken one.
> >
> > I suggest Infra are asked to drop it before it confuses more people.
> >
> > Sebb
> > [1] https://blogs.apache.org/infra/entry/subversion-to-git-service-git

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

Re: Apache Cordova's DOAP Source File Update

[sebb]

On Thu, 15 Sept 2022 at 08:12, Bryan Ellis  wrote:
>
> We (Cordova) had been notified of an issue with the syntax used in our DOAP 
> RDF file. The issue is specifically on how the categories are defined with 
> incorrect URLs.
> * https://github.com/apache/cordova/issues/291 
> 
>
> Additionally, a PR was opened to resolve this issue.
> * https://github.com/apache/cordova-docs/pull/1245 
> 
>
> On July 27th, we approved and merged this PR.
>
> I have noticed that the Apache Project’s webpage does not reflect these 
> changes.
> * https://projects.apache.org 
>
> Infra informed me that the contents of the page are pulled from this data 
> collection file.
> * 
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/trunk/data/projects.xml
>  
> 
>
> Upon reviewing the file, I noticed that it is referencing our SVN repository, 
> which we no longer maintain. As we have migrated our website deployment 
> process from SVN to GIT, we stopped pushing to SVN.
>
> Can the file be fetched from our website instead? or the GitHub raw file?
> * https://cordova.apache.org/infra/doap_Cordova.rdf 
> 
> * 
> https://raw.githubusercontent.com/apache/cordova-docs/asf-site/infra/doap_Cordova_PMC.rdf
>  
> 

The project should be able to update that file to change the source URL.

> Also, if the PMC’s RDF file is still used, it should also pull from one of 
> the new location.
> * https://cordova.apache.org/infra/doap_Cordova_PMC.rdf 
> 
> * 
> https://raw.githubusercontent.com/apache/cordova-docs/asf-site/infra/doap_Cordova_PMC.rdf
>  
> 
>
> Please let me know if there are any questions.
>
> Thank you
> Bryan

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

Re: Content Committee, ApacheCon 2014

[sebb]

On 13 December 2013 10:18, Lewis John Mcgibbney
 wrote:
> Hey Rich,
> Is there somewhere else that this conversation can continue other than pmcs@
> ?

Why not drop pmcs@; and keep the discussion on:

"dev@community.apache.org" 

plus your own pmc list if relevant

In fact, when sending such e-mails, maybe pmcs@ should be on the Bcc
rather than Cc list (with a note about this in the email body).

> Thanks very much
> Lewis
>
>
> On Thu, Dec 12, 2013 at 7:52 PM, Rich Bowen  wrote:
>
>> Dear PMCs,
>>
>> In the coming days, we'll be hearing more about ApacheCon 2014, and what
>> we need to do to make it happen.
>>
>> This time around, we, the folks at the ASF, will be responsible for
>> selecting content, while the conference producer will be responsible for
>> *EVERYTHING* else.
>>
>> Content selection is no small task, and I need help. While there are
>> several people who have already volunteered to be part of a content
>> selection committee, I'd also like to ask each PMC which wants to be
>> represented in the selection process to volunteer one person to represent
>> them in this task.
>>
>> We'll be using the RFP infrastructure supplied by the producer so all
>> you'd be on the hook for is being willing to review a list of talk
>> proposals specific to your project, and voting for/against them in some
>> method which that RFP process provides. Final schedule construction falls
>> to the producer, and, I suppose, to me.
>>
>> Thanks!
>>
>> --
>> Rich Bowen
>> rbo...@rcbowen.com
>> http://rcbowen.com/
>>
>>
>
>
> --
> *Lewis*

Re: How can we support a faster release cadence?

[sebb]

On 11 February 2014 17:01, Benson Margulies  wrote:
> Could I suggest a focus on making the release process easier? That
> will benefit everybody, and serve as a platform for ongoing discussion
> about releases and cadences.
>
> It seems to me that we could make voters' jobs easier. This would help
> get releases approved _in 72 hours_, to start with.
>
> We ask voters to participate in a business decision by;
>
> 1. being aware of the ongoing work of the community
> 2. checking the signature

+ hashes

> 3. building and running enough tests to be willing to endorse that
> release as a product of the community

4. Checking that the NOTICE & LICENSE files are appropriate to the
release artifacts that contain them.
5. Checking that the contents of the source release agree with the SCM
tag (there should be nothing in the source release that is not in SCM
- or perhaps directly derived therefrom, but that is unusual)

> At the start of this thread, someone asked: "If a trusted machine
> validated the signature, built the package, and ran the tests, could a
> responsible PMC member vote +1 on the basis of trusting the machine?"
> After all, all many voters do is to run the tests in the package, and
> if a someone has committed changes to denature them, the voter might
> well not notice.
>
> All of this should sit on the platform of my first point above: I
> submit that a person who has been paying no attention to commits and
> discussions has no business swooping in and voting on a package based
> on the other two steps.

I agree if the vote is +1
However, I don't think one should disallow reports of packaging bugs
or test failures - these can be picked up by anyone.

Also note that whatever is used to check the packaging and release
should be entirely independent of the packaging mechanism.
This is necessary to avoid common-mode failures (if that is the correct term).

>
> On Tue, Feb 11, 2014 at 11:19 AM, Shane Curcuru  wrote:
>> On 2/9/14 2:03 PM, Doug Cutting wrote:
>>>
>>> On Sat, Feb 8, 2014 at 2:44 PM, Henri Yandell  wrote:

 * Go and fork the project code on GitHub.
 * Put your changes in there and PR them up into the Apache codebase.
 * If others want to, they can PR the code to you, and then you can PR the
 code up to the codebase (or the group of you could work as a community
 preparing PRs).
 * The one pushing into the Apache codebase needs to be confident that the
 code is covered by CLAs.
 * You can release in GitHub whenever you want.
 * The Apache release happens less often and follows the rules.
>>>
>>>
>>> Keep in mind that if this is in any way a PMC activity then it is part
>>> of Apache trying to circumvent the rest of Apache, i.e., not advised.
>>> A distinct legal entity may indeed fork, re-brand, alter and release
>>> any Apache project using policies it prefers, but this must be clearly
>>> separate from any Apache project.  A subset of a PMC acting as
>>> individuals would be murky territory if they share no common legal
>>> entity outside Apache.
>>>
>>> Doug
>>
>>
>> The key point is: who is the "we" that the world perceives doing this? This
>> whole discussion really underscores the importance of trademarks and the
>> Apache brand.
>>
>> We're quite happy for anyone to take our code and ship it just about however
>> they like.  But they can't call it an Apache project: only a PMC here at
>> Apache can do that.  While the original reason for most ASF release,
>> branding, legal, etc. policies is to ensure our legal safety, the very real
>> effect of these policies and their consistent application in PMCs is that
>> our projects following these policies are *seen by the rest of the world* as
>> being "Apache projects".
>>
>> - Shane

Committer/PMC voting process is out of date

[sebb]

The committer/PMC voting process [1] is out of date, as it still
mentions the ACK e-mail rather than NOTICE.

Also, the process appears to suggest that the invite is sent to the
prospective new PMC member before the NOTICE period has elapsed. That
is not ideal. If there were ever a NAK from the board it would be too
late to cancel the invite. This does mean that occasionally the board
may be notified of an invite that is later refused, but that seems
better than the alternative.

The page ought to agree with the main site [2], [3]

Not sure who is entitled to update the Community pages?

[1] http://community.apache.org/newcommitter.html
[2] http://www.apache.org/dev/pmc.html#newcommitter
[3] http://www.apache.org/dev/pmc.html#newpmc

Re: [Legal PMC] Question with Creative Commons License

[sebb]

I think this is the wrong mailing list.

Such questions are normally dealt with on

legal-disc...@apache.org

Re: ApacheCon audio crowdsource help needed

[sebb]

Looks like
Confluence_B_02_Timmothy Potter.mp3
should probably be
Confluence_B_02_Timothy Potter.mp3


On 2 May 2014 17:44, Rich Bowen  wrote:
>
> On 05/02/2014 12:30 PM, jan i wrote:
>>
>> On 2 May 2014 18:28, Rich Bowen  wrote:
>>
>>> These recordings will begin to pop up on https://www.youtube.com/user/
>>> TheApacheFoundation over the course of the next few hours as they get
>>> done processing. I am off-grid all weekend, and so will resume uploading
>>> on
>>> Monday. I expect it'll take much of the week to get the uploading
>>> finished.
>>>
>> may I politely ask that you spell my name correct, its "jan iversen" I am
>> not swedish :-)
>
>
> Weird. I guess it must have been that way in the schedule, then? It's all
> copy-paste, although I did catch a few typos.
>
>
>
>> rgds
>> jan I.
>>
>>
>>> Meanwhile, I'll try to get the mp3 files advertised on Feathercast over
>>> the next few days, also.
>>>
>>> --Rich
>>>
>>>
>>>
>>> On 04/30/2014 04:54 PM, Rich Bowen wrote:
>>>
 I need a little help in the process of posting the ApacheCon NA 2014
 audio files

 https://docs.google.com/document/d/1Zi9RRGpQBVUDab5VLgXAuoyWlA9TG
 2zL38luJJOOn60/edit <-- Google Doc

 For each file listed, I need a speaker name and talk title. This can be
 obtained from the ApacheCon schedule itself, based on the file name and
 the
 room name. Or, you can listen to the file itself, at
 http://feathercast.apache.org/podcasts/ApacheConNA2014/ if the schedule
 doesn't make it evident.

 I'll be uploading more files over the coming hours - I'm kind of
 bandwidth limited so this may take a while - so please check back over
 the
 next day or so if you're able to help.

 Thanks!


>>> --
>>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>>> http://apachecon.com/ - @apachecon
>>>
>>>
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon
>

Re: Source code for DOAP File Generator

[sebb]

https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/xdocs/create.xml

On 13 May 2014 01:03, Lewis John Mcgibbney  wrote:
> Hi Folks,
> Can I obtain the source code for the neat doap_ file generator ?
> http://projects.apache.org/create.html
> I have another use case in mind and having this code would save me a bunch
> of time.
> Thanks for any suggestions.
> Best
> Lewis
>
>
> --
> *Lewis*

Re: Non-released Dependencies

[sebb]

On 28 July 2014 10:20, Greg Stein  wrote:
> Agreed that #2 is best.
>
> (and I'll also note I was a bit slack with some commentary; releases need
> to be signed,

Also source releases must be published via the ASF mirror system.

> so a path/revision or git-tag is not necessarily a true

s/necessarily//

> release; just trying to get across that you need a *specific* set of source
> for a dependency)
>
> Seems that Andreas is going to explore some options at dev@pdfbox.
>
> Cheers,
> -g
>
>
>
> On Fri, Jul 25, 2014 at 9:34 AM, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> I think the key bit here is that releases of Apache projects must have an
>> associated source release and have been voted on by the PMC making the
>> release.
>>
>> If the project you depend on is an independent project, you need to
>> remember that their -SNAPSHOT build is *not* a release. Therefore you need
>> it to become a release to include it.
>>
>> You therefore have three choices:
>>
>> 1. Fork the code into your project and do a big-bang release... a rude
>> option but once it's in your project your PMC can vote to release it.
>>
>> 2. Join the dependent project and help them get to a release
>>
>> 3. Find somebody outside the ASF (or at a minimum not wearing an ASF hat)
>> and get them to fork the code you want and release that. Then you can
>> depend on the non-ASF fork of the ASF project... again a rude option, but
>> perhaps less so than #1
>>
>> I vote you go for #2. It plays best with community which is what we are
>> here to foster
>>
>>
>> On 25 July 2014 15:26, Greg Stein  wrote:
>>
>>> [adding dev@community, as I believe this should go there...]
>>>
>>> On Fri, Jul 25, 2014 at 6:06 AM, Vincent Hennebert 
>>> wrote:
>>> >...
>>>
>>> > Hi,
>>> >
>>> > there's an undergoing debate in the XML Graphics project about doing
>>> > a release that has a dependency on a snapshot version of another
>>> > (Apache, for that matter) project.
>>> >
>>>
>>> The fact that it is an Apache project is *key* for my commentary below.
>>> Don't take my words for external projects, please :-P
>>>
>>>
>>> >
>>> > I know there's a policy at Apache to not release a project that has
>>> > non-released dependencies. The problem is, I don't know how I know
>>> > that... I cannot seem to be able to find any official documentation that
>>> > explicitly states it.
>>> >
>>>
>>> That's why you can't find it... I don't recall any such "policy" (over the
>>> past 15+ years I've been around) ... it just isn't a good idea. That's
>>> all.
>>>
>>>
>>> >
>>> > The following link: http://www.apache.org/dev/release.html#what is
>>> > apparently not convincing enough. I'm answered that this concerns our
>>> > own project but that it's fine to do an official release containing
>>> > a snapshot binary.
>>> >
>>>
>>> Well. You need to produce a full set of sources. No binaries. Those
>>> sources
>>> might be by-reference, but you definitely can't release a binary within
>>> your source distribution.
>>>
>>> Even if that other Apache project had a release you're happy with, there
>>> would be a source release available for it.
>>>
>>>
>>> >
>>> > Saying that every binary artefact has to be backed by source code and
>>> > that, in the case of a snapshot, we have to point to some Subversion
>>> > revision number, is apparently not convincing enough either. Despite the
>>> > obvious dependency nightmare that that would cause to users (and, in
>>> > particular, Maven users and Linux distributions).
>>> >
>>>
>>> Pause. This is not negotiable. You *must* have a source release. If you do
>>> that through a signed tarball, or through a git tag, or a Subversion
>>> revision number ... all of these identify a *specific* set of source code.
>>> That satisfies the need.
>>>
>>> You raise some concerns about nightmares... sure. Telling users "you must
>>> get r123 of /some/path, for $LIBRARY" is not exactly friendly. BUT: it
>>> satisfies all release requirements. It will specify the exact dependency.
>>> Good to go.
>>>
>>>
>>>
>>> >
>>> > Does anybody have any official reference to point at, that I may have
>>> > missed? More convincing arguments, legal reasons (should I forward to
>>> > legal-discuss@)?
>>>
>>>
>>> Much of this kind of stuff is "institutional knowledge" because having to
>>> write down "rules" and "procedures" just sucks. It is such a rare event,
>>> that it is best to leave it for the particular situation.
>>>
>>> There are no legal ramifications, if you're talking about a sibling Apache
>>> project.
>>>
>>> Now... you *should not* do any sort of release of a sibling. That will
>>> screw over that community. (version skew, unsupported bits, issue
>>> tracking,
>>> blah blah)
>>>
>>> I believe you have two options: fork their code into your project, and do
>>> some appropriate subpackage renaming to clarify it is distinct. Or,
>>> ideally, you join *their* community and help them cut a release, and then
>>> base your code on that.
>>>
>>>

Re: ApacheCon banner blocked by AdBlock Plus

[sebb]

On 9 September 2014 20:05, Mike Drob  wrote:
> Could rename the directory, but this probably breaks some existing pages.

Could keep the original location as a redirect.

> Or could request a white list entry from the AdBlock maintainers[1].

How many other Ad blockers are likely to use the same path matching?
Might end up playing whack-a-mole.

I always wondered why the directory was called ads/.
It's only used for ApacheCon.

> Mike
>
>
> [1]: https://adblockplus.org/en/acceptable-ads#application
>
> On Tue, Sep 9, 2014 at 11:48 AM, Melissa Warnkin <
> missywarn...@yahoo.com.invalid> wrote:
>
>> Thanks for the info, Andrea.
>>
>> Is there anything we need to do to unblock it?
>>
>>
>> ~M
>>
>>
>> 
>>  From: Andrea Pescetti 
>> To: ComDev 
>> Sent: Tuesday, September 9, 2014 12:05 PM
>> Subject: ApacheCon banner blocked by AdBlock Plus
>>
>>
>> Just for your information, the ApacheCon banner and the other banners
>> hosted at http://www.apache.org/ads/ are blocked by the filter
>> ".org/ads" in Adblock Plus. Yes, it's configurable, but most of the time
>> people won't notice that a banner is missing... See
>> http://markmail.org/message/z4ngzjtukidvy2ti
>> for more.
>>
>> Regards,
>>Andrea.
>>

Re: Remove me

[sebb]

On 6 October 2014 09:36, Emiliano Bossi  wrote:
> Dear Sirs,
> I would like to remove my subscription from this community, How can I do?
>
> Thanx

Send an e-mail to

dev-unsubscr...@community.apache.org

Reply to the confirmation e-mail it sends you.

See

http://www.apache.org/foundation/mailinglists.html

for more details

> Best Regards
> Emiliano Bossi

ApacheCon 2015 logos

[sebb]

There don't appear to be any ApacheCon logos in SVN yet:

http://www.apache.org/ads/ApacheCon/

It would be useful to have these so websites can link to them.

[I can fix the various distribution files once the logos have been
made available, but my graphics ability is non-existent].

Re: ApacheCon 2015 logos

[sebb]

On 13 December 2014 at 18:01, Sally Khudairi  wrote:
> Sorry --this is not the purview of Marketing & Publicity.

Sorry, I Cced Press because the ASF websites currently display adverts
for expired ApacheCons.
I assumed that was relevant to M&P even if it is not their
responsibility to fix it.

> It falls under the domain of ApacheCon. I'm copying Rich Bowen, as he's our
> lead for ApacheCon.
>
> Cheers,
>  Sally
>
>
> [From the mobile; please excuse top-posting, spelling/spacing errors, and
> brevity]
>
> - Reply message -
> From: "sebb" 
> To: 
> Cc: 
> Subject: ApacheCon 2015 logos
> Date: Sat, Dec 13, 2014 12:49
>
> There don't appear to be any ApacheCon logos in SVN yet:
>
> http://www.apache.org/ads/ApacheCon/
>
> It would be useful to have these so websites can link to them.
>
> [I can fix the various distribution files once the logos have been
> made available, but my graphics ability is non-existent].

Re: ApacheCon 2015 logos

[sebb]

Thanks, but those are rather large for use as logos.

The normal ones are 125x125 pixels and 234x60.

These are 800x255 which will break the page layouts.

The ones I am after are the replacements for these:

http://www.apache.org/ads/ApacheCon/2014-na-125x125.png
http://www.apache.org/ads/ApacheCon/2014-na-234x60.png


On 15 December 2014 at 20:35, Rich Bowen  wrote:
> Apparently neither my file attachments nor my uploads worked.
>
> Try this:
>
> https://www.flickr.com/photos/rbowen/sets/72157647453007733/
>
>
>
> On 12/13/2014 12:49 PM, sebb wrote:
>>
>> There don't appear to be any ApacheCon logos in SVN yet:
>>
>> http://www.apache.org/ads/ApacheCon/
>>
>> It would be useful to have these so websites can link to them.
>>
>> [I can fix the various distribution files once the logos have been
>> made available, but my graphics ability is non-existent].
>>
>
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon

Code of Conduct - links to why they are needed etc

[sebb]

There are some useful links in the CoC blog:

https://blogs.apache.org/foundation/entry/asf_publishes_long_overdue_code

For example,
Ashe Dryden's introductory resource for learning more about how Codes
of Conduct can help

Perhaps these should be added to the ASF CoC page at

http://www.apache.org/foundation/policies/conduct.html

Re: A maturity model for Apache projects

[sebb]

On 6 January 2015 at 18:31, Bertrand Delacretaz  wrote:
> On Tue, Jan 6, 2015 at 7:21 PM, Daniel Gruno  wrote:
>> ...How about a compromise:
>> distribution of releases and source: publicly, in a _consistent_ manner
>> according to foundation guidelines?...
>
> Works for me.

Does not work for me.

The adjective "consistent" seems to be applied to the wrong noun.

"consistent manner" implies to me that the way we release artifacts
won't change.

Maybe

distribution of releases and source: publicly, in a manner
_consistent_ with the foundation guidelines?


> -Bertrand

Re: projects.apache.org overhaul proposal

[sebb]

I think it is a good idea to replace the current projects.a.o build
system because it is extremely complicated currently.
It even has its own build system partly based on XML,and the build
tools are spread over at least two parts of SVN.
The build requires Perl, XSLT and I think there's now some Python as well.

However there may be some issues with the conversion.
I mention a few below, not to kill off the idea but to make sure the
issues are covered.

The existing build files have a few special cases built in - e.g. to
ensure that project names are treated sensibly.
It may take a while to determine which of these need to be retained.

DOAP files may have usage outside the ASF. So dropping them entirely
may not be possible.

When I suggested moving the Commons DOAPs to a common directory (they
are currently in the individual component trunks) I got a lot of
opposition, because people wanted the DOAP in the same place as the
code. I think the idea was that it made it easier to remember to
update them when doing new releases.

Also note that not all projects have DOAPs yet.
>From time to time I chase up projects that have not produced one, but
progress can be very slow.
That may prove simpler with a new online form. It reduces people's
choices as to where to store the data.

The other aspect that is often forgotten is user documentation.
The existing docs are not wonderful, but I think it is possible to
work out how to create and submit a new DOAP with careful reading.

If the new system is to be successful long-term, I think it's vital
that it is clearly documented from the start.


On 14 January 2015 at 18:31, Jacques Le Roux
 wrote:
> Yes, it's great to have 3 OFBiz demos available, we (me on behalf of the
> OFBiz team) thank you (the infra team) for that!
> We could though give one back to infra or the ASF at large ;)
>
> Note: I'm not volunterring to support Pierre's idea ;)
>
> Jacques
>
> Le 14/01/2015 17:45, Daniel Gruno a écrit :
>
>> Furthermore, with my infra hat on, we already have enough technical debt
>> to deal with in the near future, we will not be supporting a new service
>> like OFBiz for quite a while, and especially not without someone from OFBiz
>> "paying the infra tax".
>>
>> With regards,
>> Daniel.

Re: Apache Events information is out-of-date

[sebb]

On 22 January 2015 at 00:08, David Crossley  wrote:
> (I am not sure where this belongs, so starting here.
> Would someone else please handle it, as i do not have the time.)
>
> Many Apache project websites refer directly to the
> "current event" information, so that their websites will
> automatically promote the next event without the projects
> needing to do anything.
>
> See http://www.apache.org/events/
>
> Those were recently updated (2014-12-30). However there seems to be
> a glitch, and the images are still the old ones.

I think that's because there are as yet no new logos.
These should be at:

http://www.apache.org/ads/ApacheCon/

I asked about this on dev@community mid December.

I have no graphics ability, but I'm happy to update the various files
once the logos are available.


> -David

Re: ApacheCon 2015 logos

[sebb]

PING

On 16 December 2014 at 01:15, sebb  wrote:
> Thanks, but those are rather large for use as logos.
>
> The normal ones are 125x125 pixels and 234x60.
>
> These are 800x255 which will break the page layouts.
>
> The ones I am after are the replacements for these:
>
> http://www.apache.org/ads/ApacheCon/2014-na-125x125.png
> http://www.apache.org/ads/ApacheCon/2014-na-234x60.png
>
>
> On 15 December 2014 at 20:35, Rich Bowen  wrote:
>> Apparently neither my file attachments nor my uploads worked.
>>
>> Try this:
>>
>> https://www.flickr.com/photos/rbowen/sets/72157647453007733/
>>
>>
>>
>> On 12/13/2014 12:49 PM, sebb wrote:
>>>
>>> There don't appear to be any ApacheCon logos in SVN yet:
>>>
>>> http://www.apache.org/ads/ApacheCon/
>>>
>>> It would be useful to have these so websites can link to them.
>>>
>>> [I can fix the various distribution files once the logos have been
>>> made available, but my graphics ability is non-existent].
>>>
>>
>>
>> --
>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>> http://apachecon.com/ - @apachecon

Re: Apache Events information is out-of-date

[sebb]

On 26 January 2015 at 14:04, Rich Bowen  wrote:
> Here are the new logos. I sent them to the list some time ago, but didn't
> get them into the right place it appears.

No sign of logos attached to the copy of the mail I have received.
Nor can I see any attachment in the copy in the mail-archives.

Note that many lists strip attachments - this may be one such.

> Getting ready to go to FOSDEM, so I'm not sure if I'll get to this today. If
> someone beats me to it, that would be wonderful.
>

I'm happy to commit the files and change the references to them, but
cannot do so without the files...

>
>
> On 01/21/2015 07:18 PM, sebb wrote:
>>
>> On 22 January 2015 at 00:08, David Crossley  wrote:
>>>
>>> (I am not sure where this belongs, so starting here.
>>> Would someone else please handle it, as i do not have the time.)
>>>
>>> Many Apache project websites refer directly to the
>>> "current event" information, so that their websites will
>>> automatically promote the next event without the projects
>>> needing to do anything.
>>>
>>> See http://www.apache.org/events/
>>>
>>> Those were recently updated (2014-12-30). However there seems to be
>>> a glitch, and the images are still the old ones.
>>
>>
>> I think that's because there are as yet no new logos.
>> These should be at:
>>
>> http://www.apache.org/ads/ApacheCon/
>>
>> I asked about this on dev@community mid December.
>>
>> I have no graphics ability, but I'm happy to update the various files
>> once the logos are available.
>>
>>
>>> -David
>
>
>
> --
> Rich Bowen - rbo...@rcbowen.com - @rbowen
> http://apachecon.com/ - @apachecon

Re: Apache Events information is out-of-date

[sebb]

 As I noted at the time, those are not the correct sizes for the website.

The normal ones are 125x125 pixels and 234x60.

The Flikr ones are 800x255 which will break the page layouts.

Also, the Flikr images don't have any detail on them apart from "North America"

Previous ones had dates and locations, see for example:

http://www.apache.org/ads/ApacheCon/2014-na-125x125.png
http://www.apache.org/ads/ApacheCon/2014-na-234x60.png



On 27 January 2015 at 12:53, Rich Bowen  wrote:
> The email you responded to on 12/15 had a link to images on flickr
>
> https://flic.kr/p/ptyZ5L
> https://flic.kr/p/q8ZBLQ
>
> But hopefully we'll have alternates later this week.
> On Jan 26, 2015 5:10 PM, "sebb"  wrote:
>
>> On 26 January 2015 at 14:04, Rich Bowen  wrote:
>> > Here are the new logos. I sent them to the list some time ago, but didn't
>> > get them into the right place it appears.
>>
>> No sign of logos attached to the copy of the mail I have received.
>> Nor can I see any attachment in the copy in the mail-archives.
>>
>> Note that many lists strip attachments - this may be one such.
>>
>> > Getting ready to go to FOSDEM, so I'm not sure if I'll get to this
>> today. If
>> > someone beats me to it, that would be wonderful.
>> >
>>
>> I'm happy to commit the files and change the references to them, but
>> cannot do so without the files...
>>
>> >
>> >
>> > On 01/21/2015 07:18 PM, sebb wrote:
>> >>
>> >> On 22 January 2015 at 00:08, David Crossley 
>> wrote:
>> >>>
>> >>> (I am not sure where this belongs, so starting here.
>> >>> Would someone else please handle it, as i do not have the time.)
>> >>>
>> >>> Many Apache project websites refer directly to the
>> >>> "current event" information, so that their websites will
>> >>> automatically promote the next event without the projects
>> >>> needing to do anything.
>> >>>
>> >>> See http://www.apache.org/events/
>> >>>
>> >>> Those were recently updated (2014-12-30). However there seems to be
>> >>> a glitch, and the images are still the old ones.
>> >>
>> >>
>> >> I think that's because there are as yet no new logos.
>> >> These should be at:
>> >>
>> >> http://www.apache.org/ads/ApacheCon/
>> >>
>> >> I asked about this on dev@community mid December.
>> >>
>> >> I have no graphics ability, but I'm happy to update the various files
>> >> once the logos are available.
>> >>
>> >>
>> >>> -David
>> >
>> >
>> >
>> > --
>> > Rich Bowen - rbo...@rcbowen.com - @rbowen
>> > http://apachecon.com/ - @apachecon
>>

Re: Apache Events information is out-of-date

[sebb]

Thanks very much - those look fine to me.

I'll commit them and update the references.

On 27 January 2015 at 15:39, Daniel Gruno  wrote:
> http://imgur.com/a/s2uRb
>
> Good enough?
>
> With regards,
> Daniel.
>
>
> On 2015-01-27 16:22, sebb wrote:
>>
>>   As I noted at the time, those are not the correct sizes for the website.
>>
>> The normal ones are 125x125 pixels and 234x60.
>>
>> The Flikr ones are 800x255 which will break the page layouts.
>>
>> Also, the Flikr images don't have any detail on them apart from "North
>> America"
>>
>> Previous ones had dates and locations, see for example:
>>
>> http://www.apache.org/ads/ApacheCon/2014-na-125x125.png
>> http://www.apache.org/ads/ApacheCon/2014-na-234x60.png
>>
>>
>>
>> On 27 January 2015 at 12:53, Rich Bowen  wrote:
>>>
>>> The email you responded to on 12/15 had a link to images on flickr
>>>
>>> https://flic.kr/p/ptyZ5L
>>> https://flic.kr/p/q8ZBLQ
>>>
>>> But hopefully we'll have alternates later this week.
>>> On Jan 26, 2015 5:10 PM, "sebb"  wrote:
>>>
>>>> On 26 January 2015 at 14:04, Rich Bowen  wrote:
>>>>>
>>>>> Here are the new logos. I sent them to the list some time ago, but
>>>>> didn't
>>>>> get them into the right place it appears.
>>>>
>>>> No sign of logos attached to the copy of the mail I have received.
>>>> Nor can I see any attachment in the copy in the mail-archives.
>>>>
>>>> Note that many lists strip attachments - this may be one such.
>>>>
>>>>> Getting ready to go to FOSDEM, so I'm not sure if I'll get to this
>>>>
>>>> today. If
>>>>>
>>>>> someone beats me to it, that would be wonderful.
>>>>>
>>>> I'm happy to commit the files and change the references to them, but
>>>> cannot do so without the files...
>>>>
>>>>>
>>>>> On 01/21/2015 07:18 PM, sebb wrote:
>>>>>>
>>>>>> On 22 January 2015 at 00:08, David Crossley 
>>>>
>>>> wrote:
>>>>>>>
>>>>>>> (I am not sure where this belongs, so starting here.
>>>>>>> Would someone else please handle it, as i do not have the time.)
>>>>>>>
>>>>>>> Many Apache project websites refer directly to the
>>>>>>> "current event" information, so that their websites will
>>>>>>> automatically promote the next event without the projects
>>>>>>> needing to do anything.
>>>>>>>
>>>>>>> See http://www.apache.org/events/
>>>>>>>
>>>>>>> Those were recently updated (2014-12-30). However there seems to be
>>>>>>> a glitch, and the images are still the old ones.
>>>>>>
>>>>>>
>>>>>> I think that's because there are as yet no new logos.
>>>>>> These should be at:
>>>>>>
>>>>>> http://www.apache.org/ads/ApacheCon/
>>>>>>
>>>>>> I asked about this on dev@community mid December.
>>>>>>
>>>>>> I have no graphics ability, but I'm happy to update the various files
>>>>>> once the logos are available.
>>>>>>
>>>>>>
>>>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>>>>> http://apachecon.com/ - @apachecon
>
>

Re: Apache Events information is out-of-date

[sebb]

I think the updates are now all done.

If there are any issues, please report them so they can be fixed.



On 27 January 2015 at 16:01, sebb  wrote:
> Thanks very much - those look fine to me.
>
> I'll commit them and update the references.
>
> On 27 January 2015 at 15:39, Daniel Gruno  wrote:
>> http://imgur.com/a/s2uRb
>>
>> Good enough?
>>
>> With regards,
>> Daniel.
>>
>>
>> On 2015-01-27 16:22, sebb wrote:
>>>
>>>   As I noted at the time, those are not the correct sizes for the website.
>>>
>>> The normal ones are 125x125 pixels and 234x60.
>>>
>>> The Flikr ones are 800x255 which will break the page layouts.
>>>
>>> Also, the Flikr images don't have any detail on them apart from "North
>>> America"
>>>
>>> Previous ones had dates and locations, see for example:
>>>
>>> http://www.apache.org/ads/ApacheCon/2014-na-125x125.png
>>> http://www.apache.org/ads/ApacheCon/2014-na-234x60.png
>>>
>>>
>>>
>>> On 27 January 2015 at 12:53, Rich Bowen  wrote:
>>>>
>>>> The email you responded to on 12/15 had a link to images on flickr
>>>>
>>>> https://flic.kr/p/ptyZ5L
>>>> https://flic.kr/p/q8ZBLQ
>>>>
>>>> But hopefully we'll have alternates later this week.
>>>> On Jan 26, 2015 5:10 PM, "sebb"  wrote:
>>>>
>>>>> On 26 January 2015 at 14:04, Rich Bowen  wrote:
>>>>>>
>>>>>> Here are the new logos. I sent them to the list some time ago, but
>>>>>> didn't
>>>>>> get them into the right place it appears.
>>>>>
>>>>> No sign of logos attached to the copy of the mail I have received.
>>>>> Nor can I see any attachment in the copy in the mail-archives.
>>>>>
>>>>> Note that many lists strip attachments - this may be one such.
>>>>>
>>>>>> Getting ready to go to FOSDEM, so I'm not sure if I'll get to this
>>>>>
>>>>> today. If
>>>>>>
>>>>>> someone beats me to it, that would be wonderful.
>>>>>>
>>>>> I'm happy to commit the files and change the references to them, but
>>>>> cannot do so without the files...
>>>>>
>>>>>>
>>>>>> On 01/21/2015 07:18 PM, sebb wrote:
>>>>>>>
>>>>>>> On 22 January 2015 at 00:08, David Crossley 
>>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> (I am not sure where this belongs, so starting here.
>>>>>>>> Would someone else please handle it, as i do not have the time.)
>>>>>>>>
>>>>>>>> Many Apache project websites refer directly to the
>>>>>>>> "current event" information, so that their websites will
>>>>>>>> automatically promote the next event without the projects
>>>>>>>> needing to do anything.
>>>>>>>>
>>>>>>>> See http://www.apache.org/events/
>>>>>>>>
>>>>>>>> Those were recently updated (2014-12-30). However there seems to be
>>>>>>>> a glitch, and the images are still the old ones.
>>>>>>>
>>>>>>>
>>>>>>> I think that's because there are as yet no new logos.
>>>>>>> These should be at:
>>>>>>>
>>>>>>> http://www.apache.org/ads/ApacheCon/
>>>>>>>
>>>>>>> I asked about this on dev@community mid December.
>>>>>>>
>>>>>>> I have no graphics ability, but I'm happy to update the various files
>>>>>>> once the logos are available.
>>>>>>>
>>>>>>>
>>>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Rich Bowen - rbo...@rcbowen.com - @rbowen
>>>>>> http://apachecon.com/ - @apachecon
>>
>>

Re: Fwd: Apache Logos

[sebb]

Again, no logos reached the list.

On 29 January 2015 at 07:59, Rich Bowen  wrote:
> Here's some more ACNA logos. Hope this helps.
>
>
>  Forwarded Message 
> Subject:Fwd: Apache Logos
> Date:   Wed, 28 Jan 2015 17:10:41 -0800
> From:   Angela Brown 
> To: Rich Bowen 
>
>
>
> Hi Rich,
>
> Here are the logos you requested.
>
> Best,
>
> Angela
> -- Forwarded message --
> From: *Amanda Cohen*  >
> Date: Wed, Jan 28, 2015 at 12:08 PM
> Subject: Apache Logos
> To: Angela Brown  >
> Cc: "C. Craig Ross"  >
>
>
> Hey Angela,
>
> Here are the logos you requested.
>
> Just let me know if you need anything else!
>
> -A
>
>
>
> --
> Angela Brown
> Senior Director of Events
> The Linux Foundation
> 660 York Street, Suite 102
> San Francisco, CA 94110
> T: +1.415.368.4840
> E: ang...@linuxfoundation.org 
> W: linuxfoundation.org  and
> events.linuxfoundation.org 
>
> Check out the Linux Foundation Event Experience -
> http://youtu.be/-WUeelICQ2U
>
>

Re: Apache Way talks

[sebb]

On 16 February 2015 at 16:51, Ross Gardler (MS OPEN TECH)
 wrote:
> I think that's exactly it. If we write policy down it becomes a rule.

Huh?

Written policy only becomes a rule if the document declares it as such
- or perhaps, fails to declare it as policy.

There seem to be a lot of unwritten rules and unwritten policy in the ASF.
I think this is why there are so many arguments about what is
absolutely required and what is best practice.

Also that some rules are stated without providing the rationale.

> Rules work great when every environment is the same, but that's not the real 
> world.

That suggests that rules are completely unnecessary.
I don't believe that is the case.

It ought to be possible to start from a strict requirement - for
example, being able to establish provenance of code - and derive some
fundamental rules from that.

If a rule is stated without any background, it just becomes something
to argue over, and edge cases are more difficult to resolve.
Whereas if the rationale for a rule is documented, edge cases can be
checked against the rationale.

> We do, as a group of individuals, have the tendency to assume the way things 
> are done in project Foo is the entirety of The Apache Way. In fact what is 
> done in Foo is a superset of the Apache Way, designed for that specific 
> project.
>
> Consider Committer = PMC for example. The Apache Way only says that both 
> groups should be merit based (I.e. no cabals or BD). It says nothing about 
> what the merit levels are or whether they should be the same or different for 
> each group. Yet, somehow, many people will express their experience as being 
> an immutable part of the Apache Way.
>
> Individual experience should help inform other community members, but it 
> shouldn't restrict them.
>
> Ross
>
> Sent from my Windows Phone
> 
> From: jan i
> Sent: ‎2/‎16/‎2015 8:43 AM
> To: dev@community.apache.org
> Subject: Re: Apache Way talks
>
> s
>
> On 16 February 2015 at 17:21, Ross Gardler (MS OPEN TECH) <
> ross.gard...@microsoft.com> wrote:
>
>> I agree Joe,
>>
>> We only have a very few immutable rules. Everything else is policy. As
>> long as policy don't break those immutable rules the they can shift and
>> change as much as they need to in order to empower individual project
>> communities.
>>
>> Coincidentally I wrote a presentation on this very topic last night. I'll
>> look to share it once it has been delivered, but too late for me to add to
>> the CFP.
>>
> I agree with you both.only being a relative new member, it is often
> quite hard to see what is official policy and what is just the opinion of
> some members.
>
> The rules are clear, and in my opinion,  protect our values.
>
> Maybe we are back in another old discussion, that some of our policies are
> not defined, but merely "we use to do".
>
> rgds
> jan I.
>
>
>>
>>
>>
>> Sent from my Windows Phone
>> 
>> From: Joe Brockmeier
>> Sent: ‎2/‎16/‎2015 8:01 AM
>> To: dev@community.apache.org
>> Subject: Re: Apache Way talks
>>
>> On Sat, Feb 14, 2015, at 01:38 PM, jan i wrote:
>> > I have a feeling that we are standing at a crossroad where  many
>> > questions like Directd funding, ApacheCON, entry ticket to ASF
>> (Incubator/pTLP)
>> > tear us apart, and I believe it is high time the members of ASF take a
>> stand
>> > (whatever it may be), and show we are ONE united in the APACHE WAY.
>>
>> I'm not sure directed funding, handling ApacheCon, etc. are immutable or
>> define The Apache Way.
>>
>> We can allow (or not) directed funding and still practice community over
>> code, merit, openness, etc.
>>
>> The fact that a large and diverse membership do not agree on these
>> issues need not "tear us apart" if we can discuss and resolve issues
>> without animosity. If we agree that "community over code" is one of the
>> defining aspects of Apache, surely we can also agree that the community
>> is also more important than folks having their way over whether or not
>> Apache allows (or experiments with) directed funding or other models of
>> promoting/sustaining projects and their infrastructure.
>>
>> Best,
>>
>> jzb
>> --
>> Joe Brockmeier
>> j...@zonker.net
>> Twitter: @jzb
>> http://www.dissociatedpress.net/
>>

Re: Apache Reporter Service

[sebb]

The tool looks cool, but does not handle Apache Commons properly, as
it calls it "Apache Commons BeanUtils".
BeanUtils is just one of the Commons components (it seems to be
picking the first component alphabetically).

The JIRA release option does not work well for Commons.
Each component has a separate JIRA id, but the graph does not show the id.
There are other TLPs with multiple JIRA instances and release cycles,
for example Creadur

The JIRA release fetch tool does not report an error for an invalid JIRA id.

Note that all Commons JIRA ids are in the Category Commons; similarly
all Creadur instances are in the Category Creadur.
It would be really useful if the releases could be fetched using the Category.

I am on the PMC for Commons, JMeter and Creadur.
Only the JMeter display shows the chair person.

It would be useful if ASF members could see the data for every PMC -
but obviously not update PMCs they are not associated with.


On 3 March 2015 at 10:50, 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.

Re: Apache Reporter Service

[sebb]

On 4 March 2015 at 07:26, Daniel Gruno  wrote:
>
>
> On 2015-03-04 01:29, sebb wrote:
>>
>> The tool looks cool, but does not handle Apache Commons properly, as
>> it calls it "Apache Commons BeanUtils".
>> BeanUtils is just one of the Commons components (it seems to be
>> picking the first component alphabetically).
>
> This was due to Commons not having any information on the base project
> available in rdf/json, so the system picked what it thought looked like a
> winner. I have since changed it to just fetch the name from the PMC data
> instead.
>>
>>
>> The JIRA release option does not work well for Commons.
>> Each component has a separate JIRA id, but the graph does not show the id.
>> There are other TLPs with multiple JIRA instances and release cycles,
>> for example Creadur
>
> The JIRA stats are in their infancy still, I'll see if I can't make it more
> useful for Commons this week.
>>
>> The JIRA release fetch tool does not report an error for an invalid JIRA
>> id.
>>
>> Note that all Commons JIRA ids are in the Category Commons; similarly
>> all Creadur instances are in the Category Creadur.
>> It would be really useful if the releases could be fetched using the
>> Category.
>>
>> I am on the PMC for Commons, JMeter and Creadur.
>> Only the JMeter display shows the chair person.
>
> fixed for comons. As for Creadur, whenever someone creates a profile for the

How does one create profiles?
Nothing obvious on the website.

> project on projects-new.apache.org, the data will automatically start

projects-new shows

Apache Commons BeanUtils: 121 committers, 35 PMC members => sub-project

It does not make sense to include sub-projects in the project list.


> showing up on reporter.a.o.

That seems to have been done.
Might be useful to cross-link the two apps and provide some background
docs on how to use them.

>>
>>
>> It would be useful if ASF members could see the data for every PMC -
>> but obviously not update PMCs they are not associated with.
>
> That is how it already is. Use the hot-link feature to access projects you
> are not on the PMC of, or use the 'statistics' link from Whimsy.

What hot-link feature?
I only see tabs for the 3 PMCs I am on.

> With regards,
> Daniel.
>
>>
>>
>> On 3 March 2015 at 10:50, 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.
>
>

Re: svn commit: r1666030 - /infrastructure/site/trunk/content/foundation/policies/privacy.mdtext

[sebb]

On 11 March 2015 at 22:40,   wrote:
> Author: rbowen
> Date: Wed Mar 11 22:40:09 2015
> New Revision: 1666030
>
> URL: http://svn.apache.org/r1666030
> Log:
> Privacy policy, borrowed from OpenMRS upon the recommendation of Lawrence 
> Rosen
>
> Added:
> infrastructure/site/trunk/content/foundation/policies/privacy.mdtext
>
> Added: infrastructure/site/trunk/content/foundation/policies/privacy.mdtext
> URL: 
> http://svn.apache.org/viewvc/infrastructure/site/trunk/content/foundation/policies/privacy.mdtext?rev=1666030&view=auto
> ==
> --- infrastructure/site/trunk/content/foundation/policies/privacy.mdtext 
> (added)
> +++ infrastructure/site/trunk/content/foundation/policies/privacy.mdtext Wed 
> Mar 11 22:40:09 2015
> @@ -0,0 +1,29 @@
> +Title: Privacy Policy
> +Notice:Licensed to the Apache Software Foundation (ASF) under one
> +   or more contributor license agreements.  See the NOTICE file
> +   distributed with this work for additional information
> +   regarding copyright ownership.  The ASF licenses this file
> +   to you under the Apache License, Version 2.0 (the
> +   "License"); you may not use this file except in compliance
> +   with the License.  You may obtain a copy of the License at
> +   .
> + http://www.apache.org/licenses/LICENSE-2.0
> +   .
> +   Unless required by applicable law or agreed to in writing,
> +   software distributed under the License is distributed on an
> +   "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
> +   KIND, either express or implied.  See the License for the
> +   specific language governing permissions and limitations
> +   under the License.
> +
> +# Privacy Policy #
> +
> +The Apache Software Foundation (ASF) is an open source project organized 
> under the auspices of a public benefit corporation. Our challenges and goals 
> are large. For that reason, we have a very permissive (non) privacy policy 
> that mirrors our public mission.
> +
> +Please assume that everything you contribute intentionally to The ASF, or 
> any project at The ASF, is public. This includes emails on public lists, 
> wikis, online discussions of all sorts, and software or documentation that 
> you post to this website or our revision control repositories.
> +
> +Because we follow an academic model that expects mutual personal respect, 
> disclosure of interests and openness of expression is public information. 
> There may be cases where you are invited to share private information for 
> various purposes, and denote that information as such. In those cases, we 
> commit to only disclosing that information without your permission upon 
> receipt of a valid subpoena and following notice from The ASF to you.
> +
> +Although what you disclose here is public, we are all limited by copyright 
> and patent law in how we may use your contributions. Therefore, The ASF only 
> accepts voluntary contributions of software and documentation that are 
> expressly licensed to The ASF under an approved open source license.

Is that really true that we only accept contributions that are
"expressly licensed"?
What does "expressly" mean here?

To me that means I would have to accompany each contribution with an
explicit license grant.
However AFAIK that is not how we operate - for example patches on
Bugzilla and JIRA, patches in e-mails etc.

> +
> +The ASF welcomes your questions or comments regarding this Privacy Policy. 
> Send them to dev@community.apache.org
>
>

Re: the doap processing is busted for people.a.o

[sebb]

The problem seems to be the UIMA DOAP; it has the following tag:



Normal DOAPs have tags of the form:

http://vcl.apache.org"; />

The template utils.xsl tries to extract the PMC name (in  wrote:
> On Mon, Apr 27, 2015 at 07:52:37AM -0400, Shane Curcuru wrote:
>> Just a quick note: I'm pretty confident the medium term plan is to
>> replace the entire projects.a.o build system (rather complicated,
>> involving multiple steps in Perl and XSLT) with the software behind the
>> projects-new.apache.org site.  Thus, I highly recommend looking at the
>> below work instead of doing anything with the old Perl!
>
> Yes, but as i tried to explain, the old projects.a.o build has the DOAP
> files. They are imported by an irregular manually-started build
> process to feed the projects-new.a.o site.
>
> The old site was working fine until recently (see below).
> It is now broken. Therefore i presume that the new site cannot
> be updated.
>
> Over and out.
>
> -David
>
>> Discussion on making changes to the code:
>> https://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/%3C1935041.Ku0l4cXdRX%40herve-desktop%3E
>>
>> Vote thread to start the process:
>> https://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/%3C54F9DB53.1030005%40redhat.com%3E
>>
>> Sources and docs for projects-new:
>> https://projects-new.apache.org/about.html
>>
>> - Shane
>>
>> On 4/27/15 4:51 AM, Sergio Fernández wrote:
>> > Hi David,
>> >
>> > I could help on the doap part, but I see that part of the site is built
>> > using Perl, so I have an issue with that: on the one hand it's language I
>> > never felt comfortable with, on the other the RDF support is very limited.
>> >
>> > Therefore, before jumping to the see, I'd like to ask you guys a couple of
>> > details: how much that part of the site is build on doap? and how actively
>> > maintained is it? Before I could commit some time to branch it and refactor
>> > it to Python for instance, where I'm more skilled and I can warranty better
>> > RDF pipeline.
>> >
>> > So comments from you are welcomed.
>> >
>> > Cheers,
>> >
>> >
>> >
>> >
>> >
>> > On Sat, Apr 25, 2015 at 3:20 AM, David Crossley  
>> > wrote:
>> >
>> >> The 3-hourly processing of the list of DOAP files for people.apache.org
>> >> site
>> >> has been spewing errors for many days.
>> >>
>> >> I do not know enough about how the site build works
>> >> (see
>> >> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects)
>> >> and i do not have it installed locally.
>> >>
>> >> I have done some investigation.
>> >> This error message on 2015-04-17 at 15:30 was the first:
>> >>
>> >> http://mail-archives.apache.org/mod_mbox/www-site-dev/201504.mbox/%3c20150417153422.0b7c817...@minotaur.apache.org%3e
>> >>
>> >> These are the only likely changes that i can find
>> >> leading up to the error:
>> >>
>> >> Author: hboutemy
>> >> Date: Tue Apr 14 00:31:26 2015
>> >> URL: http://svn.apache.org/r1673325
>> >> Log: s/asfext:PMC/asfext:pmc/ to match the extension
>> >>
>> >> Author: gmcdonald
>> >> Date: Tue Apr 14 10:28:09 2015
>> >> URL: http://svn.apache.org/r1673402
>> >> Log: remove zookeeper entry for now
>> >> Modified: infrastructure/site-tools/trunk/projects/pmc_list.xml
>> >> (Note that there is still a zookeeper entry in
>> >> site-tools/trunk/projects/files.xml if that matters.
>> >> The commit comment is not useful.)
>> >>
>> >> However those were a few days before this error started, so they
>> >> do not seem likely.
>> >>
>> >> Perhaps it is coming from a remote project DOAP file,
>> >> but the build system does not report which file it is having
>> >> trouble with.
>> >>
>> >> These files also are utilised for people-new.apache.org with a manual
>> >> import at present.
>> >>
>> >> That is all that i have time to do, so hopefully this helps
>> >> someone else to go further.
>> >>
>> >> -David

Re: the doap processing is busted for people.a.o

[sebb]

Found out how to display basic context. UIMA have fixed their file so
hopefully the build will recover (once the SSL certificate issues have
been sorted).

On 30 April 2015 at 11:25, sebb  wrote:
> The problem seems to be the UIMA DOAP; it has the following tag:
>
> 
>
> Normal DOAPs have tags of the form:
>
> http://vcl.apache.org"; />
>
> The template utils.xsl tries to extract the PMC name (in  match="asfext:pmc") and fails.
>
> It's easy enough to do more checks on the asfext:pmc attributes, and I
> can add a message to display an error if the format is unexpected, but
> I'm having problems including suitable context in the output.
>
>
>
> On 27 April 2015 at 23:35, David Crossley  wrote:
>> On Mon, Apr 27, 2015 at 07:52:37AM -0400, Shane Curcuru wrote:
>>> Just a quick note: I'm pretty confident the medium term plan is to
>>> replace the entire projects.a.o build system (rather complicated,
>>> involving multiple steps in Perl and XSLT) with the software behind the
>>> projects-new.apache.org site.  Thus, I highly recommend looking at the
>>> below work instead of doing anything with the old Perl!
>>
>> Yes, but as i tried to explain, the old projects.a.o build has the DOAP
>> files. They are imported by an irregular manually-started build
>> process to feed the projects-new.a.o site.
>>
>> The old site was working fine until recently (see below).
>> It is now broken. Therefore i presume that the new site cannot
>> be updated.
>>
>> Over and out.
>>
>> -David
>>
>>> Discussion on making changes to the code:
>>> https://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/%3C1935041.Ku0l4cXdRX%40herve-desktop%3E
>>>
>>> Vote thread to start the process:
>>> https://mail-archives.apache.org/mod_mbox/community-dev/201503.mbox/%3C54F9DB53.1030005%40redhat.com%3E
>>>
>>> Sources and docs for projects-new:
>>> https://projects-new.apache.org/about.html
>>>
>>> - Shane
>>>
>>> On 4/27/15 4:51 AM, Sergio Fernández wrote:
>>> > Hi David,
>>> >
>>> > I could help on the doap part, but I see that part of the site is built
>>> > using Perl, so I have an issue with that: on the one hand it's language I
>>> > never felt comfortable with, on the other the RDF support is very limited.
>>> >
>>> > Therefore, before jumping to the see, I'd like to ask you guys a couple of
>>> > details: how much that part of the site is build on doap? and how actively
>>> > maintained is it? Before I could commit some time to branch it and 
>>> > refactor
>>> > it to Python for instance, where I'm more skilled and I can warranty 
>>> > better
>>> > RDF pipeline.
>>> >
>>> > So comments from you are welcomed.
>>> >
>>> > Cheers,
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > On Sat, Apr 25, 2015 at 3:20 AM, David Crossley  
>>> > wrote:
>>> >
>>> >> The 3-hourly processing of the list of DOAP files for people.apache.org
>>> >> site
>>> >> has been spewing errors for many days.
>>> >>
>>> >> I do not know enough about how the site build works
>>> >> (see
>>> >> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects)
>>> >> and i do not have it installed locally.
>>> >>
>>> >> I have done some investigation.
>>> >> This error message on 2015-04-17 at 15:30 was the first:
>>> >>
>>> >> http://mail-archives.apache.org/mod_mbox/www-site-dev/201504.mbox/%3c20150417153422.0b7c817...@minotaur.apache.org%3e
>>> >>
>>> >> These are the only likely changes that i can find
>>> >> leading up to the error:
>>> >>
>>> >> Author: hboutemy
>>> >> Date: Tue Apr 14 00:31:26 2015
>>> >> URL: http://svn.apache.org/r1673325
>>> >> Log: s/asfext:PMC/asfext:pmc/ to match the extension
>>> >>
>>> >> Author: gmcdonald
>>> >> Date: Tue Apr 14 10:28:09 2015
>>> >> URL: http://svn.apache.org/r1673402
>>> >> Log: remove zookeeper entry for now
>>> >> Modified: infrastructure/site-tools/trunk/projects/pmc_list.xml
>>> >> (Note that there is still a zookeeper entry in
>>> >> site-tools/trunk/projects/files.xml if that matters.
>>> >> The commit comment is not useful.)
>>> >>
>>> >> However those were a few days before this error started, so they
>>> >> do not seem likely.
>>> >>
>>> >> Perhaps it is coming from a remote project DOAP file,
>>> >> but the build system does not report which file it is having
>>> >> trouble with.
>>> >>
>>> >> These files also are utilised for people-new.apache.org with a manual
>>> >> import at present.
>>> >>
>>> >> That is all that i have time to do, so hopefully this helps
>>> >> someone else to go further.
>>> >>
>>> >> -David

Re: DOAP format question

[sebb]

XPath nodes are case-sensitive;  is not the same as .

The change from PMC to pmc has broken some of the reports - the PMC
name is missing from most of the entries listed in
http://projects.apache.org/indexes/pmc.html.

I don't know which case is correct, but there are currently RDF files
in project repos which use PMC rather than pmc.
These files are not easy to fix, as each project has to be asked to do them.

I can probably fix the scripts to check for both, but that is quite messy.

It would be better to use the "correct" case setting throughout
(whatever that is).
It looks like the original xsl file only used PMC, however a fairly
early revision started using pmc and continued using PMC.
Perhaps there was always an issue with some of the reports?

Until the correct setting is established, there's no point asking
projects to fix their RDF files.

I don't know if there is a formal description of the syntax anywhere.


On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
> ok, it seems I can update the source, then I did it
>
> I suppose this will be published in the next site content generation...
>
> Regards,
>
> Hervé
>
> Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
>> Hi,
>>
>> I'm working on http://projects-new.apache.org/ , which makes me dig into ASF
>> DOAP conventions
>>
>> And I found something that I think is a bug: on
>> http://projects.apache.org/docs/pmc.html , half of the page explains about
>> asfext:PMC in uppercase, while the other half is about asfext:pmc in
>> lowercase
>>
>> AFAIK, everybody is using asfext:pmc, in lowercase
>>
>> Can you confirm that it is in lowercase? Then fix the page, that is causing
>> a little bit of confusion?
>>
>> Thanks in advance,
>>
>> Hervé
>

Re: DOAP format question

[sebb]

There are 7 projects currently that maintain their own PMC RDF files.
Alll of these use asfext:PMC (not pmc).

However it looks like all of the project DOAP files use asfext:pmc
rather than PMC.

So the path of least resistance is clearly to use lower-case.


On 4 May 2015 at 01:39, sebb  wrote:
> XPath nodes are case-sensitive;  is not the same as .
>
> The change from PMC to pmc has broken some of the reports - the PMC
> name is missing from most of the entries listed in
> http://projects.apache.org/indexes/pmc.html.
>
> I don't know which case is correct, but there are currently RDF files
> in project repos which use PMC rather than pmc.
> These files are not easy to fix, as each project has to be asked to do them.
>
> I can probably fix the scripts to check for both, but that is quite messy.
>
> It would be better to use the "correct" case setting throughout
> (whatever that is).
> It looks like the original xsl file only used PMC, however a fairly
> early revision started using pmc and continued using PMC.
> Perhaps there was always an issue with some of the reports?
>
> Until the correct setting is established, there's no point asking
> projects to fix their RDF files.
>
> I don't know if there is a formal description of the syntax anywhere.
>
>
> On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
>> ok, it seems I can update the source, then I did it
>>
>> I suppose this will be published in the next site content generation...
>>
>> Regards,
>>
>> Hervé
>>
>> Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
>>> Hi,
>>>
>>> I'm working on http://projects-new.apache.org/ , which makes me dig into ASF
>>> DOAP conventions
>>>
>>> And I found something that I think is a bug: on
>>> http://projects.apache.org/docs/pmc.html , half of the page explains about
>>> asfext:PMC in uppercase, while the other half is about asfext:pmc in
>>> lowercase
>>>
>>> AFAIK, everybody is using asfext:pmc, in lowercase
>>>
>>> Can you confirm that it is in lowercase? Then fix the page, that is causing
>>> a little bit of confusion?
>>>
>>> Thanks in advance,
>>>
>>> Hervé
>>

Re: DOAP format question

[sebb]

On 4 May 2015 at 18:00, Hervé BOUTEMY  wrote:
> I'm not a RDF expert: if someone with more knowledge on this can join, it
> would be really useful
>
> But apart from seeing that most of the documentation was talking about pmc
> instead of PMC [1] (I just had to fix 1 place), I was convinced that the
> correct case is lowercase when reading asfext definition [2]
> once again, I'm not an expert then could misinterpret the content, but I read
> http://projects.apache.org/ns/asfext#pmc";> as a
> definition of pmc field, in lowercase

Perhaps; I don't know either.
It's a bit odd that the original code used PMC rather than pmc.

Also PMC is an abbreviation. RDF is also an abbreviation, and note
that the XML tag is , not .

It looks like namespaces (i.e. rdf, asfext) are lower-case, but
classes/properties (?) may be upper (rdf:RDF), lower (foaf:name) or
mixed case (foaf:Person).

>
> since I was working on projects-new.a.o, I completely forgot to try to
> generate the current projects.a.o to check that the change didn't break
> anything: sorry, I'll try it tonight

Already done.
Check the output; I think it works OK for both now.

> one question: where is the cron log of the effective run?

/home/apsite/wrkdir/projects

> Regards,
>
> Hervé
>
>
> [1] http://projects.apache.org/docs/pmc.html
>
> [2] http://projects.apache.org/ns/asfext
>
> Le lundi 4 mai 2015 01:39:45 sebb a écrit :
>> XPath nodes are case-sensitive;  is not the same as
>> .
>>
>> The change from PMC to pmc has broken some of the reports - the PMC
>> name is missing from most of the entries listed in
>> http://projects.apache.org/indexes/pmc.html.
>>
>> I don't know which case is correct, but there are currently RDF files
>> in project repos which use PMC rather than pmc.
>> These files are not easy to fix, as each project has to be asked to do them.
>>
>> I can probably fix the scripts to check for both, but that is quite messy.
>>
>> It would be better to use the "correct" case setting throughout
>> (whatever that is).
>> It looks like the original xsl file only used PMC, however a fairly
>> early revision started using pmc and continued using PMC.
>> Perhaps there was always an issue with some of the reports?
>>
>> Until the correct setting is established, there's no point asking
>> projects to fix their RDF files.
>>
>> I don't know if there is a formal description of the syntax anywhere.
>>
>> On 14 April 2015 at 00:00, Hervé BOUTEMY  wrote:
>> > ok, it seems I can update the source, then I did it
>> >
>> > I suppose this will be published in the next site content generation...
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> > Le dimanche 12 avril 2015 04:41:22 Hervé BOUTEMY a écrit :
>> >> Hi,
>> >>
>> >> I'm working on http://projects-new.apache.org/ , which makes me dig into
>> >> ASF DOAP conventions
>> >>
>> >> And I found something that I think is a bug: on
>> >> http://projects.apache.org/docs/pmc.html , half of the page explains
>> >> about
>> >> asfext:PMC in uppercase, while the other half is about asfext:pmc in
>> >> lowercase
>> >>
>> >> AFAIK, everybody is using asfext:pmc, in lowercase
>> >>
>> >> Can you confirm that it is in lowercase? Then fix the page, that is
>> >> causing
>> >> a little bit of confusion?
>> >>
>> >> Thanks in advance,
>> >>
>> >> Hervé
>

Re: DOAP format question

[sebb]

On 4 May 2015 at 19:37, Sergio Fernández  wrote:
> RDF can be serialized as XML, but the XML tool chain is not well suitable to
> process RDF. That's what a meant when I early commented I was happy to
> contribute proper DOAP/RDF infrastructure to projects-new.a.o.
>
> Back to the current issues... see my comments inline.
>
> On Mon, May 4, 2015 at 7:51 PM, sebb  wrote:
>>
>> On 4 May 2015 at 18:00, Hervé BOUTEMY  wrote:
>> > I'm not a RDF expert: if someone with more knowledge on this can join,
>> > it
>> > would be really useful
>> >
>> > But apart from seeing that most of the documentation was talking about
>> > pmc
>> > instead of PMC [1] (I just had to fix 1 place), I was convinced that the
>> > correct case is lowercase when reading asfext definition [2]
>> > once again, I'm not an expert then could misinterpret the content, but I
>> > read
>> > http://projects.apache.org/ns/asfext#pmc";> as a
>> > definition of pmc field, in lowercase
>>
>> Perhaps; I don't know either.
>> It's a bit odd that the original code used PMC rather than pmc.
>
>
> The term must be used exactly in the same way it is defined by the
> namespace/vocabulary/ontology, otherwise won't be processed as expected.

Theoretically, but not in this case.

The processing is defined by XSL files that were manually created.
So whatever the files are coded to expect is what will work.

This may or may not be the same as the definition.

In fact at present the XSL files have been coded to accept both
asfext:PMC and asfext:pmc.
Only one of these can be correct in terms of the formal definition.

The problem is that it is not clear what the formal definition is.

>>
>> Also PMC is an abbreviation. RDF is also an abbreviation, and note
>> that the XML tag is , not .
>>
>> It looks like namespaces (i.e. rdf, asfext) are lower-case, but
>> classes/properties (?) may be upper (rdf:RDF), lower (foaf:name) or
>> mixed case (foaf:Person).
>
>
> That's the best practice, yes: classes in UpperCamelCases, and properties in
> lowerCamelCase.
>
> The root element  is a special case, not a regular term, but part
> of the RDF/XML serialization.
>
> Hope that helps.

It would help to know what the formal definition of the asfext
namespace actually means.

Also if it is possible to validate that the various RDF files are
correct according to the formal definitions.
PMCs could then submit their files for checking.

> Cheers,
>
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[sebb]

On 4 May 2015 at 20:50, Sergio Fernández  wrote:
>
>
> On Mon, May 4, 2015 at 9:04 PM, sebb  wrote:
>>
>> > The term must be used exactly in the same way it is defined by the
>> > namespace/vocabulary/ontology, otherwise won't be processed as expected.
>>
>> Theoretically, but not in this case.
>>
>> The processing is defined by XSL files that were manually created.
>> So whatever the files are coded to expect is what will work.
>> This may or may not be the same as the definition.
>>
>> In fact at present the XSL files have been coded to accept both
>> asfext:PMC and asfext:pmc.
>> Only one of these can be correct in terms of the formal definition.
>
>
> OK, but that's because whoever code the XSLT decided to be defensive to such
> interpretation.

If you read back in this thread you will see that I did this in order
to support both asfext:PMC and asfext:pmc.

> But that does not mean is right.

The code is right in the sense that it works with the input files that
are provided.

My point was that the formal definition does not affect how the XSL files work.
All that matters is that the XSL file agrees with what is in the input files.
They could use asfext:XyZ provided that the XSL files were coded to expect that.

Nor does the formal definition affect validation of the input RDF
files otherwise there would not be conflicting references in the RDF
files, and we would not be having this discussion.

>>
>> The problem is that it is not clear what the formal definition is.
>
> No, the formal definition is clear at the ns file:
> http://projects.apache.org/ns/asfext#pmc
>>
>>
>> It would help to know what the formal definition of the asfext
>> namespace actually means.
>
>
> Ok, let's try to put it eas. This is the definition from the namespace (rdf
> vocabulary):
>
> http://projects.apache.org/ns/asfext#pmc";>
>   http://projects.apache.org/ns/asfext#"; />
>   PMC
>   ASF Project Management
> Committee
>   http://www.w3.org/2000/01/rdf-schema#Literal"; />
>rdf:resource="http://www.w3.org/2000/01/rdf-schema#label"; />
>   http://usefulinc.com/ns/doap#"; />
> 
>
> That means:
>
> * the exactURI <http://projects.apache.org/ns/asfext#pmc> (or abbreviated as
> asfext:pmc if the prefix declaration is available) defines the property
> name, exactly "pmc", other syntactic version would not match the formal
> definition.
> * the label is just the human-readable label of the property, can't be use
> as property
> * comment is the same, just a comment to be read
> * subproperty means that the value of the property has a specialized meaning
> over the general purpose label
> * domain is the type of objects that can use that property, in this case
> doap:Project instances
> *  range defines the values in ca take, int his case a literal, a basic
> type, such as string or int
>
> And that's more of less the semantics behind such definition of the
> property. Hope it helps to understand.

Yes, that is useful.

>>
>> Also if it is possible to validate that the various RDF files are
>> correct according to the formal definitions.
>> PMCs could then submit their files for checking.
>
>
> I think we can discuss that infrastructure for the new site. I'm happy to
> help. Python provides the required libraries. I'll open a thread, probably
> tomorrow.

I think there needs to be a way for PMCs to check their RDF files
against the formal definitions.
For example, a CGI script that accepts the URL of a file.

> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[sebb]

On 5 May 2015 at 07:06, Hervé BOUTEMY  wrote:
> Le mardi 5 mai 2015 01:05:31 sebb a écrit :
>> > OK, but that's because whoever code the XSLT decided to be defensive to
>> > such interpretation.
>>
>> If you read back in this thread you will see that I did this in order
>> to support both asfext:PMC and asfext:pmc.
>>
>> > But that does not mean is right.
>>
>> The code is right in the sense that it works with the input files that
>> are provided.
> +1
> that's a temporary workaround that we should try to not need any more in the
> future

Ideally, yes, but as already noted that is not trivial.

> [...]
>
>> >> Also if it is possible to validate that the various RDF files are
>> >> correct according to the formal definitions.
>> >> PMCs could then submit their files for checking.
>> >
>> > I think we can discuss that infrastructure for the new site. I'm happy to
>> > help. Python provides the required libraries. I'll open a thread, probably
>> > tomorrow.
>>
>> I think there needs to be a way for PMCs to check their RDF files
>> against the formal definitions.
>> For example, a CGI script that accepts the URL of a file.
> +1
> I tried W3C checker, but as it is only a syntax checker, it checked only
> syntax, not references to the namespace
> and I couldn't find any other useful tool :(
>
> Other tools to make effective use of the DOAP files would be useful too: but I
> completely agree that the first priority seems to have a more complete checker

It's possible to add warning checks to the cron job scripts, but this
will create a lot of noisy e-mails until projects have been notified
and fixed their files.
Experience shows that fixing DOAPs can take months for some PMCs.

One approach that might be worth trying is creating an additional
on-demand report that checks the list of RDFs for known issues.
Initially it could just check for asfext:PMC, but could be extended as
other issues are found or better syntax checking is available.

Checking for such simple typos could be done with almost any scripting language.

The RDF files are listed in

https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
(DOAPs)
and
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml
(PMC definitions)

Most of the PMC definitions are stored locally, and have already been fixed.

> Regards,
>
> Hervé
>
>>
>> > Cheers,
>> >
>> > --
>> > Sergio Fernández
>> > Partner Technology Manager
>> > Redlink GmbH
>> > m: +43 6602747925
>> > e: sergio.fernan...@redlink.co
>> > w: http://redlink.co
>

Re: DOAP format question

[sebb]

On 5 May 2015 at 14:58, Sergio Fernández  wrote:
> On Tue, May 5, 2015 at 12:51 PM, sebb  wrote:
>>
>> Checking for such simple typos could be done with almost any scripting
>> language.
>>
>> The RDF files are listed in
>>
>>
>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
>> (DOAPs)
>> and
>>
>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml
>> (PMC definitions)
>>
>> Most of the PMC definitions are stored locally, and have already been
>> fixed.
>
>
> OK, in the next day I'll provide a basic implementation (Python+RDFLib) that
> provides some kind of validation and reporting of pitfails. So later we can
> extend that add proper DOAP support to the projects-new.a.o.
>
> One question, sebb, how the site development is organize? Do you use jira or
> something as any other project does? Just to do the things properly
> according your guidelines.

It's not a regular project.
I don't know who "owns" the code - possibly Infra or maybe ComDev.

I have just been making the occasional fix as I notice problems.

The site-dev and dev@community mailing list are probably the place to
discuss changes.

> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[sebb]

On 5 May 2015 at 16:57, Sergio Fernández  wrote:
> Hi,
>
> On Tue, May 5, 2015 at 4:39 PM, sebb  wrote:
>>
>> > One question, sebb, how the site development is organize? Do you use
>> jira or
>> > something as any other project does? Just to do the things properly
>> > according your guidelines.
>>
>> It's not a regular project.
>> I don't know who "owns" the code - possibly Infra or maybe ComDev.
>>
>> I have just been making the occasional fix as I notice problems.
>>
>> The site-dev and dev@community mailing list are probably the place to
>> discuss changes.
>
>
> OK, then I stay in this thread for discussion about this.
>
> I didn't have much time today, but what I already did was implementing the
> basics of how the DOAP processing could look like. For the moment is at
> https://github.com/wikier/asf-doap until I'll get something more
> functional, then I'll commit it to the asf repo.
>
> Basically what if currently does that simple code is to get all DOAP/PMC
> files and report some basics (size). You can run it by yourself executing:
>
> $ python doap.py
>
> What I can already say is that I do not understand what
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
> aim to represent.

This is the default location for the PMC data [1] files which provide
data about the PMC.
A single such file may be referenced by multiple DOAPs.
E.g. all the Commons components refer to the same PMC data file.

The contents and locations of the various files are documented on the site.

[1] http://projects.apache.org/docs/pmc.html

> Because asfext:pmc is defined as a property in the
> namespace (as we discussed couple of days ago), so I missed the subject
> where it refers to (normally it should be used <http://subject> asfext:pmc
> <...>). According that usage of the term, I guess they actually wanted to
> define a class.
>
> But please, let me evolve a bit more the code for giving you some basic
> tools, and then I can discuss further such aspects.
>
> Cheers.
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

DOAP validation code (was DOAP format question)

[sebb]

On 5 May 2015 at 16:57, Sergio Fernández  wrote:
> Hi,



> I didn't have much time today, but what I already did was implementing the
> basics of how the DOAP processing could look like. For the moment is at
> https://github.com/wikier/asf-doap until I'll get something more
> functional, then I'll commit it to the asf repo.
>
> Basically what if currently does that simple code is to get all DOAP/PMC
> files and report some basics (size). You can run it by yourself executing:
>
> $ python doap.py
>


I've tried the code, and it does find some syntax errors.

[The code needs to be tweaked so it catches & reports syntax errors
rather than failing]

However, it does not seem to detect asfext:PMC as an error - it seems
to be case-blind.

I cannot work out whether the library supports exact case checking,
and if so, how to enable this.

Nor does it appear to detect invalid tags (perhaps that's why case
checking does not work).

Re: DOAP validation code (was DOAP format question)

[sebb]

On 8 May 2015 at 11:51, sebb  wrote:
> On 5 May 2015 at 16:57, Sergio Fernández  wrote:
>> Hi,
>
> 
>
>> I didn't have much time today, but what I already did was implementing the
>> basics of how the DOAP processing could look like. For the moment is at
>> https://github.com/wikier/asf-doap until I'll get something more
>> functional, then I'll commit it to the asf repo.
>>
>> Basically what if currently does that simple code is to get all DOAP/PMC
>> files and report some basics (size). You can run it by yourself executing:
>>
>> $ python doap.py
>>
> 
>
> I've tried the code, and it does find some syntax errors.
>
> [The code needs to be tweaked so it catches & reports syntax errors
> rather than failing]
>
> However, it does not seem to detect asfext:PMC as an error - it seems
> to be case-blind.
>
> I cannot work out whether the library supports exact case checking,
> and if so, how to enable this.
>
> Nor does it appear to detect invalid tags (perhaps that's why case
> checking does not work).

Also, only the first error is reported.
Ideally the validation needs to find all the errors in one pass.

It would be OK if the code gave up for serious syntax errors such as
mismatched tags, but where there are multiple other errors these
should be reported without needing to fix them one by one.

Re: DOAP format question

[sebb]

On 11 May 2015 at 07:46, Sergio Fernández  wrote:
> Hi sebb,
>
> On Tue, May 5, 2015 at 7:08 PM, sebb  wrote:
>>
>> > What I can already say is that I do not understand what
>> >
>> > https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files
>> > aim to represent.
>>
>> This is the default location for the PMC data [1] files which provide
>> data about the PMC.
>> A single such file may be referenced by multiple DOAPs.
>> E.g. all the Commons components refer to the same PMC data file.
>
>
> I do understand how DOAP is being used, and I guess it has been wrong from
> the very beginning.
>
> Taking commons-lang as example, they currently have:
>
>   http://commons.apache.org/lang/";>
> http://commons.apache.org/"/>
>   
>
> which does not really link (in RDF) to the file
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files/commons.rdf

There is some special-case XSL code which does this conversion.
If the rdf:resource URL does not end in ".rdf", then the the http://
and .apache.org/ header and trailer are stripped off, leaving
"commons"
This is then assumed to be the name of an RDF file in data_files/

I've no idea why the actual URL was not required - perhaps it was
thought that the data_files directory location might not be stable.
This was in the code before I got involved.

> RDF is a directly-label graph data model that uses URIs as names. Therefore
> the URI you put as as value of a property has a meaning, you should be able
> to directly fetch it, but not having such implicit rules where files a
> located in a svn. I guess apply that would mean a major restructuration of
> the current DOAP data, but that's something I can help to do to all PMCs.

Changing it now would be very time-consuming and tedious.
However, if this were to be done, I suggest dropping the data_files
directory entirely and insisting that PMCs host their own PMC data
files.
This would mean adding a new script to create a basic PMC file.

Another aspect of this is where the RDF files are stored.
These need to be under the control of the project, and it makes sense
to keep them under source control (SC).
However SC URLs tend to change, thus breaking the project build.
Therefore I suggest it would be best if the RDF files were stored
under the website URL - which is much less prone to change, and
redirects can deal with any required changes.
Website source is nowadays stored in SC anyway.

Another aspect is that DOAP files are not useful in source/binary releases.

> Beside that issue on linking, I have come to the conclusions that asfext
> actually have the sense of two things:
>
> * asfext:pmc is the property that links a project with its PMC
> * asfext:PMC should be a class for referring to PMCs
>
> And that completely valid, but the tooling should know the difference and
> not just try to fix wrong data.
>
> Let me try to find some time to put some of these things in order to have a
> better overview...
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: DOAP format question

[sebb]

On 11 May 2015 at 13:21, Sergio Fernández  wrote:
> Hi,
>
> On Mon, May 11, 2015 at 1:13 PM, sebb  wrote:
>>
>> There is some special-case XSL code which does this conversion.
>> If the rdf:resource URL does not end in ".rdf", then the the http://
>> and .apache.org/ header and trailer are stripped off, leaving
>> "commons"
>> This is then assumed to be the name of an RDF file in data_files/
>>
>
> Then such " assumption" is a custom patch, it' d need to be know by any
> other tool. Therefore no external tool is able to process such data.

Agreed, but I suspect think that may not be the only assumption made
by the XSL scripts.
IMO it would be best to establish all the changes that need to be made
in one hit rather than to have to keep asking PMCs to fix another
aspect of their DOAPs.

>
>> > RDF is a directly-label graph data model that uses URIs as names.
>> Therefore
>> > the URI you put as as value of a property has a meaning, you should be
>> able
>> > to directly fetch it, but not having such implicit rules where files a
>> > located in a svn. I guess apply that would mean a major restructuration
>> of
>> > the current DOAP data, but that's something I can help to do to all PMCs.
>>
>> Changing it now would be very time-consuming and tedious.
>> However, if this were to be done, I suggest dropping the data_files
>> directory entirely and insisting that PMCs host their own PMC data
>> files. This would mean adding a new script to create a basic PMC file.
>>
>
> We can provides some infrastructure, either to validate or create whatever
> in the right way.
>
>
>> Another aspect of this is where the RDF files are stored.
>> These need to be under the control of the project, and it makes sense
>> to keep them under source control (SC).
>> However SC URLs tend to change, thus breaking the project build.
>> Therefore I suggest it would be best if the RDF files were stored
>> under the website URL - which is much less prone to change, and
>> redirects can deal with any required changes.
>> Website source is nowadays stored in SC anyway.
>>
>
> FMPOV the cleanest approach would be to serve all that files from each web
> site.

Yes, that was my point.

>
>> Another aspect is that DOAP files are not useful in source/binary releases.
>>
>
> We can workout a DOAP extension for such feature.

I don't think that would be a good idea.
If the DOAP file is part of the source release, how can it have the
correct release date for the release it is part of?
Also, source trees are duplicated in tags and branches; it's confusing
to have multiple copies of a DOAP.

The point is that DOAPs are meta data about a project and its releases.
They are not data that is useful to the project code.

> I just need time ;-)
>
> Cheers,
>
> --
> Sergio Fernández
> Partner Technology Manager
> Redlink GmbH
> m: +43 6602747925
> e: sergio.fernan...@redlink.co
> w: http://redlink.co

Re: projects-new.a.o updates

[sebb]

On 14 May 2015 at 23:38, Hervé BOUTEMY  wrote:
> Hi,
>
> I seriously updated content:
> - *every* TLP is listed, even when no DOAP file has been written [1]
> - TLP project can be displayed, even without DOAP and provide link to every
> sub-project [2]
> - when a TLP has a "main sub-project" with its DOAP file, data from TLP and
> data from DOAP subproject are clearly separate [3]

The URLs [1] [2] [3] use the same namespace for PMCs and projects as
well as generic queries.
This may cause name clashes in future - e.g. a PMC called "numbers"
would clash with the "numbers" view of the data.
It would be better to use distinct namespaces for distinct types of item.

> This makes more clear what DOAP is used for (and why we need projects hand-
> writing some data, but not everything)
>
> I didn't update target doap urls [4] since I don't know what precisely to do:
> copy doap files that were processed, in appropriate directory, and with
> consistent filename than generated json?

What are the target DOAP files used for?
Where do they originate?

> Feedback expected :)
>
> Regards,
>
> Hervé
>
>
> [1] https://projects-new.apache.org/projects.html?pmc
>
> [2] https://projects-new.apache.org/project.html?commons
>
> [3] https://projects-new.apache.org/project.html?ant
>
> [4] https://projects-new.apache.org/doap/

Re: Project Visualization Tool...

[sebb]

On 5 May 2015 at 07:38, Hervé BOUTEMY  wrote:
> Le samedi 18 avril 2015 10:55:00 Shane Curcuru a écrit :
>> LOL, below.
>>
>> I highly recommend separating the model from the views, so that we can
>> efficiently enable our volunteer's energy here to actually accomplish
>> something valuable.
> +1
>
>>
>> So let's work on stuff to do that excites us, but remember to keep the
>> technical problems focused on what this PMC believes we can truly create
>> and maintain going forward.
>>
>> Don't worry about everything at once.  Just focus on separate bits:
>>
>> - Method to scrape source data from our various definitive or even not
>> completely definitive but very close places (txt files, websites, LDAP)
>>
>> - Model and data source that actually holds info about committer lists
>> and project metadata.  I'm betting Daniels' projects-new does this very
>> well already.
> +1 it's a perfect starting point: just need to document and continue to
> improve
> then I started by documenting what are the current information sources used
> for generating projects-new.a.o json files:
> see https://projects-new.apache.org/json/foundation/ and
> http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/README.txt?view=markup
>
>>
>> --
>> - Stable API to get at that model.  Would be really nice if we did this
>> just once, so that people working above here don't interfere with people
>> working below here.
>> --
> +1
>
> Since there are multiple information sources for TLPs/PMCs/committers, I think
> I will consolidate to avoid what's currently happenning: the projects.js (ie
> one visualization) contains a lot of code to consolidate the multiple
> information sources
> If the consolidation is done server side, in the generation scripts, it will
> be easier to use for projects.js and any other tool wanting to do other future
> visualizations
>
>>
>> - Visualizations.  There's lots of different stuff to do here, and I
>> think it'd be super helpful if everyone just did something they want,
>> and then show us the code.
> +1
>
>>
>> Sure, there's lots of "what is important" to focus on, but I for one
>> would love to see real examples of all the cool visualization libraries
>> out there, and I know a couple folks already use some of them.
>>
>> - UI additions for the projects-new/projects websites, which are
>> featured at the top level of a.o.  I.e., this is our "projects
>> directory", how can we better lead people who arrive there at what they
>> want to know?
> at the moment, I'm not trying to add any new UI, but improve the consistency
> of displayed data, since current state is not really consistent: some PMCs are
> not displayed, probably because they have not provided any DOAP file. But even
> without DOAP file, we have a lot of data to display for a TLP, most of what we
> display for a TLP (ie a project that does not have any subproject)
>
> I think we really have some data model problem here regarding what is a
> "project's DOAP file": sometimes, a project is a PMC, sometimes a project is a
> deliverable, more like what is called in projectsnew.a.o a "sub-project"

That is not how I understand DOAPs.

DOAP == Description Of A Project

i.e. some releaseable artifact.

A single PMC may have multiple projects, each with its own releases
and repositories.
These are modelled quite well in the DOAPs that PMCs have created.

Information about the PMC which manages the projects is NOT stored in
a DOAP, it is stored in a PMC data file.

This is referenced from a DOAP using



where URL is either an actual URL of a PMC data file or a dummy URL e.g.



which leads to a file here:

https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/data_files/.rdf


> if you look at https://projects-new.apache.org/projects.html?pmc, typical
> cases for that are:
> - Incubator: there is the "the Incubator project", displayed without DOAP file
> since the incubator has special source info, and many sub-projects which
> provide DOAP files
> - Commons: there is no "Commons' DOAP file", then no TLP... on sub-project is
> quasi randomly chosen... Common's DOAP file, if it existed would not release
> anything, it"s a pure "organizational" project

There is an ambiguity here: project can mean an organisational entity
and project can mean a releaseable artifact.

There are different RDF files for the two meanings; only the artifact
has an associated DOAP.

> - Ant: there is an Ant DOAP file that represent the TLP and the main released
> artifact

No, it only links to the TLP = PMC data file, it does not represent the TLP.
The Ant DOAP file only represents the Ant product.

> I chose Commons, but it could have been HttpComponents or Logging Services, or
> Lucene (Lucene have been very clear that there is a "Lucene core" sub-
> project), Web Services, Axis, Xalan, Xerces, XML Graphics, Attic, Creadur, DB,
> jUDDI, Tcl
>
> I chose Ant, but it could have been Velocity, MINA, Directory, HTTP Server,
> MyFaces, T

Re: Project Visualization Tool...

[sebb]

On 15 May 2015 at 23:28, Hervé BOUTEMY  wrote:
> Le vendredi 15 mai 2015 15:34:47 sebb a écrit :
>> > I think we really have some data model problem here regarding what is a
>> > "project's DOAP file": sometimes, a project is a PMC, sometimes a project
>> > is a deliverable, more like what is called in projectsnew.a.o a
>> > "sub-project"
>> That is not how I understand DOAPs.
>>
>> DOAP == Description Of A Project
>>
>> i.e. some releaseable artifact.
>>
>> A single PMC may have multiple projects, each with its own releases
>> and repositories.
>> These are modelled quite well in the DOAPs that PMCs have created.
> +1
>
>> Information about the PMC which manages the projects is NOT stored in
>> a DOAP, it is stored in a PMC data file.
>> This is referenced from a DOAP using
>>
>> 
>>
>> where URL is either an actual URL of a PMC data file or a dummy URL e.g.
>>
>> 
>>
>> which leads to a file here:
>>
>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/da
>> ta_files/.rdf
> I'm not RDF expert, but this Apache-specific algorithm to find PMC rdf file 
> seems
> strange: I understand it is coded/known from projects.a.o xslt transformation

Yes.

> But this should be usable from any RDF tooling, no?

It's not currently usable except by using special processing.

The problem is that the shorthand URL is used by all but about 4 of
the PMCs, so it would be a major challenge to get this fixed.

Some PMCs are quick to fix such issues; some may take weeks or months
to fix even a simple error.

> Another problem I see with these PMC data rdf files is that they seem to not 
> be
> really maintained: I doubt PMCs update PMC data rdf files on each PMC Chair
> change.

Yes.

> That's why I had the idea of generating/updating the chair when
> parsing committee-info.txt.

Fair enough, but that does not mean the code needs to create yet
another RDF file.

> But other information manually written in current PMC data rdf files can't be
> found anywhere else, AFAIK.
>

Yes.

> Last problem: I personnally really didn't understand this PMC data rdf file
> until now. I don't know who understands it :)
> IMHO, the magic algorithm to find the rdf file is a root cause.

The PMC data file is documented here:

http://projects.apache.org/docs/pmc.html

>> > if you look at https://projects-new.apache.org/projects.html?pmc, typical
>> > cases for that are:
>> > - Incubator: there is the "the Incubator project", displayed without DOAP
>> > file since the incubator has special source info, and many sub-projects
>> > which provide DOAP files
>> > - Commons: there is no "Commons' DOAP file", then no TLP... on sub-project
>> > is quasi randomly chosen... Common's DOAP file, if it existed would not
>> > release anything, it"s a pure "organizational" project
>>
>> There is an ambiguity here: project can mean an organisational entity
>> and project can mean a releaseable artifact.
>>
>> There are different RDF files for the two meanings; only the artifact
>> has an associated DOAP.
>>
>> > - Ant: there is an Ant DOAP file that represent the TLP and the main
>> > released artifact
>>
>> No, it only links to the TLP = PMC data file, it does not represent the TLP.
>> The Ant DOAP file only represents the Ant product.
> ok, IIUC, I should rephrase https://projects-new.apache.org/project.html?ant :
> 1. "Top Level Project data:" to "Apache Committee data:"
> 2. "Project established:" to "Committee established:"

That does not seem necessary.

> 3. "Sub-projects (8):" to "Projects (8):", eventually boldening the TLP if one
> is the TLP

No - none of the projects are the TLP.
The TLP / PMC is not the same as any of its projects.

Most PMCs happen to have the same name as one of their projects, but
they are distinct entities.

To take the Ant example, there needs to be an Ant PMC/TLP page and a
separate Ant project page.
These should be linked somehow.

> and I should rename tlps.json to committees.json (and update code accordingly)

No need.

> then on https://projects-new.apache.org/ , do we really want to graph TLPs
> evolution or committees?

No idea

> I suppose commons can be called a TLP, even if it does not have any "main"
> project that is the effective TLP

Yes, Commons is a TLP/PMC.

I don't think it's helpful to think of PMCs having a "main" project.

PMCs have one or more projects; each project has a single PMC.

>

Re: projects-new.a.o updates

[sebb]

On 15 May 2015 at 22:08, Hervé BOUTEMY  wrote:
> Le vendredi 15 mai 2015 14:02:52 sebb a écrit :
>> On 14 May 2015 at 23:38, Hervé BOUTEMY  wrote:
>> > Hi,
>> >
>> > I seriously updated content:
>> > - *every* TLP is listed, even when no DOAP file has been written [1]
>> > - TLP project can be displayed, even without DOAP and provide link to
>> > every
>> > sub-project [2]
>> > - when a TLP has a "main sub-project" with its DOAP file, data from TLP
>> > and
>> > data from DOAP subproject are clearly separate [3]
>>
>> The URLs [1] [2] [3] use the same namespace for PMCs and projects as
>> well as generic queries.
>> This may cause name clashes in future - e.g. a PMC called "numbers"
>> would clash with the "numbers" view of the data.
> not exactly: [1] is project*s*.html while the 2 others are project.html
> so no clash between projects listing type and project/PMC

Ah, OK, I'd not noticed the subtle difference.

However there is still a potential name clash: the Ant PMC is not the
same as the Ant project produced by the Ant PMC.

>> It would be better to use distinct namespaces for distinct types of item.
> I don't think a clash between a PMC and a project can happen: if they have the
> same id, it should be TLP's PMC, isn't it?

No, they are not the same thing.
A project is not a PMC, though they may have the same name.

A PMC is a group of people; a project is a software artifact.

>>
>> > This makes more clear what DOAP is used for (and why we need projects
>> > hand-
>> > writing some data, but not everything)
>> >
>> > I didn't update target doap urls [4] since I don't know what precisely to
>> > do: copy doap files that were processed, in appropriate directory, and
>> > with consistent filename than generated json?
>>
>> What are the target DOAP files used for?
> I don't know: I coded what I understood from discussion with Sergio Fernández
> But I admit I don't really know if this is a good idea or not
>
>> Where do they originate?
> {tlp-id}/pmc.rdf is generated with info parsed from committee-info.txt by
> http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/import/parsecommittees.py?view=markup
> (with the help of http://www.apache.org/#projects-list scraped info for short
> description)
>
> And the idea behind rdf copy was just to copy files in a uniform location from
> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml
>  to ease DOAP finding
> just an idea
>
> Regards,
>
> Hervé
>
>>
>> > Feedback expected :)
>> >
>> > Regards,
>> >
>> > Hervé
>> >
>> >
>> > [1] https://projects-new.apache.org/projects.html?pmc
>> >
>> > [2] https://projects-new.apache.org/project.html?commons
>> >
>> > [3] https://projects-new.apache.org/project.html?ant
>> >
>> > [4] https://projects-new.apache.org/doap/
>

Re: Project Visualization Tool...

[sebb]

On 16 May 2015 at 00:30, sebb  wrote:
> On 15 May 2015 at 23:28, Hervé BOUTEMY  wrote:
>> Le vendredi 15 mai 2015 15:34:47 sebb a écrit :
>>> > I think we really have some data model problem here regarding what is a
>>> > "project's DOAP file": sometimes, a project is a PMC, sometimes a project
>>> > is a deliverable, more like what is called in projectsnew.a.o a
>>> > "sub-project"
>>> That is not how I understand DOAPs.
>>>
>>> DOAP == Description Of A Project
>>>
>>> i.e. some releaseable artifact.
>>>
>>> A single PMC may have multiple projects, each with its own releases
>>> and repositories.
>>> These are modelled quite well in the DOAPs that PMCs have created.
>> +1
>>
>>> Information about the PMC which manages the projects is NOT stored in
>>> a DOAP, it is stored in a PMC data file.
>>> This is referenced from a DOAP using
>>>
>>> 
>>>
>>> where URL is either an actual URL of a PMC data file or a dummy URL e.g.
>>>
>>> 
>>>
>>> which leads to a file here:
>>>
>>> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/da
>>> ta_files/.rdf
>> I'm not RDF expert, but this Apache-specific algorithm to find PMC rdf file 
>> seems
>> strange: I understand it is coded/known from projects.a.o xslt transformation
>
> Yes.
>
>> But this should be usable from any RDF tooling, no?
>
> It's not currently usable except by using special processing.
>
> The problem is that the shorthand URL is used by all but about 4 of
> the PMCs, so it would be a major challenge to get this fixed.
>
> Some PMCs are quick to fix such issues; some may take weeks or months
> to fix even a simple error.
>
>> Another problem I see with these PMC data rdf files is that they seem to not 
>> be
>> really maintained: I doubt PMCs update PMC data rdf files on each PMC Chair
>> change.
>
> Yes.
>
>> That's why I had the idea of generating/updating the chair when
>> parsing committee-info.txt.
>
> Fair enough, but that does not mean the code needs to create yet
> another RDF file.
>
>> But other information manually written in current PMC data rdf files can't be
>> found anywhere else, AFAIK.
>>
>
> Yes.
>
>> Last problem: I personnally really didn't understand this PMC data rdf file
>> until now. I don't know who understands it :)
>> IMHO, the magic algorithm to find the rdf file is a root cause.
>
> The PMC data file is documented here:
>
> http://projects.apache.org/docs/pmc.html
>
>>> > if you look at https://projects-new.apache.org/projects.html?pmc, typical
>>> > cases for that are:
>>> > - Incubator: there is the "the Incubator project", displayed without DOAP
>>> > file since the incubator has special source info, and many sub-projects
>>> > which provide DOAP files
>>> > - Commons: there is no "Commons' DOAP file", then no TLP... on sub-project
>>> > is quasi randomly chosen... Common's DOAP file, if it existed would not
>>> > release anything, it"s a pure "organizational" project
>>>
>>> There is an ambiguity here: project can mean an organisational entity
>>> and project can mean a releaseable artifact.
>>>
>>> There are different RDF files for the two meanings; only the artifact
>>> has an associated DOAP.
>>>
>>> > - Ant: there is an Ant DOAP file that represent the TLP and the main
>>> > released artifact
>>>
>>> No, it only links to the TLP = PMC data file, it does not represent the TLP.
>>> The Ant DOAP file only represents the Ant product.
>> ok, IIUC, I should rephrase https://projects-new.apache.org/project.html?ant 
>> :
>> 1. "Top Level Project data:" to "Apache Committee data:"
>> 2. "Project established:" to "Committee established:"
>
> That does not seem necessary.
>
>> 3. "Sub-projects (8):" to "Projects (8):", eventually boldening the TLP if 
>> one
>> is the TLP
>
> No - none of the projects are the TLP.
> The TLP / PMC is not the same as any of its projects.
>
> Most PMCs happen to have the same name as one of their projects, but
> they are distinct entities.

Note that the Creadur PMC does not have a Creadur project.

> To take the Ant example, there needs to be an Ant PMC/TLP page and a
> separate Ant proj

Re: projects-new.a.o updates

[sebb]

On 16 May 2015 at 08:22, Hervé BOUTEMY  wrote:
> Le samedi 16 mai 2015 00:36:03 sebb a écrit :
>> On 15 May 2015 at 22:08, Hervé BOUTEMY  wrote:
>> > Le vendredi 15 mai 2015 14:02:52 sebb a écrit :
>> >> On 14 May 2015 at 23:38, Hervé BOUTEMY  wrote:
>> >> > Hi,
>> >> >
>> >> > I seriously updated content:
>> >> > - *every* TLP is listed, even when no DOAP file has been written [1]
>> >> > - TLP project can be displayed, even without DOAP and provide link to
>> >> > every
>> >> > sub-project [2]
>> >> > - when a TLP has a "main sub-project" with its DOAP file, data from TLP
>> >> > and
>> >> > data from DOAP subproject are clearly separate [3]
>> >>
>> >> The URLs [1] [2] [3] use the same namespace for PMCs and projects as
>> >> well as generic queries.
>> >> This may cause name clashes in future - e.g. a PMC called "numbers"
>> >> would clash with the "numbers" view of the data.
>> >
>> > not exactly: [1] is project*s*.html while the 2 others are project.html
>> > so no clash between projects listing type and project/PMC
>>
>> Ah, OK, I'd not noticed the subtle difference.
>>
>> However there is still a potential name clash: the Ant PMC is not the
>> same as the Ant project produced by the Ant PMC.
> yes, even if Ant is one of the few committees that explicitely makes a
> difference between the committee and the project even if they share the same
> name
>
>>
>> >> It would be better to use distinct namespaces for distinct types of item.
>> >
>> > I don't think a clash between a PMC and a project can happen: if they have
>> > the same id, it should be TLP's PMC, isn't it?
>>
>> No, they are not the same thing.
>> A project is not a PMC, though they may have the same name.
>>
>> A PMC is a group of people;
> ok
> question: are committers a second group of people attached to a PMC?

Not always.
The committers LDAP groups are basically used to grant permission to
access code repos.
Not all PMCs use them, for example Subversion (and more recently
Commons) allow any ASF committer (another LDAP group) write access to
their source code.

Incubator committer groups are not defined in LDAP but have the same
purpose as the LDAP ones.

> To me,
> that's the case, even if some projects have their own committers list (like
> incubator projects, or I suppose the lucene-* or hive-hcatalog or xmlgraphics-
> fop & xmlgraphics-batik LDAP groups representing projects that didn't write
> DOAP file)
> see http://people.apache.org/committers-by-project.html
>

The lucene/hive/etc groups are historic and AIUI are deprecated
because of the overhead of maintainance etc.
It is much preferred to use social means to control who is "allowed"
to update code, as is done by Subversion and Commons.

> I suppose we could display the difference when some projects have their own
> committers list that is different from the TLP's committers list

Not sure the distinction is useful.
The current people site just displays the membership of the various
different groups; it is up to the reader to know what the group does.

>> a project is a software artifact.
> ok,
> that's the classical way IT people talk, even if that's not the way business
> people talk: I think this is a cause for major misunderstandings between devs
> and business, but that's a larger problem than ASF's internals we're working
> on :)

It's not just IT people - in the UK at least, one can refer to a
"woodworking project" .

> what is confusing, IMHO, is that we tell that a TLP == a PMC
> and a PMC != projects

it is a project management committee, not a project.

> then a TLP != project: which in full words is "a Top Level Project is not a
> project": confusing

I don't think TLP is a synonym for PMC; they are different types of entity.
However the terms are often used as if they are interchangeable.

A software project (releaseable source code) usually starts via the Incubator.
If it generates enough interest and community it will generally become
a TLP overseen by a PMC.
But it might become a project run by an existing PMC.

>
> I'll create committee.html to display PMC (or "TLP") information and let
> projects link to the committee: that should be easy to do and revert if we're
> not happy with the result

Good.

Each PMC page also needs to include links to the project(s) it is
responsible for.

> notice that https://projects-new.apache.org/projects.html?pmc 

Re: Project Visualization Tool...

[sebb]

On 16 May 2015 at 08:31, Hervé BOUTEMY  wrote:
> Le samedi 16 mai 2015 00:30:55 sebb a écrit :
>> On 15 May 2015 at 23:28, Hervé BOUTEMY  wrote:
>> > Le vendredi 15 mai 2015 15:34:47 sebb a écrit :
>> >> > I think we really have some data model problem here regarding what is a
>> >> > "project's DOAP file": sometimes, a project is a PMC, sometimes a
>> >> > project
>> >> > is a deliverable, more like what is called in projectsnew.a.o a
>> >> > "sub-project"
>> >>
>> >> That is not how I understand DOAPs.
>> >>
>> >> DOAP == Description Of A Project
>> >>
>> >> i.e. some releaseable artifact.
>> >>
>> >> A single PMC may have multiple projects, each with its own releases
>> >> and repositories.
>> >> These are modelled quite well in the DOAPs that PMCs have created.
>> >
>> > +1
>> >
>> >> Information about the PMC which manages the projects is NOT stored in
>> >> a DOAP, it is stored in a PMC data file.
>> >> This is referenced from a DOAP using
>> >>
>> >> 
>> >>
>> >> where URL is either an actual URL of a PMC data file or a dummy URL e.g.
>> >>
>> >> 
>> >>
>> >> which leads to a file here:
>> >>
>> >> https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects
>> >> /da ta_files/.rdf
>> >
>> > I'm not RDF expert, but this Apache-specific algorithm to find PMC rdf
>> > file seems strange: I understand it is coded/known from projects.a.o xslt
>> > transformation
>> Yes.
>>
>> > But this should be usable from any RDF tooling, no?
>>
>> It's not currently usable except by using special processing.
>>
>> The problem is that the shorthand URL is used by all but about 4 of
>> the PMCs, so it would be a major challenge to get this fixed.
>>
>> Some PMCs are quick to fix such issues; some may take weeks or months
>> to fix even a simple error.
> I think that people don't understand this PMC information rdf file (I didn't
> until our current discussion)
> But with good explanations and visualization help given by projects-new.a.o,
> we can go really faster: I'm ready to try once we're clear :)
>
>>
>> > Another problem I see with these PMC data rdf files is that they seem to
>> > not be really maintained: I doubt PMCs update PMC data rdf files on each
>> > PMC Chair change.
>>
>> Yes.
>>
>> > That's why I had the idea of generating/updating the chair when
>> > parsing committee-info.txt.
>>
>> Fair enough, but that does not mean the code needs to create yet
>> another RDF file.
> +1
> my itend was not to create a new one, but replace with generated info
>
>>
>> > But other information manually written in current PMC data rdf files can't
>> > be found anywhere else, AFAIK.
>>
>> Yes.
> that's where it hurst: we need to mix handwritten with generated content...
> nedd to be clear on the process
>
>>
>> > Last problem: I personnally really didn't understand this PMC data rdf
>> > file
>> > until now. I don't know who understands it :)
>> > IMHO, the magic algorithm to find the rdf file is a root cause.
>>
>> The PMC data file is documented here:
>>
>> http://projects.apache.org/docs/pmc.html
> yeah, I read it several time before, I knew I was not confident with what I
> read, and now I know I completely misread it until now.

Does it need clarifying? If so, what is not clear? How could it be improved?

>>
>> >> > if you look at https://projects-new.apache.org/projects.html?pmc,
>> >> > typical
>> >> > cases for that are:
>> >> > - Incubator: there is the "the Incubator project", displayed without
>> >> > DOAP
>> >> > file since the incubator has special source info, and many sub-projects
>> >> > which provide DOAP files
>> >> > - Commons: there is no "Commons' DOAP file", then no TLP... on
>> >> > sub-project
>> >> > is quasi randomly chosen... Common's DOAP file, if it existed would not
>> >> > release anything, it"s a pure "organizational" project
>> >>
>> >> There is an ambiguity here: project can mean an organisational entity
>> >> and proje

Re: Re : Re: Re : Re: Project Visualization Tool...

[sebb]

The main problem I have with JSON is that AFAIK it does not support comments.

On 18 April 2015 at 19:03,   wrote:
> Yes, I have no problem with json vs xml: the question is more to define the 
> schema like doap did it, and write documentation for projects to know where 
> to publish what information
>
> editing current generated json just creates a new information source, without 
> any documentation
>
> My point is: afaik, the purpose of the site is to display info in newer ways, 
> then json generated from every existing piece of information is great, like 
> any other format that would better suit some other visualization
>
> But if we're creating any new source of information that competes with 
> existing one, this has to be done with great care on documentation, 
> explanation on how to migrate and so on
>
> of course the raw format is not an issue: no religion here on xml vs json vs 
> yaml vs ...
>
> Regards
>
> Hervé
>
>
> - Mail d'origine -
> De: jan i 
> À: dev@community.apache.org
> Envoyé: Sat, 18 Apr 2015 11:44:54 +0200 (CEST)
> Objet: Re: Re : Re: Project Visualization Tool...
>
> On Saturday, April 18, 2015,  wrote:
>
>> It was told the new site would use native json, instead of doap
>> But I'm not convinced at all, since Doap is an invaluable source of info,
>> documented, and so on
>
> json is also a documented standard, that in general is more known, and I
> believe has more tools supporting it.
>
>
>>
>> then imho it would be better to generate json from doap
>>
>> I disabled the json edit feature recently since it will cause problems
>
> which problems?
>
> with a defined json it is simple to generate the doap file.
>
> I highly recommend staying at json and using that as base for all our
> central data.
>
> rgds
> jan i
>
>
>
>>
>> regards
>>
>> Hervé
>> - Mail d'origine -
>> De: Shane Curcuru >
>> À: dev@community.apache.org 
>> Envoyé: Sat, 18 Apr 2015 06:43:37 +0200 (CEST)
>> Objet: Re: Project Visualization Tool...
>>
>> We had a great session, and a lot of energy, hopefully we can make some
>> progress. One note: this needs to be a comdev PMC project, and we need
>> to really plan the data part out if we want to be successful.
>>
>> Note that projects-new.a.o is the planned future replacement for
>> projects.a.o - there are *significant* differences, so you need to look
>> at the About page and the source repo. In particular, the new site uses
>> it's own new JSON generated sources which (I think) will no longer use
>> the DOAPs.
>>
>> In particular, Infra currently does *not* consider either the data
>> gathering (i.e. populating the JSON behind the projects-new site) nor
>> the visualizations (current or ones we want to build) as core supported
>> services. So whatever we build needs to be maintained by this PMC to
>> start with.
>>
>> Also, Link dump of useful related bits: 
>>
>> Old service, based on crappy cron jobs and DOAP files from projects:
>> https://projects.apache.org/
>>
>> New service, soon to be infra supported, relying on JSON data generated
>> by infra on a regular schedule:
>> https://projects-new.apache.org/
>>
>> Useful PMC chair report helper, that surfaces a number of different
>> statistics about your PMC(s), including mailing list stats,
>> PMC/committer changes, some software releases, etc. etc. (Members have
>> visibility to all PMCs):
>> https://reporter.apache.org
>>
>> Rob Weir (AOO, Member) used to do some visualization stuff and might
>> have code ideas:
>> http://www.robweir.com/blog/2013/05/mapping-apache.html
>>
>> Ken Coar's old mailing list stats page:
>>
>> https://people.apache.org/~coar/mlists.html
>>
>> The AOO project wrote a mailing list visualizer for who talks to whom:
>> https://blogs.apache.org/OOo/entry/visualizing_the_aoo_dev_list
>>
>> Some outside statistics FLOSSmole generated about Apache communities and
>> lists:
>> http://flossmole.org/category/tags/apache
>>
>> Random other interesting analytics:
>> The Subversion project has the "contribulyzer"
>>
>>
>>
>> - Shane
>>
>>
>
> --
> Sent from My iPad, sorry for any misspellings.
>

Re: Events calendar

[sebb]

On 14 April 2015 at 23:44, jan i  wrote:
> Can we progress with the calendar issue.
>
> Preferable I would like to get the calendar in people.a.o nuked, and
> secondly tell projects (and them how, with a filter for their project) that
> they can have their events in the google calendar.

It would be easy enough to drop the calendar in people.a.o, but I
think it ought to be replaced with a link to the proper calendar.

> To make things easy, let the projects mail this list, and one with karma
> updates the calendar, using the "you must crawl, before you walk"
> philosophy
>
> rgds
> jan I.
>
>
> On 10 April 2015 at 23:53, Pierre Smits  wrote:
>
>> Excuse me for contributing...
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Fri, Apr 10, 2015 at 11:47 PM, Ross Gardler (MS OPEN TECH) <
>> ross.gard...@microsoft.com> wrote:
>>
>> > ApacheCon is not owned by the ASF (other than the brand that is). We are
>> > not talking about ApacheCon, we are talking about a calendar of events.
>> >
>> > -Original Message-
>> > From: Pierre Smits [mailto:pierre.sm...@gmail.com]
>> > Sent: Friday, April 10, 2015 2:27 PM
>> > To: dev@community.apache.org
>> > Subject: Re: Events calendar
>> >
>> > The question is surely important, and can't be circumvented for a
>> > organisation that spends a load of money on furthering the projects and
>> > their works.
>> >
>> > Not only do we need mid and long term plans from every office, but we
>> also
>> > need the supporting and governing processes and procedures written down
>> and
>> > made available to the ASF community. That way we al can see what needs to
>> > be done when it needs to be done.
>> >
>> > For example, recent mails regarding the various activities executed for
>> > the ACNA 15 event pointed out that things got forgotten (like
>> presentation
>> > templates). For such events we need scripts, and such scripts need to
>> > evaluated and improved after the event. That way we don't make the
>> mistakes
>> > when doing a new event like we did in the past.
>> >
>> > Most importantly, Offices need to take ownership.
>> >
>> > Best regards,
>> >
>> > Pierre Smits
>> >
>> > *ORRTIZ.COM *
>> > Services & Solutions for Cloud-
>> > Based Manufacturing, Professional
>> > Services and Retail & Trade
>> > http://www.orrtiz.com
>> >
>> > On Fri, Apr 10, 2015 at 11:09 PM, Ross Gardler (MS OPEN TECH) <
>> > ross.gard...@microsoft.com> wrote:
>> >
>> > > To get people involved we need to provide value. Today, we offer no
>> > value.
>> > > So, if I may, I would like to answer a slightly different question.
>> > > The one I want to answer is "how can we provide value so that PMCs
>> > > will proactively maintain a central events calendar?" Here's my
>> > > starting answer, more ideas very welcome...
>> > >
>> > > VP Brand has added a clause to the events policy that requires
>> > > avoidance of event date clashes.
>> > >
>> > > Marketing is ramping up on a quarterly report that, once we are in the
>> > > swing of things, will be broadly distributed (and thus provide
>> > > visibility for events listed in the calendar).
>> > >
>> > > We have a budget for stickers and other such giveaways at community
>> > > events, we won't ship those unless it's on the calendar.
>> > >
>> > > More?
>> > >
>> > > -Original Message-
>> > > From: Rich Bowen [mailto:rbo...@rcbowen.com]
>> > > Sent: Friday, April 10, 2015 2:01 PM
>> > > To: dev
>> > > Subject: Events calendar
>> > >
>> > > Today I found out about yet another Apache event that is almost here
>> > > and I hadn't heard about before.
>> > >
>> > > I also noticed that http://www.apache.org/events/ is ... kinda
>> > > embarrassing.
>> > >
>> > > This, in conjunction with Jan's question a week ago about who managed
>> > > the calendar on people.a.o, which is completely a separate thing from
>> > > the calendar I thought he was talking about - the Google calendar, at
>> > > http://community.apache.org/calendars/conferences.html - makes me
>> > > wonder why this is so hard for us.
>> > >
>> > > So, two questions:
>> > >
>> > > 1) What other calendars are out there, and what can we do to
>> > > consolidate them?
>> > >
>> > > 2) How can we get PMCs to put their events in that consolidated
>> > > calendar, once it exists, so that we don't have all of these
>> > > last-minute event surprises, and, also, so that we can help in
>> promoting
>> > our communities'
>> > > events?
>> > >
>> > > Suggestions welcome.
>> > >
>> > > I, for one, am a fan of nuking every calendar we come across, and
>> > > publishing the above Google Calendar all over the place, and then
>> > > making a google form for people to submit events.
>> > >
>> > > --Rich
>> > >
>> > > --
>> > > Rich Bowen - rbo...@rcbowen.com - @rbowen http://apachecon.com/ -
>> > > @apachecon
>> > >
>> >
>>

Re: projects-new.a.o updates

[sebb]

On 19 May 2015 at 23:52, Hervé BOUTEMY  wrote:
> Le lundi 18 mai 2015 14:03:39 Sergio Fernández a écrit :
>> Hi guys,
>>
>> I have to admit I'm a bit lost with the development here; I do not have
>> that much time, things change quite fast and discussions are a bit hard to
>> follow. Hervé has done a great work; so some guidelines where I can
>> contribute would help me a lot.
>>
>> One question Hervé, do all rdf files at
>> https://projects-new.apache.org/doap/ are automatically generated or copied
>> from svn?
> these ones are automatically generated from committer-info.txt by
> parsecommittees.py
>
> http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/import/parsecommittees.py
>
> what I still don't know is what is expected handwritten data in the PMC data
> files

That is described here:

http://projects.apache.org/docs/pmc.html

> and if we really should try to generate such pmc.rdf files instead of reading
> content from 
> http://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/pmc_list.xml

Most of the PMC data files are basic place-holders, but the syntax
allows PMCs to create and maintain their own RDF files.

Do we really want to prevent them doing so?

Maybe the solution would be to ignore the dummy references such as

http://{tlp}.apache.org/"; />

and instead generate the required info from other sources.

However, I don't know whether there is a canonical source for deriving
the internal name and home page of a PMC from its full name
e.g.
Apache Portable Runtime => apr & http://apr.apache.org/
Apache HttpComponents => httpcomponents & http://hc.apache.org/

There are other such examples where the conversion cannot readily be automated.
[Except by maintaining a list of the exceptions somewhere]

> I try to maintain ideas and comments in "Work in Progres" section of about
> page: https://projects-new.apache.org/about.html

Might be easier to use a Wiki page for that?

> Regards,
>
> Hervé
>
>>
>> Cheers,
>>
>> On Sat, May 16, 2015 at 4:42 PM, sebb  wrote:
>> > On 16 May 2015 at 08:22, Hervé BOUTEMY  wrote:
>> > > Le samedi 16 mai 2015 00:36:03 sebb a écrit :
>> > >> On 15 May 2015 at 22:08, Hervé BOUTEMY  wrote:
>> > >> > Le vendredi 15 mai 2015 14:02:52 sebb a écrit :
>> > >> >> On 14 May 2015 at 23:38, Hervé BOUTEMY 
>> >
>> > wrote:
>> > >> >> > Hi,
>> > >> >> >
>> > >> >> > I seriously updated content:
>> > >> >> > - *every* TLP is listed, even when no DOAP file has been written
>> >
>> > [1]
>> >
>> > >> >> > - TLP project can be displayed, even without DOAP and provide link
>> >
>> > to
>> >
>> > >> >> > every
>> > >> >> > sub-project [2]
>> > >> >> > - when a TLP has a "main sub-project" with its DOAP file, data
>> >
>> > from TLP
>> >
>> > >> >> > and
>> > >> >> > data from DOAP subproject are clearly separate [3]
>> > >> >>
>> > >> >> The URLs [1] [2] [3] use the same namespace for PMCs and projects as
>> > >> >> well as generic queries.
>> > >> >> This may cause name clashes in future - e.g. a PMC called "numbers"
>> > >> >> would clash with the "numbers" view of the data.
>> > >> >
>> > >> > not exactly: [1] is project*s*.html while the 2 others are
>> >
>> > project.html
>> >
>> > >> > so no clash between projects listing type and project/PMC
>> > >>
>> > >> Ah, OK, I'd not noticed the subtle difference.
>> > >>
>> > >> However there is still a potential name clash: the Ant PMC is not the
>> > >> same as the Ant project produced by the Ant PMC.
>> > >
>> > > yes, even if Ant is one of the few committees that explicitely makes a
>> > > difference between the committee and the project even if they share the
>> >
>> > same
>> >
>> > > name
>> > >
>> > >> >> It would be better to use distinct namespaces for distinct types of
>> >
>> > item.
>> >
>> > >> > I don't think a clash between a PMC and a project can happen: if they
>> >
>> > have
>> >
>> > >> > the same id, it should be T

Re: projects-new.a.o updates

[sebb]

On 20 May 2015 at 02:21, Hervé BOUTEMY  wrote:
> Le mercredi 20 mai 2015 00:55:47 sebb a écrit :
>> On 19 May 2015 at 23:52, Hervé BOUTEMY  wrote:
>> > Le lundi 18 mai 2015 14:03:39 Sergio Fernández a écrit :
>> >> Hi guys,
>> >>
>> >> I have to admit I'm a bit lost with the development here; I do not have
>> >> that much time, things change quite fast and discussions are a bit hard
>> >> to
>> >> follow. Hervé has done a great work; so some guidelines where I can
>> >> contribute would help me a lot.
>> >>
>> >> One question Hervé, do all rdf files at
>> >> https://projects-new.apache.org/doap/ are automatically generated or
>> >> copied
>> >> from svn?
>> >
>> > these ones are automatically generated from committer-info.txt by
>> > parsecommittees.py
>> >
>> > http://svn.apache.org/viewvc/comdev/projects.apache.org/scripts/import/par
>> > secommittees.py
>> >
>> > what I still don't know is what is expected handwritten data in the PMC
>> > data files
>>
>> That is described here:
>>
>> http://projects.apache.org/docs/pmc.html
> yeah, I found and now understand: I tried to improve explanations to fix why I
> didn't understand explanations before (even if I read them multiple times) and
> was confused between projects DOAP files and committees PMC descriptor files
>
> There are still confusing parts, IMHO:
> - PMC entry under "DOAP Files" section
> - "PMC descriptors" section in http://projects.apache.org/guidelines.html
>
> But probably it's not really time to invest in projects.a.o since I hope we'll
> be able to switch to projects-new.a.o
>
> I just added committee.html separate from project.html, and made different
> links for PMCs and projects:
> https://projects-new.apache.org/projects.html?pmc
>
>>
>> > and if we really should try to generate such pmc.rdf files instead of
>> > reading content from
>> > http://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/
>> > pmc_list.xml
>> Most of the PMC data files are basic place-holders, but the syntax
>> allows PMCs to create and maintain their own RDF files.
>>
>> Do we really want to prevent them doing so?
> the only information that require manual entry is charter:

So where is the charter to be documented?

> everything else can
> be automated, which will be easier and give better accuracy

>>
>> Maybe the solution would be to ignore the dummy references such as
>>
>> http://{tlp}.apache.org/"; />
> yes, this dummy reference is a problem since it's "magic"
>
>>
>> and instead generate the required info from other sources.
>>
>> However, I don't know whether there is a canonical source for deriving
>> the internal name and home page of a PMC from its full name
>> e.g.
>> Apache Portable Runtime => apr & http://apr.apache.org/
>> Apache HttpComponents => httpcomponents & http://hc.apache.org/
>>
>> There are other such examples where the conversion cannot readily be
>> automated. [Except by maintaining a list of the exceptions somewhere]
> I coded the few exceptions in the beginning of parsecommittees.py

Which is yet another place that has this information.

> Now we just need to define where to maintain the charter info, and generated
> pmc.rdf files from committee-info.txt + this charter will be the most accurate
> and easy to find since it's a codified url: 
> http://project-new.a.o/doap/{committee id}/pmc.rdf
> Notice that I can improve parsecommittees.py to only update rdf files and not
> erase charter info but only update chair and PMC members
>
>>
>> > I try to maintain ideas and comments in "Work in Progres" section of about
>> > page: https://projects-new.apache.org/about.html
>>
>> Might be easier to use a Wiki page for that?
> it's temporary

Even more reason to use the Wiki, surely?

> Regards,
>
> Hervé
>
>>
>> > Regards,
>> >
>> > Hervé
>> >
>> >> Cheers,
>> >>
>> >> On Sat, May 16, 2015 at 4:42 PM, sebb  wrote:
>> >> > On 16 May 2015 at 08:22, Hervé BOUTEMY  wrote:
>> >> > > Le samedi 16 mai 2015 00:36:03 sebb a écrit :
>> >> > >> On 15 May 2015 at 22:08, Hervé BOUTEMY 
> wrote:
>> >> > >> > Le vendredi 15 mai 2015 14:02:52 sebb a écrit :
>> >> > >> >> On 14 May 2015 at 

Re: projects-new.a.o updates

[sebb]

On 22 May 2015 at 07:04, Hervé BOUTEMY  wrote:
> Le jeudi 21 mai 2015 11:38:05 sebb a écrit :
> [...]
>> > the only information that require manual entry is charter:
>> So where is the charter to be documented?
> "documented"?
> I don't understand the question

I meant:

Where is the charter recorded/written down/defined?

> if I look at http://projects.apache.org/docs/pmc.html, every field can be
> automatically filled with great precision (better precision than what people
> can do)

AFAIK the only fields that are currently recorded (documented) elsewere are:

asfext:name
asfext:chair
asfext:member
All the above can be extracted from committee-info.txt (which is the
official source for the info).

asfext:pmc - requires special processing to derive this
foaf:homepage - ditto
asfext:charter - that should be available from the board meeting
minutes, but it is non-trivial to extract.

> We just hav to decide where to write the remaining fields: there are a lot of
> svn places available
> project.a.o then projects-new.a.o seems to be a good place to make information
> central and let PMCs know they're part of projects directory
>
> the format question is just a detail (that has to be precised, of course)

s/precised/defined/

>
> [...]
>> >> Might be easier to use a Wiki page for that?
>> >
>> > it's temporary
>>
>> Even more reason to use the Wiki, surely?
> thinking at it, more than the About page, a Wiki could be a great place to put
> documentation for PMCs on the topic

Long-term documentation is fine in SVN/Git.
Wiki spaces are generally more useful for discussion and where 3rd
party input is welcomed.
But so long as the documentation can easily be found from the website,
I guess it could be on the Wiki.

> then I just tried to find COMDEV wiki and use it
> found, ok: https://cwiki.apache.org/confluence/display/COMDEV/Index
> use, ko: how do I get karma?

No idea, try filing an Infra JIRA.

> Regards,
>
> Hervé

Re: projects-new.a.o updates

[sebb]

On 22 May 2015 at 16:26, jan i  wrote:
> Hi
>
> Sorry for top posting.

This needs a new thread please.
Probably also needs to be on a different mailing list, e.g. site-dev.

> Do we have a place to record problems with the new pages ?
>
> I just had a look at http://www.apache.org/foundation/ and the list
> of Directors is looking very unformatted (not in columns)

That is nothing to do with projects-new.a.o

> rgds
> jan i.
>
>
>
>
> On 22 May 2015 at 17:21, sebb  wrote:
>
>> On 22 May 2015 at 07:04, Hervé BOUTEMY  wrote:
>> > Le jeudi 21 mai 2015 11:38:05 sebb a écrit :
>> > [...]
>> >> > the only information that require manual entry is charter:
>> >> So where is the charter to be documented?
>> > "documented"?
>> > I don't understand the question
>>
>> I meant:
>>
>> Where is the charter recorded/written down/defined?
>>
>> > if I look at http://projects.apache.org/docs/pmc.html, every field can
>> be
>> > automatically filled with great precision (better precision than what
>> people
>> > can do)
>>
>> AFAIK the only fields that are currently recorded (documented) elsewere
>> are:
>>
>> asfext:name
>> asfext:chair
>> asfext:member
>> All the above can be extracted from committee-info.txt (which is the
>> official source for the info).
>>
>> asfext:pmc - requires special processing to derive this
>> foaf:homepage - ditto
>> asfext:charter - that should be available from the board meeting
>> minutes, but it is non-trivial to extract.
>>
>> > We just hav to decide where to write the remaining fields: there are a
>> lot of
>> > svn places available
>> > project.a.o then projects-new.a.o seems to be a good place to make
>> information
>> > central and let PMCs know they're part of projects directory
>> >
>> > the format question is just a detail (that has to be precised, of course)
>>
>> s/precised/defined/
>>
>> >
>> > [...]
>> >> >> Might be easier to use a Wiki page for that?
>> >> >
>> >> > it's temporary
>> >>
>> >> Even more reason to use the Wiki, surely?
>> > thinking at it, more than the About page, a Wiki could be a great place
>> to put
>> > documentation for PMCs on the topic
>>
>> Long-term documentation is fine in SVN/Git.
>> Wiki spaces are generally more useful for discussion and where 3rd
>> party input is welcomed.
>> But so long as the documentation can easily be found from the website,
>> I guess it could be on the Wiki.
>>
>> > then I just tried to find COMDEV wiki and use it
>> > found, ok: https://cwiki.apache.org/confluence/display/COMDEV/Index
>> > use, ko: how do I get karma?
>>
>> No idea, try filing an Infra JIRA.
>>
>> > Regards,
>> >
>> > Hervé
>>

reporter.apache.org - cannot access httpcomponents

[sebb]

There is a bug in reporter.apache.org.

Although I am on the PMC, it does not appear in my list of projects,
and when I use the member access route I don't get any response. I can
see all the other PMCs I tried (I did not try them all).

The chair of HC also has the same issue.

Re: How to change the name of a release when adding data to Apache Project Report Helper

[sebb]

On 14 April 2015 at 07:36, Benedikt Ritter  wrote:
> 2015-04-06 19:26 GMT+02:00 Benedikt Ritter :
>
>> Hello,
>>
>> I've received an email from the Apache Reporter Service, asking me to fill
>> the latest release I've published at
>> https://reporter.apache.org/addrelease.html?commons
>> The problem is, that it won't let me change the name of the release. At
>> commons we have several components we develop and release individually [1].
>> So I'd like to be able to change the Project name from "commons" to
>> "commons-lang". I can do that by modifying the above URL to
>> https://reporter.apache.org/addrelease.html?commons-lang. Is that the
>> correct way to do this?
>>
>
> Nobody seems to know... Who can I get in touch with about this? Infra?
>

I think this list is the correct place, or you could try JIRA COMDEV.

It's possible to delete a release:

"Need to remove a release? Enter the version of the release and
1970-01-01 as the date then!"

So a work-round would be delete the entry and add the prefix LANG- to
the version.
I see this has been done for many components, but not all.
Also the capitalisation is inconsistent.

It does not help that the output is not sorted - it seems to be in the
order it was added to the database.

>>
>> Thanks!
>> Benedikt
>>
>> [1] http://commons.apache.org
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>>
>
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter

Re: reporter.apache.org - cannot access httpcomponents

[sebb]

On 27 May 2015 at 14:20, sebb  wrote:
> There is a bug in reporter.apache.org.
>
> Although I am on the PMC, it does not appear in my list of projects,
> and when I use the member access route I don't get any response. I can
> see all the other PMCs I tried (I did not try them all).
>
> The chair of HC also has the same issue.

I wonder if it is anything to do with the pmap variable in
https://svn.apache.org/repos/asf/comdev/reporter.apache.org/site/getjson.py

This does not have an entry for httpcomponents.
There is a similar variable in
https://svn.apache.org/repos/asf/comdev/reporter.apache.org/site/chi.py
which includes the following:

'hc': 'httpcomponents'

[It's rather difficult to tell from the source, as there appears to be
no documentation.]

Re: How to change the name of a release when adding data to Apache Project Report Helper

[sebb]

On 28 May 2015 at 01:05, James Carman  wrote:
> I fixed the stuff that I messed up manually

How did you do that?

It does not appear to be possible to rename or delete a release
version once uploaded ...

> On Wed, May 27, 2015 at 10:24 AM sebb  wrote:
>
>> On 14 April 2015 at 07:36, Benedikt Ritter  wrote:
>> > 2015-04-06 19:26 GMT+02:00 Benedikt Ritter :
>> >
>> >> Hello,
>> >>
>> >> I've received an email from the Apache Reporter Service, asking me to
>> fill
>> >> the latest release I've published at
>> >> https://reporter.apache.org/addrelease.html?commons
>> >> The problem is, that it won't let me change the name of the release. At
>> >> commons we have several components we develop and release individually
>> [1].
>> >> So I'd like to be able to change the Project name from "commons" to
>> >> "commons-lang". I can do that by modifying the above URL to
>> >> https://reporter.apache.org/addrelease.html?commons-lang. Is that the
>> >> correct way to do this?
>> >>
>> >
>> > Nobody seems to know... Who can I get in touch with about this? Infra?
>> >
>>
>> I think this list is the correct place, or you could try JIRA COMDEV.
>>
>> It's possible to delete a release:
>>
>> "Need to remove a release? Enter the version of the release and
>> 1970-01-01 as the date then!"
>>
>> So a work-round would be delete the entry and add the prefix LANG- to
>> the version.
>> I see this has been done for many components, but not all.
>> Also the capitalisation is inconsistent.
>>
>> It does not help that the output is not sorted - it seems to be in the
>> order it was added to the database.
>>
>> >>
>> >> Thanks!
>> >> Benedikt
>> >>
>> >> [1] http://commons.apache.org
>> >>
>> >> --
>> >> http://people.apache.org/~britter/
>> >> http://www.systemoutprintln.de/
>> >> http://twitter.com/BenediktRitter
>> >> http://github.com/britter
>> >>
>> >
>> >
>> >
>> > --
>> > http://people.apache.org/~britter/
>> > http://www.systemoutprintln.de/
>> > http://twitter.com/BenediktRitter
>> > http://github.com/britter
>>

Re: Apache Maven Project

[sebb]

On 14 June 2015 at 18:54, Karl Heinz Marbaise  wrote:
> Hi,
>
> we are doing the releases information on the
>
> https://reporter.apache.org/
>
> unfortunately there had been some typos in there...
>
> for example:
>
> Maven Invoker 2..2 was released
>
> two dots...instead of one..
>
> maven-assembly-plugin-2.54 was released on Mon Apr 27 2015
>
> it must be:
>
> maven-assembly-plugin-2.5.4 ...instead...
>
>
> Is there an option to fix typos ? If yes than how?

In theory you can delete an entry by using the date 1970-01-01.

But I could not get that to work.

> Kind regards
> Karl Heinz Marbaise
> Apache Maven PMC

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

[sebb]

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

Who is responsible for reporter.apache.org?

[sebb]

As the subject says.

I'm having problems updating the releases for commons.