Re: Images in source code.

2017-06-04 Thread Martin Gainty 
is there anyway to run maven-rat-plugin to make sure ASF licensed assets are 
*not* being subverted by salesforce


http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html


Apache Rat™ Plugin for Apache Maven – 
apache-rat:rat
creadur.apache.org
apache-rat:rat. Note:This goal should be used as a Maven report. Full name: 
org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:

?

Martin
__




From: John D. Ament 
Sent: Saturday, June 3, 2017 9:46 AM
To: general@incubator.apache.org
Subject: Re: Images in source code.

On Fri, Jun 2, 2017 at 8:20 PM Craig Russell  wrote:

> Hi James,
>
> Everything that is not explicitly called out in the top level NOTICE and
> LICENSE files are licensed under the Apache 2.0 license.
>
> Adding a file to this directory might mislead people into thinking that
> they need to perform more due diligence with other files in other
> directories.
>
> My advice is to *not* add anything. Let the images be licensed per the
> terms the top level LICENSE file.
>

Agreed.  What we do like to make sure is called out is if there is
provenance that these images came from somewhere else.  If these images
were not created by you and were not already under apache license, then we
would have a concern.


>
> Craig
>
> > On Jun 2, 2017, at 2:20 PM, James Bognar 
> wrote:
> >
> > Thanks!
> >
> > I haven't found a metadata editor that works yet, so I'll just add a
> > LICENSE.txt file to the directory.  Hopefully that's enough.
> >
> > On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser  wrote:
> >
> >> On 6/2/17 1:15 PM, James Bognar wrote:
> >>
> >>> I just added several png files to the source tree of our podling.  I
> >>> created them myself.  Are there any best-practices on how to mark
> these as
> >>> Apache licensed?
> >>>
> >>>
> >> I'm not sure of a good way to track this. I'm not sure if png supports
> >> arbitrary metadata which could be edited. Some ways I've seen used
> >> elsewhere to try to better propagate license/ownership:
> >>
> >> * Comments on the issue-tracker issue that introduced them citing
> >> origin/source (typically for images that are copied, not created)
> >> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of course)
> >> * A README in the same directory with relevant info
> >>
> >> If the images are of the podling's creation, I wouldn't be particularly
> >> worried. The copyright notice on your source-release and LICENSE are
> >> sufficient to inform downstream consumers.
> >>
> >> Probably not the answer you're looking for, but hope it helps :)
> >>
> >> - Josh
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
> >
> > --
> > James Bognar
>
> Craig L Russell
> c...@apache.org
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Images in source code.

2017-06-04 Thread James Bognar 
That's a good question.  I've discovered that images CAN contain metadata
that includes ownership information.  Rat could check for these.  In
practice though, these comment fields don't seem to be often used.

If I could add a simple "Copyright Apache" message to the metadata, I
would, but the tooling is suprisingly lacking.

On Sun, Jun 4, 2017 at 8:49 AM, Martin Gainty  wrote:

