|
Re: First bug report :-)
Either way we appreciate it!
On Tue, Aug 21, 2018 at 5:42 PM Jim Houston <jim.houston@...> wrote:
--
Thank you, John Mertic Director of Program Management - Linux Foundation - ODPi, R Consortium, and Open Mainframe Project
|
|
|
|
Re: All Things Open Conference in October
Michael Hall
I went (and spoke) there last year. It's a great open source
event with a community focus. Very well run and well attended. Michael Hall mhall119@... On 08/21/2018 05:29 PM, Rob Aitchison
wrote:
Hi,
|
|
|
|
Re: Code signing
Meadhbh Hamrick
I bet security requirements are going to be all over the map in this group.
toggle quoted messageShow quoted text
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@gmail.com Sent from my TRS-80 Model 102
On Tue, Aug 21, 2018 at 3:29 PM, Nathan Loofbourrow <njloof@gmail.com> wrote:
I know it’s early days, especially for Windows and Mac, but will there be a
|
|
|
|
Re: Code signing
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.
|
|
|
|
Re: All Things Open Conference in October
Jason van Gumster
Agreed. I've been going to ATO for the last handful of years and it's always been a fantastic event. Well worth going if you can make it. Granted, as a community moderator on Opensource.com (they're an event sponsor), I'm a *little* biased, but hopefully you won't hold that against me. :)
toggle quoted messageShow quoted text
-Jason
On 8/21/18 6:35 PM, Michael Hall wrote:
I went (and spoke) there last year. It's a great open source event with a community focus. Very well run and well attended.
|
|
|
|
Collaboration Tools
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.
|
|
|
|
Re: All Things Open Conference in October
I'm very familiar with this event and know the organizers well - happy to meetup with folks there this fall as I'm slated as a speaker. Thank you, John Mertic Director of Program Management - Linux Foundation - ODPi, R Consortium, and Open Mainframe Project
On Tue, Aug 21, 2018 at 10:03 PM Jason van Gumster <fweeb@...> wrote: Agreed. I've been going to ATO for the last handful of years and it's
|
|
|
|
Re: Collaboration Tools
On Wed, Aug 22, 2018 at 9:01 AM <sean@...> wrote: Hello, 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
|
|
|
|
Re: Collaboration Tools
I would agree that real-time chat is extremely important with any type of project. We use it on a daily basis when we are hashing out ideas, having meetings, or trying to solve problems. We still use the old school IRC, but we also have an IRC web client for non-technical people (https://krita.org/en/irc/) . The main reason we have stayed with IRC is that you don't have to have an account to talk with people. This is great from a support standpoint with people just wanting to ask a question, but that concern might not be relevant with this group.
I am not sure if this is a concern for the ASWF, but having a public archive might be something you may, or may not want for the realtime chat. If the entire history of conversations are preserved, that can sometimes lead to privacy issues where people don't want everything they say "on the record". Not everything is always well thought out when you can talk in real time. Lists like this people at least have a bit of time to reflect on something before they post it.
|
|
|
|
Re: Collaboration Tools
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. 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:
|
|
|
|
Re: Collaboration Tools
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:
|
|
|
|
Re: Collaboration Tools
Jim Houston
I think you just proved that threading is a must :-)
+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
|
|
|
|
Re: Collaboration Tools
Larry Gritz
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.
toggle quoted messageShow quoted text
On August 22, 2018 10:08:04 AM PDT, Jim Houston <jim.houston@...> wrote:
--
Larry Gritz lg@...
|
|
|
|
Re: Collaboration Tools
@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.
|
|
|
|
Re: Collaboration Tools
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.
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) On Wed, Aug 22, 2018 at 6:25 PM, Larry Gritz <lg@...> wrote:
|
|
|
|
Re: Collaboration Tools
Darin Grant
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.
--
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.
|
|
|
|
Re: Projects
Henry Vera
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.
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
|
|
|
|
Re: Collaboration Tools
Ben De Luca
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.
On Wed, 22 Aug 2018 at 19:59, Darin Grant <darin.grant@...> wrote:
|
|
|
|
Re: Collaboration Tools
Larry Gritz
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."
toggle quoted messageShow quoted text
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:
--
Larry Gritz lg@...
|
|
|
|
Re: Collaboration Tools
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). -- Mike
On Wed, Aug 22, 2018 at 9:33 PM Larry Gritz <lg@...> wrote:
|
|
|