Mailing List Archive

On 9/11/23 08:09, Paul Harrison wrote:
> Cool. I missed you added support for slave BE's. Is that support built
> in to the API or just the WebApp? I kind of envisioned a drop down in
> the header where you could select the BE you wanted to configure.

To configure a slave backend, you have to connect to the backend you are
configuring, as in http://slave:6544. Nothing special is built into the
APIs. The web app reads the settings and compares the Master server name
against the host name to determine if this is a slave backend.

I found that when you are running the web app from one backend you
cannot use an API on another backend, the browser prevents it. This
makes sense as otherwise a web page from the internet could access APIs
on your internal network. There are probably ways to allow it, but I did
not go into that.

Peter

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/09/2023 14:03, Peter Bennett wrote:
>
> To configure a slave backend, you have to connect to the backend you are configuring, as in
> http://slave:6544. Nothing special is built into the APIs. The web app reads the settings and
> compares the Master server name against the host name to determine if this is a slave backend.
>
> I found that when you are running the web app from one backend you cannot use an API on another
> backend, the browser prevents it. This makes sense as otherwise a web page from the internet could
> access APIs on your internal network. There are probably ways to allow it, but I did not go into that.
>
Could I ask you to clarify that, for someone not in the development loop?

Do you mean, use an API to backend B while your browser (presumably on a third host) is accessing
the webapp on backend A?

Or do you mean that while your browser is accessing the webapp on backend A /nobody/ can use the API
on any host?

--

Mike Perkins


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

Hoi Mike,

Monday, September 11, 2023, 5:49:33 PM, you wrote:

> On 11/09/2023 14:03, Peter Bennett wrote:
>>
>> To configure a slave backend, you have to connect to the backend you are configuring, as in
>> http://slave:6544. Nothing special is built into the APIs. The web app reads the settings and
>> compares the Master server name against the host name to determine if this is a slave backend.
>>
>> I found that when you are running the web app from one backend you cannot use an API on another
>> backend, the browser prevents it. This makes sense as otherwise a web page from the internet could
>> access APIs on your internal network. There are probably ways to allow it, but I did not go into that.
>>
> Could I ask you to clarify that, for someone not in the development loop?

> Do you mean, use an API to backend B while your browser (presumably on a third host) is accessing
> the webapp on backend A?

> Or do you mean that while your browser is accessing the webapp on
> backend A /nobody/ can use the API
> on any host?


Maybe this is the cooky protection, which blocks accessing cookies
placed by one ip address from another address. This assuming the api
uses cookies.


Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 9/11/23 11:49, Mike Perkins wrote:
> On 11/09/2023 14:03, Peter Bennett wrote:
>>
>> To configure a slave backend, you have to connect to the backend you
>> are configuring, as in http://slave:6544. Nothing special is built
>> into the APIs. The web app reads the settings and compares the Master
>> server name against the host name to determine if this is a slave
>> backend.
>>
>> I found that when you are running the web app from one backend you
>> cannot use an API on another backend, the browser prevents it. This
>> makes sense as otherwise a web page from the internet could access
>> APIs on your internal network. There are probably ways to allow it,
>> but I did not go into that.
>>
> Could I ask you to clarify that, for someone not in the development loop?
Sorry, I did not describe it very well. What I am saying is if you run
the web app from backend A, that web app page can call APIs on backend A
but it cannot call APIs on backend B. Other applications can call the
API on backend A or B. This restriction is only in the web app or other
web apps, not in programs running on your server.
>
> Do you mean, use an API to backend B while your browser (presumably on
> a third host) is accessing the webapp on backend A?
No, sorry for the confusion.
>
> Or do you mean that while your browser is accessing the webapp on
> backend A /nobody/ can use the API on any host?
>
No. Anybody else can call the API, only the web app is restricted.

Peter

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/09/2023 17:27, Peter Bennett wrote:

>
> On 9/11/23 11:49, Mike Perkins wrote:
>> On 11/09/2023 14:03, Peter Bennett wrote:
>>>
>>> To configure a slave backend, you have to connect to the backend you
>>> are configuring, as in http://slave:6544. Nothing special is built
>>> into the APIs. The web app reads the settings and compares the
>>> Master server name against the host name to determine if this is a
>>> slave backend.
>>>
>>> I found that when you are running the web app from one backend you
>>> cannot use an API on another backend, the browser prevents it. This
>>> makes sense as otherwise a web page from the internet could access
>>> APIs on your internal network. There are probably ways to allow it,
>>> but I did not go into that.
>>>
>> Could I ask you to clarify that, for someone not in the development
>> loop?
> Sorry, I did not describe it very well. What I am saying is if you run
> the web app from backend A, that web app page can call APIs on backend
> A but it cannot call APIs on backend B. Other applications can call
> the API on backend A or B. This restriction is only in the web app or
> other web apps, not in programs running on your server.
>>
>> Do you mean, use an API to backend B while your browser (presumably
>> on a third host) is accessing the webapp on backend A?
> No, sorry for the confusion.
>>
>> Or do you mean that while your browser is accessing the webapp on
>> backend A /nobody/ can use the API on any host?
>>
> No. Anybody else can call the API, only the web app is restricted.
>
> Peter
>
>

I've come across something similar before if I'm not mistaken it's
something called CORS or Cross Origin Resource Sharing which most modern
browsers block by default for security reasons. There are browser addons
to allow CORS but we don't really want to go down that route.


I'd have to defer to someone more knowledgeable than me about the
problem to suggest how best to avoid or work around the problem.


Paul H.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

