Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Dave Fisher]

Hi Justin,

I think that these files were discussed with legal affairs. I’ll let Steve 
explain.

Regards,
Dave

Sent from my iPhone

> On Apr 16, 2018, at 9:58 PM, Justin Mclean  wrote:
> 
> Hi,
> 
> Ignoring the signing issues I would be +1 if the license of the files[1][2]  
> known and the LICENSE fixed in the next release.  However a quick search 
> seems to imply that the two files below [1][2] may be licensed under terms 
> which are not compatible with the Apache license but I’m not 100% sure and 
> INAL.
> 
> Re everything else:
> - incubating in name.
> - DISCLAIMER exists
> - NOTICE is good
> - LICENSE looks to be missing info on these files [1][2] Has an ASF header 
> has been added incorrectly? How are they licensed and is that compatable with 
> the ALv2?
> - No unexpected binary files
> - All source files have ASF headers
> - Can compile from source
> 
> Thanks,
> Justin
> 
> 
> 1. 
> apache-daffodil-2.1.0-incubating-src/daffodil-test/src/test/resources/org/apache/daffodil/usertests/json5.dfdl.xsd
> 2. 
> apache-daffodil-2.1.0-incubating-src/daffodil-test/src/test/resources/org/apache/daffodil/usertests/testWSPStar.dfdl.xsd
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Justin Mclean]

Hi,

Ignoring the signing issues I would be +1 if the license of the files[1][2]  
known and the LICENSE fixed in the next release.  However a quick search seems 
to imply that the two files below [1][2] may be licensed under terms which are 
not compatible with the Apache license but I’m not 100% sure and INAL.

Re everything else:
- incubating in name.
- DISCLAIMER exists
- NOTICE is good
- LICENSE looks to be missing info on these files [1][2] Has an ASF header has 
been added incorrectly? How are they licensed and is that compatable with the 
ALv2?
- No unexpected binary files
- All source files have ASF headers
- Can compile from source

Thanks,
Justin


1. 
apache-daffodil-2.1.0-incubating-src/daffodil-test/src/test/resources/org/apache/daffodil/usertests/json5.dfdl.xsd
2. 
apache-daffodil-2.1.0-incubating-src/daffodil-test/src/test/resources/org/apache/daffodil/usertests/testWSPStar.dfdl.xsd
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Justin Mclean]

Hi,

Sorry but it -1 binding from me as I’m getting a bad signature. I downloads and 
rechecked and got the same issue so I don’t think it’s at my end.

gpg --verify apache-daffodil-2.1.0-incubating-bin.tgz.asc
gpg: assuming signed data in 'apache-daffodil-2.1.0-incubating-bin.tgz'
gpg: Signature made Fri  6 Apr 02:27:15 2018 AEST
gpg:using RSA key 36F3494B033AE661
gpg: BAD signature from "Steve Lawrence " [unknown]

Thanks,
Justin


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

Re: Question about IP CLEARANCE

[Christopher]

On Mon, Apr 16, 2018 at 10:34 PM Dave Fisher  wrote:

>
>
> Sent from my iPhone
>
> > On Apr 16, 2018, at 7:16 PM, Christopher  wrote:
> >
> > On Mon, Apr 16, 2018 at 8:28 PM Roman Shaposhnik 
> > wrote:
> >
> >>> On Mon, Apr 16, 2018 at 4:18 PM, Christopher 
> wrote:
> >>> Two questions about IP CLEARANCE:
> >>>
> >>> There is a line item in the template for making sure that files are
> >> updated
> >>> to reflect ASF copyright. Must this be done before the files are
> actually
> >>> transferred to the receiving PMC, while still being hosted in the
> >> donating
> >>> party's repository?
> >>
> >> There's no requirement like that. You can transfer files into a branch
> and
> >> do the clean up on ASF infrastructure. You will NOT be able to do
> releases
> >> off of that branch, of course.
> >>
> >>
> > It's pretty clearly documented:
> > http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> > If it's not a requirement, why is it there? Can I just delete it from the
> > template?
>
> No, I’m not reading the page the same way that you are. To be clear the
> two lines about SGA/CCLA and Copyright changes are separate, not
> simultaneous.
>
> Here are the real steps.
>
> (1) Submit SGA/CCLA to secretary@
> (2) Do IP Clearance with Incubator.
> (3) Arrange with Infra and/or project moving / checking in the code.
> (4) Update Copyrights - if needed. Always best if it’s someone from the
> contributor.
>
>
That list appears to be self referential:

Steps for IP Clearancce:
1. do ...
2. do "Steps for IP Clearance"
3. do ...

That is very confusing.


> If you want to suggest updating the language or the recording tables then
> please provide it for discussion.
>
>
I like to try to understand a process before suggesting changes to it. I
can try to start making some suggestions now to change
http://incubator.apache.org/ip-clearance/ip-clearance-template.html  and
http://incubator.apache.org/ip-clearance/ ; what is the best delivery
method for suggesting changes? Can I attach a patch to this list or does
the Incubator website have an issue tracker I should use? (Related thought:
this would be easier if incubator website was git-based on gitbox; I could
just do a pull request )

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 16, 2018, at 4:22 PM, toki  wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;

The implication with the way this is all being stated is that the project 
manager is making the decisions about everything and everyone is marching to 
his orders. That is just not how the ASF is supposed to operate.  It is the 
PMC’s job, as a group of collaborators, to make these decisions. That said, 
there is no reason the PMC can’t allow project managers (or anyone else) to 
make proposals regarding a roadmap using Confluence, so long as they are 
discussed and approved by the PMC. The project manager is then free to create 
Jira issues that align with the roadmap. However, what if a committer who 
doesn’t work for the same company as the project manager wants to implement one 
of the roadmap features and/or has different ideas about how it should be done? 
It is up to the PMC as a whole to resolve that, not any one individual.

What you are missing above is the third option. Grant them access to Jira and 
Confluence. Then have them discuss what they are doing on the mailing list. The 
basic difference here is that the individual is not “running” the project but 
is instead contributing to it. If,  after the merit is earned, the PMC decides 
to grant commit rights and/or make them a PMC member, then great. That is how 
it is supposed to work.

The point of all this is, the ASF isn’t trying to get in the way of anyone 
doing their job. Instead, it is trying to put each individual on an equal 
footing with everyone else. Sometimes this may get in the way of a company’s 
goals, but if they wanted to keep total control of the project then they 
shouldn’t have contributed it to the ASF.

>> 
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?

It has happened many times. When I was a committer on Apache Cocoon we voted 
Arje Cahn as a committer for his contributions to the project which had nothing 
to do with coding. He was voted in as an ASF member for pretty much the same 
reason.

Ralph



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

Re: Question about IP CLEARANCE

[Dave Fisher]

Sent from my iPhone

