Differences

This shows you the differences between two versions of the page.

--- developingpld [2007-10-01 12:15] – patrys
+++ developingpld [2014-05-13 18:34] (current) – Links to acinfo changed to ac glen
@@ Line 3: / Line 3: @@
 ====== How to become a PLD developer ======
 This article will attempt to explain the basics of a Linux-based distribution development process.
+/* UndefinedMacro: TableOfContents(3) */
 ===== Required knowledge =====
-As PLD is an RPM-based distribution, the following knowledge is assumed:
+As PLD Linux is an RPM-based distribution, the following knowledge is assumed:
   * Basic ''rpm'' operation
-  * Use of versioning tools such as ''cvs'' and ''svn''
+  * Use of versioning tools such as ''git''
   * Handling file differencies using ''diff'' and ''patch''
   * Building applications from their sources
@@ Line 23: / Line 25: @@
   * PLD Ra/1.0 (released some time ago)
-  * [[:AcInfo|PLD Ac/2.0]] (stable)
+  * [[ac|PLD Ac/2.0]] (stable)
-  * [[:ThInfo|PLD Th/3.0]] (in development)
+  * [[th|PLD Th/3.0]] (in development)
 Each line has a person in charge of it, called the Release Manager. RMs spend time maintaining parts of PLD's infrastructure, making decisions if other developers can't agree on something by themselves and taking care of the content of our FTP server.
@@ Line 35: / Line 37: @@
 ==== Spec files ====
