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 |