| 1 |
Dnia 2014-10-01, o godz. 13:30:55 |
| 2 |
Rich Freeman <rich0@g.o> napisał(a): |
| 3 |
|
| 4 |
> On Tue, Sep 30, 2014 at 10:08 PM, Rich Freeman <rich0@g.o> wrote: |
| 5 |
> > If you'd like to contribute another agenda item, please reply to this email. |
| 6 |
> |
| 7 |
> I'll offer up a further topic for the git migration. |
| 8 |
|
| 9 |
I think that there are a few issues that the Council may actually want |
| 10 |
to discuss. |
| 11 |
|
| 12 |
|
| 13 |
1. Security |
| 14 |
----------- |
| 15 |
|
| 16 |
Right now, all the 'mainline' commits in dev repo need to be signed |
| 17 |
by Gentoo developers. However, the 'B' (and further) branches of merge |
| 18 |
commits are allowed to be unsigned (or signed using non-Gentoo key) |
| 19 |
-- which makes it possible to merge pull requests while preserving |
| 20 |
original commits. We have server-side verification of signatures on |
| 21 |
pushes; we don't have portage-side verification of incoming commits but |
| 22 |
I don't think that's a major blocker. |
| 23 |
|
| 24 |
The user syncing repo uses merge commits to preserve original dev tree |
| 25 |
signatures. Both the merges and extra metadata commits are signed using |
| 26 |
automated signing key. |
| 27 |
|
| 28 |
The rsync repository contains thick Manifests signed using automated |
| 29 |
signing key. Here, the signature verification is implemented completely |
| 30 |
in Portage. We may want to use MetaManifests in the future but I doubt |
| 31 |
that would be a blocker. |
| 32 |
|
| 33 |
Also, the gentoo-keys project mentioned that we are disallowing Gentoo |
| 34 |
developers to push commits signed using another developer's key. Not |
| 35 |
sure if that's something really beneficial, so Council may want to |
| 36 |
revisit that as well. And anyway, we always have merge commits for |
| 37 |
double-signing. |
| 38 |
|
| 39 |
|
| 40 |
2. ChangeLogs |
| 41 |
------------- |
| 42 |
|
| 43 |
The matter of ChangeLogs is still not entirely clear. Right now, we are |
| 44 |
removing them completely and keeping old ones in history. From a little |
| 45 |
insight we did, users are completely content with having the access to |
| 46 |
history of changes via the historical repo and/or |
| 47 |
gitweb/cgit/github/... The fact is that most of those tools provide |
| 48 |
much better and more complete tools for analyzing changes than |
| 49 |
ChangeLogs had. |
| 50 |
|
| 51 |
In particular, this means that changes are supposed to be described |
| 52 |
properly in commit messages. In case of necessity, 'git notes' can be |
| 53 |
used to amend the messages. |
| 54 |
|
| 55 |
It is possible to generate ChangeLogs in rsync. However, this seems |
| 56 |
mostly pointless (and unnecessarily complex to implement) since most of |
| 57 |
the users don't use them, and for the remaining uses cases they are not |
| 58 |
good enough. Especially that we have git syncing repo that preserves |
| 59 |
post-migration history, including commit messages and ability to lookup |
| 60 |
the changes. |
| 61 |
|
| 62 |
|
| 63 |
3. CVS Headers |
| 64 |
-------------- |
| 65 |
|
| 66 |
The hateful thing. We could supposedly somehow fill them in rsync but |
| 67 |
that's complex and very dangerous (think of all the broken patch files |
| 68 |
currently in gx86). I think we should kill them. |
| 69 |
|
| 70 |
And while at it, I think it'd be good to actually remove most of them |
| 71 |
from our files -- changing header templates and so on. While not |
| 72 |
strictly useful, it decreases the size of the repo a bit and avoids any |
| 73 |
future nightmares :). |
| 74 |
|
| 75 |
-- |
| 76 |
Best regards, |
| 77 |
Michał Górny |
Archives