search

motioneye-project / motioneye

A web frontend for the motion daemon.
GNU General Public License v3.0
4.01k stars 662 forks source link

Plan for continuing with this project #2307

Open MichaIng opened 2 years ago

MichaIng commented 2 years ago

@cclauss @Mictronics @jmichault and everyone else, let's make a plan how to continue with this project, now moved to the new @motioneye-project GitHub organisation.

First of all, everyone who has contributed to motionEye before, or wants to do so, please feel free to join in, also I think we can add everyone who is interested to the organisation.

I think we agree that Python 3 support is the first thing to achieve, given that Python 2 has reached EOL since over 2 years already, @jmichault and @Mictronics have Python 3 compatible forks from where we can commit back, and on this repo we have the python3 branch and a bunch of open pull requests for further related fixes.

I personally would go this way:

Approximately from simple to difficult, regarding possible conflicts 😉.

MichaIng commented 2 years ago

What about GitHub pages?

jmichault commented 2 years ago

GitHub pages are static, it's great for documentation, but i don't think we can use it for translations.

jmichault commented 2 years ago

I have created a translation project on weblate : https://hosted.weblate.org/projects/motioneye-project/. Please take a look and tell me what you think about it, what you would like to change.

fulippo commented 2 years ago

It looks really cool and intuitive. Nice choice. I've already started to translate a few strings into italian. Will let you know how it goes

Il giorno mar 3 mag 2022 alle ore 19:44 Jean Michault < @.***> ha scritto:

I have created a translation project on weblate : https://hosted.weblate.org/projects/motioneye-project/. Please take a look and tell me what you think about it, what you would like to change.

— Reply to this email directly, view it on GitHub https://github.com/motioneye-project/motioneye/issues/2307#issuecomment-1116374760, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARBFAY5OCIHXFYC6224AF3VIFQYXANCNFSM5QHWXZJA . You are receiving this because you were mentioned.Message ID: @.***>

MarcelCoding commented 2 years ago

@MichaIng I would just like to mention, that I don't relay know python. I am just good at web development and backend stuff in languages other than python. You don't need to request me in things only related to python stuff. Sorry, I forget to mention that.

MichaIng commented 2 years ago

Thanks for the hint, I'll keep that in mind 🙂.

localsnet commented 2 years ago

Hi. Could you suggest regard development, which your current development environment? It is host OS Ubuntu 20 or it is Docker container(s) (and what OS version in container). So It would be great if you have link on maybe existed instruction of Devkit needed to development. I'm devops engineer, little bit code scripts on Shell/Python, Docker and etc. Will glad to help as I can.

MichaIng commented 2 years ago

The Docker image is using Debian Bullseye as base image, I personally do most testing and development on a Debian Bookworm system. Generally, as it's Python 3 and Python 3.7 and later are supported, you are quite flexible.

The automated install and build tests here on GitHub are using the latest GitHub actions Ubuntu runner, which is 20.04 Focal indeed, but as fast as there is a running with 22.04 Jammy available, I aim to migrate.

Nik71git commented 2 years ago

perfect! thanks a lot first of all, also an upgraded docker-compose example file would be appreciated. 😉

Il sab 14 mag 2022, 12:48 MichaIng @.***> ha scritto:

The Docker image is using Debian Bullseye as base image, I personally do most testing and development on a Debian Bookworm system. Generally, as it's Python 3 and Python 3.7 and later are supported, you are quite flexible.

The automated install and build tests here on GitHub are using the latest GitHub actions Ubuntu runner, which is 20.04 Focal indeed, but as fast as there is a running with 22.04 Jammy available, I aim to migrate.

— Reply to this email directly, view it on GitHub https://github.com/motioneye-project/motioneye/issues/2307#issuecomment-1126689792, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOTASPI6YNH352LXJJPBZLLVJ6AGRANCNFSM5QHWXZJA . You are receiving this because you commented.Message ID: @.***>

jose1711 commented 2 years ago

Hey, I see 4 checkmarks in the original post and all of them are ticked. But what does that mean? Looks like the new version is still not ready to be released. I am somehow missing the project mission.

