Gentoo Archives: gentoo-dev

From: Dan Douglas <ormaaj@×××××.com>
To: gentoo-dev@l.g.o
Cc: Ian Stakenvicius <axs@g.o>
Subject: Re: [gentoo-dev] Portage Git migration - clean cut or git-cvsserver
Date: Thu, 24 May 2012 19:58:31
Message-Id: 3485389.iLMx13MNW5@smorgbox
1 > On 24/05/12 02:37 PM, Dan Douglas wrote:
2 > > On Thursday, May 24, 2012 01:52:32 PM Ian Stakenvicius wrote:
3
4 > >
5 > > Of course it's read only - just like all other public
6 > > repositories. You don't want to accept improvments? I don't
7 > > understand this.
8 >
9 > I have no problem with accepting improvements, i'm just leary of
10 > semi-official copies of the tree that could be checked out and checked
11 > into by non-dev's (this said, I don't know that much about git but I
12 > assume that github users could commit to the github copy yes? that
13 > being the way users would contribute?)
14
15 > >> otherwise we're going to have a rather large mess on our hands
16 > >> (multiple forks of the main tree != a uniform main tree +
17 > >> overlays, the way it does now)
18 > >
19 > > Forking happens when it's hard to contribute. You even want to
20 > > make overlays difficult? The only real mechanism Gentoo provides
21 > > for user extensibility?
22 >
23 > Nono, I was comparing the (from my perspective) mess of multiple forks
24 > of the main tree that hosting on github/other services could
25 > potentially enable, with a single uniform source of the main tree plus
26 > overlays for extended contribution (which is the system we have now).
27
28 Git is about decentralized version control. When you clone a repo, you have
29 your own "fork". When everyone has their own branch, everyone is effectively
30 equal. So yes you can expect much much more forking. In Git land, forks are
31 good. There's no way to enforce that people only pull from some "official"
32 source.
33
34 It works out in practice so that 99% of the time people only care about a
35 couple branches of one repository. Counterintuitively, this comes as a side-
36 effect of git actually doing distribution properly and making it easier for
37 everybody's workflow. The overlay model by contrast is quite broken on its own
38 and virtually forces creation of new overlays in order to make changes without
39 the benifits of version control (with regards to the rsync tree at least).
40
41 What Github does is facilitate making it easy to fork/branch and provide a
42 central way to push changes back into a remote through pull requests. Pull
43 requests and other web services around git hosting are pretty much the thing
44 that makes github worth using. From the standpoint of accepting patches, the
45 differenc e to you is rather than (or in addition to) accepting patches through
46 bugzilla, you can choose to accept a push directly from someone else's copy of
47 the repo. It isn't like a wiki - everybody commits to their own repositories
48 and pushing to a remote is on a whitelist basis just like in centralized
49 version control.
50
51 Anyway, others are better at "selling" Git than I and there are no shortage of
52 resources out there describing distributed development models. I think this
53 thread is supposed to be about the technical hurdles and it looks like whether
54 or not it's feasible to support github. I can't really comment on the
55 latter. Aside from whatever hoops the Gentoo devs have to jump through in
56 trying to maintain multiple repos, it's hard to see the downsides to using
57 github in and of itself.
58
59 Talk to the Gentoo Haskell guys, they've been using Github for some time. And
60 if memory serves, KDE used to be on Github or Gitorious before moving to o.g.o
61
62 --
63 Dan Douglas

Attachments

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

Replies