> is there anyway to run maven-rat-plugin to make sure ASF licensed assets
> are *not* being subverted by salesforce
>
>
> http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html
>
>
> Apache Rat™ Plugin for Apache Maven – apache-rat:rat apache.org/rat/apache-rat-plugin/rat-mojo.html>
> creadur.apache.org
> apache-rat:rat. Note:This goal should be used as a Maven report. Full
> name: org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:
>
> ?
>
> Martin
> __
>
>
>
> 
> From: John D. Ament 
> Sent: Saturday, June 3, 2017 9:46 AM
> To: general@incubator.apache.org
> Subject: Re: Images in source code.
>
> On Fri, Jun 2, 2017 at 8:20 PM Craig Russell  wrote:
>
> > Hi James,
> >
> > Everything that is not explicitly called out in the top level NOTICE and
> > LICENSE files are licensed under the Apache 2.0 license.
> >
> > Adding a file to this directory might mislead people into thinking that
> > they need to perform more due diligence with other files in other
> > directories.
> >
> > My advice is to *not* add anything. Let the images be licensed per the
> > terms the top level LICENSE file.
> >
>
> Agreed.  What we do like to make sure is called out is if there is
> provenance that these images came from somewhere else.  If these images
> were not created by you and were not already under apache license, then we
> would have a concern.
>
>
> >
> > Craig
> >
> > > On Jun 2, 2017, at 2:20 PM, James Bognar 
> > wrote:
> > >
> > > Thanks!
> > >
> > > I haven't found a metadata editor that works yet, so I'll just add a
> > > LICENSE.txt file to the directory.  Hopefully that's enough.
> > >
> > > On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser  wrote:
> > >
> > >> On 6/2/17 1:15 PM, James Bognar wrote:
> > >>
> > >>> I just added several png files to the source tree of our podling.  I
> > >>> created them myself.  Are there any best-practices on how to mark
> > these as
> > >>> Apache licensed?
> > >>>
> > >>>
> > >> I'm not sure of a good way to track this. I'm not sure if png supports
> > >> arbitrary metadata which could be edited. Some ways I've seen used
> > >> elsewhere to try to better propagate license/ownership:
> > >>
> > >> * Comments on the issue-tracker issue that introduced them citing
> > >> origin/source (typically for images that are copied, not created)
> > >> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of course)
> > >> * A README in the same directory with relevant info
> > >>
> > >> If the images are of the podling's creation, I wouldn't be
> particularly
> > >> worried. The copyright notice on your source-release and LICENSE are
> > >> sufficient to inform downstream consumers.
> > >>
> > >> Probably not the answer you're looking for, but hope it helps :)
> > >>
> > >> - Josh
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > James Bognar
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



-- 
James Bognar

Re: Images in source code.

2017-06-04 Thread Ted Dunning 
What does subverted by Salesforce even mean here?

Any Apache licensed material can be "subverted" by pretty much anybody if
subverted means use for any purpose they feel like.

On Jun 4, 2017 14:49, "Martin Gainty"  wrote:

> is there anyway to run maven-rat-plugin to make sure ASF licensed assets
> are *not* being subverted by salesforce
>
>
> http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html
>
>
> Apache Rat™ Plugin for Apache Maven – apache-rat:rat apache.org/rat/apache-rat-plugin/rat-mojo.html>
> creadur.apache.org
> apache-rat:rat. Note:This goal should be used as a Maven report. Full
> name: org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:
>
> ?
>
> Martin
> __
>
>
>
> 
> From: John D. Ament 
> Sent: Saturday, June 3, 2017 9:46 AM
> To: general@incubator.apache.org
> Subject: Re: Images in source code.
>
> On Fri, Jun 2, 2017 at 8:20 PM Craig Russell  wrote:
>
> > Hi James,
> >
> > Everything that is not explicitly called out in the top level NOTICE and
> > LICENSE files are licensed under the Apache 2.0 license.
> >
> > Adding a file to this directory might mislead people into thinking that
> > they need to perform more due diligence with other files in other
> > directories.
> >
> > My advice is to *not* add anything. Let the images be licensed per the
> > terms the top level LICENSE file.
> >
>
> Agreed.  What we do like to make sure is called out is if there is
> provenance that these images came from somewhere else.  If these images
> were not created by you and were not already under apache license, then we
> would have a concern.
>
>
> >
> > Craig
> >
> > > On Jun 2, 2017, at 2:20 PM, James Bognar 
> > wrote:
> > >
> > > Thanks!
> > >
> > > I haven't found a metadata editor that works yet, so I'll just add a
> > > LICENSE.txt file to the directory.  Hopefully that's enough.
> > >
> > > On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser  wrote:
> > >
> > >> On 6/2/17 1:15 PM, James Bognar wrote:
> > >>
> > >>> I just added several png files to the source tree of our podling.  I
> > >>> created them myself.  Are there any best-practices on how to mark
> > these as
> > >>> Apache licensed?
> > >>>
> > >>>
> > >> I'm not sure of a good way to track this. I'm not sure if png supports
> > >> arbitrary metadata which could be edited. Some ways I've seen used
> > >> elsewhere to try to better propagate license/ownership:
> > >>
> > >> * Comments on the issue-tracker issue that introduced them citing
> > >> origin/source (typically for images that are copied, not created)
> > >> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of course)
> > >> * A README in the same directory with relevant info
> > >>
> > >> If the images are of the podling's creation, I wouldn't be
> particularly
> > >> worried. The copyright notice on your source-release and LICENSE are
> > >> sufficient to inform downstream consumers.
> > >>
> > >> Probably not the answer you're looking for, but hope it helps :)
> > >>
> > >> - Josh
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > James Bognar
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: Images in source code.