Goal of running under python3 has been achieved which I believe is great. Also anyone can contribute to translation of the user interface which I also very much welcome, but what are the actual blockers - is it the ability to run on Raspberry Pi (starting at Pi Zero), translation to at least 3 major languages, working Docker image, better documentation, some amount of testers/testimonials from users or some other things?

@MichaIng could you please present your thoughts? For me the version for a standard x86_64 and v4l camera already does a great job but apparently you have more expectations from the first yet-to-be-released python3-based version of motionEye. Thanks, jose

MichaIng commented 2 years ago

Goal of running under python3 has been achieved which I believe is great.

Not yet fully reached, there are still a few errors related to the Python 3 transition, at least #2486. Also adding support for motion v4.4 should be added first: #2462 I vote for starting an official beta then, including a pre-release tag here on GitHub an a related (pre-release) upload PyPI.

Here an overview over open issues and PRs attached to the v0.43.0 milestone. Not all are critical for a pre-release, but at least the open PRs should be finished and merged IMO: https://github.com/motioneye-project/motioneye/milestone/1

starbasessd commented 2 years ago

It's been over 6 months since the take-over, and 4 months since the last message here, I am curious as to the status of development?

MichaIng commented 2 years ago

I wanted to have #2462 (motion v4.4 support) added first, but as of new full-time job do not find time for it. So I'm fine with doing at least a pre-release/beta to PyPI with current dev stage and forking off a new main primary branch from dev. Checking recent bug reports, it seems overall better than the current stable release, with quite a bunch of bugs solved (not related to Python 2 > 3 move) and features added.

@jmichault I saw you added a daily upload workflow to the master2 branch, which requires a valid token only to function? https://github.com/motioneye-project/motioneye/blob/python2/.github/workflows/pypi_daily_build.yml I would vote for not doing daily uploads, but when pushing a release tag here on GitHub. A "pre-release" on GitHub could then be uploaded to PyPI as pre-release (not sure how this is done 😅), and a stable release as stable to PyPI respectively.

I can do/adjust the workflow part with triggers when pushing to release tags, but I'm not familiar with the tools to upload to PyPI.

Gonioul commented 2 years ago

What should be a priority is to be able to run motioneye on latest Raspberry Pi OS (Bullseye), 64bit preferably. Buster (previous version) is already deprecated for Home Assistant, and they move quite fast.

MichaIng commented 2 years ago

It is naturally independent of the underlying OS version. What you might mean is support for the modern RPi DSI camera stack, that works with the DRM/KMS display stack, which is the default since Bullseye: #2425

Jep it makes sense to focus on this as well, but similarly to motion v4.4 support, if we wait until those two are addressed, we provide users with the problematic motionEye v0.42 too long, which doesn't support motion v4.4 and modern RPi camera stack either, and has a large number of additional issues and bugs. So IMO, if there is not someone having time to address the two issues soon, we should start motionEye v0.43 release regardless to provide at least all the bug fixes and features that have been merged until now.

sonicpp commented 2 years ago

Hello everyone, I am interested in help with motionEyeOS. I have not much experience with motionEyeOS yet, but I have some experience with thingOS (on which is motionEyeOS based) - I am working on support for PineCube - and I also have experience with Buildroot (on which is thingOS based) - I contributed to Buildroot with few patches and was using it at work for some years. I would personally turn thingOS or motionEyeOS (or both?) into Buildroot external - mechanism which can drastically reduce code size (because the code with upstream code will stay in separate repository) and is in my opinion easier to sync between project (motioneyeos and thingos) and it is easier to see which files needs to be maintained and which one can be left untouched for the upstream project. We used Buildroot external at my work, I use it in my personal project and it is also used in projects like Home Assistant OS. I already had some discussion with @ccrisan about it in thingOS.

I am mainly interested in motionEyeOS because of PineCube I own (I also have some Rpis, but without cameras so far). I already use motionEye on Pinecube (with motion 4.3.2), but so far only in pure Buildroot (since motionEyeOS is very outdated and also thingOS has too old Python/setuptools to install motionEye).

