emacs-devel
[Top][All Lists]
Advanced

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

Re: GitLab CI setup file in scratch/tzz/gitlab


From: Lars Brinkhoff
Subject: Re: GitLab CI setup file in scratch/tzz/gitlab
Date: Thu, 27 Apr 2017 19:43:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Eli Zaretskii wrote:
> I actually meant the 'apt' commands.  It's true that some other
> distributions besides Debian support that, but AFAIK they have their
> own commands to the same effects.

Right, the build runs in a Debian image, so it must use Debian package
management commands.  Whatever operating system you pick, you must
provide some instructions to install build dependencies.

> We didn't yet decide that this site will be our CI site.  Until we do,
> why should we function as someone else's repository??

I think it would be reasonable to take that decision first, and add the
file second.

It has been demonstrated to work.  Now it has to be cleared by Emacs
maintainers, FSF policies, etc.

> OK, but why should the Emacs repository keep this file and maintain
> it?  It looks simple enough for the interested users to have it on
> their systems

It would be possible, but no that simple.  There would to be a commit
(or patch) with the .gitlab-ci.yml file which would have to be rebased
on top of master (or any oher branch to be tested) every time the GitLab
repository is synchronized with savannah.

Yes, this could be done.  But it seems to me that this would be brittle
and prone to failures.  Someone would have to look after this.

If the file could just sit in the savannah repository, it would be more
likely to be useful.

> IOW, this file looks unrelated to Emacs, so I don't think I understand
> why Ted wanted us to maintain it.  I'm probably missing something.

I have experimented with about a dozen different CI services, and to me
it seems quite reasonable that Emacs should have this file, IF the
maintainers decide that GitLab-CI is to be used for continuous
integration.

It's not unrelated to Emacs.  It provides build and testing instructions
to an automated service.  Those instuctions are specific to Emacs.




reply via email to

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