emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Android port of Emacs


From: Dmitry Gutov
Subject: Re: Android port of Emacs
Date: Mon, 19 Jun 2023 01:35:28 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0

On 18/06/2023 06:05, Po Lu wrote:
Dmitry Gutov <dmitry@gutov.dev> writes:

What will the difficulty be? If it just comes down to running 'git
pull upstream master' once in a while, then this can be a small price
to pay.

The difficulty lies the other requirements of a completely separate
project: the use of my personal inbox as a bug report address, the
unrelated bugs being reported there, having to distribute releases
myself on ftp.gnu.org, and in general the division of my attention
between Emacs and my own fork.

Ah, so you are worried about maintaining a separate project infrastructure.

Personally, I really recommend you try Gitlab/Github/SourceHut/Gogs/etc. If you can bear with using any of those, I'm almost certain that you will receive more and better bug reports through those, and maybe even additional contributors/maintainers.

But either way, like others said, developing the Android port in a separate branch -- or even in a separate repo -- doesn't necessarily preclude you from having access to Debbugs, ftp.gnu.org, and even the Emacs mailing lists. I'm sure most or all of those can be arranged.

If the merge conflicts are likely to be frequent, however, that's a
different matter.

I've only seen three or four merge conflicts over the past few months,
all involving etc/NEWS.

Some larger time period could give more data, but so far it sounds like both conclusions can work relatively easily then: keeping Android port internally wouldn't result in too many additional conflicts for others to excise. But keeping it in external repo (or branch) shouldn't results in frequent conflicts either. And as a bonus, you don't have to use the same file for NEWS, so those 3-4 conflicts you mention would be avoided.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]