2017-06-04 Thread Mike Drob 
Project logos are Apache Licensed, but cannot be used for "any purpose" I
thought? They're specifically called out and most uses of trademark logos
need to be approved by VP Brand.

https://www.apache.org/foundation/marks/

On Sun, Jun 4, 2017 at 9:09 AM, Ted Dunning  wrote:

> What does subverted by Salesforce even mean here?
>
> Any Apache licensed material can be "subverted" by pretty much anybody if
> subverted means use for any purpose they feel like.
>
> On Jun 4, 2017 14:49, "Martin Gainty"  wrote:
>
> > is there anyway to run maven-rat-plugin to make sure ASF licensed assets
> > are *not* being subverted by salesforce
> >
> >
> > http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html
> >
> >
> > Apache Rat™ Plugin for Apache Maven – apache-rat:rat > apache.org/rat/apache-rat-plugin/rat-mojo.html>
> > creadur.apache.org
> > apache-rat:rat. Note:This goal should be used as a Maven report. Full
> > name: org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:
> >
> > ?
> >
> > Martin
> > __
> >
> >
> >
> > 
> > From: John D. Ament 
> > Sent: Saturday, June 3, 2017 9:46 AM
> > To: general@incubator.apache.org
> > Subject: Re: Images in source code.
> >
> > On Fri, Jun 2, 2017 at 8:20 PM Craig Russell 
> wrote:
> >
> > > Hi James,
> > >
> > > Everything that is not explicitly called out in the top level NOTICE
> and
> > > LICENSE files are licensed under the Apache 2.0 license.
> > >
> > > Adding a file to this directory might mislead people into thinking that
> > > they need to perform more due diligence with other files in other
> > > directories.
> > >
> > > My advice is to *not* add anything. Let the images be licensed per the
> > > terms the top level LICENSE file.
> > >
> >
> > Agreed.  What we do like to make sure is called out is if there is
> > provenance that these images came from somewhere else.  If these images
> > were not created by you and were not already under apache license, then
> we
> > would have a concern.
> >
> >
> > >
> > > Craig
> > >
> > > > On Jun 2, 2017, at 2:20 PM, James Bognar <
> james.bog...@salesforce.com>
> > > wrote:
> > > >
> > > > Thanks!
> > > >
> > > > I haven't found a metadata editor that works yet, so I'll just add a
> > > > LICENSE.txt file to the directory.  Hopefully that's enough.
> > > >
> > > > On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser 
> wrote:
> > > >
> > > >> On 6/2/17 1:15 PM, James Bognar wrote:
> > > >>
> > > >>> I just added several png files to the source tree of our podling.
> I
> > > >>> created them myself.  Are there any best-practices on how to mark
> > > these as
> > > >>> Apache licensed?
> > > >>>
> > > >>>
> > > >> I'm not sure of a good way to track this. I'm not sure if png
> supports
> > > >> arbitrary metadata which could be edited. Some ways I've seen used
> > > >> elsewhere to try to better propagate license/ownership:
> > > >>
> > > >> * Comments on the issue-tracker issue that introduced them citing
> > > >> origin/source (typically for images that are copied, not created)
> > > >> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of
> course)
> > > >> * A README in the same directory with relevant info
> > > >>
> > > >> If the images are of the podling's creation, I wouldn't be
> > particularly
> > > >> worried. The copyright notice on your source-release and LICENSE are
> > > >> sufficient to inform downstream consumers.
> > > >>
> > > >> Probably not the answer you're looking for, but hope it helps :)
> > > >>
> > > >> - Josh
> > > >>
> > > >> 
> -
> > > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > > > --
> > > > James Bognar
> > >
> > > Craig L Russell
> > > c...@apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
>

