trying to reach broader audience and get some feedback, hopefully resolving the issue concerning Fedora Developer Portal. Specifically its content- C# IDEs (generated from its github source).
Changes requesting a recommendation of proprietary software on Fedora are postponed from release. Full thread is on our ML.
Note that the FDP is aimed to help developers *on* Fedora, using tools not necessarily packaged *in* Fedora. And it's not a documentation.
Thanks for feedback!
----- Original Message -----
> From: "Radka Janekova" <radka.janek(a)redhat.com>
> To: "Pavel Valena" <pvalena(a)redhat.com>
> Cc: "Justin W. Flory" <jflory7(a)gmail.com>, developer-portal(a)lists.fedoraproject.org, "Brian Exelbierd"
> Sent: Monday, November 20, 2017 7:00:33 PM
> Subject: [Developer-portal] Re: FDP release and statistics 10/2017: C# IDEs and Mono updates; Python, Docker and
> Haskell fixes
> Since this thread didn't move anywhere I would appreciate being able to refer
> people to the page again, with the original content. The current state is a
> misleading lie.
> If anyone would like to discuss this further, I suggest raising a ticket or
> complaint with Council, to determine or clarify what content should be on
> the developer portal - it seems unclear. Until such decision is made, I am
> strongly against anything being censored for any reason.
like with any OpenSource project, your PR does not have to be merged and amendments can be made to your changes. Please be patient while we try to resolve this.
> Radka Janeková
> .NET & OpenShift Engineer, Red Hat
> IRC: radka | Freenode: Rhea
> On Mon, Nov 6, 2017 at 11:06 AM, Pavel Valena < pvalena(a)redhat.com > wrote:
> > On Sun, Nov 5, 2017 at 6:40 AM, Neal Gompa < ngompa13(a)gmail.com > wrote:
> > > Fedora Developer Portal is showing how to use tools in Fedora to do
> > > awesome
> > > things. And to date, none of the JetBrains IDEs (even my favored PyCharm,
> > > which is open source) are available in Fedora. PyCharm is not mentioned
> > > in
> > > the Fedora Developer Portal for Python for exactly that reason. Neither
> > > is
> > > IntelliJ IDEA for Java. Same goes for Android development using Eclipse
> > > or
> > > Android Studio, as neither the Android SDK nor the associated IDE/IDE
> > > components are packaged in Fedora.
> I'd like to stress once more, that the advertised software ('mentioned') does
> not have to be *in* Fedora.
> Provided it works (enhances developers' experience) on Fedora, and is
> reasonably packaged/distributed. F.e. 'copr', RPM Fusion, PyPI, etc..
> Although packaging the recommended SW into Fedora is preferred, it doesn't
> necessarily mean it's a good recommendation for a developer.
For a long time we have an issue with readiness of Release notes for a
release. To solve this issue me and @bex met and we came up with a
proposal for a Changes Policy  addendum. As I would like to have
people from different teams (Devel, QA, Doc, Trans, ...) to review
this proposal and I do not want to have the discussion scatter over
sever mailing lists I opened a FESCo ticket  describing the Release
notes process we agreed on. If anyone is interested in this topic,
please contribute to the ticket.
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
Hi fedora-release maintainers and fellow developers,
The fedora-release package contains stuff that is tied to each Fedora
version and changes slowly, and it also contains the preset files for
systemd units, which change fairly often (a few requests per month).
Currently fedora-release has a fairly complicated maintenance
structure, with an "upstream" project at https://pagure.io/fedora-release
and "downstream" at https://src.fedoraproject.org/rpms/fedora-release.
"upstream" is only used for this single "downstream", and in fact changes
made in packaging "downstream" are sometimes lost when the next version
of "upstream" is imported.
I propose simplifying this and opening fedora-release releases to more
1. Let's drop "upstream" at https://pagure.io/fedora-release and
make the "downstream" the canonical source of the package,
2. Allow pull requests in src.fp.o/fedora-release,
3. With 1 and 2. implemented, it'll be easier for any fedora maintainer
to suggest improvements to the package (through PRs) and it'll also
be possible for proven packagers to do changes without stepping on
the toes of the maintainers and interfering with the separate "upstream"
repo. Let's agree to allow pps to update fedora-release as necessary
when the main maintainers are busy.
4. Release fedora-release quickly, so that when a preset change request
comes in , it can be handled in a few days or a week. (Having such
requests hanging usually blocks changes to the package in question,
so it's important to have the resolution of the preset status without
To implement this, not much action is required, mostly acceptance of the
maintainers to amend and open up the process. Concrete steps that do need
to be taken:
1. tweak https://src.fedoraproject.org/rpms/fedora-release/settings
to allow PRs
2. push a commit to "upstream" that that repo is dead
3. make a README for "downstream" that PRs can be submitted and outline
I'll be happy to submit the PRs for 2 and 3. I'll also be applying for
co-maintainership in the fedora-release package, because I want to push
those changes forward.
What do you think?
It turns out that the "Rain Date" concept is confusing to some people
(particularly where that idiom is not familiar). I propose that for F28
and onward, we keep the basic concept, but ditch that term. Instead, we
* Release Date Target 1
* Release Date Target 2 (a week later).
As now, these will exist for both Beta and Final, and final will only
be pushed back if Beta Target 2 is missed.
Then (and also new), if the Beta does slip past Target 2, we add a new
"Target 3". If Beta slips to Target 3, Final slips to Target 2 (and we
don't yet add a Target 3). If beta slips to Target 4, we cross off
Final Target 2 and add Final Target 3.
I'm happy to bikeshed on calling "Target 1" something like "Early
Target". Langdon suggested just dropping any adjectives (hence just "1"
and "2", which works, but I want to balance between a feeling of "not
really important because it's a fake target" (bad!) and journalists
reporting "Fedora slipped once again, of course, because they're always
late", no matter how much we explain the process to them.
Fedora Project Leader