What do you @ccrisan and others think?

MichaIng commented 2 years ago

That is great, since I have no experience with thingOS, but motionEyeOS seems to be much used and hence worth to receive a major update based on the new Python 3 based motionEye.

motionEyeOS seems to be aimed to work like a container in the way that it is not intended to be manipulated after installation but shipped with all that is needed for motionEye to run fully featured and motionEye data as only volatile part. So as long as it is not more work to get this done with Buildroot externals than with thingOS, I agree with you. So I think most important question is whether Buildroot ships all required packages OOTB, Python 3, motion, v4l2-utils, ffmpeg, curl, or the libraries we'd otherwise compile them against.

sonicpp commented 2 years ago

MotionEyeOS is basically fork of thingOS (you can see many merge commits from thingOS to MotionEyeOS). Similar with thingOS, which is fork of Buildroot (again, you can see merge commits from Buildroot in thingOS repository). Buildroot contains massive amount of packages (you can choose which will be included in final image). ThingOS tooks that and added few other packages on top of it (and things like over the air update, easy wifi/ap/bluetooth configuration etc) and MotionEyeOS took thingOS and added some other packages on top. I would keep it like that, only question is if to keep it as fork, or to transform it to Buildroot externals mechanism as I mentioned above.

Development should be cooperated with thingOS, since motionEyeOS is based on this project.

MichaIng commented 2 years ago

easy wifi/ap/bluetooth configuration etc

Easy network/WiFi configuration at least is something we might want to keep in motionEyeOS.

What I wanted to say or verify is that larger parts of thingOS won't be required in motionEyeOS so that there would be benefit to shorten the fork tail. ... on the other hand I just had a closer look into it and especially the text file based pre-configuration possibilities are nice for headless SBC scenarios, probably other SBC-specific parts. Maybe it causes more work to pull commits from two upstreams (thingOS for changes we want in motionEyeOS as well, and Buildroot) and in case resolve conflicts, compared to keep it as it is? The Buildroot externals transition could be applied to thingOS instead, to gain the benefit for motionEyeOS as well.

sonicpp commented 2 years ago

Yeah I agree with that. Since @ccrisan is creator of both thingOS and motionEyeOS (and if I understood him right, he plan to get involved in motionEyeOS development in the future again), lets see what is his vision.

ccrisan commented 2 years ago

My plans with thingOS are to eventually ditch all customizations and rely on vanilla Buildroot with external packages, code, helpers & whatnot. Maintaining forks and merges on each major version update is a PITA and is definitely not the way to go.

However, both motionEyeOS and thingOS have a lot of custom integrations and functionalities that would need to be rewritten (or ditched!) before switching to vanilla Buildroot. The lack of automated tests (or any kind of tests, in fact) makes this part a lot more difficult.

What I'm saying is that the "correct" way IMHO is indeed for both OSes to be plain Buildroots with external stuff, but that's not going to be an easy task.

MichaIng commented 2 years ago

So you mean, instead of using "Buildroot externals", using an own mechanism to pull vanilla Buildroot and apply customizations? Whether/in how far "Buildroot externals" can simplify this, @sonicpp will be able to answer.

Instead of doing everything in one step, probably it's more realistic to detangle Buildroot code and custom code step-by-step, when one finds time, creating/splitting out build scripts which complement/patch individual parts of vanilla Buildroot? My 2 cents without much insight into the current code structure and build process 😅.

I can help with GitHub actions to test new parts of, or the whole build process, btw, in perspective automate the image generation for motionEyeOS (How was/is this done currently?). Generated images can be also tested by booting them as container (e.g. via systemd-nspawn and QEMU for ARM emulation) and in case of motionEyeOS e.g. whether motionEye is running and the web interface port listening/API responding. But it doesn't include bootloader/kernel/firmware boot stages, of course.

sonicpp commented 2 years ago

I am not sure about tests since I have not that much experience with that, but at least automated generated images would be cool.

For the Buildroot-external, I think if we start slowly, like modifiing configs for base support of buildroot & buildroot-externals, adding few necessary packages and then adding other scripts etc, it is doable.