Re: Images in source code.

2017-06-04 Thread Martin Gainty 





From: James Bognar 
Sent: Sunday, June 4, 2017 9:13 AM
To: general@incubator.apache.org
Subject: Re: Images in source code.

That's a good question.  I've discovered that images CAN contain metadata
that includes ownership information.  Rat could check for these.  In
practice though, these comment fields don't seem to be often used.

If I could add a simple "Copyright Apache" message to the metadata, I
would, but the tooling is suprisingly lacking.

MG>To answer the second question
MG>entities who purchase a product (salesforce) would not necessarily know:
MG>who created the code (especially when license information is stripped out 
and there is no attribution in META-INF readme/licenses)
MG>who generated the images..(assuming designers have the legal right to 
trademark/copyright their work)

MG>apologies for picking on salesforce ..ive seen other organisations grab 
OpenSource Assets/Code, stripout licenses & call it their own

MG>James if you can show me where the Copyright Apache is in metadata .. I'll 
get maven-rat-plugin to read metadata and throw BuildException
MG>and fail the rat check

MG>thanks for your help

On Sun, Jun 4, 2017 at 8:49 AM, Martin Gainty  wrote:

> is there anyway to run maven-rat-plugin to make sure ASF licensed assets
> are *not* being subverted by salesforce
>
>
> http://creadur.apache.org/rat/apache-rat-plugin/rat-mojo.html
Apache Rat™ Plugin for Apache Maven – 
apache-rat:rat
creadur.apache.org
apache-rat:rat. Note:This goal should be used as a Maven report. Full name: 
org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:



>
>
> Apache Rat™ Plugin for Apache Maven – apache-rat:rat apache.org/rat/apache-rat-plugin/rat-mojo.html>
> creadur.apache.org
> apache-rat:rat. Note:This goal should be used as a Maven report. Full
> name: org.apache.rat:apache-rat-plugin:0.13-SNAPSHOT:rat. Description:
>
> ?
>
> Martin
> __
>
>
>
> 
> From: John D. Ament 
> Sent: Saturday, June 3, 2017 9:46 AM
> To: general@incubator.apache.org
> Subject: Re: Images in source code.
>
> On Fri, Jun 2, 2017 at 8:20 PM Craig Russell  wrote:
>
> > Hi James,
> >
> > Everything that is not explicitly called out in the top level NOTICE and
> > LICENSE files are licensed under the Apache 2.0 license.
> >
> > Adding a file to this directory might mislead people into thinking that
> > they need to perform more due diligence with other files in other
> > directories.
> >
> > My advice is to *not* add anything. Let the images be licensed per the
> > terms the top level LICENSE file.
> >
>
> Agreed.  What we do like to make sure is called out is if there is
> provenance that these images came from somewhere else.  If these images
> were not created by you and were not already under apache license, then we
> would have a concern.
>
>
> >
> > Craig
> >
> > > On Jun 2, 2017, at 2:20 PM, James Bognar 
> > wrote:
> > >
> > > Thanks!
> > >
> > > I haven't found a metadata editor that works yet, so I'll just add a
> > > LICENSE.txt file to the directory.  Hopefully that's enough.
> > >
> > > On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser  wrote:
> > >
> > >> On 6/2/17 1:15 PM, James Bognar wrote:
> > >>
> > >>> I just added several png files to the source tree of our podling.  I
> > >>> created them myself.  Are there any best-practices on how to mark
> > these as
> > >>> Apache licensed?
> > >>>
> > >>>
> > >> I'm not sure of a good way to track this. I'm not sure if png supports
> > >> arbitrary metadata which could be edited. Some ways I've seen used
> > >> elsewhere to try to better propagate license/ownership:
> > >>
> > >> * Comments on the issue-tracker issue that introduced them citing
> > >> origin/source (typically for images that are copied, not created)
> > >> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of course)
> > >> * A README in the same directory with relevant info
> > >>
> > >> If the images are of the podling's creation, I wouldn't be
> particularly
> > >> worried. The copyright notice on your source-release and LICENSE are
> > >> sufficient to inform downstream consumers.
> > >>
> > >> Probably not the answer you're looking for, but hope it helps :)
> > >>
> > >> - Josh
> > >>
> > >> -
> > >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > >> For additional commands, e-mail: general-h...@incubator.apache.org
> > >>
> > >>
> > >
> > >
> > > --
> > > James Bognar
> >
> > Craig L Russell
> > c...@apache.org
> >
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>