> On 11 Sep 2023, at 8:09 pm, Paul Harrison <mythtv@mythqml.net> wrote:
>
> On 11/09/2023 01:48, Peter Bennett wrote:
>
>>
>> On 9/10/23 09:59, Paul Harrison wrote:
>>> I wonder how many users have actually used it though?
>>
>> James Abernathy tested everything, including doing multiple setups from scratch using the web app setup.
>>
>> Klaas DeWaal, Bill Meek, Ken Mandelbaum, David Engel, gave feedback after testing it. Some feedback was that it does not look pretty, but no slowness complaints that have not been fixed.
>>
>>
>
> OK so just me then :(
>
>
>> I have done nothing for security in the web app. I rely on the ip address checks that I put in a couple of years ago. Unless the user specifically allows connection form all ip addresses, only connections for the local subnet are permitted.
>>
>
> Yeah you definitely don't want to expose the API or WebApp to the internet in it's current state. The initial aim was the WebApp would be secure out of the box although admittedly we never came up with a plan to do it. You can password protect some or all of the API but unless you added it there is no support in the WebApp to use it that way.
>
>
> The other thing we would have liked to add was to follow up on Stuart M's user support and to be able to restrict parts of the webApp to certain users. For example admin users could use the setup stuff but other users can't. Or the kids can only see video's or recordings appropriate for their age that sort of thing.
>
>
>> Slave backend setup is supported. If you start the web app on a slave backend, or a system that looks like it should be a slave, it displays at the top of the page:
>>
>> This appears to be a slave backend. If it is intended as a slave backend, please disable scheduling on the master backend while running slave backend setup.
>> If this is not intended as a slave backend, please go to Setup, General, Host Address Backend Setup, and select "This server is the Master Backend" or else set the correct custom identifier on the Database Setup page. Save and Restart the backend,
>>
>> In the case of master backends, the code will not save any setup pages until you disable scheduling. In the case of slave backends, the user must manually make sure that scheduling is disabled on the master.
>>
>> The dashboard part of the web app is rather limited when running against a slave.
>>
>
> Cool. I missed you added support for slave BE's. Is that support built in to the API or just the WebApp? I kind of envisioned a drop down in the header where you could select the BE you wanted to configure.
>
>
>>>
>>>> I have installed a recent master on my production system, and I use the web app perfectly successfully on that, no delays.
>>>>
>>>> Here are my timimgs for main.js: 10 ms for local machine and 51 ms for remote over wifi. Nowhere near 10 seconds.
>>>>
>>>> https://imgur.com/a/3I9iUFN
>>>>
>>>
>>> Aren't you the lucky one :)
>>>
>> It is hard work, not luck. I have spent over a year working on this and some of the time was spent on improving performance whe I found something was slow.
>>>
>
> Oh I'm not ungrateful you took on the task. I appreciate the time and effort you have put in to this because I know how much work is involved.
>
>
>>>
>>>> Peter
>>>>
>>>>
>
>>> I just did some testing on the slowest machine I have, a pentium laptop from 2017. For example it takes 30 seconds on this laptop for chrome to start after clicking it on the start menu. I am accessing a backend that is on wifi and the slow machine with the browser is also on wifi. The slow laptop has only 2.4 GHz wifi, the backend on a fast laptop has 5 GHz wifi, so the signal is getting translated in the router.
>>
>> Channel editor (843 items) : 7 seconds to open
>> Program Guide (843 channels): 6 seconds to open
>> Videos (7531 videos) : 3 seconds to open
>> Upcoming (701 shows): 1 second
>>
>> Is your database remote from your backend? Tests of running queries against my slave backend are rather slower (because of the remote database), with API response of 6.2 seconds for the call to get the video list, for example
>>
>
> My MySql server runs in it's own VM because it is shared by several VM's in my ESXI server, it just makes maintenance easier if there is just one MySql server running that is shared. I haven't observed any problems with the other users of the database server. Most of the queries are from VM to VM so never leave the virtual environment so everything is really quick from what I've seen.
>
>
>> If my database is on a system connected to the backend via wifi, then I get some horrible response times. Wifi is asymmetric. They advertise speeds of a Gigabit per second, but that is download speed. Upload speed is a fraction of that, and having the database on a wifi connected laptop kills the speed.
>>
>
> I have a really good UniFi smart switch and everything is hard wired using Gigabit connections where appropriate.


My backend is headless and although I *can* run eg nomachine My normal use would be from a front end.
Since I've not tried 34 maybe my concern is missplaced
James
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Monday 11 September 2023 12:13:11 PM (-05:00), Paul Harrison wrote:

> On 11/09/2023 17:27, Peter Bennett wrote:
>
> >
> > On 9/11/23 11:49, Mike Perkins wrote:
> >> On 11/09/2023 14:03, Peter Bennett wrote:
> >>>
> >>> To configure a slave backend, you have to connect to the backend you
are configuring, as in http://slave:6544. Nothing special is built into the
APIs. The web app reads the settings and compares the Master server name
against the host name to determine if this is a slave backend.
> >>>
> >>> I found that when you are running the web app from one backend you
cannot use an API on another backend, the browser prevents it. This makes
sense as otherwise a web page from the internet could access APIs on your
internal network. There are probably ways to allow it, but I did not go
into that.
> >>>
> >> Could I ask you to clarify that, for someone not in the development
loop?
> > Sorry, I did not describe it very well. What I am saying is if you run
the web app from backend A, that web app page can call APIs on backend A
but it cannot call APIs on backend B. Other applications can call the API
on backend A or B. This restriction is only in the web app or other web
apps, not in programs running on your server.
> >>
> >> Do you mean, use an API to backend B while your browser (presumably
on a third host) is accessing the webapp on backend A?
> > No, sorry for the confusion.
> >>
> >> Or do you mean that while your browser is accessing the webapp on
backend A /nobody/ can use the API on any host?
> >>
> > No. Anybody else can call the API, only the web app is restricted.
> >
> > Peter
> >
> >
>
> I've come across something similar before if I'm not mistaken it's
something called CORS or Cross Origin Resource Sharing which most modern
browsers block by default for security reasons. There are browser addons to
allow CORS but we don't really want to go down that route.
>
>
> I'd have to defer to someone more knowledgeable than me about the
problem to suggest how best to avoid or work around the problem.
>
>
> Paul H.

If -v http is set (or mythbackend --setverbose http is used), and it's
CORS, a
message like this may be logged:

... "Disallowing CORS for origin: '%1'" (or Allowing if it's OK)
--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 11/09/2023 23:58, James wrote:

>
>> On 11 Sep 2023, at 8:09 pm, Paul Harrison <mythtv@mythqml.net> wrote:
>>
>> On 11/09/2023 01:48, Peter Bennett wrote:
>>
>>> On 9/10/23 09:59, Paul Harrison wrote:
>>>> I wonder how many users have actually used it though?
>>> James Abernathy tested everything, including doing multiple setups from scratch using the web app setup.
>>>
>>> Klaas DeWaal, Bill Meek, Ken Mandelbaum, David Engel, gave feedback after testing it. Some feedback was that it does not look pretty, but no slowness complaints that have not been fixed.
>>>
>>>
>> OK so just me then :(
>>
>>
>>> I have done nothing for security in the web app. I rely on the ip address checks that I put in a couple of years ago. Unless the user specifically allows connection form all ip addresses, only connections for the local subnet are permitted.
>>>
>> Yeah you definitely don't want to expose the API or WebApp to the internet in it's current state. The initial aim was the WebApp would be secure out of the box although admittedly we never came up with a plan to do it. You can password protect some or all of the API but unless you added it there is no support in the WebApp to use it that way.
>>
>>
>> The other thing we would have liked to add was to follow up on Stuart M's user support and to be able to restrict parts of the webApp to certain users. For example admin users could use the setup stuff but other users can't. Or the kids can only see video's or recordings appropriate for their age that sort of thing.
>>
>>
>>> Slave backend setup is supported. If you start the web app on a slave backend, or a system that looks like it should be a slave, it displays at the top of the page:
>>>
>>> This appears to be a slave backend. If it is intended as a slave backend, please disable scheduling on the master backend while running slave backend setup.
>>> If this is not intended as a slave backend, please go to Setup, General, Host Address Backend Setup, and select "This server is the Master Backend" or else set the correct custom identifier on the Database Setup page. Save and Restart the backend,
>>>
>>> In the case of master backends, the code will not save any setup pages until you disable scheduling. In the case of slave backends, the user must manually make sure that scheduling is disabled on the master.
>>>
>>> The dashboard part of the web app is rather limited when running against a slave.
>>>
>> Cool. I missed you added support for slave BE's. Is that support built in to the API or just the WebApp? I kind of envisioned a drop down in the header where you could select the BE you wanted to configure.
>>
>>
>>>>> I have installed a recent master on my production system, and I use the web app perfectly successfully on that, no delays.
>>>>>
>>>>> Here are my timimgs for main.js: 10 ms for local machine and 51 ms for remote over wifi. Nowhere near 10 seconds.
>>>>>
>>>>> https://imgur.com/a/3I9iUFN
>>>>>
>>>> Aren't you the lucky one :)
>>>>
>>> It is hard work, not luck. I have spent over a year working on this and some of the time was spent on improving performance whe I found something was slow.
>> Oh I'm not ungrateful you took on the task. I appreciate the time and effort you have put in to this because I know how much work is involved.
>>
>>
>>>>> Peter
>>>>>
>>>>>
>>>> I just did some testing on the slowest machine I have, a pentium laptop from 2017. For example it takes 30 seconds on this laptop for chrome to start after clicking it on the start menu. I am accessing a backend that is on wifi and the slow machine with the browser is also on wifi. The slow laptop has only 2.4 GHz wifi, the backend on a fast laptop has 5 GHz wifi, so the signal is getting translated in the router.
>>> Channel editor (843 items) : 7 seconds to open
>>> Program Guide (843 channels): 6 seconds to open
>>> Videos (7531 videos) : 3 seconds to open
>>> Upcoming (701 shows): 1 second
>>>
>>> Is your database remote from your backend? Tests of running queries against my slave backend are rather slower (because of the remote database), with API response of 6.2 seconds for the call to get the video list, for example
>>>
>> My MySql server runs in it's own VM because it is shared by several VM's in my ESXI server, it just makes maintenance easier if there is just one MySql server running that is shared. I haven't observed any problems with the other users of the database server. Most of the queries are from VM to VM so never leave the virtual environment so everything is really quick from what I've seen.
>>
>>
>>> If my database is on a system connected to the backend via wifi, then I get some horrible response times. Wifi is asymmetric. They advertise speeds of a Gigabit per second, but that is download speed. Upload speed is a fraction of that, and having the database on a wifi connected laptop kills the speed.
>>>
>> I have a really good UniFi smart switch and everything is hard wired using Gigabit connections where appropriate.
>
> My backend is headless and although I *can* run eg nomachine My normal use would be from a front end.
> Since I've not tried 34 maybe my concern is missplaced
> James


Well one the reasons for creating the WebApp was so users could run
their BE headless if they wanted and you would be able to do everything
you can currently do in mythtv-setup by using the WebApp in any web
brower on any machine that can see the BE on the local network.
Unfortunately it's not quite there where you can do everything in the
WebApp you still need to do some things from the commandline like
setting up XMLTV for example.


If you mean you want to be able to do all the setup from the frontend
then I agree that has always been my preferred method, I mean how many
TV or STB's do you have to configure using a browser? If you think of
MythTV as an appliance then it makes more sense to be able to do all the
setup from the FE. The cool thing is once the Service API is all there
to be able to run the WebApp then the same API can be used by any
client, a modified mythtv-setup, a modified mythfrontend, a Kodi client
or any 3rd party client could if they wanted be updated to allow you to
do everything you can in the existing  mythtv-setup but it would work on
any machine on the local network that can see the BE or potentially any
machine on the internet although that is not recommended because there
is no way to secure it. The clients don't need database access of their
own since they do everything through the API so they should be really
easy to setup. The long term goal a few of the devs have wanted to do
for some time is update the FE so it doesn't require direct DB access
but would use the API for everything.

Paul H.


_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 12/09/2023 16:46, Paul Harrison wrote:
>
> Well one the reasons for creating the WebApp was so users could run
> their BE headless if they wanted and you would be able to do
> everything you can currently do in mythtv-setup by using the WebApp in
> any web brower on any machine that can see the BE on the local
> network. Unfortunately it's not quite there where you can do
> everything in the WebApp you still need to do some things from the
> commandline like setting up XMLTV for example.
>
As for me, I'm not particular about which application I need to use to
configure Myth, but what I do care about is that it be possible without
downtime. The current mythtv-setup method falls down on that criterion,
which (for me at least) is one reason why I sometimes make simple
changes directly in the database rather than stopping the backend so
that I can use mythtv-setup.

One point though about the "headlessness" of the BE machine: whereas my
BE machine does have a keyboard and monitor attached, there is hardly
ever any need for me to use them because I can do most everything from
my laptop over the network (e.g. using X-over-ssh).

So in summary, for me the principal benefit of the new API-based
approach is that the BE remains running (as it is the provider of the
API) during (re)configuration sessions. Configuration changes can be
made without interrupting ongoing recordings or viewing sessions.

Cheers, Jan

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Sun, Sep 10, 2023 at 2:02?PM Paul Harrison <mythtv@mythqml.net> wrote:

> I did see that, I'm not laughing honestly! Dare I say it? I'm going to
> say it. We should try having regular 6 monthly releases to coincide
> with Ubuntu releases. I know I'm crazy I really should not be let out in
> public.

I remember that goal. I did not see any developer step
up to do the entire release process on that timeframe
(a release manager who herds the developers for a
regular release is only something one tends to see in
mature projects).

Are you saying you are going to volunteer to be that
release manager going forward, or just that you wish
*someone* would do so (and we all know how that
works out)?
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 13/09/2023 05:47, Gary Buhrmaster wrote:

> On Sun, Sep 10, 2023 at 2:02?PM Paul Harrison <mythtv@mythqml.net> wrote:
>
>> I did see that, I'm not laughing honestly! Dare I say it? I'm going to
>> say it. We should try having regular 6 monthly releases to coincide
>> with Ubuntu releases. I know I'm crazy I really should not be let out in
>> public.
> I remember that goal. I did not see any developer step
> up to do the entire release process on that timeframe
> (a release manager who herds the developers for a
> regular release is only something one tends to see in
> mature projects).
>
> Are you saying you are going to volunteer to be that
> release manager going forward, or just that you wish
> *someone* would do so (and we all know how that
> works out)?


I was taking the piss out of Peter and my fellow developers. What you
don't know is behind the scenes I was the one pushing for the 6 month
release cycle. I did try to herd them in the right direction but it
would be easier to herd cats :) In the end I gave up trying out of
frustration so exactly when the next release will be is anyone's guess.
David H. has said he would try for February next year which sounds
reasonable?


Paul H.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Sep 13, 2023 at 03:59:30PM +0100, Paul Harrison wrote:
> On 13/09/2023 05:47, Gary Buhrmaster wrote:
>
> > On Sun, Sep 10, 2023 at 2:02?PM Paul Harrison <mythtv@mythqml.net> wrote:
> >
> > > I did see that, I'm not laughing honestly! Dare I say it? I'm going to
> > > say it. We should try having regular 6 monthly releases to coincide
> > > with Ubuntu releases. I know I'm crazy I really should not be let out in
> > > public.
> > I remember that goal. I did not see any developer step
> > up to do the entire release process on that timeframe
> > (a release manager who herds the developers for a
> > regular release is only something one tends to see in
> > mature projects).
> >
> > Are you saying you are going to volunteer to be that
> > release manager going forward, or just that you wish
> > *someone* would do so (and we all know how that
> > works out)?
>
>
> I was taking the piss out of Peter and my fellow developers. What you don't
> know is behind the scenes I was the one pushing for the 6 month release
> cycle. I did try to herd them in the right direction but it would be easier
> to herd cats :) In the end I gave up trying out of frustration so exactly
> when the next release will be is anyone's guess. David H. has said he would
> try for February next year which sounds reasonable?

I'm too lazy to go lookup old, email threads but I don't recall any
insurmountable objections to more frequent releases. As Gary
suggests, I think the main thing preventing it, is someone willing to
drive the release bus. It's not too onerous for developers to hold
off on new or dangerous changes or do them in a branch when a release
is immanent. The translators are the group I would be most concerned
with having to perform their tasks more frequently.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Sep 13, 2023 at 3:01?PM Paul Harrison <mythtv@mythqml.net> wrote:

> I did try to herd them in the right direction but it
> would be easier to herd cats :)

