From Fedora Project Wiki

(→‎Upgrade path examples are confusing: I Was Bold (as I could be))
(Remove text on talk page to stop leading people to believe that it's actually used to make changes to the guidelines)
Line 1: Line 1:
Sorry for the confusion -- no one watches the talk pages actively.  Please do not use the discussion page to try to get changes to the guidelines approved.


Do this instead:


The following metadata was found in MoinMoin that could not be converted
# Add a page to the wiki normally with your proposed changes.  It's best if your page makes clear what's being changed.  In some cases, that means starting by copying the original text in.  Then modifying it in subsequent saves (so that people can use the history function to see the changes).  Other times, it's enough to simply point out which pieces of text you're changed.
to a useful value in MediaWiki:
# Go to https://fedorahosted.org/fpc/ and login
# Enter a ticket for the FPC to review the new guideline.  Include a link to the wiki page with your proposed change as well as information you don't have on the page that you think is relevant.


* : Note that Epoch: has been dropped here, but preserved in Provides/Obsoletes below
The FPC members receive email from the ticketing system so sometimes it pays to repeat some of the information from your wiki page if you think that it will help people to look at and start forming questions about your change prior to going to an FPC meeting.
 
=== Clarification request ===
"  Snapshot packages
 
If a snapshot package is considered a "pre-release package", you should follow the guidelines listed in Pre-Release Packages , and use an %{alphatag} beginning with the date in YYYYMMDD format and followed by up to 16 (ASCII) alphanumeric characters of your choosing."
 
Is there a minimum number of alphatag chars ?
Would 2 be a good minimum eg: fits hg
 
Suggest change to:
"followed by between 2 and 16 (ASCII) alphanumeric characters of your choosing."
 
== Exception to spec naming still valid? ==
 
Does the following still need to be included in this document?
{{Quote|
== Spec file name ==
As a special exception, there are a few packages which are allowed to have a version in their spec filename. This is because they had the version in their name when they were merged from Fedora Core's cvs and removing the version at that time would have *lost* history:
 
* gcc
* [Please ask the packaging committee to add your package if you think it should also fall under this exception.]
 
This exception will go away when any of the following criteria are met: 1. We move the packages to a revision control system which is able to preserve history across a file rename. 1. The package spec file is going to be renamed anyway (for example, gcc41.spec is currently in cvs. When gcc is upgraded to gcc-4.2, the new spec will be created as gcc.spec '''not''' gcc42.spec)|}}
gcc is at gcc-4.6.0-9.fc15 currently, so I assume its spec has been renamed. Regardless, the packaging system is now using git, which I believe ''does'' preserve history across file renames, doesn't it? --[[User:Ferdnyc|Ferdnyc]] 12:55, 22 June 2011 (UTC)
 
Thanks, that has indeed been fixed. /me removes the exception. --[[User:Toshio|abadger1999]] 14:50, 22 June 2011 (UTC)
 
== Upgrade path examples are confusing ==
 
The two "Upgrade path example" listings (for mozilla and alsa-lib) in the Release Tag section strike me as confusing. In every other list of NVRs given as an example, the text in parentheses that follows each entry is a description of that NVR. For the two upgrade path examples, even though they're formatted in exactly the same way, the text in parentheses effectively describes the NVR on the ''following'' line.
 
I had to read through it twice to catch on to that. On first read I thought I'd just spotted typos in some of the tags, because the entries didn't seem to match "their" descriptions. I don't know if the parenthetical descriptions in these examples should all be shifted downwards by one line, or if the formatting should be changed to make it much more obvious that these two lists are different from all of the others, but either of those changes would enhance clarity a great deal. --[[User:Ferdnyc|Ferdnyc]] 13:07, 22 June 2011 (UTC)
 
: Well, after 5 months without comment on this, I decided to take a page from Wikipedia and "be bold". So, I undertook a re-working of the descriptions in the two Upgrade Path examples I mentioned. In the process, I ended up eliminating the giant <PRE>s and wikifying the whole works. (All because I wanted to use links in the descriptions! LOL.)
 
:Since I can't edit this page, my proposed replacement for [[Packaging:NamingGuidelines#Pre-Release_packages|Section 1.5.2.1.2 (currently) of this document]] can be found at [[User:Ferdnyc/PackagingEditTest]]. The full source code of that page should be a drop-in replacement for the [[Packaging:NamingGuidelines#Pre-Release_packages]] section; I tried to preserve the structure to make things as easy as possible should anyone wish to adopt my changes.
 
: There shouldn't be any content changes (other than the explanation texts in the two Upgrade Path examples), just lots of formatting tweaks. I'm still not happy about how the table captions look -- I'd prefer they be left-justified rather than centered, I think. Other than that, it seems pretty serviceable to me... but I'm biased. [[User:Ferdnyc/PackagingEditTest]], submitted for your consideration. ;-)
: --[[User:Ferdnyc|Ferdnyc]] 09:09, 23 November 2011 (UTC)

Revision as of 21:28, 23 November 2011

Sorry for the confusion -- no one watches the talk pages actively. Please do not use the discussion page to try to get changes to the guidelines approved.

Do this instead:

  1. Add a page to the wiki normally with your proposed changes. It's best if your page makes clear what's being changed. In some cases, that means starting by copying the original text in. Then modifying it in subsequent saves (so that people can use the history function to see the changes). Other times, it's enough to simply point out which pieces of text you're changed.
  2. Go to https://fedorahosted.org/fpc/ and login
  3. Enter a ticket for the FPC to review the new guideline. Include a link to the wiki page with your proposed change as well as information you don't have on the page that you think is relevant.

The FPC members receive email from the ticketing system so sometimes it pays to repeat some of the information from your wiki page if you think that it will help people to look at and start forming questions about your change prior to going to an FPC meeting.