--
James Bognar

Re: Images in source code.

2017-06-04 Thread Ted Dunning 
Mike,

Is that what Martin was talking about? Doesn't that seem pretty far off of
this thread which is about how to label images created for testing purposes?


On Sun, Jun 4, 2017 at 9:12 PM, Mike Drob  wrote:

> Project logos are Apache Licensed, but cannot be used for "any purpose" I
> thought? They're specifically called out and most uses of trademark logos
> need to be approved by VP Brand.
>
> https://www.apache.org/foundation/marks/
>
>
> On Sun, Jun 4, 2017 at 9:09 AM, Ted Dunning  wrote:
>
> > What does subverted by Salesforce even mean here?
> >
> > Any Apache licensed material can be "subverted" by pretty much anybody if
> > subverted means use for any purpose they feel like.
> >
> > On Jun 4, 2017 14:49, "Martin Gainty"  wrote:
> >
> > > is there anyway to run maven-rat-plugin to make sure ASF licensed
> assets
> > > are *not* being subverted by salesforce
>

Re: Images in source code.

2017-06-04 Thread Shane Curcuru 
Mike Drob wrote on 6/4/17 3:12 PM:
> Project logos are Apache Licensed, but cannot be used for "any purpose" I
> thought? They're specifically called out and most uses of trademark logos
> need to be approved by VP Brand.

Correct, although not quite exact.  The Apache license itself explicitly
*excludes* trademark rights [1]:

  https://www.apache.org/licenses/LICENSE-2.0.html#trademarks

So users are free to reuse our icons and logos and what-not almost
anyway they like, but *not* in ways that would infringe on our existing
trademarks for software products.

Users can take the nutty Apache Flink squirrel logo and use it to refer
to Apache Flink itself.  They could also use it as part of an art
collage, or in a presentation about squirrels, or mash it up with logos
of dogs or any other sort of non-trademark uses.  They can't use it (in
general cases) to refer to a different software product than Flink.

The reporting guide has some steps for thinking about "Is this
$somebody's use of an Apache logo OK or not?"

  https://www.apache.org/foundation/marks/reporting#kinds

-- 

- Shane
  https://www.apache.org/foundation/marks/resources

[1] Protip: no OSI-approved software license gives users any trademark
rights - even if "trademarks" never appears in the license.  FOSS
licenses are only *copyright* licenses, not trademark licenses.

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

Re: [VOTE] Apache HTrace 4.3.0 incubating release (rc3)

2017-06-04 Thread Josh Elser 

+1 (binding)

* xsums/sigs OK
* DISCLAIMER present
* LICENSE looks good
* NOTICE file has some unnecessary stuff, IMO:
	- "In addition, this product includes software dependencies. See the 
accompanying LICENSE.txt for a listing of dependencies that are NOT 
Apache licensed (with pointers to their licensing)" -- This does not 
seem necessary to me. This is the "norm" IMO.
	- "Apache HTrace includes an Apache Thrift connector to Zipkin. Zipkin 
is a distributed tracing system that is Apache 2.0 Licensed. Copyright 
2012 Twitter, Inc." -- First off, are these two sentences related? What 
component does the Twitter copyright apply to? My hunch would be the 
files beneath "htrace-zipkin/src/main/java/com/twitter/zipkin". This 
could be clarified in a later release.
* Could build from source (ran into troubles with htraced, but found 
BUILDING.txt to help)

* KEYS contains the signing key
* Tag/commit exists in scm

For your next release...