The EDS super bowl commercial from nearly
15 years ago now about cat herders....

https://www.youtube.com/watch?v=m_MaJDK3VNE

> David H. has said he would try for February next year which sounds
> reasonable?

It is a target. I personally mostly don't care,
as I build my own packages and install
them from whatever release/commit I wish
to select, but some people seem to want
a "release", as if that really implies much
more than a point in time build and bumping
of a number.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On 13/09/2023 16:27, David Engel wrote:

> On Wed, Sep 13, 2023 at 03:59:30PM +0100, Paul Harrison wrote:
>> I was taking the piss out of Peter and my fellow developers. What you
>> don't
>> know is behind the scenes I was the one pushing for the 6 month release
>> cycle. I did try to herd them in the right direction but it would be easier
>> to herd cats :) In the end I gave up trying out of frustration so exactly
>> when the next release will be is anyone's guess. David H. has said he would
>> try for February next year which sounds reasonable?
> I'm too lazy to go lookup old, email threads but I don't recall any
> insurmountable objections to more frequent releases. As Gary
> suggests, I think the main thing preventing it, is someone willing to
> drive the release bus. It's not too onerous for developers to hold
> off on new or dangerous changes or do them in a branch when a release
> is immanent. The translators are the group I would be most concerned
> with having to perform their tasks more frequently.
>
> David

