Differences

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

--- developingpld [2013-12-24 20:30] – [Required knowledge] glen
+++ developingpld [2014-05-13 18:34] (current) – Links to acinfo changed to ac glen
@@ Line 25: / 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 37: / 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).
+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 //SPECS// module of our [[:Repositories| CVS server]]. The module also contains some special files, the most crucial being the ''builder'' script.
+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 84: / 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 94: / 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).
@@ Line 103: / Line 102: @@
 ==== 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