When building Buildroot with br2-external, it is required to specify path to the br2-external directory. If I understand it well, for building thingOS we will need Buildroot repository and repository with thingOS Buildroot-external. For MotionEyeOS we will need the same plus repository with MotionEyeOS Buildroot-external - so two br2-externals in total. Question is where to put the helper scripts common for thingOS/motionEyeOS - to the thingOS repository?

@ccrisan Please tell me here, on thingOS issue we discussed or via email if there is something I can help with (like with the conversion to br2-external for example), I will be more than happy.

ccrisan commented 2 years ago

So you mean, instead of using "Buildroot externals", using an own mechanism to pull vanilla Buildroot and apply customizations? Whether/in how far "Buildroot externals" can simplify this, @sonicpp will be able to answer.

I mean Buildroot + externals. The way it was designed to be used :)

I can help with GitHub actions to test new parts of, or the whole build process, btw, in perspective automate the image generation for motionEyeOS (How was/is this done currently?). Generated images can be also tested by booting them as container (e.g. via systemd-nspawn and QEMU for ARM emulation) and in case of motionEyeOS e.g. whether motionEye is running and the web interface port listening/API responding. But it doesn't include bootloader/kernel/firmware boot stages, of course.

Building Buildroot images is an extremely intensive operation. A considerable computing power is needed and the whole process takes a few hours.

ccrisan commented 2 years ago

@ccrisan Please tell me here, on thingOS issue we discussed or via email if there is something I can help with (like with the conversion to br2-external for example), I will be more than happy.

I first need to allocate a serious amount of time to plan this move. I have a few projects that rely on thingOS and breaking them is something I reaaaaaaally want to avoid. I will let you know of the plan as soon as I find the necessary time to come up with one.

MichaIng commented 2 years ago

A considerable computing power is needed and the whole process takes a few hours.

There bigger the argument to use GitHub actions runners for this 🙂. They don't have much CPU power, so it might even take longer, but no own hardware is blocked 🙈.

husjon commented 2 years ago

Just wanted to pop on by and let you know that I'm in the process of translating the Norwegian Bokmål texts. :)

husjon commented 2 years ago

Norwegian Bokmål is now finished.

jowax commented 2 years ago

Hi, I'd like to contribute. Is it possible to add me as a collaborator?

MichaIng commented 2 years ago

Many thanks for considering to contribute to motionEye. Before it becomes to inflationary, IMO good practice is to add you to the contributors list, after your did some contribution, and not beforehand 🙂. I'm all in for being open and inclusive, but a minimum level of trust building is fine I think.

avanc commented 1 year ago

Development should be cooperated with thingOS, since motionEyeOS is based on this project.

I fully support this, as I'm using thingOS for photOS :-) Thus, it would be great if improvements to the base software would go upstream (i.e. merged into thingOS).

I might be able to support on the base system. Just @mention me.

avanc commented 1 year ago

A considerable computing power is needed and the whole process takes a few hours.

There bigger the argument to use GitHub actions runners for this slightly_smiling_face. They don't have much CPU power, so it might even take longer, but no own hardware is blocked see_no_evil.

@MichaIng Feel free to have a look at https://github.com/avanc/photOS/tree/master/.github/workflows I'm building photOS for 4 platforms (RaspberyPi 1-4) in parallel based on git tags. But there might be potential for optimization. Sometimes I hit the GuthubActions time limit...

MichaIng commented 1 year ago

You mean to merge improvements from photOS into thingOS? I suggest to open PRs in this case.

However, I'm the wrong person to discuss about thingOS 😉.

avanc commented 1 year ago

My intention was to use the photOS Github workflow as starting point for automatic compilation of motioneyos :-)

avanc commented 1 year ago

Ah, in with my first comment I meant to port improvements from motioneyeos back to thingOS, so photOS can also benefit from it ;-)

strips commented 1 year ago

Any thought about switching Motion to Motionplus?

I just gave up on Motioneye and Motion for my new Rasperry Pi Camera V3. I have not got any of the workarounds to work. Motionplus works but the GUI is lacking. Switching to Motionplus will give good support for libcamera.