> On Apr 16, 2018, at 7:16 PM, Christopher  wrote:
> 
> On Mon, Apr 16, 2018 at 8:28 PM Roman Shaposhnik 
> wrote:
> 
>>> On Mon, Apr 16, 2018 at 4:18 PM, Christopher  wrote:
>>> Two questions about IP CLEARANCE:
>>> 
>>> There is a line item in the template for making sure that files are
>> updated
>>> to reflect ASF copyright. Must this be done before the files are actually
>>> transferred to the receiving PMC, while still being hosted in the
>> donating
>>> party's repository?
>> 
>> There's no requirement like that. You can transfer files into a branch and
>> do the clean up on ASF infrastructure. You will NOT be able to do releases
>> off of that branch, of course.
>> 
>> 
> It's pretty clearly documented:
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> If it's not a requirement, why is it there? Can I just delete it from the
> template?

No, I’m not reading the page the same way that you are. To be clear the two 
lines about SGA/CCLA and Copyright changes are separate, not simultaneous.

Here are the real steps.

(1) Submit SGA/CCLA to secretary@
(2) Do IP Clearance with Incubator.
(3) Arrange with Infra and/or project moving / checking in the code.
(4) Update Copyrights - if needed. Always best if it’s someone from the 
contributor.

If you want to suggest updating the language or the recording tables then 
please provide it for discussion.

Regards,
Dave

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

Re: Question about IP CLEARANCE

[Christopher]

On Mon, Apr 16, 2018 at 8:28 PM Roman Shaposhnik 
wrote:

> On Mon, Apr 16, 2018 at 4:18 PM, Christopher  wrote:
> > Two questions about IP CLEARANCE:
> >
> > There is a line item in the template for making sure that files are
> updated
> > to reflect ASF copyright. Must this be done before the files are actually
> > transferred to the receiving PMC, while still being hosted in the
> donating
> > party's repository?
>
> There's no requirement like that. You can transfer files into a branch and
> do the clean up on ASF infrastructure. You will NOT be able to do releases
> off of that branch, of course.
>
>
It's pretty clearly documented:
http://incubator.apache.org/ip-clearance/ip-clearance-template.html
If it's not a requirement, why is it there? Can I just delete it from the
template?

Re: Default webpages for new podlings

[Dave Fisher]

Hi -

Sent from my iPhone

> On Apr 16, 2018, at 5:13 PM, Greg Stein  wrote:
> 
> On Mon, Apr 16, 2018 at 10:21 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> 
>>> On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:
>>> ...Most places I've seen the CMS still in use was because of svnpubsub,
>> not
>>> necessarily cms.a.o. We use it to commit the output from
>> maven-site-plugin,
>>> javadocs, scaladocs, etc. Am I confused here?...
>> 
>> AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.
>> 
> 
> Correct.
> 
> 
>> It's the content management part of the ASF CMS that's deprecated.
> 
> 
> Grandfathered. No new projects, but projects currently using it, can
> continue to do so. We have other priorities, but will eventually get around
> to a plan to move everybody off the CMS.

Greg - You know which project I’m thinking about - OpenOffice.org. (1) I can 
see a way to make Jekyll or something similar function for site generation. 
Since I did the migration in I ought to be able to migrate out. (2) The main 
challenge is that the CMS provides good in site patching by new contributors on 
page. Replacing that method of getting new contributors to easily provide 
patches is the hurdle AFAICT. Has Infra thought about a solution for this?

Feel free to move this thread.

Regards,
Dave

> 
> Cheers,
> Greg
> InfraAdmin, ASF


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

Re: Question about IP CLEARANCE

[Roman Shaposhnik]

On Mon, Apr 16, 2018 at 4:18 PM, Christopher  wrote:
> Two questions about IP CLEARANCE:
>
> There is a line item in the template for making sure that files are updated
> to reflect ASF copyright. Must this be done before the files are actually
> transferred to the receiving PMC, while still being hosted in the donating
> party's repository?

There's no requirement like that. You can transfer files into a branch and
do the clean up on ASF infrastructure. You will NOT be able to do releases
off of that branch, of course.

Thanks,
Roman.

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

Re: Challenges using Gitbox

[Greg Stein]

On Mon, Apr 16, 2018 at 6:22 PM, toki  wrote:
>...

> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?
>

Rich Bowen. Current Director of the Foundation, third term, I believe.

He earned his merit through years of working on documentation for the
Apache HTTP Server Project, and through just as many years helping to
organize our conferences.

Cheers,
-g

Re: Default webpages for new podlings

[Greg Stein]

On Mon, Apr 16, 2018 at 10:21 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:
> > ...Most places I've seen the CMS still in use was because of svnpubsub,
> not
> > necessarily cms.a.o. We use it to commit the output from
> maven-site-plugin,
> > javadocs, scaladocs, etc. Am I confused here?...
>
> AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.
>

Correct.


> It's the content management part of the ASF CMS that's deprecated.


Grandfathered. No new projects, but projects currently using it, can
continue to do so. We have other priorities, but will eventually get around
to a plan to move everybody off the CMS.

Cheers,
Greg
InfraAdmin, ASF

Re: Challenges using Gitbox

[Dave Fisher]

Hi -

Having started on a project as such a “Management" person ….

> On Apr 16, 2018, at 4:22 PM, toki  wrote:
> 
> On 04/16/2018 07:37 PM, Ralph Goers wrote:
>> IMO, it is inappropriate to add project managers to a project as a committer 
>> just because they are employed by a company that has committers who are paid 
>> to work on the project.
> 
> There are some companies who have a person whose sole duty is manage the
> employees that work on a specific open source project.
> 
> As such, open source projects have two options:
> * grant the employee position the access needed to manage the project,
> so that everybody can see what is going on;
> * deny the employ position the needed access, and be surprised by what
> the company contributes. In most instances, the surprises are things
> that were neither anticipated, nor considered needed by the non-employee
> contributors;
> 
> How fast could an individual expect to be given the authority to do this
> type of project management, without contributing a line of code?

It depends on the project. The place to start is by contributing to discussions 
on the dev@ and/or user@ lists in order to get recognized. If there are 
developers from $DayJob on the PPMC they with the rest of the PPMC can 
determine when they get these people involved with rights.

Apache projects require a flat, meritocracy and these PM need to earn the right 
within the Project. That right then is theirs whether or not they remain 
employed by $BigCo.

If having commit rights on GitHub is a problem then the project can use a Wiki 
(MoinMoin or Confluence) and/or an Issue Tracker (JIRA or Bugzilla).

The project should not be surprised as the developers should be communicating 
about what they are developing.

This is Open Source Development … do it in public and be happily surprised when 
unexpected people show up with contributions. Grow a true community.

Regards,
Dave