The problem I was facing was lack of enthusiasm whenever the subject was
brought up. I was taking the silence as meaning everyone really couldn't
be bother with it. The few comments I did get were negative towards it
from what I remember.


To be far the last time this was discussed you did basically say you
didn't see the point of 6 monthly releases you would prefer to just do a
release when an important change was made or something along that line.
I think it was a private discussion between Gary, You and I when this
subject was last brought up but I can't be bothered to go find it either :)


Maybe we should advertise in the wanted section of the local paper. 
Wanted "Release Manager". Must be willing to work long hours with zero
payment and no prospect of promotion. Experience of herding cats would
be an advantage but not necessary.


Paul H.



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Sep 13, 2023 at 8:23?PM Paul Harrison <mythtv@mythqml.net> wrote:

> Maybe we should advertise in the wanted section of the local paper.
> Wanted "Release Manager". Must be willing to work long hours with zero
> payment and no prospect of promotion. Experience of herding cats would
> be an advantage but not necessary.

Don't forget: You will have zero real authority, but be
responsible for delivery (so, you will likely fail, and be
blamed, even though you had no way to accomplish
your goals). Those that self identify as masochists
will likely be the most successful candidates for this
position.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Wed, Sep 13, 2023 at 09:20:17PM +0100, Paul Harrison wrote:
> On 13/09/2023 16:27, David Engel wrote:
>
> > On Wed, Sep 13, 2023 at 03:59:30PM +0100, Paul Harrison wrote:
> > > I was taking the piss out of Peter and my fellow developers. What
> > > you don't
> > > know is behind the scenes I was the one pushing for the 6 month release
> > > cycle. I did try to herd them in the right direction but it would be easier
> > > to herd cats :) In the end I gave up trying out of frustration so exactly
> > > when the next release will be is anyone's guess. David H. has said he would
> > > try for February next year which sounds reasonable?
> > I'm too lazy to go lookup old, email threads but I don't recall any
> > insurmountable objections to more frequent releases. As Gary
> > suggests, I think the main thing preventing it, is someone willing to
> > drive the release bus. It's not too onerous for developers to hold
> > off on new or dangerous changes or do them in a branch when a release
> > is immanent. The translators are the group I would be most concerned
> > with having to perform their tasks more frequently.
> >
> > David
>
> The problem I was facing was lack of enthusiasm whenever the subject was
> brought up. I was taking the silence as meaning everyone really couldn't be
> bother with it. The few comments I did get were negative towards it from
> what I remember.