* That Maven 3.0.4 hard requirement is rough :). Would be nice if HTrace 
could move to a modern version of Maven.
* The shaded jars need work. They bundle numerous dependencies (with 
their various licenses and notice requirements) but include the default 
LICENSE and NOTICE files from the Apache parent pom. For reference, I 
checked the htrace-hbase jar and see that Protobuf classes are included 
but their license text is not included. I'm assuming the rest of the 
jars also violate policy in a similar manner.


- Josh

On 6/2/17 4:11 PM, Mike Drob wrote:

Hi IPMC,

Please consider the release of Apache HTrace 4.3.0 Incubating



Project [VOTE]:

https://lists.apache.org/thread.html/6e60ba2574a853da59c3a150f18cd9bbd52051785380a7cc837b583e@%3Cdev.htrace.apache.org%3E

Project [RESULT][VOTE]:

https://lists.apache.org/thread.html/fb2a68fcd9c80d9db4a483794112aecde486ca263384dec0bad38c34@%3Cdev.htrace.apache.org%3E

Artifacts staged at:

http://people.apache.org/~mdrob/htrace-4.3.0-incubating-rc3/

Staging maven repository at:

https://repository.apache.org/content/repositories/orgapachehtrace-1029

Source tree:

https://git-wip-us.apache.org/repos/asf?p=incubator-htrace.git;a=tree;h=2ca8767b38c83f0d2f46ce7f91373d9df69f7fb8;hb=a47398aea8d65fb544faba150beb49bb7654cb49


Please download and evaluate the release candidate.

This vote will remain open for minimum 5 days

[ ] +1 Approve the release

[ ] +0 No opinion

[ ] -1 Do not approve the release because ...


Thanks,

Mike



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

[DISCUSS] Migration of Podling Maintenance Tooling to Whimsy

2017-06-04 Thread John D. Ament 
All,

I want to bring up this discussion to see others opinions.  I would like to
move forward on migrating podling status maintenance into Whimsy.  Some of
the key things I want to improve upon is the overall experience around
managing the podling.  Sam's done a great job with rosters, but we can
start to track other things in whimsy, which mirrors what's in the status
file.  This can include IP Clearance/SGAs, Podling Name Searches, the
various dates we track.

Ultimately, I want to simplify how podlings are managed and make it a bit
easier on an end user.  Rather than needing to svn checkout to get files,
they simply go to a webpage, and assuming they're on that podling's roster
they would have access to update the status.  We could even automate
certain events so that when the board passes a resolution to graduate the
podling, the status file is updated along side any other record the podling
may have.

This does mean that the status file format is likely to change.  It also
means we're likely to move away from the java based build tool that has to
parse the XML templates into web pages and instead rely on a more
structured format for the status.

It doesn't mean you have to change.  If you like using SVN to edit this
stuff that's fine, you would still be able to.  Just what you're editing is
likely to be different.

Thoughts? Opinions?

John

Re: [DISCUSS] Migration of Podling Maintenance Tooling to Whimsy

2017-06-04 Thread Chris Mattmann 
+1 from me.

Cheers,
Chris


On 6/4/17, 4:33 PM, "John D. Ament"  wrote:

All,

I want to bring up this discussion to see others opinions.  I would like to
move forward on migrating podling status maintenance into Whimsy.  Some of
the key things I want to improve upon is the overall experience around
managing the podling.  Sam's done a great job with rosters, but we can
start to track other things in whimsy, which mirrors what's in the status
file.  This can include IP Clearance/SGAs, Podling Name Searches, the
various dates we track.

Ultimately, I want to simplify how podlings are managed and make it a bit
easier on an end user.  Rather than needing to svn checkout to get files,
they simply go to a webpage, and assuming they're on that podling's roster
they would have access to update the status.  We could even automate
certain events so that when the board passes a resolution to graduate the
podling, the status file is updated along side any other record the podling
may have.

This does mean that the status file format is likely to change.  It also
means we're likely to move away from the java based build tool that has to
parse the XML templates into web pages and instead rely on a more
structured format for the status.

It doesn't mean you have to change.  If you like using SVN to edit this
stuff that's fine, you would still be able to.  Just what you're editing is
likely to be different.

Thoughts? Opinions?

John




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