|
Building OpenEXR on Windows
Thanh Ha
Hi Everyone,
We rolled out Windows builders for the ASWF project and are having some issues building OpenEXR's IlmBase project (see the command and error below) with it (trying to confirm that the builder is good). It seems like CMake is trying to call msbuild from a C:/Windows path but we have it installed at "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild"
It's not obvious to me where CMake is picking up this path. Is there a way I can tell it where to look for msbuild?
The jenkins job I've been tested is here:
Please let me know if the approach I am taking is incorrect, I'm trying to follow what's documented in the README.cmake.txt file.
Thanks, Thanh
& "C:\Program Files\CMake\Bin\cmake" -DCMAKE_INSTALL_PREFIX=C:\lib\ilmbase -G "Visual Studio 10 Win64" ..
CMake Error at CMakeLists.txt:8 (PROJECT):
Failed to run MSBuild command:
C:/Windows/Microsoft.NET/Framework/v4.0.30319/MSBuild.exe
to get the value of VCTargetsPath:
Microsoft (R) Build Engine version 4.6.1586.0
[Microsoft .NET Framework, version 4.0.30319.42000]
Copyright (C) Microsoft Corporation. All rights reserved.
Build started 9/19/2018 12:45:34 AM.
Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" on node 1 (default targets).
C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Done Building Project "C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default targets) -- FAILED.
Build FAILED.
"C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj" (default target) (1) ->
C:\w\workspace\openexr-win64-master\IlmBase\build\CMakeFiles\3.12.2\VCTargetsPath.vcxproj(14,2): error MSB4019: The imported project "C:\Microsoft.Cpp.Default.props" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
0 Warning(s)
1 Error(s)
|
|
|
Re: Missing link in Infra Bootstrap documentation?
Thanh Ha
On Tue, Sep 11, 2018 at 11:30 AM Thanh Ha < thanh.ha@...> wrote: On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset < panisset@...> wrote: Hi Thanh,
Hi JF,
I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.
I'm starting to configure Jenkins to match the documented config,
looking at the documentation:
https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html
I find:
9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>
which doesn't seem to link to anything. Should it?
It's supposed to link to this:
I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.
Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.
We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.
On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.
Hi JF,
IT gave me the following puppet information in case it's helpful for you but as I suspected we don't have any custom config in place to handle Jenkins and use what's already available out on puppet forge. Here was the response I got:
jenkins::config_hash: JENKINS_LISTEN_ADDRESS: value: '0.0.0.0' JENKINS_AJP_PORT: value: '-1' JENKINS_ARGS: value: '-Dhudson.model.ParametersAction.safeParameters=GERRIT_EVENT_TYPE,GERRIT_EVENT_HASH,GERRIT_BRANCH,GERRIT_TOPIC,GERRIT_CHANGE_NUMBER,GERRIT_CHANGE_ID,GERRIT_PATCHSET_NUMBER,GERRIT_PATCHSET_REVISION,GERRIT_REFSPEC,GERRIT_PROJECT,GERRIT_CHANGE_SUBJECT,GERRIT_CHANGE_COMMIT_MESSAGE,GERRIT_CHANGE_URL,GERRIT_CHANGE_OWNER,GERRIT_CHANGE_OWNER_NAME,GERRIT_CHANGE_OWNER_EMAIL,GERRIT_PATCHSET_UPLOADER,GERRIT_PATCHSET_UPLOADER_NAME'
# yamllint enable
jenkins::port: '8080' jenkins::admin: '<projectname>-jenkins'
|
|
|
Re: Missing link in Infra Bootstrap documentation?
Perfect, thank you for the documentation link. I had been using those official containers as a base so looks like I'm on the right track.
JF Panisset
On Sep 11, 2018, at 08:30, Thanh Ha < thanh.ha@...> wrote: On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset < panisset@...> wrote: Hi Thanh,
Hi JF,
I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.
I'm starting to configure Jenkins to match the documented config,
looking at the documentation:
https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html
I find:
9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>
which doesn't seem to link to anything. Should it?
It's supposed to link to this:
I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.
Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.
We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.
On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.
Hope this helps, Thanh
|
|
|
Re: Missing link in Infra Bootstrap documentation?
Thanh Ha
On Tue, Sep 11, 2018 at 3:27 AM Jean-Francois Panisset < panisset@...> wrote: Hi Thanh,
Hi JF,
I hope you don't mind me cc'ing the mailing lists so that others can benefit from the knowledge from this discussion as well.
I'm starting to configure Jenkins to match the documented config,
looking at the documentation:
https://docs.releng.linuxfoundation.org/en/latest/infra/bootstrap.html
I find:
9. Configure Jenkins security as described in Jenkins Security
<jenkins-security>
which doesn't seem to link to anything. Should it?
It's supposed to link to this:
I'll let you know once my project gets to the point of having
reproduced the documented config for Jenkins / Nexus 2 / Nexus 3
servers.
Does the LF have code that creates these servers? There's value for me
in figuring this out on my own, and in particular in creating a local
/ standalone version, but it would be create to have a reference to
compare against.
We do but I've been told we cannot share it because it's tied in with our infra management puppet configuration.
On the other hand I can assure you that there's nothing special about our configuration to create these servers. These docs assume a completely fresh install of these servers with no additional changes in the backend. You could for example even use the official Jenkins docker container and start off from these docs for both Jenkins / Nexus 2 / Nexus 3 even.
Hope this helps, Thanh
|
|
|
Henk Vanneste <hankbonk2@...>
I am a 52 years young programmer from Belgium . I am learning Linux on an education site called edx.org because I am very interested in it, and also have Lubuntu 16.04 LTS running on my little PC . It would be an honour to work with a group of Linux programmers, I am not yet familiar with Java or perl or python, but I am planning to learn python .
|
|
|
Thanh Ha
Yep, we'll have to figure out Windows and Mac once we get the infra for those in place and working. I have some experience with signing OSX code from a past life which might be of use. Today our infra is mainly Linux based so our signing services are a lot more mature on the Linux platform, but as we get the non-linux builders up and running we will definitely be interested rolling out tooling to support those platforms as well.
Regards, Thanh
On Mon, Aug 27, 2018 at 11:19 AM Nathan Loofbourrow < njloof@...> wrote: For both Windows and Max OSX, you will need a developer signing certificate which is used to ensure the origin of the compiled code. Similar to GPG, but verified by the OS rather than by a package manager.
Let me know if you need additional details.
n
On Tue, Aug 21, 2018 at 9:24 PM Thanh Ha < thanh.ha@...> wrote: Hi Everyone,
For those who don't know me I'm a Release Engineer at the Linux Foundation and am helping the ASWF project get setup. Feel free to direct any CI related questions to me.
I can confirm that signing is very important to many of our projects and we definitely sign both our artifacts (binaries) as well as git tags when we release software for many of our other projects at the Linux Foundation.
Today the signing is done manually via "git tag -s" as well as gpg sign of release artifacts when projects approve a staged release for public release.
We are working on providing some automation in our CI platform to allow projects to have their artifacts signed along with the staging jobs (these jobs prepare releases) but it's not ready just yet.
Cheers, Thanh On Tue, Aug 21, 2018 at 7:31 PM Meadhbh Hamrick < ohmeadhbh@...> wrote: I bet security requirements are going to be all over the map in this group.
I bet people who are trying to push out media to end user devices are
going to be VERY interested in signed code, but other people who are
running binaries they completely compiled from source files they just
downloaded from github are going to be more interested in verifying
the provenance of the tarballs they just downloaded than verifying
signatures on executables they just built.
I'm mostly in the latter camp, except for the tiny bits where i'm in
the former. I really want my developers that are building FLOSS
projects to be able to pick operational security procedures that make
sense for them (but yeah, at the same time I don't want to say
"SIGNING EXECUTABLES IS USELESS!" because I do bump up into that world
from time to time and know it's a requirement for some people.)
I guess what I'm saying is... I bet it's going to be a little more
complicated than people might originally think based on their own
experiences. But I also think we could do a small amount of work
up-front to define a handful of security models that will work for 80%
of people on the list and it'll give the other 20% something to point
at when they're trying to describe how it doesn't work.
Do you have specific requirements, Nathan? Like I said, I'm mostly a
backend server farm guy, but every now and again I bump into the
mobile / app store world where code signing makes a lot more sense.
-cheers
-m
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.hamrick.rocks/ * OhMeadhbh@...
Sent from my TRS-80 Model 102
On Tue, Aug 21, 2018 at 3:29 PM, Nathan Loofbourrow <njloof@...> wrote:
> I know it’s early days, especially for Windows and Mac, but will there be a
> plan for code signing the binaries produced by CI? This will be important
> for security and adoption.
|
|
|
For both Windows and Max OSX, you will need a developer signing certificate which is used to ensure the origin of the compiled code. Similar to GPG, but verified by the OS rather than by a package manager.
Let me know if you need additional details.
n
toggle quoted message
Show quoted text
On Tue, Aug 21, 2018 at 9:24 PM Thanh Ha < thanh.ha@...> wrote: Hi Everyone,
For those who don't know me I'm a Release Engineer at the Linux Foundation and am helping the ASWF project get setup. Feel free to direct any CI related questions to me.
I can confirm that signing is very important to many of our projects and we definitely sign both our artifacts (binaries) as well as git tags when we release software for many of our other projects at the Linux Foundation.
Today the signing is done manually via "git tag -s" as well as gpg sign of release artifacts when projects approve a staged release for public release.
We are working on providing some automation in our CI platform to allow projects to have their artifacts signed along with the staging jobs (these jobs prepare releases) but it's not ready just yet.
Cheers, Thanh On Tue, Aug 21, 2018 at 7:31 PM Meadhbh Hamrick < ohmeadhbh@...> wrote: I bet security requirements are going to be all over the map in this group.
I bet people who are trying to push out media to end user devices are
going to be VERY interested in signed code, but other people who are
running binaries they completely compiled from source files they just
downloaded from github are going to be more interested in verifying
the provenance of the tarballs they just downloaded than verifying
signatures on executables they just built.
I'm mostly in the latter camp, except for the tiny bits where i'm in
the former. I really want my developers that are building FLOSS
projects to be able to pick operational security procedures that make
sense for them (but yeah, at the same time I don't want to say
"SIGNING EXECUTABLES IS USELESS!" because I do bump up into that world
from time to time and know it's a requirement for some people.)
I guess what I'm saying is... I bet it's going to be a little more
complicated than people might originally think based on their own
experiences. But I also think we could do a small amount of work
up-front to define a handful of security models that will work for 80%
of people on the list and it'll give the other 20% something to point
at when they're trying to describe how it doesn't work.
Do you have specific requirements, Nathan? Like I said, I'm mostly a
backend server farm guy, but every now and again I bump into the
mobile / app store world where code signing makes a lot more sense.
-cheers
-m
--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.hamrick.rocks/ * OhMeadhbh@...
Sent from my TRS-80 Model 102
On Tue, Aug 21, 2018 at 3:29 PM, Nathan Loofbourrow <njloof@...> wrote:
> I know it’s early days, especially for Windows and Mac, but will there be a
> plan for code signing the binaries produced by CI? This will be important
> for security and adoption.
|
|
|
Edward Warnicke
Depends a lot on the communities.
While I personally prefer IRC (or did, until it started dying of spam :( ), I also participate in many communities that use slack instead. Ed
On August 22, 2018 at 9:30:51 PM, Michael Dolan (mdolan@...) wrote:
FWIW, I've seen a number of communities start off by
adding everyone's favorite real time service - but then they
commonly end up back at email and maybe IRC for real time chat
during meetings (with a MeetBot addon).
On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz
< lg@...>
wrote:
Not to beat a dead horse, but when somebody says "real time",
what I hear is "somebody important on the project, maybe even me,
is going to miss it."
As I understand it, ASWF projects are intended to have a very high
level of autonomy in what gets developed and how. I can't imagine
that each project community wouldn't decide on its own
communications style and mode. Though it's possible that for the
ones who choose to have a real time (aka people left out 😜) comm
channel, there may end up being an org-wide preference for which
one.
On August 22, 2018 2:48:01 PM PDT, Ben De
Luca < bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a
crappy timezone where you are all mostly asleep, I hope that
mailing lists can at least be the main form of communication with
real-time being a supplement for the real-time
interactions.
I
believe Larry has it correct. Chat is amazing for quick
collaboration and question answering but I suspect that these
discussions are actually meant for discussions and thus belong on
an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail
lists
Nope. I think its completely fair for the ASWF to just say no
to real-time options.
Just the number of mile-long emails when something contentious
is discussed always irritates me, especially when usually
people can be calmed down and come to level ground when its a
real-time interaction. So real solutions happen faster. That's all
hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to
dead links because of a change
in the collaboration tool
This is precisely why I propose the ideal solution would be
open source and hosted as a part of ASWF stack (sorry to
maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800
(main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia
38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
   
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It
is confidential and may contain privileged information. If you are
not the intended recipient, any use, distribution, disclosure or
copying of this email is strictly prohibited. Confidentiality and
legal privilege attached to this communication are not waived or
lost by reason of the mistaken delivery to you. If you have
received this email in error, please delete it and notify us
immediately by telephone or email.
--
Larry Gritz
lg@...
|
|
|
Sebastian Sylwan
I think both forms of communication are perfectly fine and have their place, but most importantly I don't think it's the role of the ASWF to dictate the tools to use. It is very much - I believe-- in the purview of the individual projects to decide what works best for them.
The foundation (the TAC actually) could recommend that if a real time communication channel is used a default one should be preferred (but again not imposed), or provide an infrastructure for it, if enough projects choose the same, to encourage others to join in (for the advantages pointed up above). Same for a mailing list infrastructure.
S
On Wed, Aug 22, 2018, 5:53 PM Ben De Luca, < bdeluca@...> wrote: Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions.
I believe Larry has it correct. Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's
all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality
and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
|
|
|
Michael Dolan
FWIW, I've seen a number of communities start off by adding everyone's favorite real time service - but then they commonly end up back at email and maybe IRC for real time chat during meetings (with a MeetBot addon).
On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz < lg@...> wrote: Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."
As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.
On August 22, 2018 2:48:01 PM PDT, Ben De Luca < bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions.
I believe Larry has it correct. Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's
all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality
and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
--
Larry Gritz
lg@...
|
|
|
Not to beat a dead horse, but when somebody says "real time", what I hear is "somebody important on the project, maybe even me, is going to miss it."
As I understand it, ASWF projects are intended to have a very high level of autonomy in what gets developed and how. I can't imagine that each project community wouldn't decide on its own communications style and mode. Though it's possible that for the ones who choose to have a real time (aka people left out 😜) comm channel, there may end up being an org-wide preference for which one.
On August 22, 2018 2:48:01 PM PDT, Ben De Luca <bdeluca@...> wrote:
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions.
I believe Larry has it correct. Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's
all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality
and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
--
Larry Gritz
lg@...
|
|
|
Too echo Larry and Darin's the joy of living in a crappy timezone where you are all mostly asleep, I hope that mailing lists can at least be the main form of communication with real-time being a supplement for the real-time interactions.
I believe Larry has it correct. Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's
all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality
and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
|
|
|
To follow-up on Rob's email. The TAC just had our first meeting where one of the orders of business was an initial review of the project lifecycle and project contribution proposal template document, used when proposing a projects for admittance to the ASWF. It is being made available via Google Docs for editing. This is very much a work-in-progress and we have decided to proceed using the proposed document for openEXR, OCIO and OpenVDB, as well as trialling using JIRA to track submissions. This will allow us to start getting these projects moved over to the foundation and flesh-out the process.
The process currently being discussed (as of an hour ago) consisted of. - Providing information on the ASWF website on how to propose a project for consideration for adoption
- To propose a project, a project contribution proposal document must be filled out and submitted to the main aswf list.
- A JIRA ticket will be created to track the process of the submission
- The project can be submitted for either incubation or adoption. The difference being the maturity of the project and it's conformance to criteria that will be defined and communicated by the ASWF
- The submitters will meet with the TAC to discuss their project
- The TAC will review the submission and vote whether to put the proposal forward to the Governance Board
All of the above are in very early stages of discussion and I would suggest that anyone considering submitting a project wait until we have fleshed out the process a bit more and officially communicated the steps required.
As we know there is a lot of interest in the ASWF, the TAC is looking to meet fairly frequently (weekly, tbd) to make progress on these and other issues.
Hopefully, this sheds a bit more light on what is happening.
Henry Vera.
From: rob@...
To: main@...
Sent: Friday, August 10, 2018 11:27:31 PM
Subject: Re: [ASWF] Projects
Hi Jordan, Thanks for writing and your interest. One of the first items of business for the new ASWF will be to create the "project submission process". This will allow new and existing projects to be submitted to the ASWF, allow them to be evaluated to insure they are a fit into the mission and resources, and then accepted into the ASWF. Our conversations to date have been around some critical existing projects for the media business whose maintainers have expressed interest. Projects like OpenEXR, OpenColorIO and OpenVDB have been discussed so far. There are a lot more, but the ASWF will have to evaluate each to make sure the resources to host the community are in place to take on more projects. To get some background on how the Linux Foundation generally approaches project submissions, you might like reading this presentation by Chris Aniszczyk ( https://www.slideshare.net/caniszczyk/bringing-an-open-source-project-to-the-linux-foundation). Each organization under the LF (of which ASWF is one) specifies their own submission process so the ASWF may have some customization, but I think those slides provide some good background. Hope that help. Sincerely, Rob Bredow
|
|
|
I believe Larry has it correct. Chat is amazing for quick collaboration and question answering but I suspect that these discussions are actually meant for discussions and thus belong on an email list / forum.
On Aug 22, 2018, at 10:50 AM, Sean Cooper < sean@...> wrote:
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's
all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
--
Darin Grant
Chief Technology Officer
T: +61 2 9383 4800 (main)
D: 604 398 3945 (direct)
E: Darin.Grant@...
Bld 54/FSA #19, Fox Studios Australia 38 Driver Ave
Moore Park, NSW 2021
AUSTRALIA
www.animallogic.com
CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality
and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
|
|
|
Sean Cooper
Am I just a cranky old man for preferring mail lists
Nope. I think its completely fair for the ASWF to just say no to real-time options.
Just the number of mile-long emails when something contentious is discussed always irritates me, especially when usually people can be calmed down and come to level ground when its a real-time interaction. So real solutions happen faster. That's all hearsay, conjecture, and personal bias of course.
It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool
This is precisely why I propose the ideal solution would be open source and hosted as a part of ASWF stack (sorry to maintainers in advance if that actually happens)
|
|
|
Alien Ghost Ship Animation Studios
@LarryGritz, Perhaps, lol. There are implementations that will allow you to post/read like a mail list but have messages thread and show up in real time on a chat window so everyone is happy. I believe Slack has this feature, and maybe a few IRC's? Haven't used IRC in a while.
|
|
|
Am I just a cranky old man for preferring mail lists and dreading using Slack or IRC? They're ok for totally ephemeral "gotta do this thing right now" stuff, but I hate when actual substantive discussions or decisions for projects are made on those channels.
On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:
On Aug 22, 2018, at 9:04 AM, Sean Cooper < sean@...> wrote:
I think you just proved that threading is a must :-)
I agree though, an option to join a channel without signing up would be great.
+1
A consistent approach among projects would be great. I think it is difficult though to use a new startup’s tool because they are still chasing a business model. What features will still be present and/or advancing and which go by the wayside.
For a project started in 2004, I found it very useful at times to have the history of the project and sample images that were used still available. It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool. This is true as well in SMPTE’s Kavi (higher logic) where reorganizations have wiped clean previous threads. Although working in the moment on current topics is important for collaboration, I would also suggest the benefits of long-term learning from past decisions can be useful.
Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts sometimes ignoring the benefits of tested and working codes. (acknowledging that sometimes spaghetti just has to GO )
Jim Houston
--
Larry Gritz
lg@...
|
|
|
On Aug 22, 2018, at 9:04 AM, Sean Cooper < sean@...> wrote:
I think you just proved that threading is a must :-)
I agree though, an option to join a channel without signing up would be great.
+1
A consistent approach among projects would be great. I think it is difficult though to use a new startup’s tool because they are still chasing a business model. What features will still be present and/or advancing and which go by the wayside.
For a project started in 2004, I found it very useful at times to have the history of the project and sample images that were used still available. It is a significant nuisance when past e-mail/posts point to dead links because of a change in the collaboration tool. This is true as well in SMPTE’s Kavi (higher logic) where reorganizations have wiped clean previous threads. Although working in the moment on current topics is important for collaboration, I would also suggest the benefits of long-term learning from past decisions can be useful.
Especially in software projects where it seems that every decade or so, there is a significant throwing out of previous efforts sometimes ignoring the benefits of tested and working codes. (acknowledging that sometimes spaghetti just has to GO )
Jim Houston
|
|
|
Sean Cooper
Thanks,
Yes, I don't want my comment to seem to impose my solution, but exactly to the point above if something isn't chosen at the get-go, each sub-project will do their own thing and some uniformity would be great.
Each project has different communities and different paces of development of course, so I don't think its right to force anyone to use a real-time tool if Email Lists get the job done, but having one answer when people start asking for it would be nice and ease integration and cross-project communication.
Perhaps I'm just a young yuppie, but abandoning modern features for IRC could work but logging would be a must, and from following ffmpeg development even loosely finding any conversation is horrible unless you know the exact day and time the conversation happened, and you better hope no one else asked a question in between. This is why I'm so drawn to the Zulip real-time threads concept. I agree though, an option to join a channel without signing up would be great. I've asked that question to Zulip here if you care to follow.
On Wed, Aug 22, 2018 at 3:57 PM, Edward Warnicke <hagbard@...> wrote: Sean,
Community personalities differ, and its important to find the tool that fits them.
I’ve worked in communities that *only* operate via mailing lists, you can’t get *anyone* on slack or IRC. I’ve also worked in communities where almost *everything* happens on slack and IRC and the mailing lists are moribund.
Slack and IRC each have their pluses and minuses. Choosing one is something that the ASWF community is going to have to do for itself.
You also need to decide whether to have a single ASWF slack with channels for the projects, or a slack channel per project. Again, the appropriate choice is going to be dictated by the particular personalities of the projects in ASWF.
My recommendation would be to make a quick ‘starter call’ and get something going, and then see how it goes. Some things simply require experimentation.
Ed
On August 22, 2018 at 9:45:55 AM, Thanh Ha (thanh.ha@...) wrote:
On Wed, Aug 22, 2018 at 9:01 AM < sean@...>
wrote:
Hello,
I'm on the development team for OpenColorIO, and would like to
raise the conversation around project communication platforms.
Quickly looking at the Collaboration Tools list for ASWF I see the
usual options of Mailing Lists and Issue Tracking. However, OCIO
has greatly benefited by having real-time communication through a
Slack group which promotes candid responses from maintainers and
community members instead of long essays like this. I believe this
fosters a greater feeling of participation and community which was
very helpful in re-kindling development with the
project.
I'm am definitely not a proponent of Slack. In fact, I really
dislike it and am starting the conversation with our community on
switching to an alternative. When/if OpenColorIO is moved under the
care of the ASWF, I would like to see a real-time communication
platform promoted. At the moment the best option which I have yet
to use in practice is Zulip (https://zulipchat.com/for/open-source/).
The features they offer seem to be a substantial gain over Slack or
alternatives.
- Apache 2.0 Licensed
- Free hosting for OSS (maybe ASWF hosts a server)
- Join without invitation
- Permalink to conversations
- Github issue links e.g. #1234
- Github/Jenkins/TravisCI integrations
- Proper nested conversations (thank goodness)
- Public archival coming soon apparently
In summary, real-time communication with
asynchronous participation is vital to project success. With
the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see
an option promoted and used across ASWF projects.
Many Open Source projects use Freenode IRC. Something that I
think a lot of these new tools miss is that there's no single
agreed upon server for Open Source projects in general, so if folks
want to cross collaborate with another community it's harder (need
new accounts on different systems just to join 1 channel).
If you work with 10 different project communities and have to
connect to 10 different tools / protocols it quickly get's out of
hand. I'm not sure if anyone else participates in multiple project
communities but if ASWF plans to cross collaborate with another
community (maybe dependency projects) it is much easier to just
"/join #channel" then to have to sign up for an entirely new
account on another system.
Something ASWF might want to consider when choosing a
collaboration tool.
Regards,
Thanh
|
|
|
Edward Warnicke
Sean,
Community personalities differ, and its important to find the tool that fits them.
I’ve worked in communities that *only* operate via mailing lists, you can’t get *anyone* on slack or IRC. I’ve also worked in communities where almost *everything* happens on slack and IRC and the mailing lists are moribund.
Slack and IRC each have their pluses and minuses. Choosing one is something that the ASWF community is going to have to do for itself.
You also need to decide whether to have a single ASWF slack with channels for the projects, or a slack channel per project. Again, the appropriate choice is going to be dictated by the particular personalities of the projects in ASWF.
My recommendation would be to make a quick ‘starter call’ and get something going, and then see how it goes. Some things simply require experimentation.
On August 22, 2018 at 9:45:55 AM, Thanh Ha (thanh.ha@...) wrote:
On Wed, Aug 22, 2018 at 9:01 AM < sean@...>
wrote:
Hello,
I'm on the development team for OpenColorIO, and would like to
raise the conversation around project communication platforms.
Quickly looking at the Collaboration Tools list for ASWF I see the
usual options of Mailing Lists and Issue Tracking. However, OCIO
has greatly benefited by having real-time communication through a
Slack group which promotes candid responses from maintainers and
community members instead of long essays like this. I believe this
fosters a greater feeling of participation and community which was
very helpful in re-kindling development with the
project.
I'm am definitely not a proponent of Slack. In fact, I really
dislike it and am starting the conversation with our community on
switching to an alternative. When/if OpenColorIO is moved under the
care of the ASWF, I would like to see a real-time communication
platform promoted. At the moment the best option which I have yet
to use in practice is Zulip (https://zulipchat.com/for/open-source/).
The features they offer seem to be a substantial gain over Slack or
alternatives.
- Apache 2.0 Licensed
- Free hosting for OSS (maybe ASWF hosts a server)
- Join without invitation
- Permalink to conversations
- Github issue links e.g. #1234
- Github/Jenkins/TravisCI integrations
- Proper nested conversations (thank goodness)
- Public archival coming soon apparently
In summary, real-time communication with
asynchronous participation is vital to project success. With
the declining use of email-lists ( https://arxiv.org/pdf/1803.09529.pdf) I'd love to see
an option promoted and used across ASWF projects.
Many Open Source projects use Freenode IRC. Something that I
think a lot of these new tools miss is that there's no single
agreed upon server for Open Source projects in general, so if folks
want to cross collaborate with another community it's harder (need
new accounts on different systems just to join 1 channel).
If you work with 10 different project communities and have to
connect to 10 different tools / protocols it quickly get's out of
hand. I'm not sure if anyone else participates in multiple project
communities but if ASWF plans to cross collaborate with another
community (maybe dependency projects) it is much easier to just
"/join #channel" then to have to sign up for an entirely new
account on another system.
Something ASWF might want to consider when choosing a
collaboration tool.
Regards,
Thanh
|
|
|
