Re: [gentoo-project] Re: Call for Council Agenda Items - 14 Oct 2014

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

Dnia 2014-10-01, o godz. 13:30:55
Rich Freeman <rich0@gentoo.org> napisał(a):

> On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > If you'd like to contribute another agenda item, please reply to this email.
> 
> I'll offer up a further topic for the git migration.

I think that there are a few issues that the Council may actually want
to discuss.


1. Security
-----------

Right now, all the 'mainline' commits in dev repo need to be signed
by Gentoo developers. However, the 'B' (and further) branches of merge
commits are allowed to be unsigned (or signed using non-Gentoo key)
-- which makes it possible to merge pull requests while preserving
original commits. We have server-side verification of signatures on
pushes; we don't have portage-side verification of incoming commits but
I don't think that's a major blocker.

The user syncing repo uses merge commits to preserve original dev tree
signatures. Both the merges and extra metadata commits are signed using
automated signing key.

The rsync repository contains thick Manifests signed using automated
signing key. Here, the signature verification is implemented completely
in Portage. We may want to use MetaManifests in the future but I doubt
that would be a blocker.

Also, the gentoo-keys project mentioned that we are disallowing Gentoo
developers to push commits signed using another developer's key. Not
sure if that's something really beneficial, so Council may want to
revisit that as well. And anyway, we always have merge commits for
double-signing.


2. ChangeLogs
-------------

The matter of ChangeLogs is still not entirely clear. Right now, we are
removing them completely and keeping old ones in history. From a little
insight we did, users are completely content with having the access to
history of changes via the historical repo and/or
gitweb/cgit/github/... The fact is that most of those tools provide
much better and more complete tools for analyzing changes than
ChangeLogs had.

In particular, this means that changes are supposed to be described
properly in commit messages. In case of necessity, 'git notes' can be
used to amend the messages.

It is possible to generate ChangeLogs in rsync. However, this seems
mostly pointless (and unnecessarily complex to implement) since most of
the users don't use them, and for the remaining uses cases they are not
good enough. Especially that we have git syncing repo that preserves
post-migration history, including commit messages and ability to lookup
the changes.


3. CVS Headers
--------------

The hateful thing. We could supposedly somehow fill them in rsync but
that's complex and very dangerous (think of all the broken patch files
currently in gx86). I think we should kill them.

And while at it, I think it'd be good to actually remove most of them
from our files -- changing header templates and so on. While not
strictly useful, it decreases the size of the repo a bit and avoids any
future nightmares :).

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]