I think we do have the pain only with Linux. Since some distributions move slower then others.
We could bundle the only 1.0.0 with Windows and Mac I think. For Linux we would need some logic, that identifies the right gstreamer available on the distribution. Maybe we could even reduce the effort to one certain package. I do not know about OS/2 or BSD. Maybe the appropiate volunteers could answer that. But imho it should not be a problem to create an additional port for this on BSD and integrate the right extention on OS/2. A complete different approach could be not to bundle the extention. It would give us the option for Windows user to add the gstreamer into the extention, providing them a simplified access. For Linux a integration into the distribution would be the way. But I do not know how we can do that. We need maintainers for that. Am 1. Mai 2018 13:57:50 MESZ schrieb Jim Jagielski <j...@jagunet.com>: >So that would mean that our 'official' community builds would >not longer bundle/include it by default? Would we have 2 different >versions of the extension (0.10 and 1.0) or just one? > >I like the idea, btw :) > >> On Apr 26, 2018, at 1:14 AM, Peter Kovacs <pe...@apache.org> wrote: >> >> Does it make sense to reorg the gstreamer module into an extention? >> We could then have multiple versions of it. >> >> I mean after all this is only a optional feature, thats important to >some not all. >> >> On 25.04.2018 16:18, Jim Jagielski wrote: >>> I think this shows that we need to come to *some* consensus on >>> how to handle the gstreamer stuff. Either we provide both CentOS6 >>> and Ubuntu builds to our community or we fold in the proposed >>> gstreamer "work-around" which makes it a purely runtime >>> concern. >>> >>> I would love to see how far we can go with the latter, but I am >>> loath to volunteer someone else to "do the work" since I am >>> unsure what the exact status of the patch is, how to fold it >>> into trunk and how to handle building with the patch folded in. >>> >>> I know that there are other issues related to being at the stage >>> to branch AOO420 from trunk but this, to me, seems like the >>> priority at this point. >>> >>> >--------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >>> For additional commands, e-mail: dev-h...@openoffice.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >For additional commands, e-mail: dev-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
