https://fedoraproject.org/wiki/Changes/fedora-change-wrangler
= Track Changes in Taiga =
The Motivation for this proposal is to propose using the Taiga
instance at teams.fedoraproject.org for Change processing.
[[User:Bcotton/UsePagureForChanges|Using Pagure]] was previously
proposed for this. The new Change Processing workflow aims to simplify
the process to improve visibility and ease of management.
== Summary ==
The current process allows contributors to propose changes in upcoming
Fedora releases. However, the management of those feature proposals is
cumbersome and requires several manual steps. This introduces more
opportunity for error and reduces the time available to the Change
Wrangler for more valuable contributions to Fedora. In particular, the
current process includes artifacts and discussion in the Fedora Wiki,
on mailing lists, FESCo tickets, Bugzilla tickets, and Docs tickets.
The current process is cumbersome with several manual steps,this
introduces more opportunity for error and reduces the time available
for the Change Wrangler.
A Cli Tool Written in Python that interacts with Taiga,Pagure and
Bugzilla.Functionality includes
Promoting,announcing,submitting,accepting and updating the changes
across the three platforms and over mailing list.
The new process will consolidate much of the information in
Taiga.Proposed Changes will be submitted as an issue in Taiga. The
description of the Issue will include the content with few exceptions:
* System-Wide or Self-Contained change will be indicated by a binary
in the issue metadata
* Fedora release will be indicated by a milestone in the issue metadata
* Change status will be indicated by a list selection in the issue metadata
== Owner ==
* Name: [[User:Pac23| Manas Mangaonkar]]
* Email: manasmangaonkar(a)gmail.com || pac23(a)fedoraproject.org
* Name: [[User:Bcotton | Ben Cotton]]
* Email: bcotton(a)redhat.com
== Detailed Description ==
As Part of GSoC 2019 the fedora-change-wrangler tool will be developed
to smooth out the workflow,reduce Manual Work involved for both the
Contributors and the Change-Wrangler(FPgm). The tool makes it easy by
covering all the functionality required for the process of moving
forward proposals.
The tool will be developed using Python 3.6+ and will interact with
Taiga/Pagure/Bugzilla via their API and the Mailing List via SMTP.
The General Workflow would be :
1. Change Owner opens an issue and fills in the fields. When they are
ready to submit the Change proposal, they set the status to "Ready
for Wrangler".
2. The Change Wrangler (FPgM) reviews the proposal. If it is
incomplete, they set the status back to "New" and inform the Change
Owner of what's needed. If it is ready to process, then...
Functionality covered
1. Promote
* The issue will be promoted to a user story in taiga,copies the
contents of the custom fields from the issue to the user story. Closes
the issue.
2. Announce
* The tool would have the functionality to enable announcing the
change proposal to devel and devel-announce lists using smtp. It will
also automatically change the story status to announced.
3. fesco-submit
* Allowing creation of a new issue in the FESco Pagure repo directly
from the command line.
4. Accept
* Once the changes are accepted the change-wrangler can create a
tracking bug in Bugzilla along with release notes on Pagure.THe status
of the user story is updated to accepted aswell.
5. Update
* Status can be changed to testable if BZ is "Modified" and to
Complete is BZ is "ON_QA"
6. Creation of Report
* The user can create a report to provide quick view of changes and
their status. It can be in wiki or Html form.
Techstack:
* Python3.6+
* SMTP
* Taiga/Pagure/Bugzilla API's
* Nano/Gedit/Vi ( Inbuilt support to edit text)
* Kerberos(For authentication)
The current sample arg created looks like this [ change-tool convert
--taiga <issue no> <issue no> ] . The advantage of this the Manager
would be able to specify unlimited no of issues to change at once in a
single command using the issue no in taiga to convert to user story.
== Benefit to Fedora ==
The proposed change will make the change-process easier for
everyone.Everyone would be able to see them in one place with
status,id filters. The current wiki process can be bit difficult for
formatting,having defined fields would mean easy access without the
cumbersome wiki edits.
Since changes would be submitted in Issue format on
Taiga,pre-submission discussions would be available thus getting
suggestions/feedback at the first stage itself would be easy for
everyone involved.
== Scope ==
* Proposal owners:
I will be working with the Change-Wrangler(Ben Cotton) throughout the
summer to create this tool from scratch.
* Other developers: N/A (not a System Wide Change)
* Release engineering:(no release engineering impact is expected)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
N/A (not a System Wide Change)
== How To Test ==
N/A (not a System Wide Change)
== User Experience ==
No visible Impact is expected.
== Dependencies ==
No other packages depend on this.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
Enough buffer time has been allocated to complete this during the GSoC period.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
(Manually forwarding to devel-announce as we work out some tooling issues)
---------- Forwarded message ---------
From: <bcotton(a)redhat.com>
Date: Wed, Aug 28, 2019 at 4:23 PM
Subject: Fedora 32 Self-Contained Change proposal: Switch mingw32
toolchain to dwarf-2 exceptions
To: <devel(a)lists.fedoraproject.org>, <devel-announce(a)lists.fedoraproject.org>
== Issue Link ==
https://teams.fedoraproject.org/project/changes-tracker/issue2
== Summary ==
Switch the mingw32 toolchain to dwarf-2 exceptions, instead of SJLJ.
== owner ==
smani
== Detailed Description ==
# Detailed Description
The two exception modes supported by mingw32 targets are SJLJ
(currently used in Fedora, and still default upstream), and the more
recent dwarf-2. According to various sources [1][2][3], the key
differences between the two are:
SJLJ (setjmp/longjmp):
* not "zero-cost": even if an exception isn't thrown, it incurs a
minor performance penalty (~15% in exception heavy code)
* allows exceptions to traverse through e.g. windows callbacks
DWARF (DW2, dwarf-2):
* no permanent runtime overhead
* needs whole call stack to be dwarf-enabled, which means exceptions
cannot be thrown over e.g. Windows system DLLs (i.e. throwing an
exception in a system DLL callback and attempting to catch it won't
work)
* DW2 potentially generates bigger libraries. The overhead however is
not big (< 10%) for typical applications.
The main reason for switching to dwarf-2 is that rust can only be
compiled to a MinGW toolchain targeting dwarf exceptions on 32-bit
[4], and rust usage is starting to appear in some packages (i.e.
librsvg2). Switching to dwarf-2 on mingw32 would hence allow to keep
the same consistent package offering between mingw32 and mingw64,
whereas otherwise one would need to either freeze the mingw32 variants
at older versions, or remove them altogether.
* [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=540782
* [2] https://sourceforge.net/p/mingw-w64/mailman/message/30532139/
* [3] https://wiki.qt.io/MinGW-64-bit#Exception_handling:_SJLJ.2C_DWARF.2C_and_SEH
* [4] https://github.com/rust-lang/rust/issues/12859#issuecomment-185081071
# Benefit to Fedora
Continue being able to ship the same package set on mingw32 as well as mingw64.
# Scope
## Proposal owners:
GCC for mingw32 will be built with `--disable-sjlj-exceptions
--with-dwarf2` and all `mingw-*` packages rebuilt.
## Other developers:
None
## Release engineering
Rebuild in a side-tag
# Upgrade/compatibility impact
No impact
# Contingency Plan
* Contingency mechanism: Revert to SJLJ
* Contingency deadline: Before release
* Blocks release? Yes
* Blocks product? No
# Documentation
None
# Release Notes
The mingw32 toolchain in Fedora 32 uses the dwarf-2 exception model
instead of SJLJ.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
On 8/1/19 3:34 AM, Clement Verna wrote:
> > Dear all,
> >
> > The Fedora Infrastructure is planning to retire the infinote [0]
> > service. This service allows text collaboration using the Gobby
> > client[1] and was mainly used by the Infrastructure team to coordinate
> > our weekly meeting and the mass update & reboot of the machines.
> >
> > The service will be taken offline on August 30th 2019. If you wish to
> > backup some of the document currently hosted, you should make sure
> > that you have downloaded them locally before that date.
> >
> > The Infrastructure team will most likely use the service provided by
> > hackmd.io [2] for their needs. Other alternatives like public etherpad
> > can also be used to replace this service.
> >
>
Hi all, this is a reminder that this service will be retired this Friday
August 30th.
Thanks
> _______________________________________________
> > infrastructure mailing list -- infrastructure(a)lists.fedoraproject.org
> > To unsubscribe send an email to
> infrastructure-leave(a)lists.fedoraproject.org
> > Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraprā€¦
>
Hi all,
Today's an important day on the Fedora 31 schedule[1], with several
significant cut-offs. First of all today is
the Bodhi activation point [2]. That means that from now all Fedora 31
packages must be submitted to
updates-testing and pass the relevant requirements[3] before they will be
marked as 'stable' and moved to the
fedora repository.
Today is also the Beta freeze[4]. This means that only packages which fix
accepted blocker or freeze exception
bugs[5][6] will be marked as 'stable' and included in the Beta composes.
Other builds will remain in updates-
testing until the Beta release is approved, at which point the Beta freeze
is lifted and packages can move to
'stable' as usual until the Final freeze.
Finally, Today is the '100% code complete deadline' Change Checkpoint[5],
meaning that Fedora 31 Changes
must now be code complete, meaning all the code required to enable to the
new change is finished. The level
of code completeness is reflected as tracker bug state ON_QA. The change
does not have to be fully tested
by this deadline'.
Finally, today is also the Software String freeze[7], which means that
strings marked for translation in Fedora-
translated projects should not now be changed for Fedora 31.
Mohan Boddu
[1] https://fedoraproject.org/wiki/Releases/31/Schedule
[2] https://fedoraproject.org/wiki/Updates_Policy#Bodhi_enabling
[3] https://fedoraproject.org/wiki/Updates_Policy#Branched_release
[4] https://fedoraproject.org/wiki/Milestone_freezes
[5] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
[6] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process
[7] https://fedoraproject.org/wiki/ReleaseEngineering/StringFreezePolicy
Hello, in order to deliver Python 3.8, we are running a coordinated rebuild in a
side tag.
Ā Ā Ā https://fedoraproject.org/wiki/Changes/Python3.8
If you see a "Rebuild for Python 3.8" commit in your package, please don't
rebuild it in regular rawhide.
If you need to, please let me know, so we can coordinate.
If you'd like to update the package, you should be able to build it in the side
tag via:
Ā Ā Ā on branch master:
Ā Ā Ā $ fedpkg build --target=f32-python
Note that it will take a while before the essential packages are rebuilt, so
don't except all your dependencies to be available right away.
Thanks. Let us know if you have any questions.
--
Miro HronĨok
--
Phone: +420777974800
IRC: mhroncok
=== Planned Outage - Staging/Build - 2019-08-20 20:00 UTC
There will be an outage starting at 2019-08-20 20:00 UTC,
which will last approximately 4 hours.
To convert UTC to your local time, take a look at
http://fedoraproject.org/wiki/Infrastructure/UTCHowto
or run:
date -d '2019-08-20 20:00UTC'
Reason for outage:
RHEL-7.7 came out and a lot of other updates for various Fedora issues
will need updates and reboots of systems.
Affected Services:
All staging and build and related services will be affected.
Ticket Link:
https://pagure.io/fedora-infrastructure/issue/8106
Please join #fedora-admin or #fedora-noc on irc.freenode.net
or add comments to the ticket for this outage above.
--
Stephen J Smoogen.