[389-devel] 389 DS nightly 2019-05-22 - 94% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2019/05/22/report-389-ds-base-1.4.1.2-20190521gita8bc2e3.fc29.x86_64.html ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[389-devel] Please review 50399/50400
https://pagure.io/389-ds-base/issue/50399 https://pagure.io/389-ds-base/pull-request/50400 -- Sincerely, William ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
[Bug 1712142] perl-PAR-1.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1712142 Fedora Update System changed: What|Removed |Added Status|MODIFIED|ON_QA --- Comment #2 from Fedora Update System --- perl-PAR-1.016-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-83a468aaac -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: python-more-itertools - dropped Python 2 support?
On 21. 05. 19 20:15, Scott Talbert wrote: On Tue, 21 May 2019, Miro Hrončok wrote: On 21. 05. 19 17:34, Scott Talbert wrote: Hi, It seems that you just updated python-more-itertools and dropped Python 2 support. Unfortunately, this breaks quite a few packages - namely python2-pytest and all of its users. Can you please restore Python 2 support for now? https://bugzilla.redhat.com/show_bug.cgi?id=1582171#c7 I'm trying to put out the fire. See me on #fedora-python. Thanks Miro for packaging python2-more-itertools. Looks like all my package dependency errors just cleared. :) indeed, looks like it's back to normal (failures, but not with deps). python-ptyprocess's builds are back to normal in Fedora rawhide python-dropbox's builds are back to normal in Fedora rawhide python-click's builds are back to normal in Fedora rawhide python-packaging's builds are back to normal in Fedora rawhide python-wheel's builds are back to normal in Fedora rawhide python-cffi's builds are back to normal in Fedora rawhide python-six's builds are back to normal in Fedora rawhide python-mako's builds are back to normal in Fedora rawhide python-kiwisolver's builds are back to normal in Fedora rawhide python-pexpect's builds are back to normal in Fedora rawhide python-setuptools's builds are back to normal in Fedora rawhide python-html5lib's builds started to fail in Fedora rawhide python-pip's builds are back to normal in Fedora rawhide python-priority's builds started to fail in Fedora rawhide python-hyperframe's builds are back to normal in Fedora rawhide python-h2's builds started to fail in Fedora rawhide python-hpack's builds are back to normal in Fedora rawhide python-Automat's builds are back to normal in Fedora rawhide python-graphviz's builds are back to normal in Fedora rawhide scipy's builds started to fail in Fedora rawhide python-chardet's builds started to fail in Fedora rawhide python-dateutil's builds started to fail in Fedora rawhide python-pygments's builds started to fail in Fedora rawhide -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Changing the maintainer on a couple packages
On 21. 05. 19 20:05, Steve Dickson wrote: Hello, I would like to change the maintership of nfsometer and nfstest now that they have been re-write in python 3. How do I do that? https://src.fedoraproject.org/rpms/nfsometer/settings#usersgroups-tab https://src.fedoraproject.org/rpms/NFStest/settings#usersgroups-tab -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Changing the maintainer on a couple packages
Hello, I would like to change the maintership of nfsometer and nfstest now that they have been re-write in python 3. How do I do that? tia, steved. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] [Fedocal] Reminder meeting : EPEL Steering Co
Dear all, You are kindly invited to the meeting: EPEL Steering Co on 2019-05-22 from 18:00:00 to 19:00:00 GMT At freenode@fedora-meeting The meeting will be about: This is the weekly EPEL Steering Committee Meeting. Agenda is in the https://infinote.fedoraproject.org/cgit/infinote/tree/epel-meeting-next Source: https://apps.fedoraproject.org/calendar/meeting/9364/ ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: Fedora 30 Elections: Nomination period open
Final reminder that elections nominations are open through Wednesday 2019-05-22 at 23:59:59 UTC. Current nomination counts: FESCo: 8 (4 open seats) https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations Council: 2 (1 open seat) https://fedoraproject.org/wiki/Council/Nominations Mindshare: 3 (1 open seat) https://fedoraproject.org/wiki/Mindshare/Nominations On Wed, May 8, 2019 at 9:08 AM Ben Cotton wrote: > > Today we are starting the Nomination & Campaign period during which we > accept nominations to the "steering bodies" of the following teams: > > * FESCo (Engineering) (4 seats) [1] > * Fedora Council (1 seat) [2] > * Mindshare (1 seat) [3] > > This period is open until 2019-05-22 at 23:59:59 UTC. > > Candidates may self-nominate. If you nominate someone else, please > check with them to ensure that they are willing to be nominated before > submitting their name. > > The steering bodies are currently selecting interview questions for > the candidates. > > Nominees submit their questionnaire answers via a private Pagure > issue. The Election Wrangler or their backup will publish the > interviews to the Community Blog before the start of the voting > period. Fedora Podcast episodes will be recorded and published as > well. > > Please note that the interview is mandatory for all nominees. Nominees > not having their interview ready by end of the Interview period > (2019-05-29) will be disqualified and removed from the election. > > As part of the campaign people may also ask questions to specific > candidates on the appropriate mailing list. > > The full schedule of the elections is available on the Elections > schedule[4]. For more information about the elections process, see the > wiki[5]. > > [1] https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations > [2] https://fedoraproject.org/wiki/Council/Nominations > [3] https://fedoraproject.org/wiki/Mindshare/Nominations > [4] https://fedorapeople.org/groups/schedule/f-30/f-30-elections.html > [5] https://fedoraproject.org/wiki/Elections > -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
On Tue, May 21, 2019 at 4:52 AM Zbigniew Jędrzejewski-Szmek wrote: > > The formatting of the page leaves a bit to be desired too, esp. the > "Detailed Description" section is mangled. > I've cleaned up the formatting there a bit. > > == 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. > > I think we need some contingency plan: if issues are filed for F32 in > taiga, and we decide do abort the switch, somebody will need to transfer > them back to wiki. This should be spelled out. > I added a note that I will convert existing changes to wiki pages if necessary (and churchyard brought up in IRC that he already has an F32 proposal accepted. I will move that to Taiga for him, as well as any other F32 proposals that come up as this is being implemented). > What is the long-term prospect? Our Change pages serve as documentation > even years after the fact (e.g. > https://fedoraproject.org/wiki/Features/UsrMove > is being referenced in Debian as they do the same conversion…). Will taiga > be as long-lived? Are URLs in taiga stable? If we decide to switch away from > taiga, can we turn the Changes into static html or preserve them in some other > way? > I can't say if Taiga will out live the wiki. I can say that it is an area of importance for the Council and the Community Platform Engineering team. Taiga's URLs are stable, in my experience. We can preserve the content if we decide to switch away at some point. There's a part of me that thinks change descriptions should be committed to a docs repo after implementation (as an appendix to the release notes, perhaps), but that's outside the scope of this proposal. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to maintain python-urwid orphaned package
On 21. 05. 19 18:23, Globe Trotter via devel wrote: I am interested in supporting the python-urwid package. How do I do this?I am able to compile without errors and create the rpm locally. I have an FAS account called aarem. Tomáš is already the maintainer. https://pagure.io/releng/issue/8369 Talk to him if you want to offer help. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
How to maintain python-urwid orphaned package
I am interested in supporting the python-urwid package. How do I do this?I am able to compile without errors and create the rpm locally. I have an FAS account called aarem. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: python-more-itertools - dropped Python 2 support?
On 21. 05. 19 17:34, Scott Talbert wrote: Hi, It seems that you just updated python-more-itertools and dropped Python 2 support. Unfortunately, this breaks quite a few packages - namely python2-pytest and all of its users. Can you please restore Python 2 support for now? https://bugzilla.redhat.com/show_bug.cgi?id=1582171#c7 I'm trying to put out the fire. See me on #fedora-python. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
python-more-itertools - dropped Python 2 support?
Hi, It seems that you just updated python-more-itertools and dropped Python 2 support. Unfortunately, this breaks quite a few packages - namely python2-pytest and all of its users. Can you please restore Python 2 support for now? Thanks, Scott ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: How to predict Python 3 SOABI naming scheme?!?
Ok, well the output works fine for armv7hf on F29 so I implemented the workaround (-DPYTHON_SUFFIX) there and then rebuilt shiboken to make python3 the default for F30+ and got all packages rebuilt. Thanks! Richard ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Unresponsive maintainer: mflobo
Hello, I've been trying to contact mflobo in order to get some packages updated but didn't get any response: https://bugzilla.redhat.com/show_bug.cgi?id=1711394 https://bugzilla.redhat.com/show_bug.cgi?id=1711395 Output of fedora_active_user.py: Last login in FAS: mflobo 2017-02-23 Last action on koji: Tue, 15 Jan 2019 package list entry revoked: python-muranoclient in trashcan by oscar Last package update on bodhi: 2016-04-15 15:26:46 on package python-muranoclient-0.8.4-1.fc24 Last actions performed according to fedmsg: - amora...@redhat.com updated nothing on RHBZ#1711395 'Update to latest release upstream 1.12.0' on 2019-05-17 18:58:33 () - amora...@redhat.com updated nothing on RHBZ#1711394 'Update to latest released upstream 3.8.0' on 2019-05-17 18:55:32 () - upstream-release-monitoring updated 'short_desc' on RHBZ#1445107 'python-mistralclient-3.9.0 is available' on 2019-05-16 11:14:55 () - upstream-release-monitoring updated 'short_desc' on RHBZ#1445107 'python-mistralclient-3.8.1 is available' on 2019-05-14 17:11:52 () - upstream-release-monitoring updated 'short_desc' on RHBZ#1445107 'python-mistralclient-3.8.0 is available' on 2019-03-08 22:12:32 () - zbys...@in.waw.pl updated 'bug_status', 'cf_fixed_in', and 'resolution' on RHBZ#1579356 'python-mistralclient has no dist tag' on 2019-02-15 18:02:32 () - mhron...@redhat.com updated 'bug_status', 'flag.needinfo', and 'resolution' on RHBZ#1560485 'python-muranoclient: Switch to Python 3 ...' on 2019-01-09 15:27:54 () - mhron...@redhat.com updated 'flag.needinfo' on RHBZ#1560485 'python-muranoclient: Switch to Python 3 ...' on 2019-01-09 15:27:53 () - mhron...@redhat.com updated 'status', 'cf_fixed_in', 'resolution', and 'cf_last_closed' on RHBZ#1649010 'python-vitrageclient: Remove (sub)packag...' on 2018-11-19 14:36:19 () - mhron...@redhat.com updated 'status' and 'assigned_to' on RHBZ#1649010 'python-vitrageclient: Remove (sub)packag...' on 2018-11-19 14:29:14 () According to https://src.fedoraproject.org/user/mflobo he's the only maintainer for python-mistralclient, python-congressclient and python-yaql. As these three are somehow related to OpenStack packages, i'd be happy to take them as maintainer. Best regards, Alfredo ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Please review
@Simon Pichugin Please review: https://pagure.io/389-ds-base/pull-request/50336 Regards Anuj Borah On Wed, May 15, 2019 at 8:50 PM Anuj Borah wrote: > @Simon Pichugin > > Please review: > > https://pagure.io/389-ds-base/pull-request/50328 > > Regards > Anuj Borah > > > > On Thu, May 9, 2019 at 5:27 PM Anuj Borah wrote: > >> @Simon Pichugin >> >> This one is still pending . >> >> https://pagure.io/389-ds-base/pull-request/50192 >> >> Regards >> Anuj Borah >> >> >> On Tue, Apr 30, 2019 at 4:03 PM Anuj Borah wrote: >> >>> Hi Simon , >>> >>> Rebsed onto master . >>> >>> Regards >>> Anuj Borah >>> >>> On Tue, Apr 30, 2019 at 3:54 PM Simon Pichugin >>> wrote: >>> On Tue, Apr 30, 2019 at 02:15:55PM +0530, Anuj Borah wrote: >Hi all, Hi Anuj, >Please review these PRs. >Pending from Long Time. >[1]https://pagure.io/389-ds-base/pull-request/50180 >[2]https://pagure.io/389-ds-base/pull-request/50192 Could you please rebase them onto master? Thanks, Simon >Regards >Anuj Borah > > References > >1. https://pagure.io/389-ds-base/pull-request/50180 >2. https://pagure.io/389-ds-base/pull-request/50192 > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org >>> ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Swag Finding Mission
Hi All, I am working on managing our swag and logo-ed goods inventory to ensure we are in good shape when it is time to move to the new logo. As a part of this, I'd like to find any items you may have stored somewhere that are to be used for Fedora events and activities. I am trying to avoid ordering any unnecessary items with the current logo by using up our existing stock. If you have swag or other logo-ed goods, please contact me off list so we can get it sent to an upcoming event or used up as appropriate. Thank you! regards, bex -- Brian "bex" Exelbierd (he/him/his) Fedora Community Action & Impact Coordinator @bexelbie | http://www.winglemeyer.org bexel...@redhat.com | b...@pobox.com ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: How to submit Root CA to ship with Fedora
On Mon, May 20, 2019 at 9:20 AM Stephen Gallagher wrote: > > On Mon, May 20, 2019 at 8:53 AM Danishka Navin wrote: > > Seems government is working with Chinese tech people to run mass online > > surveillance system. > > http://www.themorning.lk/china-styled-mass-online-surveillance/ > > > > > > But I am not clear how Root CA can use to SSL MITM attack instead of user > > cert. > > > > If you trust a root CA for signing websites, then they can sign a new > certificate for google.com, then modify DNS to send you to a > non-Google server presenting their certificate, signed by the corrupt > CA. They'd decrypt all of your traffic, read it, re-encrypt it with > the real google.com cert and pass it along. You would still see the > website you expect to, but in the middle all of your traffic is > exposed to the man-in-the-middle server. It's typically detectable by delays because the SSL connection occurs twice, but given the clients are in China, well, some delays are not shocking. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1704645] Upgrade perl-Devel-Cover to 1.33
https://bugzilla.redhat.com/show_bug.cgi?id=1704645 Jitka Plesnikova changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Devel-Cover-1.33-1.fc3 ||1 Resolution|--- |RAWHIDE Last Closed||2019-05-21 08:58:46 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
On Mon, May 20, 2019 at 04:33:57PM -0400, Ben Cotton wrote: > https://fedoraproject.org/wiki/Changes/fedora-change-wrangler Please rename this to https://fedoraproject.org/wiki/Changes/TrackChangesInTaiga The formatting of the page leaves a bit to be desired too, esp. the "Detailed Description" section is mangled. > == 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. I think we need some contingency plan: if issues are filed for F32 in taiga, and we decide do abort the switch, somebody will need to transfer them back to wiki. This should be spelled out. What is the long-term prospect? Our Change pages serve as documentation even years after the fact (e.g. https://fedoraproject.org/wiki/Features/UsrMove is being referenced in Debian as they do the same conversion…). Will taiga be as long-lived? Are URLs in taiga stable? If we decide to switch away from taiga, can we turn the Changes into static html or preserve them in some other way? Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1712142] perl-PAR-1.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1712142 --- Comment #1 from Fedora Update System --- perl-PAR-1.016-1.fc30 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-83a468aaac -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1712142] perl-PAR-1.016 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1712142 Jitka Plesnikova changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-PAR-1.016-1.fc31 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
-1 I am against this proposal. For me as a contributor, Wiki works just fine. It is readable, it is discoverable. It is tool which will hopefully stand long after taiga is forgotten and the proposed script is unmaitained. Vít Dne 20. 05. 19 v 22:33 Ben Cotton napsal(a): > 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: manasmangaon...@gmail.com || pa...@fedoraproject.org > * Name: [[User:Bcotton | Ben Cotton]] > * Email: bcot...@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 ] . 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
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
On 20/05/2019 21:33, Ben Cotton wrote: = 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. So I don't know much about taigi but I just had a quick browse of a few things in that instance and I'm having some trouble visualising what it would look like when used for this. Is there an example page you can point at in the current instance that gives some of idea of what a "change" might looked at when documented in taiga? ie a view somewhat equivalent of the current wiki page for a change that shows a one page summary of it? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 32 Self-Contained Change proposal: Track Changes in Taiga
I support this with every vote I have. mkonecny On 5/20/19 10:33 PM, Ben Cotton wrote: 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: manasmangaon...@gmail.com || pa...@fedoraproject.org * Name: [[User:Bcotton | Ben Cotton]] * Email: bcot...@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 ] . 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) ==
