When: I am not too picky about when. I'll do my best to be available whenever possible that best works for everybody.
Frequency: I vote for 1 time per Month. Given the current speed of releases for packages I think that is a good length to have a decent update per meeting.

Well, next week is us thanksgiving holidays, so not a great time.

Perhaps sometime in the first week of december we could do another meeting.

Well, next week is us thanksgiving holidays, so not a great time.

Perhaps sometime in the first week of december we could do another meeting.

I was meaning monthly in a general sense for the frequency. We can start doing it the beginning week or two each month?

Once a month sounds reasonable to me. If there is a lot of new stuff happening, then a meeting can also be scheduled add-hoc at the usual time (only in a different week).

Monthly sounds good to me too.

How about we shoot for a meeting on say... december 7th at 16utc? Thats early for me, but hopefully not too late for most EU folks?

And of course I got busy and didn't advertise that time... so will look at some other time next week.

Would there be time to advertise for the Monday the 14th at 16utc?

I think so, how about we aim to do a meeting the second Mon of every month. That should avoid most things like new year

That sounds good to me. So, next meeting on the 14th. How about 16:30UTC? or is that too late for you all?

Proposed agenda:

• introductions
• status / plans on current remix
• status / plans for next step remix with fedora kernel + patches and images built on copr
• status / plans for official kickstart/images
• All other business

If that sounds ok will send announcement out later today.

Sent an announcement.

possible Topic: Downstream vs. Upstreampatches

Gnome has answered to a request for a patch to gsd-media-keys ( thats the one who controls volume and power buttons ) , that they prefer downstream patches, as they are device-dependend.

This leads to the question, how we handle patches for pines internally: do we patch for an arch, for all arches or do we build i.e. pinephone related replacement packages. As it will cause differences in patch levels for sure, if we choose the last option.

Bugtracker for mobility issues.

inside the pine "team" bugtracking was a question. Should we keep it to github, or switch entirely to bugzilla. To do the second, all copr packages must be bugreportable listed in bugzilla. Are there better options?

A replacement for gnome-software ( which works on the pine, but based on package kit, is incredibly slow )

A fast, up2date, touch optimized if possible, app store like tool.

better power governors

this is important for any mobile device, as currently the power consumption is to high, way to high in idle mode. Someone known with a big boot, needs to kick some head on the kernel devs, to finally supply energy efficient governors and schedulers like in Android.

better window toolkits

We can see several apps adapting to the small screen and/or the touch screen , but the tools for efficient app coding are rare, same as the knowledge about it i.e. outsourcing tasks to the gpu. All apps for soc of anykind would benefit from a Webschool for Linux App Programming.

A request to the big brother rh for a master plan and resources for a hopefully distro independend project, would bring Linux on Mobile forward. ATM everyone tries to fix anything for themself. Any dristro has a different patch for the same problem. Someone needs to go in front with a torch of hope.

Hope to see you on the 14th.

possible Topic: Downstream vs. Upstreampatches

Gnome has answered to a request for a patch to gsd-media-keys ( thats the one who controls volume and power buttons ) , that they prefer downstream patches, as they are device-dependend.

This leads to the question, how we handle patches for pines internally: do we patch for an arch, for all arches or do we build i.e. pinephone related replacement packages. As it will cause differences in patch levels for sure, if we choose the last option.

Good question. Fedora has a upstream first policy... so we should try and get things upstream if we can at all.
In this case, perhaps we could convince them to provide some way to change what we need in config? then we could just ship config in a pinephone package?

Bugtracker for mobility issues.

inside the pine "team" bugtracking was a question. Should we keep it to github, or switch entirely to bugzilla. To do the second, all copr packages must be bugreportable listed in bugzilla. Are there better options?

We could use this tracker here? But yeah, we can discuss... :)

A replacement for gnome-software ( which works on the pine, but based on package kit, is incredibly slow )

A fast, up2date, touch optimized if possible, app store like tool.

I'd prefer to try and get gnome-software to work better for us? Not sure thats possible, but we should try.

better power governors

this is important for any mobile device, as currently the power consumption is to high, way to high in idle mode. Someone known with a big boot, needs to kick some head on the kernel devs, to finally supply energy efficient governors and schedulers like in Android.

Perhaps we could leverage the android ones? Most of those are upstream I think, we just need to figure out how to get them enabled...

better window toolkits

We can see several apps adapting to the small screen and/or the touch screen , but the tools for efficient app coding are rare, same as the knowledge about it i.e. outsourcing tasks to the gpu. All apps for soc of anykind would benefit from a Webschool for Linux App Programming.

A request to the big brother rh for a master plan and resources for a hopefully distro independend project, would bring Linux on Mobile forward. ATM everyone tries to fix anything for themself. Any dristro has a different patch for the same problem. Someone needs to go in front with a torch of hope.

Hope to see you on the 14th.

Likewise! Thanks so much for all the great topics!

Lets close this and I will open a new ticket for the next meeting and we can use those to provide agenda/comments/info.