Gentoo Archives: gentoo-dev

From: "Michał Górny" <mgorny@g.o>
To: Jauhien Piatlicki <jauhien@g.o>
Cc: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it)
Date: Sun, 14 Sep 2014 14:56:55
Message-Id: 20140914163139.4edf970d@pomiot.lan
In Reply to: Re: [gentoo-dev] My masterplan for git migration (+ looking for infra to test it) by Jauhien Piatlicki
1 Dnia 2014-09-14, o godz. 15:09:25
2 Jauhien Piatlicki <jauhien@g.o> napisał(a):
3
4 > 14.09.14 14:03, Michał Górny написав(ла):
5 > > Hi,
6 > >
7 > > I'm quite tired of promises and all that perfectionist non-sense which
8 > > locks us up with CVS for next 10 years of bikeshed. Therefore, I have
9 > > prepared a plan how to do git migration, and I believe it's doable in
10 > > less than 2 weeks (plus the testing). Of course, that assumes infra is
11 > > going to cooperate quickly or someone else is willing to provide the
12 > > infra for it.
13 > >
14 >
15 > as always, nice effort, but I foresee lots of bikeshedding in this thread. )
16
17 Yes. I'm planning to ignore most of bikeshed and take only serious
18 answers into consideration. Otherwise, we will be stuck with CVS.
19
20 > > This means we don't have to wait till someone figures out the perfect
21 > > way of converting the old CVS repository. You don't need that history
22 > > most of the time, and you can play with CVS to get it if you really do.
23 > > In any case, we would likely strip the history anyway to get a small
24 > > repo to work with.
25 >
26 > Is it so difficult to convert CVS history?
27
28 It may be difficult to convert it properly, especially considering
29 the splitting of ebuild+Manifest commit. Then we need to somehow check
30 if it was converted properly. I don't even want to waste my time on
31 this. IMO the history doesn't have such a great value.
32
33 > > The rsync tree
34 > > --------------
35 > >
36 > > We'd also propagate things to rsync. We'd have to populate it with old
37 > > ChangeLogs, new ChangeLog entries (autogenerated from git) and thick
38 > > Manifests. So users won't notice much of a change.
39 > >
40 >
41 > How will user check the ebuild integrity with thick manifests using rsync?
42
43 The same way he currently does :).
44
45 > > The remaining issue is signing of stuff. We could supposedly sign
46 > > Manifests but IMO it's a waste of resources considered how poor
47 > > the signing system is for non-git repos.
48 >
49 > Again, how will user check the integrity and authenticity if Manifests are unsigned?
50
51 As far as I'm concerned, user can use the user git tree to get proper
52 signatures or any other method that has proper signing support already.
53
54 If someone wants proper GPG support in rsync, he can work on that.
55
56 --
57 Best regards,
58 Michał Górny

Attachments

File name MIME type
signature.asc application/pgp-signature