aboutsummaryrefslogtreecommitdiff
path: root/carbslinux.org
diff options
context:
space:
mode:
Diffstat (limited to 'carbslinux.org')
-rw-r--r--carbslinux.org117
1 files changed, 117 insertions, 0 deletions
diff --git a/carbslinux.org b/carbslinux.org
index dce939b..230b236 100644
--- a/carbslinux.org
+++ b/carbslinux.org
@@ -74,6 +74,10 @@ with your favorite pager. You can install either the @command{info} or
- [[#conventions][Conventions]]
- [[#shell-conventions][Shell Conventions]]
- [[#repository-conventions][Repository Conventions]]
+ - [[#contributing-to-the-community-repository][Contributing to the Community repository]]
+ - [[#sending-patches][Sending Patches]]
+ - [[#git-patches][Git Patches]]
+ - [[#fossil-patches][Fossil Patches]]
- [[#gnu-free-documentation-license][GNU Free Documentation License]]
* Copying
@@ -929,6 +933,119 @@ taken literally, they are meant as examples.
python setup.py install --prefix=/usr --root="$1"
#+END_SRC
+** Contributing to the Community repository
+:PROPERTIES:
+:DESCRIPTION: Package maintainership and issue reports
+:END:
+
+The community repository is available for any user to submit packages. However,
+there are certain guidelines that the users are expected to follow before they
+submit packages.
+
+- {{{contid(3000)}}} ::
+
+ Any submitted package should contain a =meta= file that includes a short
+ description of the package, the maintainer's name and email address, and the
+ license of the package. Below is an example:
+
+ #+begin_example
+description: some IRC client with some interesting feature
+license: MIT
+maintainer: Your Name <address@example.com>
+ #+end_example
+
+ The order of these are not important. However, make sure to use the license
+ identifiers as defined by [[https://spdx.org/licenses/][SPDX]] when listing the license.
+
+- {{{contid(3010)}}} ::
+
+ The user submitting the package is expected to maintain their packages. This
+ means that they are keeping the packages up-to-date, and responding to issues
+ related to the package.
+
+- {{{contid(3020)}}} ::
+
+ If a maintainer doesn't follow the above expectation for a duration of up to a
+ month, their packages will be orphaned and can be adopted by a new maintainer.
+ Maintainers can also request that their packages be orphaned. If the orphaned
+ packages aren't adopted by a new maintainer in a period of two weeks, these
+ packages will be dropped from the repository.
+
+- {{{contid(3030)}}} ::
+
+ Package submissions and updates should be submitted in the form of patches to
+ the [[https://lists.sr.ht/~carbslinux/carbslinux-devel][~carbslinux/carbslinux-devel]] mailing list. The repository on Github is a
+ read-only mirror, and Pull Requests will *NOT* be accepted.
+
+- {{{contid(3031)}}} ::
+
+ Issues regarding community packages should be submitted to the
+ [[https://lists.sr.ht/~carbslinux/carbslinux-discuss][~carbslinux/carbslinux-discuss]] mailing list. When submitting issues, do not
+ forget to add the maintainer as a recipient. You can easily find the maintainer
+ information by running ~cpt-maintainer <pkg>~.
+
+** Sending Patches
+:PROPERTIES:
+:DESCRIPTION: Code contribution
+:END:
+*** Git Patches
+
+There are multiple ways of sending patches with git. Unfortunately, the most
+popular / official way of doing it requires Perl and some extra Perl libraries
+that are not packaged in the repository. This section tries to list other
+options that are just as useful as =git send-email=.
+
+**** =git-send-email= with msmtp
+
+By default, =git-send-email= uses a Perl SMTP client, but without using it this
+command doesn't actually need extra Perl libraries, only Perl itself. So, if you
+are okay with using Perl, the easiest option is to install the =msmtp= package,
+and change your git configuration to match your msmtp settings.
+
+To your =~/.gitconfig=, add the following section:
+
+#+begin_example
+[sendemail]
+ smtpserver = /usr/bin/msmtp
+ smtpserveroption = -a
+ smtpserveroption = your-account-name
+#+end_example
+
+**** =git-imap-send=
+
+The =git imap-send= command reads patches in mbox format, and uploads it to your
+imap server as drafts. You can then use your preferred email-client to edit and
+send them. This is the option with no dependencies. Check out the manual page
+=git-imap-send(1)= for more information on setting up.
+
+*** Fossil Patches
+
+You can create multiple types of "patches" with Fossil. Unlike the common
+convention in Git, the first two examples here uses uncommitted changes to
+create a patch (although you could very well create patches of committed
+changes). The preferred method is by creating a plaintext patch by doing the
+following:
+
+#+begin_src sh
+fossil diff -i > your-changes.patch
+#+end_src
+
+You can also create a binary patch:
+
+#+begin_src sh
+fossil patch create your-changes.db
+#+end_src
+
+If your patchset is complex, and needs to be splitted in multiple check-ins, you
+can create a Fossil bundle:
+
+#+begin_src sh
+fossil bundle create --from CHECKIN --to CHECKIN2 patchset.bundle
+#+end_src
+
+After creating the patches, you can simply send them to the mailing list, or
+upload the patches to the Fossil forum of the relevant repository.
+
* GNU Free Documentation License
:PROPERTIES:
:APPENDIX: t