Automatic close of bugs for retired packages?
by Pavel Raiskup
I today tried to mimic something that random Fedora user can do, and I
submitted bug against one of our long-time retired components. I haven't
been warned at all that the package is dead.
As user, it is easy to pick a wrong component when filling a bug - but the
problem with orphaned/retired packages is that nobody listens there
usually. Only 'Orphan Owner <extras-orphan(a)fedoraproject.org>'.
Should such reports be kindly closed automatically by some bot, so user
can reopen against different component? Or should we drop the component
from bugzilla?
Pavel
4 years, 1 month
Ideas and proposal for removing changelog and release fields from
spec file
by Pierre-Yves Chibon
Good Morning Everyone,
This topic has already been discussed a few times over the past month, but Adam
Saleh, Nils Philippsen and myself have had the opportunity to invest some time
on it with the hope of making the packager's life simpler as well as making it
easier to build automation around our package maintenance.
We have investigated a few ideas, the full list with their pros and cons can be
found in this document: https://hackmd.io/8pSwJidhTYel9euQqMEKpw?viev
If you have any questions about some of these, please ask them, we'll be happy
to answer them and potentially complete this document.
For both the release and the changelog fields we believe using RPM macros would
satisfy the requirements we have for opting-in/out:
- You can easily opt-in by using the macros
- You can easily opt-out by removing the macros from your spec file
For the changelog, we believe we have a potential good solution:
- The changelog will be automatically generated using an external `changelog`
file as well as the commit history
- When you opt-in, you will simply move the existing changelog to an external
file `changelog`, which is placed in the dist-git repo and add the
appropriate macro.
- Upon building, the macro will generate the changelog using all the commits
of the repo up to the last commit touching the `changelog` file. Of all
these commits it will only consider the commits following these rules:
- There are generally two approaches regarding what to include by default:
1. commits touching only the `sources`, `.gitignore`, `dead.package`
files, `tests` folder will be ignored by default, i.e. a blacklist
2. only commits touching the spec file or patches will be included by
default, i.e. a whitelist
==> Which approach do you think is better/will work in most cases?
- empty commits (not touching any files) will be included on the assumption
that this is their purpose
- commits containing "magic keyword" (#changelog_exclude,
#changelog_include?) will be ignored or included as the case may be
- Finally the content of the changelog file specified will be appended to the
changelog generated from the git history
If you wanted to edit the changelog, you would:
- Generate the changelog locally via a command like:
`fedpkg generate-changelog > changelog`
- Edit `changelog` as desired
- Commit and push the changes
Since the macro will only consider the commits up to the first commit touching
`changelog` (in other words, the macro will only consider the commits after this
one) and include `changelog` file as is, your edits will appear in the RPM
changelog as you want.
One thing to note is that rebuilds from the same commit will have the same
%changelog, they will not get a new entry. If you want a new changelog entry,
you have to create a new commit with the desired changelog entry as commit
message (the commit itself can be empty).
However, for the release field, we are struggling a little bit more, two options
are more appealing to us:
A) The release field is automatically generated using two elements:
- the number of commits at this version
- the number of builds at this commit
- the dist-tag being added after them
The release field would thus look like:
``<number of commit at version>.<number of build at commit>%{dist}``
So we could have: (A, B, C and D being different commits)
A -- version: 0.9 -- release: ?
|
B -- version: 1.0 -- release: 1.0
|
C -- version: 1.0 -- release: 2.0
|
D -- version: 1.1 -- release: 1.0
A rebuild of the commit D, would lead to a release 1.1 (assuming the first one
succeeded)/
Pros:
- Easy to replicate locally
- Every changelog entry can be mapped to a `version-release` (No changes to the
packaging guidelines)
- Allows triggering two builds from the same commit without any manual change
(simplifies mass-rebuilds)
- Easy to link a certain build with a specific commit
- Easy to “guess” the next release value before triggering the build
Cons:
- Old packages which are no longer receiving upstream releases may need
special care (for example if they are at the release -48 but only had 45
commits leading to this)
- Relies on information from the build system for the build number (but can
be closely simulated locally since the <n_build> info is only used for
rebuilds)
- Upgrade path may be problematic if Fn is upgraded to version X with one
commit while Fn-1 is upgrade to version X with 2 commits (or more)
B) The release field is automatically generated taking existing builds in all
current Fedora releases (ie: rawhide, Fn, Fn-1...) into account. This means for
builds of the same epoch:version, find a new release that (if at all possible)
ensures upgradability from older Fedora versions to newer ones, adhering to the
structure of a release tag documented in the Versioning Guidelines[1]. Going
from the (RPM-wise) "latest build" that the new one should surpass, this can
mean bumping in the front (`pkgrel`) or the back (`minorbump`).
This allows packages from "very stable" upstreams who haven't released in years
to still benefit from automatically generated releases.
The following examples would use a macro for the release field as outlined in a
separate document[2].
Example #1 ("normal" release progression):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in F31: 1.0-2.fc32
Example #2 ("hotfix" in an older release, selected by an alternative macro (or
option) in the spec file):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in F30: 1.0-1.fc30.1
Example #3 (pre-release, selected by an alternative macro (or option) in the
spec file):
Rawhide has: 2.0-1.fc32
F31 has: 1.0-1.fc31
F30 has: 1.0-1.fc30
Next release in Rawhide: 3.0-0.1.20200224git1234abcd
Pros:
- Allows triggering two builds from the same commit without manual
intervention
- Emulates what many maintainers do manually today for most use cases
- Can cater for pre-releases (e.g.: by offering different macros or macro
options for the different use cases)
Cons:
- Needs the build system for information about builds in this and other Fedora
versions
- Not easy to reproduce locally because we don’t have machine-consumable
knowledge about other builds in e.g. the dist-git repo
- Does not allow to generate changelog entries with `version-release`
information for all commits (and this will require a change in our packaging
guidelines)
So these are the results of our current investigations, we are very much eager
to get your feedback on them and even more eager if you have ideas on how to
approach/solve some of the challenges mentioned here.
Looking forward for the discussion,
Pierre
For Adam, Nils and myself
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/Versioning/
[2]: https://hackmd.io/kuXOPe74RfepuztBz7pBsg
4 years, 1 month
Re: Non-responsive maintainer: pocock
by Dakota Williams
On 2/26/20 6:59 PM, Daniel Pocock wrote:
>
>
> On 26/02/2020 22:56, Dakota Williams wrote:
>> On 2/24/20 5:57 PM, Daniel Pocock wrote:
>>>
>>>
>>> On 24/02/2020 20:47, Dakota Williams wrote:
>>>> Does anyone know how to contact maintainer pocock?
>>>>
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1806708
>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1790674
>>>
>>>
>>> Like most developers, I have a backlog of things to deal with and I try
>>> to coordinate fixes for packaging issues into the right part of the
>>> release cycle
>>>
>>
>> Would you like help? I'd be willing to be a co-maintainer to make the
>> branch.
>
> Yes, I would welcome help with these packages
>
> But there is also an increasing problem of making decisions about trust
>
> In the case of developers who I haven't met or worked with, I don't
> really know how to proceed
>
> I've seen several extraordinary examples of developers doing things that
> undermine my confidence in them over the last couple of years. The
> fighting within GNU and FSF right now is the latest iteration of that.
>
> Now, whenever I receive a request from somebody I don't know, there is
> an extra effort for me to decide how to proceed.
>
> Maybe I can simply resign from maintaining the asio package and then opt
> out of the process of choosing a new maintainer.
>
> Please don't take this personally: it is a reflection of the overall
> state of free software communities today.
>
I don't know about the situation with the GNU project and the FSF, but
if there's something you'd like me to do to prove trust, I could do it.
4 years, 1 month
Build into < Rawhide side tag fails with "Package ... has already
been built"
by Richard W.M. Jones
I built ocaml-4.10.0-1.fc33 yesterday.
Now I want to build ocaml-4.10.0-1.fc32 into a side tag today, but
builds fail with:
$ fedpkg request-side-tag --base-tag f32-build
Side tag 'f32-build-side-19863' (id 19863) created.
Use 'fedpkg build --target=f32-build-side-19863' to use it.
Use 'koji wait-repo f32-build-side-19863' to wait for the build repo to be generated.
$ fedpkg build --target=f32-build-side-19863
Could not execute build: Package ocaml-4.10.0-1 has already been built
Note: You can skip this check with --skip-nvr-check. See help for more info.
This is wrong isn't it?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
4 years, 1 month
Generate list of my packages
by Orion Poplawski
Can someone point me to a way to generate a list of non-retired packages
that I am a maintainer on? Thanks.
Hunting around for a "pagure cli" doesn't bring up much that seems active.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
4 years, 1 month
Fedora 32 compose report: 20200229.n.0 changes
by Fedora Branched Report
OLD: Fedora-32-20200228.n.0
NEW: Fedora-32-20200229.n.0
===== SUMMARY =====
Added images: 0
Dropped images: 0
Added packages: 1
Dropped packages: 0
Upgraded packages: 0
Downgraded packages: 0
Size of added packages: 1.09 MiB
Size of dropped packages: 0 B
Size of upgraded packages: 0 B
Size of downgraded packages: 0 B
Size change of upgraded packages: 0 B
Size change of downgraded packages: 0 B
===== ADDED IMAGES =====
===== DROPPED IMAGES =====
===== ADDED PACKAGES =====
Package: rust-zram-generator-0.1.2-2.fc32
Summary: Systemd unit generator for zram devices
RPMs: zram-generator
Size: 1.09 MiB
===== DROPPED PACKAGES =====
===== UPGRADED PACKAGES =====
===== DOWNGRADED PACKAGES =====
4 years, 1 month
Fedora-32-20200229.n.0 compose check report
by Fedora compose checker
No missing expected images.
Failed openQA tests: 21/171 (x86_64), 1/2 (arm)
New failures (same test not failed in Fedora-32-20200228.n.0):
ID: 529891 Test: x86_64 Workstation-live-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/529891
ID: 529940 Test: x86_64 universal install_sata
URL: https://openqa.fedoraproject.org/tests/529940
Old failures (same test failed in Fedora-32-20200228.n.0):
ID: 529867 Test: x86_64 Server-dvd-iso modularity_tests
URL: https://openqa.fedoraproject.org/tests/529867
ID: 529869 Test: x86_64 Server-dvd-iso install_updates_nfs
URL: https://openqa.fedoraproject.org/tests/529869
ID: 529917 Test: x86_64 KDE-live-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/529917
ID: 529924 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload
URL: https://openqa.fedoraproject.org/tests/529924
ID: 529933 Test: x86_64 Silverblue-dvd_ostree-iso desktop_background
URL: https://openqa.fedoraproject.org/tests/529933
ID: 529947 Test: x86_64 universal install_simple_encrypted@uefi
URL: https://openqa.fedoraproject.org/tests/529947
ID: 529950 Test: x86_64 universal install_cyrillic_language
URL: https://openqa.fedoraproject.org/tests/529950
ID: 529952 Test: x86_64 universal install_arabic_language
URL: https://openqa.fedoraproject.org/tests/529952
ID: 529953 Test: x86_64 universal install_asian_language
URL: https://openqa.fedoraproject.org/tests/529953
ID: 529962 Test: x86_64 universal install_software_raid
URL: https://openqa.fedoraproject.org/tests/529962
ID: 529963 Test: x86_64 universal install_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/529963
ID: 529970 Test: x86_64 universal install_european_language
URL: https://openqa.fedoraproject.org/tests/529970
ID: 529975 Test: x86_64 universal install_blivet_software_raid
URL: https://openqa.fedoraproject.org/tests/529975
ID: 529978 Test: x86_64 universal install_blivet_software_raid@uefi
URL: https://openqa.fedoraproject.org/tests/529978
ID: 529991 Test: x86_64 universal install_simple_encrypted
URL: https://openqa.fedoraproject.org/tests/529991
ID: 530003 Test: x86_64 universal upgrade_2_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/530003
ID: 530010 Test: x86_64 universal upgrade_server_domain_controller
URL: https://openqa.fedoraproject.org/tests/530010
ID: 530011 Test: x86_64 universal install_iscsi
URL: https://openqa.fedoraproject.org/tests/530011
ID: 530016 Test: x86_64 universal upgrade_2_realmd_client
URL: https://openqa.fedoraproject.org/tests/530016
ID: 530017 Test: x86_64 universal upgrade_realmd_client
URL: https://openqa.fedoraproject.org/tests/530017
Soft failed openQA tests: 13/171 (x86_64)
(Tests completed, but using a workaround for a known bug)
New soft failures (same test not soft failed in Fedora-32-20200228.n.0):
ID: 529846 Test: x86_64 Server-boot-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/529846
Old soft failures (same test soft failed in Fedora-32-20200228.n.0):
ID: 529845 Test: x86_64 Server-boot-iso install_default
URL: https://openqa.fedoraproject.org/tests/529845
ID: 529848 Test: x86_64 Server-dvd-iso install_vncconnect_client
URL: https://openqa.fedoraproject.org/tests/529848
ID: 529850 Test: x86_64 Server-dvd-iso install_default@uefi
URL: https://openqa.fedoraproject.org/tests/529850
ID: 529853 Test: x86_64 Server-dvd-iso install_default_upload
URL: https://openqa.fedoraproject.org/tests/529853
ID: 529854 Test: x86_64 Server-dvd-iso install_vnc_client
URL: https://openqa.fedoraproject.org/tests/529854
ID: 529874 Test: x86_64 Server-dvd-iso server_realmd_join_kickstart
URL: https://openqa.fedoraproject.org/tests/529874
ID: 529937 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud
URL: https://openqa.fedoraproject.org/tests/529937
ID: 529946 Test: x86_64 universal install_serial_console
URL: https://openqa.fedoraproject.org/tests/529946
ID: 529964 Test: x86_64 universal install_anaconda_text
URL: https://openqa.fedoraproject.org/tests/529964
ID: 529999 Test: x86_64 universal upgrade_2_kde_64bit
URL: https://openqa.fedoraproject.org/tests/529999
ID: 530002 Test: x86_64 universal upgrade_2_server_64bit
URL: https://openqa.fedoraproject.org/tests/530002
ID: 530009 Test: x86_64 universal upgrade_server_64bit
URL: https://openqa.fedoraproject.org/tests/530009
Passed openQA tests: 121/171 (x86_64)
New passes (same test not passed in Fedora-32-20200228.n.0):
ID: 529910 Test: x86_64 KDE-live-iso apps_startstop
URL: https://openqa.fedoraproject.org/tests/529910
ID: 530004 Test: x86_64 universal upgrade_desktop_64bit
URL: https://openqa.fedoraproject.org/tests/530004
Skipped non-gating openQA tests: 17 of 173
Installed system changes in test x86_64 Server-dvd-iso install_default@uefi:
1 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-7BF6\x2d2273.service
1 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-513C\x2dEBA9.service
Previous test data: https://openqa.fedoraproject.org/tests/529559#downloads
Current test data: https://openqa.fedoraproject.org/tests/529850#downloads
Installed system changes in test x86_64 Everything-boot-iso install_default@uefi:
2 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-776B\x2d2EAE.service, systemd-fsck@dev-disk-by\x2duuid-9f4a0658\x2dd0f9\x2d4649\x2d98ad\x2df68d59bee877.service
2 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-3e5c9c06\x2d1898\x2d44ff\x2dbf0a\x2da1423236a42a.service, systemd-fsck(a)dev-disk-by\x2duuid-524E\x2d978D.service
Previous test data: https://openqa.fedoraproject.org/tests/529596#downloads
Current test data: https://openqa.fedoraproject.org/tests/529887#downloads
Installed system changes in test x86_64 Everything-boot-iso install_default:
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-8b4c9c84\x2dfa8a\x2d468f\x2d8865\x2de82aa3975ea5.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-c92b56d6\x2d9e70\x2d4b3a\x2dbb39\x2d519d15953feb.service
Previous test data: https://openqa.fedoraproject.org/tests/529597#downloads
Current test data: https://openqa.fedoraproject.org/tests/529888#downloads
Installed system changes in test x86_64 Workstation-live-iso install_default@uefi:
Used swap changed from 7 MiB to 1 MiB
2 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-19d670d5\x2d0831\x2d4494\x2d86c0\x2d242b543742b7.service, systemd-fsck(a)dev-disk-by\x2duuid-7391\x2dBB16.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-494C\x2dADAC.service, systemd-fsck@dev-disk-by\x2duuid-dbfae847\x2d58c3\x2d4883\x2d95de\x2d5c31a280090c.service
Previous test data: https://openqa.fedoraproject.org/tests/529599#downloads
Current test data: https://openqa.fedoraproject.org/tests/529890#downloads
Installed system changes in test x86_64 KDE-live-iso install_default@uefi:
2 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-6d38722b\x2d4712\x2d4f16\x2d8daa\x2df6e01a950431.service, systemd-fsck(a)dev-disk-by\x2duuid-82B5\x2dE53D.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-5563\x2d49BC.service, systemd-fsck@dev-disk-by\x2duuid-80eb3f6d\x2d031f\x2d4f74\x2dba34\x2dff3689998dd6.service
Average CPU usage changed from 11.50952381 to 23.92857143
Previous test data: https://openqa.fedoraproject.org/tests/529617#downloads
Current test data: https://openqa.fedoraproject.org/tests/529908#downloads
Installed system changes in test x86_64 KDE-live-iso install_default_upload:
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-d5a3720b\x2de139\x2d4ed4\x2dbf24\x2d65455aba52e2.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-4a546216\x2dd6cb\x2d427c\x2d9548\x2dd9c997805292.service
System load changed from 1.51 to 1.28
Previous test data: https://openqa.fedoraproject.org/tests/529618#downloads
Current test data: https://openqa.fedoraproject.org/tests/529909#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default@uefi:
Used swap changed from 2 MiB to 5 MiB
2 services(s) added since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-31D6\x2dA4C2.service, systemd-fsck@dev-disk-by\x2duuid-51d39515\x2deee4\x2d4ae4\x2d9dce\x2d11625dc35358.service
2 services(s) removed since previous compose: systemd-fsck(a)dev-disk-by\x2duuid-8EDB\x2dE06B.service, systemd-fsck@dev-disk-by\x2duuid-b9e247f5\x2d7893\x2d42df\x2dbed1\x2d2ced504c79fb.service
System load changed from 0.45 to 0.78
Previous test data: https://openqa.fedoraproject.org/tests/529635#downloads
Current test data: https://openqa.fedoraproject.org/tests/529926#downloads
Installed system changes in test x86_64 Silverblue-dvd_ostree-iso install_default_upload:
1 services(s) added since previous compose: systemd-fsck@dev-disk-by\x2duuid-523a3e8f\x2db378\x2d4d87\x2d9757\x2d589bf822b6ef.service
1 services(s) removed since previous compose: systemd-fsck@dev-disk-by\x2duuid-5e946d66\x2d629c\x2d4f45\x2da7a8\x2d2cb176d75520.service
System load changed from 0.72 to 0.46
Previous test data: https://openqa.fedoraproject.org/tests/529636#downloads
Current test data: https://openqa.fedoraproject.org/tests/529927#downloads
Installed system changes in test x86_64 universal install_package_set_kde:
1 services(s) added since previous compose: dbus-:1.6-org.freedesktop.problems@0.service loaded active running dbus-:1.6-org.freedesktop.problems@0.service
1 services(s) removed since previous compose: dbus-:1.7-org.freedesktop.problems@0.service loaded active running dbus-:1.7-org.freedesktop.problems@0.service
System load changed from 1.07 to 0.61
Previous test data: https://openqa.fedoraproject.org/tests/529704#downloads
Current test data: https://openqa.fedoraproject.org/tests/529995#downloads
x86_64 Everything-boot-iso memory_check@uefi peak memory: 1125MiB (100% of previous compose peak)
x86_64 Everything-boot-iso memory_check peak memory: 1141MiB (102% of previous compose peak)
--
Mail generated by check-compose:
https://pagure.io/fedora-qa/check-compose
4 years, 1 month
Let's talk about Fedora in the '20s!
by Matthew Miller
Hi everyone! Since it's a new year and a new decade [*], it seems like a
good time to look forward and talk about what we want the Fedora Project to
be in the next five and even ten years. How do we take the awesome
foundation we have now and build and grow and make something that continues
to thrive and be useful, valuable, and fun?
[My thoughts below. Feel free to respond to those, or cut here and start
your own!]
I see three big themes I think we need to tackle.
First, I'd like to see Fedora become more of an "operating system factory".
The direction we took with the Fedora Editions has been a success — Fedora's
general growth and popularity bears that out. But now it's a good time to
re-examine the positioning. The Editions were meant to fit big, broad
use-cases defined by (at the time) the Fedora Board and FESCo. Since then,
everything's become more complicated, with Atomic and then CoreOS, and IoT,
and Silverblue — and we never really found a satisfying way to present the
work of our other desktop SIGs.
So, I think we should revisit the top-level design for Get Fedora. I'm not a
designer and I don't have a particular answer in mind, but I think we should
try an approach which showcases all of our different outputs in some way
which also makes it easy for new users to find the right solution quickly
(and to understand the support options and expecations for their choice).
In support of that, I'd like to also have that page steer people into
tooling for creating new spins —- and I'd like to see us invest in and
rebuild the spin creation processes. (Particularly, I'd like spin releases
to be decoupled from the main OS release, and for those to be self-service
by their SIGs with minimal rel-eng involvement needed.)
Second, we need to figure out how to work with language-native packaging
formats and more directly with code that's distributed in git repos rather
than as tarball releases.
We're not adding meaningful end-user value by manually repackaging these in
our own format. We _do_ add value by vetting licenses and insuring
availability and consistency, but I think we can find better ways to do
that. I think the "source git" project is an interesting step here.
These two things are linked. I want application developers to find Fedora a
convenient and easy way to get their software to users. Pulling from the
Fedora container and flatpak registries should give the same feeling of
trust and safety that installing and RPM from our repos does today. We're
not going to get either of those things with the system we have now. Our
value is unclear to both developers and end users, so we just get left out.
If we don't address this, we're ultimately going to be reduced to a
barely-differentiated implementation of a base OS that no one really cares
about, not the rich software ecosystem we've always aspired to build.
Third, we really need to continue to grow the project as more than coding
and packaging.
Obviously that engineering work is the core of the project
(and we should grow that too!), but it doesn't matter what we build if no
one can find it or find how to use it. We need to feed and grow our
documentation and support communities around the world. Marie (our new
FCAIC, in case you missed that!) and I have been talking about this, and we
hope to really expand the $150-mini-event Mindshare program in the next
year, and hopefully build on that further in the coming ones.
Those are my thoughts. What other challenges and opportunities do you see,
and what would you like us to focus on?
----
[*] https://www.xkcd.com/2249/
(Also, on a more personal note: I've been SUPER swamped with email. If you
sent me something over the holiday break and I didn't answer, it's not you,
it's me. If I dropped something important, please send again. I'm declaring
email bankrupcy and starting the year fresh.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4 years, 1 month