| 1 |
Presently, the way to make contributions as outlined in [1] is to create |
| 2 |
a bugzilla ticket and attach the patch to that ticket. But there is no |
| 3 |
community involvement really for this. |
| 4 |
|
| 5 |
A possible model for increasing user-collaboration and promoting user activity: |
| 6 |
|
| 7 |
From User's POV: |
| 8 |
- Do emerge --sync and get the tree (Obvious) |
| 9 |
- Make changes, fix/add ebuilds in /usr/portage |
| 10 |
- Do emerge --please-take-my-tree-to-community-review |
| 11 |
|
| 12 |
What will emerge --please-take-my-tree-to-community-review do? |
| 13 |
- Generate a suitable patch between the user's local tree and the |
| 14 |
official tree |
| 15 |
- Trigger pybugz[2] (or similar..) to create a new Bugzilla |
| 16 |
ticketwith as much information |
| 17 |
as possible. For example, it can be automatically guessed whether |
| 18 |
the changes |
| 19 |
are about fixing an existing ebuild or adds a new ebuild. |
| 20 |
=== |
| 21 |
- In addition to the emails that are sent by bugzilla to the |
| 22 |
developers or groups |
| 23 |
responsible, a new email would be sent to |
| 24 |
nice-users-that-will-help-me-review-my-code at gentoo.org for |
| 25 |
community review. |
| 26 |
This will help the user fix issues (The user might range from |
| 27 |
complete novice to |
| 28 |
almost-developer) according to feedback he or she recieves from other users. |
| 29 |
Other users can also run the new ebuilds easily (will promote |
| 30 |
sharing user contributions). |
| 31 |
- Once enough people have used the new contributions, the changes |
| 32 |
have more chances |
| 33 |
of being merged into the official tree. |
| 34 |
=== |
| 35 |
|
| 36 |
The bugzilla ticket can be suitably updated by the contributor. The |
| 37 |
best part is that |
| 38 |
the user doesn't need any git expertise and can focus on the task at |
| 39 |
hand. This will |
| 40 |
also help promote user discussion and the feedback-improve cycle for |
| 41 |
user contributions. |
| 42 |
IMHO, once it is extremely easy for the users to make contributions, they will |
| 43 |
have less mental barriers to become contributors. The discussion on |
| 44 |
the ML (or IRC), |
| 45 |
will also help in deduplication/enhancement as some existing user(s) |
| 46 |
might have already made |
| 47 |
similar changes to the same ebuilds but didn't consider sharing them earlier. |
| 48 |
|
| 49 |
As far as the execution is concerned, one possibility is to have a USE flag: |
| 50 |
So if portage was installed with USE="dev-mode", all the above |
| 51 |
features would be enabled |
| 52 |
and dependencies like pybugz (or others) will be pulled in. |
| 53 |
Who ever sets this USE flag should also have the possibility of adding |
| 54 |
his or her email address |
| 55 |
to the contributors ML through the terminal so that they can start |
| 56 |
participating asap. |
| 57 |
|
| 58 |
I'm not sure if this satisfies or handles all/any of the features that bernalex |
| 59 |
had in mind but I think it would be a big step forward in user contributions and |
| 60 |
making them feel that they are a part of the Gentoo community and that |
| 61 |
their work |
| 62 |
/contributions are deemed important. It might also make potential |
| 63 |
Gentoo devs feel |
| 64 |
that it is not *that* difficult to become an official developer as |
| 65 |
they are already |
| 66 |
contributing as a user. |
| 67 |
|
| 68 |
PS - Not directly related, but the same model can most probably be used to help |
| 69 |
users in suggesting would-be-good-to-have features and receiving |
| 70 |
feedback on that |
| 71 |
from other users, out of which some might actually take the bold step of |
| 72 |
building it and sending it back to the requesting user. |
| 73 |
|
| 74 |
All criticism is welcome. |
| 75 |
|
| 76 |
[1]: https://wiki.gentoo.org/wiki/Submitting_ebuilds |
| 77 |
[2]: https://github.com/williamh/pybugz/ (Package is www-client/pybugz) |
| 78 |
|
| 79 |
Regards, |
| 80 |
Ashish Gupta |
Archives