Gentoo Archives: gentoo-project

From: "Michał Górny" <mgorny@g.o>
To: Markos Chandras <hwoarang@g.o>
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Official rsync->git mirror & 'Git mirror' project announcement
Date: Wed, 28 Jan 2015 22:30:35
Message-Id: 20150128233022.3e5d3d29@pomiot.lan
In Reply to: Re: [gentoo-project] Official rsync->git mirror & 'Git mirror' project announcement by Markos Chandras
1 Dnia 2015-01-28, o godz. 21:48:37
2 Markos Chandras <hwoarang@g.o> napisał(a):
3
4 > -----BEGIN PGP SIGNED MESSAGE-----
5 > Hash: SHA512
6 >
7 > On 01/26/2015 08:12 PM, Michał Górny wrote:
8 > > Hello, everyone.
9 > >
10 > > I have the pleasure to announce that the official rsync2git mirror
11 > > is up and running [1] thanks to Sven Wegener. It is updated from
12 > > rsync every 30 minutes, and can be used both to sync your local
13 > > Gentoo installs and to submit improvements via pull requests (see
14 > > README [2] for some details).
15 > >
16 > > At the same time, I have established the 'Git Mirror' [3] project
17 > > which welcomes developers willing to help reviewing the pull
18 > > requests and helping those improvements reach package maintainers.
19 > >
20 > > For users, this means that we now have a fairly efficient syncing
21 > > method and a pull request-based workflow for submitting fixes. The
22 > > auto-synced repository can also make proxy-maint workflow easier.
23 > >
24 > > For developers, this either means:
25 > >
26 > > a. if you want to help us, join the team, watch the pull requests.
27 > > CC maintainers when appropriate, review, even work towards merging
28 > > the changes with approval of the maintainers,
29 > >
30 > > b. if you want to support git users, just wait till we CC you and
31 > > then review, help, merge :),
32 > >
33 > > c. if you don't want to support git users, just ignore the repo.
34 > > We'll bother you directly after the changes are reviewed and ready
35 > > :).
36 > >
37 > > [1]:https://github.com/gentoo/gentoo-portage-rsync-mirror
38 > > [2]:https://github.com/gentoo/gentoo-portage-rsync-mirror#README
39 > > [3]:https://wiki.gentoo.org/wiki/Project:Git_mirror
40 > >
41 > Hi,
42 >
43 > First of all let me express my gratitude on what you did! It's a
44 > really nice effort towards the right direction. However, I feel there
45 > is a bit of overlap with the proxy-maintainers[1] repository. On the
46 > readme file you suggest to not commit anything to this git repository
47 > (not even merge pull requests). So what's the purpose of having the
48 > pull requests in the first place? I believe, in order to avoid
49 > confusion, users should use the proxy-maintainers repository for pull
50 > requests for the packages they maintain. Otherwise, just stick to the
51 > bugzilla for ebuilds that have developers as maintainers. I believe we
52 > are running into the risk of having too many places for user
53 > contributions, and that will make maintenance a nightmare because you
54 > will have devs taking care of proxy-maint pull requests, and then
55 > others taking care of the rsync-git mirror pull requests. I believe
56 > you need to rethink the proposed workflow.
57 >
58 > [1] https://github.com/gentoo/proxy-maintainers
59
60 I have talked to some of the team members and they expressed interest
61 in using this repository instead of proxy-maint one. The main advantage
62 is that the repository is synced to gx86, so users don't have to
63 copy/sync ebuilds manually to work on them.
64
65 The pull request workflow still has advantages, even if you don't use
66 the github's built-in merge mechanism. Developers can easily pull
67 the changes to their local repo and test them, and then copy over to
68 CVS. Plus github provides a simple review workflow with comments
69 and updates.
70
71 As I see it, it's both better for users and developers. More points of
72 contribution can be a bit confusing but also go towards a more
73 distributed workflow. If user can help me by contributing to Gentoo, I
74 don't think we should require him to match our fancy tools but let him
75 use the tools he finds helpful. And a lot of people find github this
76 way.
77
78 That said, I still think the workflow is easier. Cloning and creating
79 the pull request is more console-friendly than opening a bug
80 and attaching few files. Reviews can be more dynamic, and updating
81 the pull request is much easier than deprecating and attaching new
82 files. Not to mention downloading and testing those files...
83
84 --
85 Best regards,
86 Michał Górny