PkgDB and the ArbitraryBranching Change
by Ralph Bean
Hello,
As part of the Factory 2.0 and Modularity efforts[1], we’ve been
developing a plan to migrate to an “arbitrary” branching model from
our current model of one branch per release (as had been discussed at
Flock and DevConf[2]).
The main motivation behind this is to enable functionality required by
Modularity[3] and to ultimately reduce some package maintenance
burden. For some packages, it makes sense to have only a single branch
that feeds into multiple releases. For other packages, it makes sense
to have multiple branches which correlate with multiple upstream minor
releases. Today, our source branches are tied to the distro release,
via PkgDB. We want to decouple that and use modules to put it all
back together again.
To make this happen requires significant infrastructure changes. Our
proposed plan[4] is to decommission PkgDB entirely and to replace it
with a combination of PDC[5] and pagure over dist-git. (Tangentially,
getting pagure over dist-git to play nicely with PkgDB was a
challenge. This route gets us to a pull-request interface for spec
files quicker.)
We have brought this Change to FESCo[6][7][8] who expressed general
agreement on the project but also concern that the community may be
caught by off guard by the removal of PkgDB. As part of this change,
we have proposed a timeline[9] that outlines the steps we plan to take
to actually proceed with the migration. Please review that if you have
time and provide feedback. We are most concerned with missing
scripts/tools that may rely on PkgDB’s API. If you can think of any
that we may have overlooked, please let us know and we will add it to
the timeline!
We are meeting again with FESCo next Friday, June 2nd, where a
decision will be made on the Change. Any feedback before that would be
greatly appreciated.
Ralph and Matt,
From the so-called Factory 2.0 team
[1] https://fedoraproject.org/wiki/Infrastructure/Factory2
[2] https://youtu.be/5gqccjyjwFk?t=26m27s
[3] https://docs.pagure.org/modularity/
[4] https://fedoraproject.org/wiki/Infrastructure/Factory2/Focus/ArbitraryBra...
[5] https://fedoraproject.org/wiki/Changes/ProductDefinitionCenter
[6] https://fedoraproject.org/wiki/Changes/ArbitraryBranching
[7] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-19-16.00.html
[8] https://meetbot.fedoraproject.org/teams/fesco/fesco.2017-05-26-16.00.html
[9] https://fedoraproject.org/wiki/Changes/ArbitraryBranching#Timeline
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
1 month
Two more concrete ideas for what a once-yearly+update schedule would
look like
by Matthew Miller
Trying to make this idea a little more concrete. Here's two suggestions
for how it might work. These are strawman ideas -- please provide
alternates, poke holes, etc. And particularly from a QA and rel-eng
point of view. Both of these are not taking modularity into account in
any way; it's "how we could do this with our current distro-building
process".
Option 1: Big batched update
1. Release F26 according to schedule
https://fedoraproject.org/wiki/Releases/26/Schedule
2. At the beginning of October, stop pushing non-security updates
from updates-testing to updates
3. Bigger updates (desktop environment refreshes, etc.) allowed into
updates-testing at this time.
4. Mid-October, freeze exceptions for getting into updates-testing
even.
5. Test all of that together in Some Handwavy Way for serious
problems and regressions.
6. Once all good, push from updates-testing to updates at end of
October or beginning of November.
Option 2: Branching!
1. Release F26 according to schedule.
2. July/August: branch F26.1 from F26 (not rawhide)
3. Updates to F26 also go into F26.1 (magic happens here?)
4. No Alpha, but do "Beta" freeze and validation as normal for
release.
5. And same for F26.1 final
6. And sometime in October/November, release that (but without big
press push).
7. GNOME Software presents F26.1 as upgrade option
8. F26 continues in parallel through December
9. In January, update added to F26 which activates the F26.1 repo.
10. And also in January updates stop going to F26.
Some of this idea, by the way, is reminiscent of Spot's suggestions at
FUDCon Lawrence in 2013. This is not completely coincidence - I always
liked those ideas!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
1 month, 3 weeks
Xulrunner - intent to remove from Fedora 24
by Martin Stransky
Hi,
does anyone use the xulrunner package? (and gecko-devel actually).
Mozilla does not maintain it any more and the XUL as technology is going
to be removed/deprecated. I'd like to remove the package from Fedora 24.
ma.
2 months, 4 weeks
F27 System Wide Change: Rsyslog log format change proposal
by Jan Kurik
= Proposed System Wide Change: Rsyslog log format change proposal =
https://fedoraproject.org/wiki/Changes/RsyslogLogFormat
Change owner(s):
* Radovan Sroka <rsroka AT redhat DOT com>
* Roman Pavelka <rpavelka AT redhat DOT com>
Currently Fedora uses RSYSLOG_TraditionalFileFormat as a default
format for timestamps in its logs. There is missing year and timezone.
This proposal aims to change this by adopting ISO 8601 and RFC 3339
compliant timestamp format known as RSYSLOG_FileFormat instead of
current RSYSLOG_TraditionalFileFormat.
== Detailed Description ==
Currently Fedora, RHEL and CentOS use RSYSLOG_TraditionalFileFormat
for log’s timestamp, so timestamps in files like /var/log/messages,
/var/log/cron and /var/log/secure looks like e.g.:
May 29 13:37:50 localhost systemd: Starting Fingerprint Authentication Daemon...
This format has few disadvantages
* Does not include year which sometimes may be needed, mostly when
doing long term analysis or some investigation.
* Does not include timezone which may be important piece when working
with system scattered around the globe.
* It is not standard format. Standards are ISO 8601 and more strict RFC 3339
We would propose to change this to defaults to standard format with
timezone included. We are suggesting new RSYSLOG_FileFormat that looks
like e.g.:
2017-05-29T13:40:50.976409+02:00 localhost systemd: Stopping System
Logging Service...
== Scope ==
* Proposal owners:
- commit necessary changes
- create rsyslog build
* Other developers:
none
* Release engineering:
Releng#6818 https://pagure.io/releng/issue/6818
* List of deliverables:
Not affected
* Policies and guidelines:
Not affected
* Trademark approval:
Not needed for this Change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
3 months, 1 week
retiring git-annex
by Jens-Ulrik Petersen
Hi,
I think we need to retire git-annex from Fedora (the current version is
very old and has security issues), since to build current versions needs
adding a lot of new Haskell dependencies to Fedora.
Currently noone has expressed interested in doing this... I plan to make a
copr repo later at some point. So unless someone wants to help do a lot of
package reviews, I think it is better just to retire git-annex from Fedora
for now.
I will do that next week unless someone volunteers to do all the work to
update.
I am writing on behalf of Ben who is on away and the Haskell SIG.
Thanks, Jens
3 months, 1 week
F27 Self Contained Change: Making sudo pip Safe (Again)
by Jan Kurik
= Proposed Self Contained Change: Making sudo pip Safe (Again) =
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Change owner(s):
* Michal Cyprian <mcyprian AT redhat DOT com>
* Petr Viktorin <pviktori AT redhat DOT com>
* Tomas Orsava <torsava AT redhat DOT com>
* Miro Hroncok <mhroncok AT redhat DOT com>
At the present time, running sudo pip3 in Fedora is not safe. Pip
shares its installation directory with dnf, can remove dnf-managed
files and generally break the Python 3 interpreter. We propose a
series of measures that will make it safe to use.
== Detailed Description ==
The danger of using sudo pip3 stems from the fact that both Python dnf
packages and sudo pip3 install modules to the same location, namely
/usr/lib/pythonX.Y/site-packages.
We aim to move the working directory for sudo pip3 to a more
appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
modify the Python 3 interpreter in Fedora to scan both above mentioned
locations when importing modules. In addition, system-python—a
stripped down version of Python 3 for use by system tools—will not
read the sudo pip3 install location, making it more secure by being
less susceptible to interference by user-downloaded modules.
From the technical standpoint, this will be accomplished by changing
the install prefix setting of the distutils install command in the
/usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
distutils will thereafter use this prefix when determining where to
install modules. In addition, the paths
/usr/local/lib/pythonX.Y/site-packages and
/usr/local/lib64/pythonX.Y/site-packages will be added to the front of
the sys.path variable so that modules are imported preferentially from
there. These settings, however, will not be modified for the
system-python binary, the /usr/bin/python3 executable when running
with -I option specified, nor when an RPM build is detected.
Therefore, Python RPM packages will continue to be built with the
correct installation path for system modules.
The purpose of this change is not to make sudo pip a standard way to
install Python packages. Virtual environments and pip3 install --user
should still be the prefered options. Nevertheless, sudo pip is far
too prevalent an instruction in various guides and installation notes
throughout the Internet that there is little hope of changing users'
behaviour in this regard.
== Scope ==
* Proposal owners:
Modify the distutils install command as described above.
Modify the site.py script to add additional paths to sys.path when it is needed.
* Other developers:
N/A (not a System Wide Change)
* Release engineering:
https://pagure.io/releng/issue/6820
* List of deliverables:
N/A (not a System Wide Change)
* Policies and guidelines:
N/A (not a System Wide Change)
* Trademark approval:
Not needed for this Change
--
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
3 months, 1 week
dnf bodhi plugin
by Randy Barlow
Hello!
I had an idea for a summer internship project, but I wanted to ask my
fellow Fedora devs if something like this already exists so it doesn't
get created as a duplicate project.
The idea is to create a dnf plugin that would allow you to do this:
$ sudo dnf upgrade FEDORA-2017-30604deb62
That update is a Gnome update, and likely has packages in it that you
don't use, but others that you do. The plugin would compare the
packages in the update against your installed set of packages to form
and execute the true dnf update command that should be run without
installing new packages (unless they are required). It would also
enable updates-testing of course. It could even be written to pull the
rpms from Koji if the update hasn't hit testing yet.
I've found that it is a little painful for me to test multi-package
updates when I don't use all the RPMs and I don't keep updates-testing
enabled on my system, so that's my motivation behind the idea. Does
anything like this already exist? If not, does it sound like a useful
tool to others?
It could also support the install command, in which case it would just
install all the RPMs from the update.
3 months, 1 week