NuclearPhoenixx commented 1 year ago

Any thought about switching Motion to Motionplus?

I just gave up on Motioneye and Motion for my new Rasperry Pi Camera V3. I have not got any of the workarounds to work. Motionplus works but the GUI is lacking. Switching to Motionplus will give good support for libcamera.

Yeah good luck with that. I think you should very much look forward to the Python 3 port at the moment, that's the most important thing right now AFAIK.

bigmac5753 commented 1 year ago

is there an ETA on the next release? seems to be taking forever

MichaIng commented 1 year ago

Not really. To speed things up, would be great if someone could write release notes. Then I'll merge #2675 to push a pre-release to PyPI.

localsnet commented 1 year ago

If I correct understand, that now migration on Python3 is actually nothing happening (just a translation to other languages) ?

MichaIng commented 1 year ago

Could you rephrase your question? I do not understand.

Multi-language support is probably the most visible change aside of the Python 2 to Python 3 migration. But there were a lot of other changes and fixes, especially around the upload options and methods. Check out the list of merged PRs with the milestone assigned: https://github.com/motioneye-project/motioneye/pulls?q=is%3Apr+is%3Aclosed+milestone%3Av0.43.0

localsnet commented 1 year ago

@MichaIng , you answered on my question actually, this is what i meant, thank you. Do you have documentation on CI/CD part or it's CI files only? Thanks.

va1entin commented 1 year ago

@MichaIng Happy to see that motioneye lives on and gets the well deserved Python 3 migration! Thanks for your work everyone 😃

With a new team at the helm and new features already added or in the works, I was wondering if there was any interest in this functionality I requested to merge five years ago now: https://github.com/motioneye-project/motioneye/pull/821 At the time Calin didn't want to merge it because it adds pynacl as a new dependency and he expected most users to not be interested in encrypting media files uploaded to the cloud by motioneye or using separate tooling for that. If you as the team are interested, please let me know and I'll gladly make a new PR. I've been using the functionality for 5 years now and still think it's a nice feature :)

Aside from that, are there any technical blockers remaining for the 0.43.0 release or is the list of issues assigned to the milestone representative of all the work left? Maybe I can help with something.

beppo-dd commented 1 year ago

@cclauss I wrote you an email. Can you invite me to your organsiation?

cclauss commented 1 year ago

@beppo-dd You have created no issues and no pull requests. Why should you be named as a project maintainer? https://github.com/motioneye-project/motioneye/issues/created_by/beppo-dd https://github.com/motioneye-project/motioneye/pulls?q=is%3Apr+author%3Abeppo-dd

beppo-dd commented 1 year ago

@cclauss This was of course not my intention. My question arose because I wanted to correct a wiki page in motioneyeos, but I couldn't find any ways to edit it: In Github, there is no way to do pull requests on other wiki pages, see #846. I can clone the wiki repository, but I have no right to write on it, see this answer of the stackoverflow question "On GitHub, can I fork … a wiki". Question: Can I get a possibility to correct the wiki page that belongs to the motioneyeos reposity?

cclauss commented 1 year ago

Now I understand. Let's try this approach. Let's say that you want to make edits to wiki/Manual-Download-And-Installation

Leaving the first commit be the wiki page unmodified will allow maintainers to spot exactly what was changed.

I hope this process makes sense.

beppo-dd commented 1 year ago

@cclauss I hope, I did it right: see motioneye-project/motioneyeos/pull/2998. Please be sure to read my "Warning" at the end of the pull request description.

theGiuMac commented 1 year ago

Good morning, Do you still need help in coding, git ops (mergin, rebasing...) and so on? Specifically on the migration to Py3, I might be of help. Anyhow, any news on its release?

cclauss commented 1 year ago

@theGiuMac Python 2 died 1,372 days ago on 1/1/2020.

It is therefore a shame that the default branch of this repo still points to a Python 2 implementation.

If you are interested in this functionality, please look at the dev branch instead. It is 800+ commits ahead of the default.