Inertia can be a hard thing to overcome.

> To be far the last time this was discussed you did basically say you didn't
> see the point of 6 monthly releases you would prefer to just do a release
> when an important change was made or something along that line. I think it
> was a private discussion between Gary, You and I when this subject was last
> brought up but I can't be bothered to go find it either :)

I can still see that position as being valid. Peter's web setup work
would qualify for doing a release.

David

> Maybe we should advertise in the wanted section of the local paper.? Wanted
> "Release Manager". Must be willing to work long hours with zero payment and
> no prospect of promotion. Experience of herding cats would be an advantage
> but not necessary.
>
>
> Paul H.
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

--
David Engel
david@istwok.net
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

On Thu, Sep 14, 2023 at 02:55:04AM +0000, Gary Buhrmaster wrote:
> On Wed, Sep 13, 2023 at 8:23?PM Paul Harrison <mythtv@mythqml.net> wrote:
>
> > Maybe we should advertise in the wanted section of the local paper.
> > Wanted "Release Manager". Must be willing to work long hours with zero
> > payment and no prospect of promotion. Experience of herding cats would
> > be an advantage but not necessary.
>
> Don't forget: You will have zero real authority, but be
> responsible for delivery (so, you will likely fail, and be
> blamed, even though you had no way to accomplish
> your goals). Those that self identify as masochists
> will likely be the most successful candidates for this
> position.

All kidding aside, this could be worth while. Since it's primarily a
coordination effort, the old, "I'm not a probrammer/developer" excuse
doesn't apply. Maybe there is a user out there who would be willing
to contribute in this way.

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org