4 |
development group operates. Also see the HACKING file. |
development group operates. Also see the HACKING file. |
5 |
|
|
6 |
---------------------------------------------------------------------- |
---------------------------------------------------------------------- |
|
Charter for the devel-cvs mailing list: |
|
|
|
|
|
The CVS Developers' List <dev@ccvs.cvshome.org> exists to help people |
|
|
with access to the CVS source repository co-ordinate changes, make |
|
|
releases, and administer the repository. |
|
|
|
|
|
Everyone who has been given checkin access to the repository for the |
|
|
CVS sources should read devel-cvs. Only those with checkin access may |
|
|
send messages to the list. |
|
|
|
|
|
The devel-cvs list may be used to discuss: |
|
|
- administrivia regarding the CVS source repository and release |
|
|
process, and |
|
|
- changes and features intended for inclusion in the official CVS |
|
|
release (either source code or documentation), which someone plans |
|
|
to implement, or has implemented. |
|
|
|
|
|
The devel-cvs list should not be used to discuss: |
|
|
- changes or features to packages other than the CVS release |
|
|
(e.g., related packages like tkCVS, RAD/CVS, or other groups' |
|
|
distributions of CVS, like RCVS, etc.), |
|
|
- changes which nobody has offered to implement, or |
|
|
- the philosophy of CVS (as opposed to a specific change to CVS). |
|
|
These topics should either go on info-cvs, or have a new mailing list |
|
|
created for them. |
|
|
|
|
|
The topic restrictions in this charter do not reflect the development |
|
|
group's future plans for CVS; rather, they reflect a topic |
|
|
classification which the group finds helpful. |
|
|
|
|
|
---------------------------------------------------------------------- |
|
7 |
Policies regarding the CVS source repository: |
Policies regarding the CVS source repository: |
8 |
|
|
9 |
By checking items into the repository, developers agree to permit |
By checking items into the repository, developers agree to permit |
15 |
People who want checkin access are first requested to send |
People who want checkin access are first requested to send |
16 |
patches and have them reviewed by a developer. If they submit some |
patches and have them reviewed by a developer. If they submit some |
17 |
good ones (preferably over a period of time, to demonstrate sustained |
good ones (preferably over a period of time, to demonstrate sustained |
18 |
interest), then one of the developers can ask the devel-cvs mailing |
interest), then one of the developers can ask the other CVS |
19 |
list whether it is OK to make this person a developer (after first |
developers, usually via the bug-cvs@gnu.org mailing list, whether it |
20 |
sending the prospective developer a copy of this file and then having |
is OK to make this person a developer (after first sending the |
21 |
the prospective developer say they want to be a developer). If there |
prospective developer a copy of this file and then having the |
22 |
are no objections, the person will be made a developer. |
prospective developer say they want to be a developer). If there are |
23 |
|
no objections, the person will be made a developer. |
24 |
|
|
25 |
---------------------------------------------------------------------- |
---------------------------------------------------------------------- |
26 |
Policy regarding checkout-only access: |
Policy regarding checkout-only access: |