> 
> Ralph wrote:
> 
>> Companies do not do the prioritization, planning, road-mapping,
> shaping product-design, etc of ASF projects. The committers and PMC
> members do that.
> 
> Most of the companies that have a person whose sole duty is to manage
> employees that work on a specific open source project, will ignore
> upstream requests, if they don't have access to do management things
> there. This will result in undesirable surprises.
> 
> If the company PM does have access at the Open Source Project level,
> then the input from the other contributors will be taken into consideration.
> 
> Yes, there is a very fine line to walk, between allowing a company
> position authority to do "x", and preventing the company from taking
> over the project.
> 
>> They can use their own Jira repo for that kind of stuff.
> 
> Do you really want to see a build of, say, Apache OpenOffice, with
> complete L10N (Help documentation, UI, grammar checking, spell checking
> for both ancient, medieval, and modern forms of the official
> language(s), and writing system(s), etc.) for say, Crimea, North Korea,
> or Syria, with no prior notice, much less discussion. I have a pretty
> good idea of what ASF-Legal will say about that specific scenario.
> 
> Sure the company can just fork the project. It has happened before, and
> it will happen again. But setting up conditions where forking is the
> only option for a community based project is, IMNSHO, non-viable.
> 
>> such people can earn merit by becoming involved with the community and
> helping out where they can.
> 
> In theory, that sounds good, but as a practical matter, how many people
> that have ever been on the ASF board of directors neither know/knew, nor
> use(d) any programming languages in getting there? IOW, they got there
> exclusively on their ability to write documentation, do community
> relations, or utilize other non-coding skills?
> 
> jonathon
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: Challenges using Gitbox

[toki]

On 04/16/2018 07:37 PM, Ralph Goers wrote:
> IMO, it is inappropriate to add project managers to a project as a committer 
> just because they are employed by a company that has committers who are paid 
> to work on the project.

There are some companies who have a person whose sole duty is manage the
employees that work on a specific open source project.

As such, open source projects have two options:
* grant the employee position the access needed to manage the project,
so that everybody can see what is going on;
* deny the employ position the needed access, and be surprised by what
the company contributes. In most instances, the surprises are things
that were neither anticipated, nor considered needed by the non-employee
contributors;

How fast could an individual expect to be given the authority to do this
type of project management, without contributing a line of code?

Ralph wrote:

> Companies do not do the prioritization, planning, road-mapping,
shaping product-design, etc of ASF projects. The committers and PMC
members do that.

Most of the companies that have a person whose sole duty is to manage
employees that work on a specific open source project, will ignore
upstream requests, if they don't have access to do management things
there. This will result in undesirable surprises.

If the company PM does have access at the Open Source Project level,
then the input from the other contributors will be taken into consideration.

Yes, there is a very fine line to walk, between allowing a company
position authority to do "x", and preventing the company from taking
over the project.

> They can use their own Jira repo for that kind of stuff. 

Do you really want to see a build of, say, Apache OpenOffice, with
complete L10N (Help documentation, UI, grammar checking, spell checking
for both ancient, medieval, and modern forms of the official
language(s), and writing system(s), etc.) for say, Crimea, North Korea,
or Syria, with no prior notice, much less discussion. I have a pretty
good idea of what ASF-Legal will say about that specific scenario.

Sure the company can just fork the project. It has happened before, and
it will happen again. But setting up conditions where forking is the
only option for a community based project is, IMNSHO, non-viable.

> such people can earn merit by becoming involved with the community and
helping out where they can.

In theory, that sounds good, but as a practical matter, how many people
that have ever been on the ASF board of directors neither know/knew, nor
use(d) any programming languages in getting there? IOW, they got there
exclusively on their ability to write documentation, do community
relations, or utilize other non-coding skills?

jonathon

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

Question about IP CLEARANCE

[Christopher]

Two questions about IP CLEARANCE:

There is a line item in the template for making sure that files are updated
to reflect ASF copyright. Must this be done before the files are actually
transferred to the receiving PMC, while still being hosted in the donating
party's repository? It seems to me that this could be done after transfer,
but before any release by the PMC, and it would be inappropriate to do this
before IP CLEARANCE has been approved, while the code is still sitting in
the donating party's repo. (Note: we're not donating a patch... otherwise
the patch would include any such alterations; rather, we're trying to
donate an entire git repo from one GitHub organization to an ASF project).

There is an item that says to remind active committers that they are
responsible for ensuring that a CCLA is recorded if required to authorize
their contributions under their ICLA. All the contributors to the incoming
codebase already have ICLAs on file because they are already committers to
ASF projects. Since CLAs are already filed, is this reminder necessary?
Presumably, by filing an ICLA, these committers have already accepted that
responsibility. It doesn't seem to have anything to do with this donation,
though. Does it make sense to remind people to do X before Y, when Y is a
NOOP for them?

Thanks,

Christopher

Re: Challenges using Gitbox

[Dave Fisher]

> On Apr 16, 2018, at 1:52 PM, Ted Dunning  wrote:
> 
> On Mon, Apr 16, 2018 at 12:37 PM, Ralph Goers 
> wrote:
> 
>> 
>> 
>>> On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin <
>> maximebeauche...@gmail.com> wrote:
>>> 
>>> About PMs, or other "non-coding contributors", it's pretty common to have
>>> them at sponsoring organizations. For example both Airbnb and Lyft both
>>> have a dedicated PM for Apache Superset. While they don't write code,
>> they
>>> contribute to the project and many other ways (prioritization / planning
>> /
>>> road-mapping, shaping product design, communication, training,
>>> documentation, bug reports, issue triaging,  organizing events, ...). It
>>> sounds like the solution is to make them committers to provide them with
>>> the level of control they need on Github.
>> 
>> I have a problem with the way this is phrased. Companies do not do the
>> prioritization, planning, road-mapping, shaping product-design, etc of ASF
>> projects. The committers and PMC members do that.
> 
> 
> 
> The phrasing is problematic, clearly.
> 
> But managers at companies *do* have an outsized influence because they can
> divert a substantial amount of people-power to particular issues. As such,
> the priority setting, road mapping and triaging that they are doing is done
> to keep the corporation's efforts coherent. Keeping these efforts coherent
> is actually a community service, as I see it. Doing these efforts off-list
> is a disservice, however, and is a common anti-pattern in communities.
> 
> Overall, I think that it is great if somebody takes a strong and public
> position to help organize efforts of the community and I think that efforts
> like that should be recognized. At the same time, I am strenuously of the
> opinion that doing the same thing off-list is something that should not be
> recognized.
> 
> The difference is probably not clear to most corporate overlords.

Here is the main documentation. [0]
Here is a short discussion. [1]
Here is a very long one [2]

Please have a look. (Wondering lately if we need a page for Corporations about 
how to Incubate a Project.)

Regards,
Dave

[0] https://www.apache.org/foundation/how-it-works.html#management 

[1] https://community.apache.org/committers/decisionMaking.html 

[2] 
https://blogs.apache.org/foundation/entry/success-at-apache-asynchronous-decision
 







signature.asc
Description: Message signed with OpenPGP

Re: Challenges using Gitbox

[Ted Dunning]

On Mon, Apr 16, 2018 at 12:37 PM, Ralph Goers 
wrote:

>
>
> > On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > About PMs, or other "non-coding contributors", it's pretty common to have
> > them at sponsoring organizations. For example both Airbnb and Lyft both
> > have a dedicated PM for Apache Superset. While they don't write code,
> they
> > contribute to the project and many other ways (prioritization / planning
> /
> > road-mapping, shaping product design, communication, training,
> > documentation, bug reports, issue triaging,  organizing events, ...). It
> > sounds like the solution is to make them committers to provide them with
> > the level of control they need on Github.
>
> I have a problem with the way this is phrased. Companies do not do the
> prioritization, planning, road-mapping, shaping product-design, etc of ASF
> projects. The committers and PMC members do that.



The phrasing is problematic, clearly.

But managers at companies *do* have an outsized influence because they can
divert a substantial amount of people-power to particular issues. As such,
the priority setting, road mapping and triaging that they are doing is done
to keep the corporation's efforts coherent. Keeping these efforts coherent
is actually a community service, as I see it. Doing these efforts off-list
is a disservice, however, and is a common anti-pattern in communities.

Overall, I think that it is great if somebody takes a strong and public
position to help organize efforts of the community and I think that efforts
like that should be recognized. At the same time, I am strenuously of the
opinion that doing the same thing off-list is something that should not be
recognized.

The difference is probably not clear to most corporate overlords.

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 16, 2018, at 10:46 AM, Maxime Beauchemin  
> wrote:
> 
> About PMs, or other "non-coding contributors", it's pretty common to have
> them at sponsoring organizations. For example both Airbnb and Lyft both
> have a dedicated PM for Apache Superset. While they don't write code, they
> contribute to the project and many other ways (prioritization / planning /
> road-mapping, shaping product design, communication, training,
> documentation, bug reports, issue triaging,  organizing events, ...). It
> sounds like the solution is to make them committers to provide them with
> the level of control they need on Github.

I have a problem with the way this is phrased. Companies do not do the 
prioritization, planning, road-mapping, shaping product-design, etc of ASF 
projects. The committers and PMC members do that. IMO, it is inappropriate to 
add project managers to a project as a committer just because they are employed 
by a company that has committers who are paid to work on the project. They can 
use their own Jira repo for that kind of stuff. Furthermore, merit should be 
earned, not just handed out to anyone who needs it to do the job their employer 
requires.

That said, such people can earn merit by becoming involved with the community 
and helping out where they can.

Ralph



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

Re: Challenges using Gitbox

[Dave Fisher]

Hi -

> Another point I didn't bring up in my original email is the obsolescence of
> Apache's svn binaries repository in the light of commonly used package
> manager (Pypi.org for Python, npm for Javacsript, ..., Maven for Java(?) ,
> ...). While I understand the importance of the ASF being independent and
> the need for signed binaries, it seems like effectively everyone will just
> use the release available on popular package manager. Maybe in a perfect
> world we'd have tooling that pushes to both repos atomically. In the
> meantime, I guess it's for podlings to build their own process & tooling to
> ship their releases.

Every project must put all of their Apache releases onto the Apache Infra and 
offer the source download. This is Open Source! The binaries are convenience. 
Most projects treat these the same, and many use other channels to provide 
binaries.

Maven releases are supported though repository.apache.org 
 and can be pushed through to Maven Central.
I know of at least one project that is pushing out through NPM. That would be 
Apache Royale.
Apache OpenOffice binaries are too much for the Apache Mirror system and the 
PMC uses SourceForge.

Ask around about binaries.

If you have questions about the release policy then ask on legal-discuss@

Regards,
Dave

> 
> On Mon, Apr 16, 2018 at 6:39 AM, Ralph Goers 
> wrote:
> 
>> 
>> 
>>> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin <
>> maximebeauche...@gmail.com> wrote:
>>> 
>>> Hi general@incubator!
>>> 
>>> This is an email discussing the challenges we are facing while using
>> Github
>>> / Gitbox for our ASF project and wanted to start a thread to discuss
>>> solutions and ways we can mitigate.
>>> 
>>> We're very grateful for Gitbox, but here are the challenges we're facing
>>> with it:
>>> 
>>> 1. Our PMs are not committers, so they can't do simple things as labeling
>>> issues, closing issues and assigning issues to people. We need either for
>>> them to have write access to Github, or for them to get some sort of
>>> special committer status so they can get write access. Is voting PMs as
>>> committers the solution here?
>> 
>> 
>> I’m just wondering what a project manager is in the context of an Apache
>> project? Why would anyone be assigning issues to people? This is a
>> volunteer organization.  If this is being done as part of an employer then
>> it should not be handled at the ASF.
>> 
>> Ralph
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Challenges using Gitbox

[Maxime Beauchemin]

Thanks everyone for all the input!

I had not looked at https://lists.apache.org/ in a while and it looks
pretty usable along with the "site:" Google trick. Thanks to those who made
"Apache Mail Archives" happen!

About PMs, or other "non-coding contributors", it's pretty common to have
them at sponsoring organizations. For example both Airbnb and Lyft both
have a dedicated PM for Apache Superset. While they don't write code, they
contribute to the project and many other ways (prioritization / planning /
road-mapping, shaping product design, communication, training,
documentation, bug reports, issue triaging,  organizing events, ...). It
sounds like the solution is to make them committers to provide them with
the level of control they need on Github.

Another point I didn't bring up in my original email is the obsolescence of
Apache's svn binaries repository in the light of commonly used package
manager (Pypi.org for Python, npm for Javacsript, ..., Maven for Java(?) ,
...). While I understand the importance of the ASF being independent and
the need for signed binaries, it seems like effectively everyone will just
use the release available on popular package manager. Maybe in a perfect
world we'd have tooling that pushes to both repos atomically. In the
meantime, I guess it's for podlings to build their own process & tooling to
ship their releases.

On Mon, Apr 16, 2018 at 6:39 AM, Ralph Goers 
wrote:

>
>
> > On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > Hi general@incubator!
> >
> > This is an email discussing the challenges we are facing while using
> Github
> > / Gitbox for our ASF project and wanted to start a thread to discuss
> > solutions and ways we can mitigate.
> >
> > We're very grateful for Gitbox, but here are the challenges we're facing
> > with it:
> >
> > 1. Our PMs are not committers, so they can't do simple things as labeling
> > issues, closing issues and assigning issues to people. We need either for
> > them to have write access to Github, or for them to get some sort of
> > special committer status so they can get write access. Is voting PMs as
> > committers the solution here?
>
>
> I’m just wondering what a project manager is in the context of an Apache
> project? Why would anyone be assigning issues to people? This is a
> volunteer organization.  If this is being done as part of an employer then
> it should not be handled at the ASF.
>
> Ralph
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire the HTrace Podling

[Pierre Smits]

+1

Sad to see this happening. But if there is no prospect of a community to
revitalize the project under the greater ASF umbrella, then there no other
way to go.


On Mon, 16 Apr 2018 at 16:06 Dave Fisher  wrote:

> +1 (binding)
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Apr 16, 2018, at 6:47 AM, P. Taylor Goetz  wrote:
> >
> > +1 (binding)
> >
> > -Taylor
> >
> >> On Apr 16, 2018, at 9:28 AM, Ralph Goers 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> Ralph
> >>
> >>> On Apr 11, 2018, at 4:40 PM, lewis john mcgibbney 
> wrote:
> >>>
> >>> Hi Folks,
> >>> Please excuse the error on my part, which essentially missed this
> important
> >>> stage of VOTE'ing on general@ for official retirement of the HTrace
> Podling.
> >>> However, we are here now. The VOTE will be open for a minimum of 72
> hours.
> >>> The previous community VOTE [0] took place on the HTrace dev@ list
> with a
> >>> lot of participation. I closed this off today with the RESULT [1].
> >>> I would like to explicitly note that a subsequent parallel thread was
> >>> initiated [2] which essentially suggested HTrace staying alive as a
> >>> Subproject. Unfortunately this thread petered out... my inclination is
> that
> >>> this outcome is that for HTrace to become a Subproject, essentially
> work
> >>> would need to be done by some people... which brings us back to the
> initial
> >>> reason for drafting the retirement email thread in the first place e.g.
> >>> no-one has the time to work on HTrace any more.
> >>> Please DISCUSS or VOTE as below
> >>>
> >>> [ ] +1 retire the HTrace podling
> >>> [ ] -1 NOT NOT retire the HTrace podling (please provide justification)
> >>>
> >>> Thanks,
> >>> Lewis
> >>> P.S. Here is my +1
> >>>
> >>>
> >>> [0] VOTE: https://s.apache.org/2sGB
> >>> [1] RESULT: https://s.apache.org/e22i
> >>> [2] https://s.apache.org/MlLn
> >>>
> >>> --
> >>> http://home.apache.org/~lewismc/
> >>> http://people.apache.org/keys/committer/lewismc
> >>
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
> --

Best regards,

Pierre Smits

Apache Trafodion , Vice President
Apache Directory , PMC Member
Apache Incubator , committer
Apache OFBiz , contributor since 2008
Apache Steve , committer

Re: Default webpages for new podlings

[Daniel Gruno]

On 04/16/2018 07:14 PM, Gian Merlino wrote:

Is there any ASF infra that would be usable for automatically running
Jekyll on the master branch and pushing the results to the "asf-git"
branch, where they can be served? Maybe CI/build infra, if we have that? It
would provide an experience that is somewhat like GitHub pages.


You have your choice of either buildbot or jenkins - both work and 
produce web sites for many projects already.




On Mon, Apr 16, 2018 at 9:53 AM, Julian Hyde  wrote:


Just to clarify, in case people are not familiar with Jekyll. It is a code
generator that a developer runs in their sandbox, and it generates the
site. The developer then checks in the site to git or svn.

So, the developer has complete control over the HTML that is checked in.
They can manually post-process the files produced by Jekyll, if they wish.

Jekyll is not in the code path running on ASF infrastructure that serves
the site. The ASF infra just sees HTML, CSS style sheets and images.

Julian



On Apr 16, 2018, at 8:21 AM, Bertrand Delacretaz <

bdelacre...@codeconsult.ch> wrote:


On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:

...Most places I've seen the CMS still in use was because of svnpubsub,

not

necessarily cms.a.o. We use it to commit the output from

maven-site-plugin,

javadocs, scaladocs, etc. Am I confused here?...


AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.

It's the content management part of the ASF CMS that's deprecated.

-Bertrand

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




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







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

Re: Default webpages for new podlings

[Gian Merlino]

Is there any ASF infra that would be usable for automatically running
Jekyll on the master branch and pushing the results to the "asf-git"
branch, where they can be served? Maybe CI/build infra, if we have that? It
would provide an experience that is somewhat like GitHub pages.

On Mon, Apr 16, 2018 at 9:53 AM, Julian Hyde  wrote:

> Just to clarify, in case people are not familiar with Jekyll. It is a code
> generator that a developer runs in their sandbox, and it generates the
> site. The developer then checks in the site to git or svn.
>
> So, the developer has complete control over the HTML that is checked in.
> They can manually post-process the files produced by Jekyll, if they wish.
>
> Jekyll is not in the code path running on ASF infrastructure that serves
> the site. The ASF infra just sees HTML, CSS style sheets and images.
>
> Julian
>
>
> > On Apr 16, 2018, at 8:21 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
> >
> > On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:
> >> ...Most places I've seen the CMS still in use was because of svnpubsub,
> not
> >> necessarily cms.a.o. We use it to commit the output from
> maven-site-plugin,
> >> javadocs, scaladocs, etc. Am I confused here?...
> >
> > AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.
> >
> > It's the content management part of the ASF CMS that's deprecated.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Default webpages for new podlings

[Bertrand Delacretaz]

On Mon, Apr 16, 2018 at 6:53 PM, Julian Hyde  wrote:
> ...The ASF infra just sees HTML, CSS style sheets and images...

Yes, to be more precise in the standard gitpubsub setup it's only the
asf-site branch of the Git repository that's published, without
processing. It can even include .htaccess files for redirects etc.

-Bertrand

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

Re: Default webpages for new podlings

[Julian Hyde]

Just to clarify, in case people are not familiar with Jekyll. It is a code 
generator that a developer runs in their sandbox, and it generates the site. 
The developer then checks in the site to git or svn.

So, the developer has complete control over the HTML that is checked in. They 
can manually post-process the files produced by Jekyll, if they wish.

Jekyll is not in the code path running on ASF infrastructure that serves the 
site. The ASF infra just sees HTML, CSS style sheets and images.

Julian


> On Apr 16, 2018, at 8:21 AM, Bertrand Delacretaz  
> wrote:
> 
> On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:
>> ...Most places I've seen the CMS still in use was because of svnpubsub, not
>> necessarily cms.a.o. We use it to commit the output from maven-site-plugin,
>> javadocs, scaladocs, etc. Am I confused here?...
> 
> AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.
> 
> It's the content management part of the ASF CMS that's deprecated.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Default webpages for new podlings

[Bertrand Delacretaz]

On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:
> ...Most places I've seen the CMS still in use was because of svnpubsub, not
> necessarily cms.a.o. We use it to commit the output from maven-site-plugin,
> javadocs, scaladocs, etc. Am I confused here?...

AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.

It's the content management part of the ASF CMS that's deprecated.

-Bertrand

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

Re: Default webpages for new podlings

[Matt Sicker]

Most places I've seen the CMS still in use was because of svnpubsub, not
necessarily cms.a.o. We use it to commit the output from maven-site-plugin,
javadocs, scaladocs, etc. Am I confused here?

On 16 April 2018 at 07:27, John D. Ament  wrote:

> On Mon, Apr 16, 2018 at 7:04 AM Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Mon, Apr 16, 2018 at 12:26 PM, John D. Ament 
> > wrote:
> > > ...FWIW, Jekyll is pretty heavily used across projects
> >
> > Yes, it's good to have a suggested default for this.
> >
> > OTOH the nice thing about the current setup is that people can use
> > whatever tool they want to create content: from emacs^H^H^H^H^H vi to
> > Jekyll, JBake, Pelican and many others there's choice depending on
> > people's preferences and that's great.
> >
>
> I don't believe this precludes using other tools.  One of the things I
> learned from how ASF did CMS, its very useful to have a common entry
> point.  If everything remains wrapped in a checked in build script
> (Jenkinsfile, shell script or otherwise) to avoid impacting your build
> tool, you're fine using the programming model.
>
>
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



-- 
Matt Sicker 

Re: [VOTE] Retire the HTrace Podling

[Dave Fisher]

+1 (binding)

Regards,
Dave

Sent from my iPhone

> On Apr 16, 2018, at 6:47 AM, P. Taylor Goetz  wrote:
> 
> +1 (binding)
> 
> -Taylor
> 
>> On Apr 16, 2018, at 9:28 AM, Ralph Goers  wrote:
>> 
>> +1 (binding)
>> 
>> Ralph
>> 
>>> On Apr 11, 2018, at 4:40 PM, lewis john mcgibbney  
>>> wrote:
>>> 
>>> Hi Folks,
>>> Please excuse the error on my part, which essentially missed this important
>>> stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
>>> However, we are here now. The VOTE will be open for a minimum of 72 hours.
>>> The previous community VOTE [0] took place on the HTrace dev@ list with a
>>> lot of participation. I closed this off today with the RESULT [1].
>>> I would like to explicitly note that a subsequent parallel thread was
>>> initiated [2] which essentially suggested HTrace staying alive as a
>>> Subproject. Unfortunately this thread petered out... my inclination is that
>>> this outcome is that for HTrace to become a Subproject, essentially work
>>> would need to be done by some people... which brings us back to the initial
>>> reason for drafting the retirement email thread in the first place e.g.
>>> no-one has the time to work on HTrace any more.
>>> Please DISCUSS or VOTE as below
>>> 
>>> [ ] +1 retire the HTrace podling
>>> [ ] -1 NOT NOT retire the HTrace podling (please provide justification)
>>> 
>>> Thanks,
>>> Lewis
>>> P.S. Here is my +1
>>> 
>>> 
>>> [0] VOTE: https://s.apache.org/2sGB
>>> [1] RESULT: https://s.apache.org/e22i
>>> [2] https://s.apache.org/MlLn
>>> 
>>> --
>>> http://home.apache.org/~lewismc/
>>> http://people.apache.org/keys/committer/lewismc
>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 


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

Re: [VOTE] Retire the HTrace Podling

[P. Taylor Goetz]

+1 (binding)

-Taylor

> On Apr 16, 2018, at 9:28 AM, Ralph Goers  wrote:
> 
> +1 (binding)
> 
> Ralph
> 
>> On Apr 11, 2018, at 4:40 PM, lewis john mcgibbney  wrote:
>> 
>> Hi Folks,
>> Please excuse the error on my part, which essentially missed this important
>> stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
>> However, we are here now. The VOTE will be open for a minimum of 72 hours.
>> The previous community VOTE [0] took place on the HTrace dev@ list with a
>> lot of participation. I closed this off today with the RESULT [1].
>> I would like to explicitly note that a subsequent parallel thread was
>> initiated [2] which essentially suggested HTrace staying alive as a
>> Subproject. Unfortunately this thread petered out... my inclination is that
>> this outcome is that for HTrace to become a Subproject, essentially work
>> would need to be done by some people... which brings us back to the initial
>> reason for drafting the retirement email thread in the first place e.g.
>> no-one has the time to work on HTrace any more.
>> Please DISCUSS or VOTE as below
>> 
>> [ ] +1 retire the HTrace podling
>> [ ] -1 NOT NOT retire the HTrace podling (please provide justification)
>> 
>> Thanks,
>> Lewis
>> P.S. Here is my +1
>> 
>> 
>> [0] VOTE: https://s.apache.org/2sGB
>> [1] RESULT: https://s.apache.org/e22i
>> [2] https://s.apache.org/MlLn
>> 
>> --
>> http://home.apache.org/~lewismc/
>> http://people.apache.org/keys/committer/lewismc
> 
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 



signature.asc
Description: Message signed with OpenPGP

Re: Challenges using Gitbox

[Ralph Goers]

> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin  
> wrote:
> 
> Hi general@incubator!
> 
> This is an email discussing the challenges we are facing while using Github
> / Gitbox for our ASF project and wanted to start a thread to discuss
> solutions and ways we can mitigate.
> 
> We're very grateful for Gitbox, but here are the challenges we're facing
> with it:
> 
> 1. Our PMs are not committers, so they can't do simple things as labeling
> issues, closing issues and assigning issues to people. We need either for
> them to have write access to Github, or for them to get some sort of
> special committer status so they can get write access. Is voting PMs as
> committers the solution here?


I’m just wondering what a project manager is in the context of an Apache 
project? Why would anyone be assigning issues to people? This is a volunteer 
organization.  If this is being done as part of an employer then it should not 
be handled at the ASF.

Ralph

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

Re: [VOTE] Retire the HTrace Podling

[Ralph Goers]

+1 (binding)

Ralph

> On Apr 11, 2018, at 4:40 PM, lewis john mcgibbney  wrote:
> 
> Hi Folks,
> Please excuse the error on my part, which essentially missed this important
> stage of VOTE'ing on general@ for official retirement of the HTrace Podling.
> However, we are here now. The VOTE will be open for a minimum of 72 hours.
> The previous community VOTE [0] took place on the HTrace dev@ list with a
> lot of participation. I closed this off today with the RESULT [1].
> I would like to explicitly note that a subsequent parallel thread was
> initiated [2] which essentially suggested HTrace staying alive as a
> Subproject. Unfortunately this thread petered out... my inclination is that
> this outcome is that for HTrace to become a Subproject, essentially work
> would need to be done by some people... which brings us back to the initial
> reason for drafting the retirement email thread in the first place e.g.
> no-one has the time to work on HTrace any more.
> Please DISCUSS or VOTE as below
> 
> [ ] +1 retire the HTrace podling
> [ ] -1 NOT NOT retire the HTrace podling (please provide justification)
> 
> Thanks,
> Lewis
> P.S. Here is my +1
> 
> 
> [0] VOTE: https://s.apache.org/2sGB
> [1] RESULT: https://s.apache.org/e22i
> [2] https://s.apache.org/MlLn
> 
> -- 
> http://home.apache.org/~lewismc/
> http://people.apache.org/keys/committer/lewismc



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

Re: Default webpages for new podlings

[John D. Ament]