-A ''spec'' file contains metadata and building instruction required to create at least one RPM package. It is a text file suitable for processing with the ''builder'' script which in turn handles the whole building process from fetching all the necessary sources from PLD's infrastructure (or directly from the Internet) to packaging the results into installable RPM files (the latter being done by the ''rpmbuild'' utility).
-You can also [[:DevelopingPLD:SpecFiles|read more on spec files]].
-All the ''spec'' files reside inside //SPECS// module of our [[:Repositories| CVS server]]. The module also contains some special files, the most crucial being the ''builder'' script.
+A ''spec'' file contains metadata and building instruction required to create at least one RPM package. It is a text file suitable for processing with the [[developingpld:builderscript|builder]] script which in turn handles the whole building process from fetching all the necessary sources from PLD's infrastructure (or directly from the Internet) to packaging the results into installable RPM files (the latter being done by the ''rpmbuild'' utility).
+You can also [[http://www.rpm.org/max-rpm/ch-rpm-inside.html|read more on spec files]].
+All the ''spec'' files reside inside their respective package dir of our [[repositories#git_repositories| GIT server]]. [[package>rpm-build-tools]] package, containing ''builder'' script, also contains some special files, the most crucial being the ''builder'' script.
 ==== The builder script ====
 The ''builder'' script is responsible for the whole package assembly process. It fetches all the needed sources, checks for required dependencies, unpacks the sources, compiles them and finally packages the result into installable RPM files.
@@ Line 82: / Line 82: @@
 You should start right off by subscribing to at least some of our [[:MailingLists| mailing lists]]. Especially the ''pld-devel-en'' (or ''pl'' for Polish speaking developers) list and possibly also ''pld-discuss'' for various distribution-related discussions.
-Take note that there is a special ''pld-cvs-commit'' list but it's not meant for direct posting. Instead, this list collects all CVS, SVN and website changes commited by other developers.
+Take note that there is a special ''pld-cvs-commit'' list but it's not meant for direct posting. Instead, this list collects GIT, SVN or CVS commits and website changes commited by PLD Linux developers.
@@ Line 92: / Line 92: @@
 ==== Working on packages ====
-Start with simple things. Picking a random package and updating it might seem like a good idea, but it'll eventually get you in trouble. Breaking an app someone depends on won't hurt the distribution itself that much, but people will get angry at you and making future changes will get a lot harder. Try adding a ''spec'' file for that little application you use for your everyday work or update an existing ''spec'' for a new release of some useful tool you just can't live without.
+Start with simple things. Picking random package and updating it might seem like a good idea, but it'll eventually get you in trouble. Breaking an app someone depends on won't hurt the distribution itself that much, but people will get angry at you and making future changes will get a lot harder. Try adding a ''spec'' file for that little application you use for your everyday work or update an existing ''spec'' for a new release of some useful tool you just can't live without.
 Before you decide you are done, double-check your dependencies section for all necessary packages and make sure the package builds cleanly (for instance, no files are left after packaging RPM files - ''builder'' warns about that at the end of building process).
-If you're bored and don't know what to do, you can try fulfilling requests from [[http://cvs.pld-linux.org/PLD-doc/PLD-specs-TODO?rev=HEAD|PLD-doc/PLD-specs-TODO]], or autogenerated TODO headers from *.spec: [[http://cvs.pld-linux.org/PLD-doc/specs-auto-todo.txt?rev=HEAD|PLD-doc/specs-auto-todo.txt]]
+If you're bored and don't know what to do, you can try fulfilling requests from [[http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/PLD-specs-TODO?rev=HEAD|PLD-doc/PLD-specs-TODO]](or this same list but with additional entries on wiki [[http://pld-users.org/specs-todo|http://pld-users.org/specs-todo]]), or autogenerated TODO headers from *.spec: [[http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/PLD-doc/specs-auto-todo.txt?rev=HEAD|PLD-doc/specs-auto-todo.txt]]
 ==== Publishing your changes ====
-As a wannabe developer you most likely won't have read/write access to the CVS repository so you'll have to find someone to check your changes in and add them to the repository. The best way to do it is to send a //unified diff// of your changes against the original files (or the whole files in case you are adding any) in a mail message along with a brief description of what you did to the ''pld-devel-en'' (or ''pl'') mailing list.
-Once one of the other developers has time to review your changes, you will be notified of any errors that need to be fixed and eventually your files will get commited.
+As a wannabe developer you most likely won't have read/write access to the GIT repository so you'll have to find someone to check your changes in and add them to the repository. The best way to do it is to send a //unified diff// of your changes against the original files (or the whole files in case you are adding any) in a mail message along with a brief description of what you did to the ''pld-devel-en'' (or ''pl'') mailing list.
-Once you provide enough valuable changes, other developers might decide to give you full access to our repositories. This process is always initiated by someone who already has read/write access, asking for access on your own will not do you any good.
+It's also acceptable to make your changes in your git repository, perhaps published in [[https://github.com|github]] and let somebody to pull your changes to pld repository.
-When that happens, you will be able to do regular CVS commits. Remember to check the files you are committing before sending them to the repository. Make sure you also provide a meaningful commitlog. All logs have to be in the following format:
+Once existing developer, who has time to review your changes, you will be notified of any errors that need to be fixed and eventually your files will get committed or pushed.
+Once you provide enough valuable changes, other developers might decide to give you full access to our repositories. This process is always initiated by someone who already has read/write access, asking for access on your own will not do you any good.
+When that happens, you will be able to do GIT commits and push them to PLD servers yourself. Remember to check the files you are committing before sending them to the repository. Make sure you also provide a meaningful commitlog. All logs have to be in the following format:
 <file>- first change
@@ Line 124: / Line 126: @@
   - ''spec'' file is commited (including changes to needed patches and other files referenced in the ''spec'')
-  - One of the developers requests a test build (this is done using the [[http://cvs.pld-linux.org/pld-builder.new/client/make-request.sh?rev=HEAD|make-request.sh]] script). If you don't have the rights contact your RM for access. It is possible to skip this step and ask for an upgrade directly however it is not recommended as a partial upgrade results in desynchronising packages between build servers. If found guilty, you will be executed on the spot.
+  - One of the developers requests a test build (this is done using the [[http://cvs.pld-linux.org/cgi-bin/cvsweb.cgi/pld-builder.new/client/make-request.sh?rev=HEAD|make-request.sh]] script). If you don't have the rights contact your RM for access. It is possible to skip this step and ask for an upgrade directly however it is not recommended as a partial upgrade results in desynchronising packages between build servers. If found guilty, you will be executed on the spot.
   - The package is successfully built on all architectures.
   - One of the priviledged developers requests an upgrade build (same script as above) - contact your RM for access.
@@ Line 131: / Line 133: @@
   - Your RM takes further care of the package. He decides when the package is ready to be moved to the stable tree (or the ''updates'' tree in case of an already released version). If you believe it takes too long, check if all the dependencies (both introduced or broken by the particular package) have been satisfied in the queue tree.
   - The package is finally moved to the stable or ''updates'' tree and anyone can use it.
+  - The package is placed to ''obolete'' source if new version available.