This script is run as:
- perl Porting/make-rmg-checklist \
- --type [BLEAD-POINT or MAINT or ...] > /tmp/rmg.pod
+ perl Porting/make-rmg-checklist \
+ --type [BLEAD-POINT or MAINT or ...] > /tmp/rmg.pod
You can also pass the C<--html> flag to generate an HTML document instead of
POD.
- perl Porting/make-rmg-checklist --html \
- --type [BLEAD-POINT or MAINT or ...] > /tmp/rmg.html
+ perl Porting/make-rmg-checklist --html \
+ --type [BLEAD-POINT or MAINT or ...] > /tmp/rmg.html
=head1 SYNOPSIS
a few weeks before the release, a number of steps are performed,
including bumping the version to 5.10.2
- ...a few weeks passes...
+ ...a few weeks pass...
perl-5.10.2-RC1 is released
sweet-talking somebody with a Github account into obedience is needed. This
is only needed on the day of the release or shortly afterwards.
-=for checklist skip RC
-
=head3 Quotation for release announcement epigraph
-I<SKIP this step for RC>
-
-For all except an RC release of perl, you will need a quotation
-to use as an epigraph to your release announcement.
+You will need a quotation to use as an epigraph to your release announcement.
=head2 Building a release - advance actions
$ ./perl -Ilib Porting/core-cpan-diff -a -o /tmp/corediffs
-Passing C<-u cpan> (and maybe C<-u undef>) will probably be helpful, since
-it limits the search to distributions with those upstream sources. (It's
-OK for blead upstream to differ from CPAN because those dual-life releases
-usually come I<after> perl is released.
+Passing C<-u cpan> will probably be helpful, since it limits the search to
+distributions with 'cpan' upstream source. (It's OK for blead upstream to
+differ from CPAN because those dual-life releases usually come I<after> perl
+is released.)
See also the C<-d> and C<-v> options for more detail (and the C<-u> option as
mentioned above). You'll probably want to use the C<-c cachedir> option to
but can provide a good first pass to quickly get a list of modules which
definitely haven't changed, to avoid having to download absolutely everything.
-For a BLEAD release with 'cpan' upstream, if a CPAN release appears to be ahead
-of blead, then consider updating it (or asking the relevant porter to do so).
-If blead contains edits to a 'cpan' upstream module, this is naughty but
-sometimes unavoidable to keep blead tests passing. Make sure the affected file
-has a CUSTOMIZED entry in F<Porting/Maintainers.pl>. For 'undef' upstream,
-you'll have to use your judgment for whether any delta should be ignored (like
-'blead' upstream) or treated like a 'cpan' upstream and flagged. Ask around on
-#p5p if you're not sure.
+For a BLEAD-POINT or BLEAD-FINAL release with 'cpan' upstream, if a CPAN
+release appears to be ahead of blead, then consider updating it (or asking the
+relevant porter to do so). (However, if this is a BLEAD-FINAL release or one of
+the last BLEAD-POINT releases before it and hence blead is in some kind of
+"code freeze" state (e.g. the sequence might be "contentious changes freeze",
+then "user-visible changes freeze" and finally "full code freeze") then any
+CPAN module updates must be subject to the same restrictions, so it may not be
+possible to update all modules until after the BLEAD-FINAL release.) If blead
+contains edits to a 'cpan' upstream module, this is naughty but sometimes
+unavoidable to keep blead tests passing. Make sure the affected file has a
+CUSTOMIZED entry in F<Porting/Maintainers.pl>.
If you are making a MAINT release, run C<core-cpan-diff> on both blead and
maint, then diff the two outputs. Compare this with what you expect, and if
=item *
Remove files we do not need. That is, remove any files that match the
-entries in C<@IGNORE> in F<Porting/Maintainer.pl>, and anything that
+entries in C<@IGNOR
ABLE> in F<Porting/Maintainer.pl>, and anything that
matches the C<EXCLUDED> section of the distro's entry in the C<%Modules>
hash.
Ensure dual-life CPAN modules are stable, which comes down to:
- for each module that fails its regression tests on $current
- did it fail identically on $previous?
- if yes, "SEP" (Somebody Else's Problem)
- else work out why it failed (a bisect is useful for this)
+ for each module that fails its regression tests on $current
+ did it fail identically on $previous?
+ if yes, "SEP" (Somebody Else's Problem)
+ else work out why it failed (a bisect is useful for this)
- attempt to group failure causes
+ attempt to group failure causes
- for each failure cause
- is that a regression?
- if yes, figure out how to fix it
- (more code? revert the code that broke it)
- else
- (presumably) it's relying on something un-or-under-documented
- should the existing behaviour stay?
- yes - goto "regression"
- no - note it in perldelta as a significant bugfix
- (also, try to inform the module's author)
+ for each failure cause
+ is that a regression?
+ if yes, figure out how to fix it
+ (more code? revert the code that broke it)
+ else
+ (presumably) it's relying on something un-or-under-documented
+ should the existing behaviour stay?
+ yes - goto "regression"
+ no - note it in perldelta as a significant bugfix
+ (also, try to inform the module's author)
=head3 monitor smoke tests for failures
Similarly, monitor the smoking of perl for compiler warnings, and try to
fix.
+=for checklist skip BLEAD-POINT
+
+=head3 monitor CPAN testers for failures
+
+For any release except a BLEAD-POINT: Examine the relevant analysis report(s)
+at http://analysis.cpantesters.org/beforemaintrelease to see how the impending
+release is performing compared to previous releases with regard to building
+and testing CPAN modules.
+
=head3 update perldelta
Get perldelta in a mostly finished state.
There is a tool to semi-automate this process:
- $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
+ $ ./perl -Ilib Porting/bump-perl-version -i 5.10.0 5.10.1
Remember that this tool is largely just grepping for '5.10.0' or whatever,
so it will generate false positives. Be careful not change text like
Be particularly careful with F<INSTALL>, which contains a mixture of
C<5.10.0>-type strings, some of which need bumping on every release, and
some of which need to be left unchanged.
-The line in F<INSTALL> about "is binary incompatible with" requires a
-correct choice of earlier version to declare incompatibility with.
+See below in L<"update INSTALL"> for more details.
+
+For the first RC release leading up to a BLEAD-FINAL release, update the
+description of which releases are now "officially" supported in
+F<pod/perlpolicy.pod>.
When doing a BLEAD-POINT or BLEAD-FINAL release, also make sure the
C<PERL_API_*> constants in F<patchlevel.h> are in sync with the version
After editing, regenerate uconfig.h (this must be run on a system with a
/bin/sh available):
- $ perl regen/uconfig_h.pl
+ $ perl regen/uconfig_h.pl
This might not cause any new changes.
+You may also need to regen opcodes:
+
+ $ ./perl -Ilib regen/opcode.pl
+
+You may have to add stub entries in C<%Module::CoreList::version>,
+C<%Module::CoreList::deprecated> and C<%Module::CoreList::Utils::delta>.
+If so, you must up their version numbers as well.
+
Test your changes:
- $ git clean -xdf # careful if you don't have local files to keep!
- $ ./Configure -des -Dusedevel
- $ make
- $ make test
+ $ git clean -xdf # careful if you don't have local files to keep!
+ $ ./Configure -des -Dusedevel
+ $ make
+ $ make test
Commit your changes:
- $ git status
- $ git diff
- B<review the delta carefully>
+ $ git status
+ $ git diff
+ B<review the delta carefully>
- $ git commit -a -m 'Bump the perl version in various places for 5.x.y'
+ $ git commit -a -m 'Bump the perl version in various places for 5.x.y'
At this point you may want to compare the commit with a previous bump to
see if they look similar. See commit f7cf42bb69 for an example of a
=head3 update INSTALL
-Review and update INSTALL to account for the change in version number;
-in particular, the "Coexistence with earlier versions of perl 5" section.
+Review and update INSTALL to account for the change in version number.
+The lines in F<INSTALL> about "is not binary compatible with" may require a
+correct choice of earlier version to declare incompatibility with. These are
+in the "Changes and Incompatibilities" and "Coexistence with earlier versions
+of perl 5" sections.
Be particularly careful with the section "Upgrading from 5.X.Y or earlier".
The "X.Y" needs to be changed to the most recent version that we are
Check that the copyright years are up to date by running:
- $ ./perl t/porting/copyright.t --now
+ $ ./perl t/porting/copyright.t --now
Remedy any test failures by editing README or perl.c accordingly (search for
the "Copyright"). If updating perl.c, check if the file's own copyright date in
BLEAD-FINAL, MAINT, and RC releases, since blead will already be frozen in
those cases. Create the branch by running
- git checkout -b release-5.xx.yy
+ git checkout -b release-5.xx.yy
=head3 build a clean perl
$ ./Configure -Dusedevel -des && make
+=head3 Check module versions
+
+For each Perl release since the previous release of the current branch, check
+for modules that have identical version numbers but different contents by
+running:
+
+ $ ./perl Porting/cmpVERSION.pl --tag=v5.X.YY
+
+(This is done automatically by F<t/porting/cmp_version.t> for the previous
+release of the current branch, but not for any releases from other branches.)
+
+Any modules that fail will need a version bump, plus a nudge to the upstream
+maintainer for 'cpan' upstream modules.
+
=head3 update Module::CoreList
-Update C<Module::CoreList> with module version data for the new release.
+=head4 Bump Module::CoreList* $VERSIONs
+
+If necessary, bump C<$Module::CoreList::VERSION> (there's no need to do this
+for every RC; in RC1, bump the version to a new clean number that will
+appear in the final release, and leave as-is for the later RCs and final).
+It may also happen that C<Module::CoreList> has been modified in blead, and
+hence has a new version number already. (But make sure it is not the same
+number as a CPAN release.)
+
+C<$Module::CoreList::TieHashDelta::VERSION> and
+C<$Module::CoreList::Utils::VERSION> should always be equal to
+C<$Module::CoreList::VERSION>. If necessary, bump those two versions to match
+before proceeding.
+
+The files to modify are: F<dist/Module-CoreList/lib/Module/CoreList.pm>,
+F<dist/Module-CoreList/lib/Module/CoreList/Utils.pm> and
+F<dist/Module-CoreList/lib/Module/CoreList/TieHashDelta.pm>.
+
+=head4 Update C<Module::CoreList> with module version data for the new release.
Note that if this is a MAINT release, you should run the following actions
from the maint branch, but commit the C<CoreList.pm> changes in
DAPM May 2013 ]
-
F<corelist.pl> uses ftp.funet.fi to verify information about dual-lived
modules on CPAN. It can use a full, local CPAN mirror and/or fall back
on HTTP::Tiny to fetch package metadata remotely.
badly-indexed CPAN modules unrelated to the modules actually in core.
Assuming all goes well, it will update
F<dist/Module-CoreList/lib/Module/CoreList.pm> and possibly
-F<dist/Module-CoreList/lib/Module/CoreList.pod> and/or
F<dist/Module-CoreList/lib/Module/CoreList/Utils.pm>.
Check those files over carefully:
$ git diff dist/Module-CoreList/lib/Module/CoreList.pm
- $ git diff dist/Module-CoreList/lib/Module/CoreList.pod
$ git diff dist/Module-CoreList/lib/Module/CoreList/Utils.pm
-=head4 Bump C<$Module::CoreList::VERSION>
-
-If necessary, bump C<$Module::CoreList::VERSION> (there's no need to do this for
-every RC; in RC1, bump the version to a new clean number that will
-appear in the final release, and leave as-is for the later RCs and final).
-It may also happen that C<Module::CoreList> has been modified in blead, and
-hence has a new version number already. (But make sure it is not the same
-number as a CPAN release.)
-
-Edit the version number in the new C<< 'Module::CoreList' => 'X.YZ' >>
-entry, as that is likely to reflect the previous version number.
-
-=head4 Bump C<$Module::CoreList::TieHashDelta::VERSION>
-
-C<$Module::CoreList::TieHashDelta::VERSION> should always be equal to
-C<$Module::CoreList::VERSION>. Make sure the two versions match before
-proceeding.
-
-Edit the version number in the new
-C<< 'Module::CoreList::TieHashDelta' => 'X.YZ' >> entry, as that is likely to
-reflect the previous version number.
-
-=head4 Bump C<$Module::CoreList::Utils::VERSION>
-
-C<$Module::CoreList::Utils::VERSION> should always be equal to
-C<$Module::CoreList::VERSION>. Make sure the two versions match before
-proceeding.
-
-Edit the version number in the new
-C<< 'Module::CoreList::Utils' => 'X.YZ' >> entry, as that is likely to
-reflect the previous version number.
-
=head4 Bump version in Module::CoreList F<Changes>
-Also edit Module::CoreList's new version number in its F<Changes>
-file.
+Also edit Module::CoreList's new version number in its F<Changes> file.
=head4 Add Module::CoreList version bump to perldelta
=for checklist skip RC
-=head4 Update C<%Module::CoreList::released> and C<CAVEATS>
-
-In addition, if this is a final release (rather than a release candidate):
-
-=over 4
-
-=item *
+=head4 Update C<%Module::CoreList::released>
-Update this version's entry in the C<%released> hash with today's date.
-
-=item *
-
-Make sure that the script has correctly updated the C<CAVEATS> section
-(Note, the C<CAVEATS> section is in
-F<dist/Module-CoreList/lib/Module/CoreList.pod>)
-
-=back
+For any release except an RC: Update this version's entry in the C<%released>
+hash with today's date.
=head4 Commit Module::CoreList changes
(unless this is for MAINT; in which case commit it to blead first, then
cherry-pick it back).
- $ git commit -m 'Update Module::CoreList for 5.x.y' dist/Module-CoreList/lib/Module/CoreList.pm dist/Module-CoreList/lib/Module/CoreList.pod dist/Module-CoreList/lib/Module/CoreList/Utils.pm
+ $ git commit -m 'Update Module::CoreList for 5.x.y' \
+ dist/Module-CoreList/Changes \
+ dist/Module-CoreList/lib/Module/CoreList.pm \
+ dist/Module-CoreList/lib/Module/CoreList/Utils.pm
=head4 Rebuild and test
-Build and test to get the changes into the currently built lib directory and to ensure
-all tests are passing.
+Build and test to get the changes into the currently built lib directory and to
+ensure all tests are passing.
=head3 finalize perldelta
Finalize the perldelta. In particular, fill in the Acknowledgements
section, which can be generated with something like:
- $ perl Porting/acknowledgements.pl v5.15.0..HEAD
+ $ perl Porting/acknowledgements.pl v5.15.0..HEAD
+
+Fill in the "New/Updated Modules" sections now that Module::CoreList is
+updated:
+
+ $ ./perl -Ilib Porting/corelist-perldelta.pl \
+ --mode=update pod/perldelta.pod
+
+For a MAINT release use something like this instead:
+
+ $ ./perl -Ilib Porting/corelist-perldelta.pl 5.020001 5.020002 \
+ --mode=update pod/perldelta.pod
-Fill in the "Updated Modules" section now that Module::CoreList is updated.
+Ideally, also fill in a summary of the major changes to each module for which
+an entry has been added by F<corelist-perldelta.pl>.
Re-read the perldelta to try to find any embarrassing typos and thinkos;
remove any C<TODO> or C<XXX> flags; update the "Known Problems" section
Also, you may want to generate and view an HTML version of it to check
formatting, e.g.
- $ ./perl -Ilib ext/Pod-Html/bin/pod2html pod/perldelta.pod > /tmp/perldelta.html
+ $ ./perl -Ilib ext/Pod-Html/bin/pod2html pod/perldelta.pod > \
+ /tmp/perldelta.html
Another good HTML preview option is http://search.cpan.org/pod2html
$ cp ..../blead/pod/perlhist.pod pod/
$ git commit -m 'sync perlhist from blead' pod/perlhist.pod
-=for checklist skip RC
-
=head3 update perlhist.pod
-I<You MUST SKIP this step for a RC release>
-
Add an entry to F<pod/perlhist.pod> with the release date, e.g.:
David 5.10.1 2009-Aug-06
-Make sure that the correct pumpking is listed in the left-hand column, and
-if this is the first release under the stewardship of a new pumpking, make
-sure that his or her name is listed in the section entitled
-C<THE KEEPERS OF THE PUMPKIN>.
+List yourself in the left-hand column, and if this is the first release
+that you've ever done, make sure that your name is listed in the section
+entitled C<THE KEEPERS OF THE PUMPKIN>.
I<If you're making a BLEAD-FINAL release>, also update the "SELECTED
RELEASE SIZES" section with the output of
static const char * const local_patches[] = {
NULL
+ ,"RC1"
- PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
+ #ifdef PERL_GIT_UNCOMMITTED_CHANGES
+ ,"uncommitted-changes"
+ #endif
Be sure to commit your change:
commits. (Note that for an odd-numbered version, perl will install
itself as C<perl5.x.y>). C<perl -v> will identify itself as:
- This is perl 5, version X, subversion Y (v5.X.Y (v5.X.Z-NNN-gdeadbeef))
+ This is perl 5, version X, subversion Y (v5.X.Y (v5.X.Z-NNN-gdeadbeef))
where 5.X.Z is the latest tag, NNN the number of commits since this tag,
and C<< deadbeef >> commit of that tag.
people a small amount of download time and disk space, which adds
up.
+In order to produce the C<xz> tarball, XZ Utils are required. The C<xz>
+utility is included with most modern UNIX-type operating systems and
+is available for Cygwin. A Windows port is available from
+L<http://tukaani.org/xz/>.
+
Create a tarball. Use the C<-s> option to specify a suitable suffix for
the tarball and directory name:
- $ cd root/of/perl/tree
- $ make distclean
- $ git clean -xdf # make sure perl and git agree on files
- $ git status # and there's nothing lying around
+ $ cd root/of/perl/tree
+ $ make distclean # make sure distclean works
+ $ git clean -xdf # make sure perl and git agree on files
+ # git clean should not output anything!
+ $ git status # and there's nothing lying around
- $ perl Porting/makerel -b -s RC1 # for a release candidate
- $ perl Porting/makerel -b # for a final release
+ $ perl Porting/makerel -bx -s RC1 # for a release candidate
+ $ perl Porting/makerel -bx # for the release itself
This creates the directory F<../perl-x.y.z-RC1> or similar, copies all
the MANIFEST files into it, sets the correct permissions on them, then
tars it up as F<../perl-x.y.z-RC1.tar.gz>. With C<-b>, it also creates a
-C<tar.bz2> file.
+C<tar.bz2> file. The C<-x> also produces a C<tar.xz> file.
If you're getting your tarball suffixed with -uncommitted and you're sure
your changes were all committed, you can override the suffix with:
=head4 Copy the tarball to a web server
-Copy the tarballs (.gz and possibly .bz2) to a web server somewhere you
+Copy the tarballs (.gz and possibly .bz2 and .xz) to a web server somewhere you
have access to.
=head4 Download the tarball to another machine
$ ./Configure -des && make all test
+ # Or for a development release:
+ $ ./Configure -Dusedevel -des && make all test
+
=head4 Run the test harness and install
Check that the test harness and install work on each test machine:
$ bin/cpan
+ # Or, perhaps:
+ $ bin/cpan5.xx.x
+
=head4 Install the Inline module with CPAN and test it
Try installing a popular CPAN module that's reasonably complex and that
has dependencies; for example:
- CPAN> install Inline
+ CPAN> install Inline::C
CPAN> quit
Check that your perl can run this:
on dromedary. I<Remember>: if your upload is partially successful, you
may need to contact a PAUSE administrator or even bump the version of perl.
-Upload both the .gz and .bz2 versions of the tarball.
+Upload the .gz, .xz, and .bz2 versions of the tarball.
Do not proceed any further until you are sure that your tarballs are on CPAN.
Check your authors directory www.cpan.org (the globally balanced "fast"
static const char * const local_patches[] = {
NULL
- ,"RC1"
- PERL_GIT_UNPUSHED_COMMITS /* do not remove this line */
+ #ifdef PERL_GIT_UNCOMMITTED_CHANGES
+ ,"uncommitted-changes"
+ #endif
Be sure to commit your change:
Merge the (local) release branch back into master now, and delete it.
- git checkout blead
- git pull
- git merge release-5.xx.yy
- git push
- git branch -d release-5.xx.yy
+ git checkout blead
+ git pull
+ git merge release-5.xx.yy
+ git push
+ git branch -d release-5.xx.yy
+
+Note: The merge will create a merge commit if other changes have been pushed
+to blead while you've been working on your release branch. Do NOT rebase your
+branch to avoid the merge commit (as you might normally do when merging a
+small branch into blead) since doing so will invalidate the tag that you
+created earlier.
=head3 publish the release tag
=head3 update epigraphs.pod
Add your quote to F<Porting/epigraphs.pod> and commit it.
-Your release announcement will probably not have reached the web-visible
-archives yet, so you won't be able to include the customary link to the
-release announcement yet.
+You can include the customary link to the release announcement even before your
+message reaches the web-visible archives by looking for the X-List-Archive
+header in your message after receiving it back via perl5-porters.
=head3 blog about your epigraph
=for checklist skip RC
+=head3 Release schedule
+
+I<You MUST SKIP this step for RC>
+
+Tick the entry for your release in F<Porting/release_schedule.pod>.
+
+=for checklist skip RC
+
=head3 Module::CoreList nagging
I<You MUST SKIP this step for RC>
After bumping the version, follow the section L<"update INSTALL"> to
ensure all version number references are correct.
+(Note: The version is NOT bumped immediately after a MAINT release in order
+to avoid confusion and wasted time arising from bug reports relating to
+"intermediate versions" such as 5.20.1-and-a-bit: If the report is caused
+by a bug that gets fixed in 5.20.2 and this intermediate version already
+calls itself 5.20.2 then much time can be wasted in figuring out why there
+is a failure from something that "should have been fixed". If the bump is
+late then there is a much smaller window of time for such confusing bug
+reports to arise. (The opposite problem -- trying to figure out why there
+*is* a bug in something calling itself 5.20.1 when in fact the bug was
+introduced later -- shouldn't arise for MAINT releases since they should,
+in theory, only contain bug fixes but never regressions.))
+
=head3 clean build and test
Run a clean build and test to make sure nothing obvious is broken.
In particular, F<Porting/perldelta_template.pod> is intentionally exempted
from podchecker tests, to avoid false positives about placeholder text.
However, once it's copied to F<pod/perldelta.pod> the contents can now
-cause test failures. Problems should resolved by doing one of the
+cause test failures. Problems should be resolved by doing one of the
following:
=over
Copy the perldelta.pod for this release into blead; for example:
- $ cd ..../blead
- $ cp -i ../5.10.x/pod/perldelta.pod pod/perl5101delta.pod # for example
- $ git add pod/perl5101delta.pod
+ $ cd ..../blead
+ $ cp -i ../5.10.x/pod/perldelta.pod pod/perl5101delta.pod # for example
+ $ git add pod/perl5101delta.pod
+
+Don't forget to set the NAME correctly in the new file (e.g. perl5101delta
+rather than perldelta).
Edit F<pod/perl.pod> to add an entry for the file, e.g.:
Make sure any recent F<pod/perlhist.pod> entries are copied to
F<perlhist.pod> on blead. e.g.
- 5.8.9 2008-Dec-14
+ 5.8.9 2008-Dec-14
=head3 bump RT version number
open up any ticket for modification and check the drop downs next to the
C<Perl Version> and C<Fixed In> labels.
-Here, try this link: L<https://rt.perl.org/rt3/Ticket/Modify.html?id=10000>
+Here, try this link: L<https://rt.perl.org/Ticket/Modify.html?id=10000>
If the new version is not listed there, send an email to C<perlbug-admin at
perl.org> requesting this.
=head2 Building a release - the day after
-=head3 link announcement in epigraphs.pod
-
-Add, to your quote to F<Porting/epigraphs.pod>, a link to the release
-announcement in the web-visible mailing list archive. Commit it.
-
=for checklist skip BLEAD-FINAL, MAINT, RC
=head3 update Module::CoreList
$ ./perl -Ilib Porting/corelist.pl cpan
-This will update F<dist/Module-CoreList/lib/Module/CoreList.pm>,
-F<dist/Module-CoreList/lib/Module/CoreList.pod> and
+This will update F<dist/Module-CoreList/lib/Module/CoreList.pm> and
F<dist/Module-CoreList/lib/Module/CoreList/Utils.pm> as it did before,
but this time adding new sections for the next BLEAD-POINT release.
Run
- $ ./perl -Ilib -MModule::CoreList -le 'print Module::CoreList->find_version($]) ? "ok" : "not ok"'
+ $ ./perl -Ilib -MModule::CoreList \
+ -le 'print Module::CoreList->find_version($]) ? "ok" : "not ok"'
and check that it outputs "ok" to prove that Module::CoreList now knows
about blead's current version.
https://perl5.git.perl.org / perl5.git / blobdiff