On Mon, Apr 16, 2018 at 7:04 AM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Mon, Apr 16, 2018 at 12:26 PM, John D. Ament 
> wrote:
> > ...FWIW, Jekyll is pretty heavily used across projects
>
> Yes, it's good to have a suggested default for this.
>
> OTOH the nice thing about the current setup is that people can use
> whatever tool they want to create content: from emacs^H^H^H^H^H vi to
> Jekyll, JBake, Pelican and many others there's choice depending on
> people's preferences and that's great.
>

I don't believe this precludes using other tools.  One of the things I
learned from how ASF did CMS, its very useful to have a common entry
point.  If everything remains wrapped in a checked in build script
(Jenkinsfile, shell script or otherwise) to avoid impacting your build
tool, you're fine using the programming model.


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

Re: [VOTE] Release Apache Daffodil (incubating) 2.1.0-rc3

[Steve Lawrence]

Hi all,

We are still in need of a couple more +1's. I'd appreciate it if you
could find some time to take a look at our release.

Thanks,
- Steve


On 04/09/2018 07:24 PM, Steve Lawrence wrote:
> The Apache Daffodil community has voted and approved the proposed
> release of Apache Daffodil (incubating) 2.1.0-rc3.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Daffodil is an open source implementation of the DFDL specification that
> uses DFDL schemas to parse fixed format data into an infoset, which is
> most commonly represented as either XML or JSON. This allows the use of
> well-established XML or JSON technologies and libraries to consume,
> inspect, and manipulate fixed format data in existing solutions.
> Daffodil is also capable of the reverse by serializing or "unparsing" an
> XML or JSON infoset back to the original data format.
> 
> Vote thread:
> https://lists.apache.org/thread.html/10811e8f520bf100a9250a3ae0610633e9018e0ae8fc422e2c0f097a@%3Cdev.daffodil.apache.org%3E
> 
> Result thread:
> https://lists.apache.org/thread.html/54a3e681b25f084e0dc46e19764cd19507ff502b927516093a3bd667@%3Cdev.daffodil.apache.org%3E
> 
> All distribution packages, including signatures, digests, etc. can be
> found at:
> 
> https://dist.apache.org/repos/dist/dev/incubator/daffodil/2.1.0-rc3/
> 
> Staging artifacts can be found at:
> 
> https://repository.apache.org/content/repositories/orgapachedaffodil-1002/
> 
> This release has been signed with PGP key 033AE661, corresponding to
> slawre...@apache.org, which is included in the repository's KEYS file.
> This key can be found on keyservers, such as:
> 
> http://pgp.mit.edu/pks/lookup?op=get=0x033AE661
> 
> It is also listed here:
> 
> https://people.apache.org/keys/committer/slawrence.asc
> 
> The release candidate has been tagged in git with v2.1.0-rc3.
> 
> For reference, here is a list of all closed JIRAs tagged with 2.1.0:
> 
> https://issues.apache.org/jira/browse/DAFFODIL-1897?jql=project%20%3D%20DAFFODIL%20AND%20fixVersion%20%3D%202.1.0%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC
> 
> For a summary of the changes in this release, see:
> 
> https://daffodil.apache.org/releases/2.1.0/
> 
> Please review and vote. The vote will be open for at least 72 hours.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> Thanks,
> - Steve
> 


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

Re: Default webpages for new podlings

[Bertrand Delacretaz]

On Mon, Apr 16, 2018 at 12:26 PM, John D. Ament  wrote:
> ...FWIW, Jekyll is pretty heavily used across projects

Yes, it's good to have a suggested default for this.

OTOH the nice thing about the current setup is that people can use
whatever tool they want to create content: from emacs^H^H^H^H^H vi to
Jekyll, JBake, Pelican and many others there's choice depending on
people's preferences and that's great.

-Bertrand

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

Re: Default webpages for new podlings

[John D. Ament]

On Mon, Apr 16, 2018 at 5:57 AM sebb  wrote:

> On 16 April 2018 at 10:39, Bertrand Delacretaz
>  wrote:
> > On Mon, Apr 16, 2018 at 11:20 AM, sebb  wrote:
> >>... Podlings can create a simple page in Git/SVN, however it won't be
> >> displayed without some Infra setup to copy the html from the SCM to
> >> the host...
> >
> > Granted but that's quite easy to do from the podling's side: just push
> > the content to the asf-site branch of a Git repository and ask infra
> > to activate the sync as in
> > https://issues.apache.org/jira/browse/INFRA-12311
>
> Yes, it is simple but it is one other job to do.
> And it cannot be done by Infra until it is known what SCM they are want to
> use.
>


And that goes back to my original statement about solutions - we tell them
what to do.  Infra has tools in place.  They've deprecated old tools and
want new tools to be used, so we make that the norm for podlings.  Assuming
no build requirement, we seed a git repo from the apache-website-template
and have them fill it in with info, or create a skeleton off of
apache-website-template that has it done.

I'm even inclined to think forking apache-website-template to
incubator-podling-template makes the most sense, and make the edits there.
It would have all of the branches set up and a base page that infra can
point to.

FWIW, Jekyll is pretty heavily used across projects.  I didn't use it for
the incubator website due to the file parsing that's needed, but for the
static content it would be fine.


>
> > How that content is generated does not matter, in a pinch you could
> > just edit a single index.html file manually in that asf-site branch
> > and be done with it.
>
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Default webpages for new podlings

[sebb]

On 16 April 2018 at 10:39, Bertrand Delacretaz
 wrote:
> On Mon, Apr 16, 2018 at 11:20 AM, sebb  wrote:
>>... Podlings can create a simple page in Git/SVN, however it won't be
>> displayed without some Infra setup to copy the html from the SCM to
>> the host...
>
> Granted but that's quite easy to do from the podling's side: just push
> the content to the asf-site branch of a Git repository and ask infra
> to activate the sync as in
> https://issues.apache.org/jira/browse/INFRA-12311

Yes, it is simple but it is one other job to do.
And it cannot be done by Infra until it is known what SCM they are want to use.

> How that content is generated does not matter, in a pinch you could
> just edit a single index.html file manually in that asf-site branch
> and be done with it.

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

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

Re: Default webpages for new podlings

[Bertrand Delacretaz]

On Mon, Apr 16, 2018 at 11:20 AM, sebb  wrote:
>... Podlings can create a simple page in Git/SVN, however it won't be
> displayed without some Infra setup to copy the html from the SCM to
> the host...

Granted but that's quite easy to do from the podling's side: just push
the content to the asf-site branch of a Git repository and ask infra
to activate the sync as in
https://issues.apache.org/jira/browse/INFRA-12311

How that content is generated does not matter, in a pinch you could
just edit a single index.html file manually in that asf-site branch
and be done with it.

-Bertrand

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

Re: Default webpages for new podlings

[sebb]

On 16 April 2018 at 09:34, Bertrand Delacretaz
 wrote:
