#29 suppress indentation warning
Merged 4 years ago by bcotton. Opened 4 years ago by jibecfed.
fesco/ jibecfed/fesco-docs indent  into  master

@@ -91,49 +91,49 @@ 

  == Tracking bugs

  

  * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=440169[generic

- FTBFS blocker bug]

+   FTBFS blocker bug]

  * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=440169&hide_resolved=1[F9FTBFS]

  * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=463452&hide_resolved=1[F10FTBFS]

  * F11 was handled by Release Engineering, no FTBFS bugs were filed.

- link:http://jkeating.fedorapeople.org/needed-f11-rebuilds.html[]

- (link:https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

+   link:http://jkeating.fedorapeople.org/needed-f11-rebuilds.html[]

+   (link:https://fedoraproject.org/wiki/Fedora_11_Mass_Rebuild[Fedora 11 Mass Rebuild])

  * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=511348&hide_resolved=1[F12FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_12_Mass_Rebuild[Fedora 12 Mass Rebuild])

  * link:https://bugzilla.redhat.com/showdependencytree.cgi?id=538681&hide_resolved=1[F13FTBFS]

  ** link:https://bugzilla.redhat.com/showdependencytree.cgi?id=564245&hide_resolved=1[F13FTBFS

- due to] Features/ChangeInImplicitDSOLinking

+    due to] Features/ChangeInImplicitDSOLinking

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=596849[F14FTBFS]

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=659965[F15FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild[Fedora 15 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=713919[F16FTBFS]

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=817273[F17FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_17_Mass_Rebuild[Fedora 17 Mass Rebuild])

  * There seem to be no FTBFS bugs reported for Fedora 18, list of failed

- builds from the mass rebuild:

- link:http://fedorapeople.org/~ausil/f18-failures.html[]

- (link:https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

+   builds from the mass rebuild:

+   link:http://fedorapeople.org/~ausil/f18-failures.html[]

+   (link:https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild[Fedora 18 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=913825[F19FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild[Fedora 19 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=991858[F20FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild[Fedora 20 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1105908[F21FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_21_Mass_Rebuild[Fedora 21 Mass Rebuild])

  * F22?

  * F23? (link:https://fedoraproject.org/wiki/Fedora_23_Mass_Rebuild[Fedora 23 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1305208[F24FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_24_Mass_Rebuild[Fedora 24 Mass Rebuild])

  * No mass rebuild in F25

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1423041[F26FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

+   (link:https://fedoraproject.org/wiki/Fedora_26_Mass_Rebuild[Fedora 26 Mass Rebuild])

  * F27? (link:https://fedoraproject.org/wiki/Fedora_27_Mass_Rebuild[Fedora 27 Mass Rebuild])

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1555378[F28FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]),

+   (link:https://fedoraproject.org/wiki/Fedora_28_Mass_Rebuild[Fedora 28 Mass Rebuild]),

    link:https://bugzilla.redhat.com/show_bug.cgi?id=1700320[F28FailsToInstall]

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1602938[F29FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild]),

+   (link:https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild[Fedora 29 Mass Rebuild]),

    link:https://bugzilla.redhat.com/show_bug.cgi?id=1700321[F29FailsToInstall]

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1674516[F30FTBFS]

- (link:https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild]),

+   (link:https://fedoraproject.org/wiki/Fedora_30_Mass_Rebuild[Fedora 30 Mass Rebuild]),

    link:https://bugzilla.redhat.com/show_bug.cgi?id=1700323[F30FailsToInstall]

  * link:https://bugzilla.redhat.com/show_bug.cgi?id=1700317[F31FTBFS],

    link:https://bugzilla.redhat.com/show_bug.cgi?id=1700324[F31FailsToInstall]
@@ -147,32 +147,33 @@ 

  

  .  Fix the problems uncovered and commit the changes.

  .  Build the package. The fixed package will land in rawhide, generally

- the next day. If branching has already occurred, also fix the build in

- branched.

+    the next day. If branching has already occurred, also fix the build in

+    branched.

  .  If the build succeeds, close the bug as CLOSED: RAWHIDE, and include

- the package version number in the _Fixed In Version_ field.

+    the package version number in the _Fixed In Version_ field.

      Here is a command line template for powerusers:

      `bugzilla modify --close RAWHIDE <bug-number> --comment

      'Built successfully in rawhide' -F <package-nevr>`

  .  If branching already occurred, but bodhi hasn't been activated yet,

- also build the package in branched.

+    also build the package in branched.

  .  If bodhi has already been activated for branched, also make an

- update. An update should be made even if branched has already been

- released.

+    update. An update should be made even if branched has already been

+    released.

  

  * If the build of your package fails due to a bug in *another package*

  (such as a compiler bug or missing dependency):

  

  .  Find an existing bug for that package describing the problem. Set

- your bug to "Depends on" that other bug. Do not change the component of

- your bug to the other package, or you will get more FTBFS bugs created

- against you.

+    your bug to "Depends on" that other bug. Do not change the component of

+    your bug to the other package, or you will get more FTBFS bugs created

+    against you.

  .  When that other bug is closed, you'll get an email from bugzilla as

- usual. Rebuild your package using a koji scratch build, to verify it

- builds cleanly again. Proceed according to points 2-5 above.

+    usual. Rebuild your package using a koji scratch build, to verify it

+    builds cleanly again. Proceed according to points 2-5 above.

  

  * If the package is no longer useful to the Fedora project, it should be

- retired.

+   retired.

+ +

  See link:https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life[How

  to remove a package at end of life].

  

@@ -48,12 +48,12 @@ 

  == Deal with reported bugs in a timely manner

  

  * If you find yourself unable to handle the load of bugs from your package(s), please ask for assistance on the link:https://admin.fedoraproject.org/mailman/listinfo/devel[devel] and/or link:https://admin.fedoraproject.org/mailman/listinfo/test[test] lists.

- Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora.

- Consider reaching out for some (more) co-maintainers to assist as well.

+   Teaching triagers about how to triage your bugs or getting help from other maintainers can not only reduce your load, but improve Fedora.

+   Consider reaching out for some (more) co-maintainers to assist as well.

  * If there are bugs which you aren't capable of fixing yourself because they deal with intricacies of the source code which you don't fully understand, then you still need to address these bugs.

- It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches.

- Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect.

- It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.

+   It can be helpful to work with the upstream maintainer of the code, obtain help from more code-oriented people on fedora-devel, or check other distributions for patches.

+   Always be sure to post to the bug report what you have done so that the reporter knows what it happening and what to expect.

+   It is recommended that non-coder packagers should find co-maintainers who are familiar with the programming language used by their package(s), and can help with such bugs as a kind of 'second line support'.

  * Try and solve bugs or issues for the release against which they were reported, or if that is impractical note to bug reporters why their bug cannot be fixed in that release

  

  == Package updates
@@ -62,8 +62,8 @@ 

  In summary, however, maintainers should bear in mind that:

  

  * Many Fedora users update automatically, so it is most important that an update doesn't cause a users' applications or system to stop working suddenly.

- *  Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.

- *  Not all Fedora users have good Internet bandwidth available and may prefer a single update with multiple changes rather than many updates in a short period.

+ * Fedora users who do not update automatically may review the descriptions attached to updates before choosing whether they should apply them.

+ * Not all Fedora users have good Internet bandwidth available and may prefer a single update with multiple changes rather than many updates in a short period.

  

  == Mentor and watch over co-maintainers

  
@@ -95,9 +95,9 @@ 

  * Branches (Rawhide, F9, etc.) which will be affected by the change.

  * Expected date of the change.

  * List of packages which are affected by the change.

- Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with `repoquery --whatrequires <package>` where `<package>` is the package being updated.

+   Generally, this is merely the list of packages which depend directly on the package which is being updated, and can be found with `repoquery --whatrequires <package>` where `<package>` is the package being updated.

  * If your package upgrade breaks other packages in Rawhide, you should try to help fix the packages affected.

- For example, if you're a provenpackager, queue the rebuilds yourself.

+   For example, if you're a provenpackager, queue the rebuilds yourself.

  

  == Respect Schedules

  
@@ -111,6 +111,6 @@ 

  F(current-1) -> F(current) -> Rawhide

  

  * Packages should be pushed to the Rawhide branch first.

- If it builds and works fine for a few days, then it can be pushed to F(current).

- If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).

+   If it builds and works fine for a few days, then it can be pushed to F(current).

+   If there is a good reason to push it to F(current-1), it should be done after a few days of being in F(current).

  * When releasing a new package to a stable release branch, they should be pushed to the testing repo first in most cases.

in the internationalization system of our docs, the tool po4a we use to convert asciidoc files into pot displays three lines of warning for each missing indentation.

most of the time it is cosmetic issues in adoc (like here), but sometimes it's po4a bugs that I want to see
this PR has no impact on your rendering, it is fully cosmetic

Since it's cosmetic, merging without delay

Pull-Request has been merged by bcotton

4 years ago