> On Mon, Apr 16, 2018 at 8:50 AM, Greg Stein  wrote:
>> ...placeholder page. It should explain the situation. Provide links to
>> the incubator and the podling status page, to the original/external site,
>> disclaimer, etc. Just one page. Fast set up. Done...
>
> Yes, BIG +1 to this.
>
> It's not hard to create a single-page site using Jekyll or any of the
> many site generators around. As Greg says, just a few links and brief
> status information, but each podling should have an editable website
> on their apache.org domain very early in incubation. Even if it's a
> single ugly page.

Podlings can create a simple page in Git/SVN, however it won't be
displayed without some Infra setup to copy the html from the SCM to
the host.

Perhaps this needs to be done as part of the initial process of
creating a podling?

Or maybe there could be a temporary holding area under the incubator
SVN tree with RW access for all incubator committers.
The podling website could redirect to that if present. Once the new
site was available, the temporary one would be removed.

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

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

Re: Default webpages for new podlings

[Bertrand Delacretaz]

On Mon, Apr 16, 2018 at 8:50 AM, Greg Stein  wrote:
> ...placeholder page. It should explain the situation. Provide links to
> the incubator and the podling status page, to the original/external site,
> disclaimer, etc. Just one page. Fast set up. Done...

Yes, BIG +1 to this.

It's not hard to create a single-page site using Jekyll or any of the
many site generators around. As Greg says, just a few links and brief
status information, but each podling should have an editable website
on their apache.org domain very early in incubation. Even if it's a
single ugly page.

-Bertrand

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

Re: Default webpages for new podlings

[Dave Fisher]

Sent from my iPhone

>> On Apr 15, 2018, at 11:50 PM, Greg Stein  wrote:
>> 
>> On Sun, Apr 15, 2018 at 9:30 PM, Ted Dunning  wrote:
>> 
>> On Sun, Apr 15, 2018 at 12:37 PM, Dave Fisher 
>> wrote:
>>> Hi -
>>> 
>>> I think that a brand compliant initial podling page would not be hard to
>>> create using the Apache CMS.
> 
> The CMS is deprecated.

Then documentation which lists it as the first option must be updated. [1]

> No podlings/TLPs can choose to set up sites on the
> CMS any more. Existing CMS sites are grandfathered, and allowed to continue
> operating. Our hope is they will migrate, but we have not started a program
> (yet) to actively attempt to incent communities to migrate away from the
> CMS.

This is a debate for another time on another list. It is a debate I do not want 
to have, ever. 



Regards,
Dave

[1] http://www.apache.org/dev/project-site.html

> 
> 
>> The problem I have with that is that it encourages further use of CMS and
>> also that CMS is hard for people to learn because the standard practice is
>> so far from how web-sites are normally done. Better to give them a Jekyll
>> prototype to edit from. Or use John's suggestion about a temporary redirect
>> to avoid the 404's but not pretend to be a project web-site alternative.
> 
> A redirect to an external site does not provide any information about the
> Apache podling.
> 
> Repeat: placeholder page. It should explain the situation. Provide links to
> the incubator and the podling status page, to the original/external site,
> disclaimer, etc. Just one page. Fast set up. Done.
> 
> For a community to decide/plan how to move their website and
> edit/workflow/tooling over to the ASF is a long process. Jekyll? Pelican?
> Jbake? ... Buildbot or Jenkins? Markdown, or raw HTML? It is unreasonable
> to assume that will be done within the first week of acceptance into the
> Incubator. But a single page during that first week? Sure.
> 
> Going to druid.incubator.a.o and getting redirected to druid.io can create
> a huge misunderstanding. "What? I thought I went to the Apache project?!
> Oh. Guess it isn't an Apache project after all."
> 
> One simple page. Explain and disclaim. Provide links.
> 
> Cheers,
> -g

Re: Default webpages for new podlings

[Greg Stein]

On Sun, Apr 15, 2018 at 9:30 PM, Ted Dunning  wrote:

> On Sun, Apr 15, 2018 at 12:37 PM, Dave Fisher 
> wrote:
> > Hi -
> >
> > I think that a brand compliant initial podling page would not be hard to
> > create using the Apache CMS.
>

The CMS is deprecated. No podlings/TLPs can choose to set up sites on the
CMS any more. Existing CMS sites are grandfathered, and allowed to continue
operating. Our hope is they will migrate, but we have not started a program
(yet) to actively attempt to incent communities to migrate away from the
CMS.


> The problem I have with that is that it encourages further use of CMS and
> also that CMS is hard for people to learn because the standard practice is
> so far from how web-sites are normally done. Better to give them a Jekyll
> prototype to edit from. Or use John's suggestion about a temporary redirect
> to avoid the 404's but not pretend to be a project web-site alternative.
>

A redirect to an external site does not provide any information about the
Apache podling.

Repeat: placeholder page. It should explain the situation. Provide links to
the incubator and the podling status page, to the original/external site,
disclaimer, etc. Just one page. Fast set up. Done.

For a community to decide/plan how to move their website and
edit/workflow/tooling over to the ASF is a long process. Jekyll? Pelican?
Jbake? ... Buildbot or Jenkins? Markdown, or raw HTML? It is unreasonable
to assume that will be done within the first week of acceptance into the
Incubator. But a single page during that first week? Sure.

Going to druid.incubator.a.o and getting redirected to druid.io can create
a huge misunderstanding. "What? I thought I went to the Apache project?!
Oh. Guess it isn't an Apache project after all."

One simple page. Explain and disclaim. Provide links.

Cheers,
-g

Re: Default webpages for new podlings

[William Guo]

griffin is using the same tech for site generator.

check the repo if you would like to

https://github.com/apache/incubator-griffin-site


Thanks,
William


On Mon, Apr 16, 2018 at 1:38 PM, Ted Dunning  wrote:

> Dave,
>
> You probably already know enough to use Jekyll.
>
> It is just a markdown to HTML translator. It is what github uses, as I
> remember.
>
>
>
> On Sun, Apr 15, 2018 at 8:31 PM, Dave Fisher 
> wrote:
>
> > I’m always willing to learn new tools.
> >
> > Regards,
> > Dave
> >
> > Sent from my iPhone
> >
> > > On Apr 15, 2018, at 8:15 PM, Julian Hyde 
> wrote:
> > >
> > > Luciano created a Jekyll prototype a year or so ago. Let’s dust that
> > off.
> > >
> > > Julian
> > >
> > >>> On Apr 15, 2018, at 19:30, Ted Dunning 
> wrote:
> > >>>
> > >>> On Sun, Apr 15, 2018 at 12:37 PM, Dave Fisher  >
> > wrote:
> > >>>
> > >>> Hi -
> > >>>
> > >>> I think that a brand compliant initial podling page would not be hard
> > to
> > >>> create using the Apache CMS.
> > >>
> > >> The problem I have with that is that it encourages further use of CMS
> > and
> > >> also that CMS is hard for people to learn because the standard
> practice
> > is
> > >> so far from how web-sites are normally done. Better to give them a
> > Jekyll
> > >> prototype to edit from. Or use John's suggestion about a temporary
> > redirect
> > >> to avoid the 404's but not pretend to be a project web-site
> alternative.
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>