[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #6 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-b4277f16f9

-- 
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

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #5 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-1aef2547f7

-- 
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

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #4 from Fedora Update System  ---
perl-Iterator-Simple-0.07-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-2c59d7248e

-- 
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

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Iterator-Simple-0.07-1
   ||.fc28



--- Comment #3 from Petr Pisar  ---
A bug-fix release suitable for all Fedoras.

-- 
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

Re: Autumn Elections 2017 are cancelled

[Dominik 'Rathann' Mierzejewski]

On Thursday, 07 December 2017 at 18:54, Jan Kurik wrote:
> During the Autumn 2017 Election cycle we wanted to try a new approach
> in the way how Elections are organized [1]. Unfortunately, at the
> beginning of the Voting period we realized the new way does not work
> as expected [2] and even we tried to put some mitigation plan in place
> [3], we have not succeeded. To come up with some workable solution we
> have decided to cancel the currently running Autumn 2017 Elections and
> start it again in early January 2018. In upcoming days I will publish
> a schedule for the January 2018 Elections as well as more details on
> how we are going to organize it.

Who is "we" that "decided" to cancel the running elections? What were the
reasons for this "decision"? I object to this strongly. It doesn't look
like this "decision" was made through an open process as is the usual
Fedora way. I can't even find a Council ticket for this or a thread
in the council-discuss mailing list.

I'm afraid I'm losing confidence that the current Council is capable
of leading Fedora if they cannot even hold an election according to
the current documented rules without breaking them in more than one way.

I haven't checked if elections to the Council and Mindshare were
organized according to policy (maybe I should!), but with FESCo
elections, the following were broken:
1. Candidate nominations were accepted later than 3 days before
   the voting period started. This contradicts
   https://fedoraproject.org/wiki/FESCo_election_policy#Candidates
2. Candidates whose interviews weren't ready for publication before the
   start of the voting period were not disqualified. This contradicts
   https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Due to not having enough (number of open seats + 25%) candidates on the
day before the voting period, the nomination period was extended by 3
days. Arguably, the extension should have happened 3 days earlier
and should have been made longer than 3 days because extending by 3 days
on the eve of the voting period start still doesn't give anyone a chance
to be nominated according to
https://fedoraproject.org/wiki/FESCo_election_policy#Candidates .
I'd have extended by at least a week, also due to infrastructure
instability this week. The interview readiness deadline was,
suprisingly, extended by a week, allowing candidates who couldn't be
bothered to write their interviews to be voted in anyway. Nothing was
said about disqualifying candidates who'd fail to publish their interviews
despite getting votes in the first few days of the elections.

Last but not least, I wonder why all elections are being cancelled
instead of just FESCo. This was not explained, either.

With sad regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Re: Autumn Elections 2017 are cancelled

[Matthew Miller]

On Fri, Dec 08, 2017 at 12:39:08AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Who is "we" that "decided" to cancel the running elections? What were the
> reasons for this "decision"? I object to this strongly. It doesn't look
> like this "decision" was made through an open process as is the usual
> Fedora way. I can't even find a Council ticket for this or a thread
> in the council-discuss mailing list.

"We" is the council -- we had a quick discussion on the private council list
(which we normally reserve for sensitive things). I asked Jan to file a
public ticket about it because I agree this should be a public
discussion. It's a mess and we need to figure out how to reset it in a
way that restores confidence.

I had meant a ticket to discussion reseting everything, but in that
conversation, everyone on the council who chimed in was in favor of
restarting, so ... I guess I didn't communicate that clearly enough to
Jan, for which I apologize. (There's a bunch of other stuff going on
today and I was terse.)

All of that said, I don't think there was any *malice* here -- just a
series of unfortunately ad hoc decisions. I really do think resetting
and doing it better and more clearly is the best way forward.


> Last but not least, I wonder why all elections are being cancelled
> instead of just FESCo. This was not explained, either.

Because they were inconsistent too, and it's _really_ better to run
them all at the same time.

-- 
Matthew Miller

Fedora Project Leader
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

[EPEL-devel] package overlap between EPEL and RHEL server extra

[Qixiang Wan]

Hi,

I find some packages in EPEL are also available from RHEL server extra
repo, and kdreyer told me that EPEL's policy is to not overlap, maybe
this is something need to be fixed?

Packages which are available from both RHEL server extra and EPEL:

WALinuxAgent
python-passlib
python2-crypto
libev-devel
libtommath-doc
libev
libtomcrypt
python-paramiko-doc
python-httplib2
libev-source
sshpass
python2-jmespath
libtommath-devel
libev-libevent-devel
libtommath
___
epel-devel mailing list -- epel-devel@lists.fedoraproject.org
To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org

Re: Autumn Elections 2017 are cancelled

[Matthew Miller]

On Fri, Dec 08, 2017 at 12:39:08AM +0100, Dominik 'Rathann' Mierzejewski wrote:
> Who is "we" that "decided" to cancel the running elections? What were the
> reasons for this "decision"? I object to this strongly. It doesn't look
> like this "decision" was made through an open process as is the usual
> Fedora way. I can't even find a Council ticket for this or a thread
> in the council-discuss mailing list.

"We" is the council -- we had a quick discussion on the private council list
(which we normally reserve for sensitive things). I asked Jan to file a
public ticket about it because I agree this should be a public
discussion. It's a mess and we need to figure out how to reset it in a
way that restores confidence.

I had meant a ticket to discussion reseting everything, but in that
conversation, everyone on the council who chimed in was in favor of
restarting, so ... I guess I didn't communicate that clearly enough to
Jan, for which I apologize. (There's a bunch of other stuff going on
today and I was terse.)

All of that said, I don't think there was any *malice* here -- just a
series of unfortunately ad hoc decisions. I really do think resetting
and doing it better and more clearly is the best way forward.


> Last but not least, I wonder why all elections are being cancelled
> instead of just FESCo. This was not explained, either.

Because they were inconsistent too, and it's _really_ better to run
them all at the same time.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Michael Cullen]

> because I can no longer cherry-pick between branches.

Not true at all - you’d be surprised how well git deals with cherry
picks across diverse branches. And even when it doesn’t there’s very
rarely anything in a spec file that would be a difficult conflict to
resolve. At work I often cherry pick across branches that have diverged
sometimes by hundreds of commits without too many problems!
Michael


On Thu, 7 Dec 2017, at 11:13 PM, Sérgio Basto wrote:
> On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> > Hello,
> >
> > What do I have to do to stop random people
> > from making random changes to packages I maintain?
> >
> > How do people get this type of permission?
> >
> > Case in point;
> >
> > commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> > origin/master, origin/HEAD)
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:21 2017 +0100
> >
> > Remove old crufty coreutils requires
> >
> > Signed-off-by: Igor Gnatenko > >
> > commit 66851ea12370a786844262620a40b0a2ac9632ce
> > Author: Igor Gnatenko 
> > Date:   Tue Nov 7 16:31:14 2017 +0100
> >
> > systemd-units -> systemd
> >
> > Signed-off-by: Igor Gnatenko > >
> > Where committed to the master branch and not to any other
> > branch make the maintenance of those branches a pain
> > because I can no longer cherry-pick between branches.
> > I have to make multiple commits to multiple branches
> > which sucks... Something random people do not understand!
> >
> > There is a pull mechanism... Why was that not used??
> >
> > Maintaining the stability of packages is hard enough
> > esp packages everybody uses... but that stability
> > goes out the window when random people allowed to
> > make random changes...
> >
> > Who are these super humans, how do they become
> > super humans and why aren't they required to
> > use the pull mechanism??
>
> I don't agree with you, you may contact the super human and ask him
> why> ? you may revert the commit .
>
> IMHO we shouldn't inhibit people do his best, we already have lots of> work, 
> is kernel updates , glibc updates , gcc updates , systemd , etc> etc ... 
> (hopefully)
>
> As wrote in coreuitls commit
> " Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
> stat) Those are gone in fc9, more than decade ago."
>
> Nobody takes care of opencv for example , despite a very long bug
> report, we got bugs like  822844 [1] opened in 2012-05-18  to update
> giflib, my problem here is I don't know if giflib is used
> anymore or if> have a replacement etc, so just do a monkey update is not 
> enough for
> me.
> I got more and more SELinux bugs, people more and more enable
> SELinux ,> but SE team doesn't have time to fix it or something like that .
>
> So I think you should write (offlist) to the people which made the
> commits , and understand the motivation , and organize with him the
> best way of committing in "your" packages.
>
> Best regards,
>
> [1]
> https://bugzilla.redhat.com/show_bug.cgi?id=822844
>
> > steved.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org> --
> Sérgio M. B.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #2 from Upstream Release Monitoring 
 ---
hotness's scratch build of perl-Iterator-Simple-0.07-1.el7.src.rpm for rawhide
completed http://koji.fedoraproject.org/koji/taskinfo?taskID=23574101

-- 
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

[Bug 1523427] perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427



--- Comment #1 from Upstream Release Monitoring 
 ---
Created attachment 1364570
  --> https://bugzilla.redhat.com/attachment.cgi?id=1364570=edit
[patch] Update to 0.07 (#1523427)

-- 
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

[Bug 1523427] New: perl-Iterator-Simple-0.07 is available

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1523427

Bug ID: 1523427
   Summary: perl-Iterator-Simple-0.07 is available
   Product: Fedora
   Version: rawhide
 Component: perl-Iterator-Simple
  Keywords: FutureFeature, Triaged
  Assignee: ppi...@redhat.com
  Reporter: upstream-release-monitor...@fedoraproject.org
QA Contact: extras...@fedoraproject.org
CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com



Latest upstream release: 0.07
Current version/release in rawhide: 0.06-6.fc27
URL: http://search.cpan.org/dist/Iterator-Simple/

Please consult the package updates policy before you issue an update to a
stable branch: https://fedoraproject.org/wiki/Updates_Policy

More information about the service that created this bug can be found at:
https://fedoraproject.org/wiki/Upstream_release_monitoring

Please keep in mind that with any upstream change, there may also be packaging
changes that need to be made. Specifically, please remember that it is your
responsibility to review the new version to ensure that the licensing is still
correct and that no non-free or legally problematic items have been added
upstream.

Based on the information from anitya: 
https://release-monitoring.org/project/7343/

-- 
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

[Fedocal] Reminder meeting : Voting period is in progress

[jkurik]

Dear all,

You are kindly invited to the meeting:
   Voting period is in progress on 2017-12-09 from 00:00:00 to 00:00:00 UTC
   

The meeting will be about:
The Voting period of the currently running Fedora Elections in progress. Please 
vote for your candidates to Council [1], Mindshare[2] and FESCo [3].
You can vote until December 18th, 2017 when the voting ends at 23:59:00 UTC.

To help you to make the right decision we have published Fedora Magazine 
article [4] summarizing this elections and pointing to interviews with nominees 
we have published on Community Blog. It is definitely worth a look [4].

[1] https://admin.fedoraproject.org/voting/about/council-december-2017

[2] https://admin.fedoraproject.org/voting/about/mindshare-december-2017

[3] https://admin.fedoraproject.org/voting/about/fesco-december-2017

[4] https://fedoramagazine.org/december-2017-elections/

More information available at:
[https://fedoraproject.org/wiki/Elections](https://fedoraproject.org/wiki/Elections)


Source: https://apps.fedoraproject.org/calendar/meeting/8656/

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Autumn Elections 2017 are cancelled

[Dominik 'Rathann' Mierzejewski]

On Thursday, 07 December 2017 at 18:54, Jan Kurik wrote:
> During the Autumn 2017 Election cycle we wanted to try a new approach
> in the way how Elections are organized [1]. Unfortunately, at the
> beginning of the Voting period we realized the new way does not work
> as expected [2] and even we tried to put some mitigation plan in place
> [3], we have not succeeded. To come up with some workable solution we
> have decided to cancel the currently running Autumn 2017 Elections and
> start it again in early January 2018. In upcoming days I will publish
> a schedule for the January 2018 Elections as well as more details on
> how we are going to organize it.

Who is "we" that "decided" to cancel the running elections? What were the
reasons for this "decision"? I object to this strongly. It doesn't look
like this "decision" was made through an open process as is the usual
Fedora way. I can't even find a Council ticket for this or a thread
in the council-discuss mailing list.

I'm afraid I'm losing confidence that the current Council is capable
of leading Fedora if they cannot even hold an election according to
the current documented rules without breaking them in more than one way.

I haven't checked if elections to the Council and Mindshare were
organized according to policy (maybe I should!), but with FESCo
elections, the following were broken:
1. Candidate nominations were accepted later than 3 days before
   the voting period started. This contradicts
   https://fedoraproject.org/wiki/FESCo_election_policy#Candidates
2. Candidates whose interviews weren't ready for publication before the
   start of the voting period were not disqualified. This contradicts
   https://fedoraproject.org/wiki/Development/SteeringCommittee/Nominations

Due to not having enough (number of open seats + 25%) candidates on the
day before the voting period, the nomination period was extended by 3
days. Arguably, the extension should have happened 3 days earlier
and should have been made longer than 3 days because extending by 3 days
on the eve of the voting period start still doesn't give anyone a chance
to be nominated according to
https://fedoraproject.org/wiki/FESCo_election_policy#Candidates .
I'd have extended by at least a week, also due to infrastructure
instability this week. The interview readiness deadline was,
suprisingly, extended by a week, allowing candidates who couldn't be
bothered to write their interviews to be voted in anyway. Nothing was
said about disqualifying candidates who'd fail to publish their interviews
despite getting votes in the first few days of the elections.

Last but not least, I wonder why all elections are being cancelled
instead of just FESCo. This was not explained, either.

With sad regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Reminder: upcoming retirement of webkitgtk and webkitgtk3 packages

[Sérgio Basto]

On Wed, 2017-12-06 at 16:19 -0800, Adam Williamson wrote:
> On Thu, 2017-12-07 at 00:04 +, Sérgio Basto wrote:
> > 
> > hum Markdown plugin is build with GTK3 , the plus of GTK+ is
> > confusing
> > me 
> 
> GTK+ is the correct name of the project and the product. It is not
> called GTK. "GTK+ 3" and "GTK 3" refer to the same thing, and "GTK+
> 3"
> is technically the correct name. (It was called GTK a long, long,
> long
> time ago and the + was added to indicate an OO rewrite, but that's
> ancient history).

Thanks, I already can build geany-plugin-markdown with webkitgtk3-devel 
.

 
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Sérgio Basto]

On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:
> Hello,
> 
> What do I have to do to stop random people 
> from making random changes to packages I maintain? 
> 
> How do people get this type of permission?
> 
> Case in point;
> 
> commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master,
> origin/master, origin/HEAD)
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:21 2017 +0100
> 
> Remove old crufty coreutils requires
> 
> Signed-off-by: Igor Gnatenko 
> 
> commit 66851ea12370a786844262620a40b0a2ac9632ce
> Author: Igor Gnatenko 
> Date:   Tue Nov 7 16:31:14 2017 +0100
> 
> systemd-units -> systemd
> 
> Signed-off-by: Igor Gnatenko 
> 
> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!
> 
> There is a pull mechanism... Why was that not used??
> 
> Maintaining the stability of packages is hard enough
> esp packages everybody uses... but that stability
> goes out the window when random people allowed to
> make random changes...
> 
> Who are these super humans, how do they become 
> super humans and why aren't they required to 
> use the pull mechanism?? 

I don't agree with you, you may contact the super human and ask him why
? you may revert the commit . 

IMHO we shouldn't inhibit people do his best, we already have lots of
work, is kernel updates , glibc updates , gcc updates , systemd , etc
etc ... (hopefully) 

As wrote in coreuitls commit 
" Remove very old Provides (mktemp, sh-utils, textwrap, fileutils,
stat) Those are gone in fc9, more than decade ago."

Nobody takes care of opencv for example , despite a very long bug
report, we got bugs like  822844 [1] opened in 2012-05-18  to update
giflib, my problem here is I don't know if giflib is used anymore or if
have a replacement etc, so just do a monkey update is not enough for
me. 
I got more and more SELinux bugs, people more and more enable SELinux ,
but SE team doesn't have time to fix it or something like that . 

So I think you should write (offlist) to the people which made the
commits , and understand the motivation , and organize with him the
best way of committing in "your" packages. 

Best regards,

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=822844

> steved.
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
-- 
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Kevin Kofler]

Steve Dickson wrote:
> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

Huh? Normally, just committing to the master branch is the right thing to do 
for such cleanups. The other branches will either get the changes when I 
fast-forward-merge master into them (remember that you should always work in 
Rawhide first), or I don't merge and they don't get the changes, which is 
typically fine too for this kind of cosmetic cleanups.

Committing the changes to all branches separately is exactly what I DON'T 
want provenpackagers to do because that would break fast-forward 
mergeability (and fixing that is painful and will pollute the history with 
several merge commits: I have to merge master into the branch, and then 
fast-forward-merge the branch back into master, which pollutes all branches 
including the master with one merge commit per branch). I always curse at 
rel-eng when they do a mass rebuild in a branch, bumping the branch directly 
with their scripts instead of merging from master.

I don't understand what kind of workflow you use that makes you want cleanup 
commits to be done on each and every branch.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Autumn Elections 2017 are cancelled

[Kevin Kofler]

Jan Kurik wrote:
> During the Autumn 2017 Election cycle we wanted to try a new approach
> in the way how Elections are organized [1]. Unfortunately, at the
> beginning of the Voting period we realized the new way does not work
> as expected [2] and even we tried to put some mitigation plan in place
> [3], we have not succeeded. To come up with some workable solution we
> have decided to cancel the currently running Autumn 2017 Elections and
> start it again in early January 2018. In upcoming days I will publish
> a schedule for the January 2018 Elections as well as more details on
> how we are going to organize it.

IMHO, the questionnaire answers need to be up when the voting opens. This 
means the deadline needs to be such that there is time to actually publish 
the answers (even in the event of technical difficulties, or at least there 
needs to be the time to make a decision to postpone the election in case of 
technical difficulties). It is impossible to decide whom to vote for without 
knowing what the candidates actually stand for.

In addition, the deadline for nomination probably needs to be even earlier, 
or the candidates will have a hard time trying to nominate late because 
there is no time left for the questionnaire. It is pointless to allow people 
to nominate at the last second just to remove them again because there is no 
way they can answer the questionnaire in one second.

The schedule tried this time, with deadline for nomination, deadline for 
questionnaire answers, and start of the voting period all at the same time, 
just does not work.

Previous elections had deadlines that were suitably spaced out. There was 
one week for campaigning and questions with nomination already 
closed. Why was that changed this time?

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Adam Williamson]

On Thu, 2017-12-07 at 10:31 -0500, Steve Dickson wrote:

> Where committed to the master branch and not to any other
> branch make the maintenance of those branches a pain 
> because I can no longer cherry-pick between branches.
> I have to make multiple commits to multiple branches
> which sucks... Something random people do not understand!

You can bring branches back into line with merge commits. Can require a
bit of git juggling, but it's always doable in the end.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[R P Herrold]

On Thu, 7 Dec 2017, Yaakov Selkowitz wrote:

> https://fedoraproject.org/wiki/Provenpackager_policy

> These were properly announced:
> 
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/

That section provides in relevant part:

> Provenpackagers should try to communicate with owners of a 
package in bugzilla, irc or email prior to making changes

IMHO, A general email to a high traffic mailing list is 
insufficient

IRC is even worse for notification

Absent some pressing need (which was NOT present here -- this 
was just 'distribution housecleaning'), this was insufficient 
notice on a non-urgent matter, to my thinking

I have filed a FESCO bug on the topic, with proposed revised 
language:

https://pagure.io/fesco/issue/1799

-- Russ herrold
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Florian Weimer]

On 12/07/2017 04:31 PM, Steve Dickson wrote:

Where committed to the master branch and not to any other
branch make the maintenance of those branches a pain
because I can no longer cherry-pick between branches.


Maybe you can elaborate on how this causes problems for your development 
process, and we can find a way to avoid that?


Thanks,
Florian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What to I have to do....

[Yaakov Selkowitz]

On 2017-12-07 09:31, Steve Dickson wrote:
> What do I have to do to stop random people 
> from making random changes to packages I maintain? 
> 
> How do people get this type of permission?

https://fedoraproject.org/wiki/Provenpackager_policy

> Case in point;
[snip]

These were properly announced:

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/RJYQNLIWBAVQPGLIGUT77WGY5D4TK334/
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/YKPCYY2JJOAQG67X4I6ZNYRHNYDCNQFL/

This is proper use of the provenpackager privileges.

-- 
Yaakov Selkowitz
Software Engineer - Platform Enablement Group
Red Hat, Inc.



signature.asc
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Autumn Elections 2017 are cancelled

[Jan Kurik]

During the Autumn 2017 Election cycle we wanted to try a new approach
in the way how Elections are organized [1]. Unfortunately, at the
beginning of the Voting period we realized the new way does not work
as expected [2] and even we tried to put some mitigation plan in place
[3], we have not succeeded. To come up with some workable solution we
have decided to cancel the currently running Autumn 2017 Elections and
start it again in early January 2018. In upcoming days I will publish
a schedule for the January 2018 Elections as well as more details on
how we are going to organize it.

[1] https://pagure.io/Fedora-Council/tickets/issue/135
[2] https://pagure.io/Fedora-Council/tickets/issue/153
[3] 
https://lists.fedoraproject.org/archives/list/ambassad...@lists.fedoraproject.org/thread/QDZYPM6HKYB7A4DY2DQW7CM2HTEZAQJJ/

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel-announce mailing list -- devel-announce@lists.fedoraproject.org
To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org

Autumn Elections 2017 are cancelled

[Jan Kurik]

During the Autumn 2017 Election cycle we wanted to try a new approach
in the way how Elections are organized [1]. Unfortunately, at the
beginning of the Voting period we realized the new way does not work
as expected [2] and even we tried to put some mitigation plan in place
[3], we have not succeeded. To come up with some workable solution we
have decided to cancel the currently running Autumn 2017 Elections and
start it again in early January 2018. In upcoming days I will publish
a schedule for the January 2018 Elections as well as more details on
how we are going to organize it.

[1] https://pagure.io/Fedora-Council/tickets/issue/135
[2] https://pagure.io/Fedora-Council/tickets/issue/153
[3] 
https://lists.fedoraproject.org/archives/list/ambassad...@lists.fedoraproject.org/thread/QDZYPM6HKYB7A4DY2DQW7CM2HTEZAQJJ/

Regards,
Jan
-- 
Jan Kuřík
Platform & Fedora Program Manager
Red Hat Czech s.r.o., Purkynova 99/71, 612 45 Brno, Czech Republic
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

What to I have to do....

[Steve Dickson]

Hello,

What do I have to do to stop random people 
from making random changes to packages I maintain? 

How do people get this type of permission?

Case in point;

commit 358a8fff974f0e124527a3281c90fa04cb7c7a7f (HEAD -> master, origin/master, 
origin/HEAD)
Author: Igor Gnatenko 
Date:   Tue Nov 7 16:31:21 2017 +0100

Remove old crufty coreutils requires

Signed-off-by: Igor Gnatenko 

commit 66851ea12370a786844262620a40b0a2ac9632ce
Author: Igor Gnatenko 
Date:   Tue Nov 7 16:31:14 2017 +0100

systemd-units -> systemd

Signed-off-by: Igor Gnatenko 

Where committed to the master branch and not to any other
branch make the maintenance of those branches a pain 
because I can no longer cherry-pick between branches.
I have to make multiple commits to multiple branches
which sucks... Something random people do not understand!

There is a pull mechanism... Why was that not used??

Maintaining the stability of packages is hard enough
esp packages everybody uses... but that stability
goes out the window when random people allowed to
make random changes...

Who are these super humans, how do they become 
super humans and why aren't they required to 
use the pull mechanism?? 

steved.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Package naming question

[Stephen John Smoogen]

On 6 December 2017 at 05:33, Michal Sekletar  wrote:
> On Tue, Dec 5, 2017 at 1:07 PM, Tomasz Torcz  wrote:
>
>> We have solved this years ago. man alternatives
>
> alternatives is a terrible solution if you ask me. Symlink hackery in
> /etc/alternatives is awful and I these days with Fedora kernel
> supporting mount namespaces we could do better. But it certainly works
> nonetheless.
>

We could do better in a lot of ways but until someone takes the risk
and puts the effort into making all the mis-steps to getting to
there... alternatives is probably going to be it.


> Michal
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org



-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Retrace failed. Try again later and if the problem persists report this issue please.

[Silvia Sánchez]

Hello,
This happens to me when I try to report dnfdragora crashes in Gnome. It
doesn't happen in KDE mainly because dnfdragora doesn't crash there.
Regards,
Silvia



2017-11-28 7:46 GMT+01:00 Adam Williamson :

> On Mon, 2017-11-27 at 22:10 -0700, Chris Murphy wrote:
> > I'm on a Fedora 27 Workstation system, dnf system-upgrade(d) from
> > Fedora 26. I've got a few crashes that gnome-abrt (Problem Reporting)
> > I've clicked on to report, but I get this message for all three of
> > them:
> >
> > Retrace job failed
> > Retrace failed. Try again later and if the problem persists report
> > this issue please.
> >
> > The main problem with this is the message itself: I'm not sure where
> > to report it or what information to include.
> >
> > This is an example from one of their log windows (I've already
> > downloaded all the
> > debuginfos and separately filed bugs for these crashes with coredumpctl
> gdb
> > output, but maybe there's an issue with the retrace server (?)
>
> Report it to https://github.com/abrt/retrace-server/issues . Thanks!
> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
> http://www.happyassassin.net
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Fedora Modular bikeshed compose report: changes

[Adam Williamson]

On Mon, 2017-12-04 at 16:01 -0500, Przemek Klosowski wrote:
> On 12/02/2017 01:15 PM, Fedora Rawhide Report sent this report, quoted 
> in its entirety:
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> Could someone associated with Fedora Modular bikeshed look into 
> this---the automated reports come out empty for as many cycles as I can 
> remember. Maybe if there aren't any changes, don't send anything?

BTW, in case you were wondering, I also looked into the 27 modular
compose report emails - why they're often full of zeroes, and why we
seem to keep getting ones for 20171204.n.1 .

Turns out the reason we keep getting emails for 20171204.n.1 is the
same reason we were getting lots of mails for bikeshed composes: the
compose script wasn't set to quit (skipping the 'send out emails' step)
if the compose failed. And the way the script works is, it reads out
the "current" compose ID before starting the compose, then when the
compose is done, it reads the "current" compose ID again, expecting it
to be the ID of the compose that just finished. Then it runs the diff
against those two compose IDs. But if the compose *failed*, then it
won't be - the "current" compose ID will still be the same as it was.

So basically, since the last successful 27-modular compose was
20171204.n.1, every time a compose fails, the script winds up
generating and sending out the 'diff' between 20171204.n.1 (which it
sees as the "old" compose) and...20171204.n.1 (which it sees as the
"new" compose, since the actual new compose failed).

I've sent a PR to stop it doing this:
https://pagure.io/pungi-fedora/pull-request/488

Of course when it winds up diffing a compose against itself the results
are all zeroes (no difference). But it's also worth noting that
sometimes there will be a "correct" compose report for modular which is
all zeroes, because the content doesn't always change every day, as it
almost always does in regular Rawhide and Branched. So even with this
change, there will be some all-zero mails. I don't think it makes sense
to not send out mails when there are no changes, because "there was a
successful new compose, but nothing changed in it" is valid information
that may be of use to someone.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Fedora Modular 27 compose report: 20171204.n.1 changes

[Fedora Branched Report]

OLD: Fedora-Modular-27-20171204.n.1
NEW: Fedora-Modular-27-20171204.n.1

= SUMMARY =
Added images:0
Dropped images:  0
Added packages:  0
Dropped packages:0
Upgraded packages:   0
Downgraded packages: 0

Size of added packages:  0 B
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 =

= DROPPED PACKAGES =

= UPGRADED PACKAGES =

= DOWNGRADED PACKAGES =
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

ppisar pushed to perl-Specio (master). "Control optional test with a build-condition"

[notifications]

From e3e46441e8655ce73f235f2370a68291244662f8 Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Dec 07 2017 12:46:18 +
Subject: Control optional test with a build-condition


---

diff --git a/perl-Specio.spec b/perl-Specio.spec
index 30cea0c..ded6579 100644
--- a/perl-Specio.spec
+++ b/perl-Specio.spec
@@ -1,3 +1,6 @@
+# Run optional test
+%bcond_without perl_Specio_enables_optional_test
+
 Name:  perl-Specio
 Version:   0.42
 Release:   1%{?dist}
@@ -44,6 +47,7 @@ BuildRequires:perl(lib)
 BuildRequires: perl(open)
 BuildRequires: perl(Test::Needs)
 BuildRequires: perl(utf8)
+%if %{with perl_Specio_enables_optional_test}
 # Optional Tests
 BuildRequires: perl(CPAN::Meta) >= 2.120900
 BuildRequires: perl(CPAN::Meta::Prereqs)
@@ -55,6 +59,7 @@ BuildRequires:perl(Moose) >= 2.1207
 BuildRequires: perl(Mouse)
 %endif
 BuildRequires: perl(namespace::autoclean)
+%endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Ref::Util) >= 0.112



https://src.fedoraproject.org/rpms/perl-Specio/c/e3e46441e8655ce73f235f2370a68291244662f8?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1520944] Upgrade perl-Moo to 2.003004

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1520944

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Moo-2.003004-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2017-12-07 06:49:07



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1007950

-- 
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

[Bug 1520945] Upgrade perl-Mojolicious to 7.58

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1520945

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Mojolicious-7.58-1.fc2
   ||8
 Resolution|--- |RAWHIDE
Last Closed||2017-12-07 06:47:56



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1007945

-- 
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

ppisar pushed to perl-Params-ValidationCompiler (master). "Control optional test with a build condition"

[notifications]

From c013089dad8dc010339a26c19ebdea0aa1e9b28a Mon Sep 17 00:00:00 2001
From: Petr Písař 
Date: Dec 07 2017 11:43:56 +
Subject: Control optional test with a build condition


---

diff --git a/perl-Params-ValidationCompiler.spec 
b/perl-Params-ValidationCompiler.spec
index 4925e30..aa216de 100644
--- a/perl-Params-ValidationCompiler.spec
+++ b/perl-Params-ValidationCompiler.spec
@@ -1,3 +1,6 @@
+# Run optional test
+%bcond_without perl_Params_ValidationCompiler_enables_optional_test
+
 Name:  perl-Params-ValidationCompiler
 Version:   0.26
 Release:   1%{?dist}
@@ -35,15 +38,18 @@ BuildRequires:  perl(Test2::Require::Module)
 BuildRequires: perl(Test2::V0)
 BuildRequires: perl(Test::More) >= 1.302015
 BuildRequires: perl(Test::Without::Module)
-# Optional Tests (avoid build dependency cycles via Moose and DateTime)
+%if %{with perl_Params_ValidationCompiler_enables_optional_test}
+# Optional Tests
 BuildRequires: perl(Const::Fast)
 BuildRequires: perl(CPAN::Meta) >= 2.120900
 BuildRequires: perl(CPAN::Meta::Prereqs)
 BuildRequires: perl(Hash::Util)
 %if !%{defined perl_bootstrap}
+# Avoid build dependency cycles via Moose and DateTime
 BuildRequires: perl(Moose::Util::TypeConstraints)
 BuildRequires: perl(Types::Standard)
 %endif
+%endif
 # Dependencies
 Requires:  perl(:MODULE_COMPAT_%(eval "`perl -V:version`"; echo $version))
 Requires:  perl(Sub::Util) >= 1.40



https://src.fedoraproject.org/rpms/perl-Params-ValidationCompiler/c/c013089dad8dc010339a26c19ebdea0aa1e9b28a?branch=master
___
perl-devel mailing list -- perl-devel@lists.fedoraproject.org
To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org

[Bug 1522688] Upgrade perl-Catalyst-Action-REST to 1.21

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522688

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Catalyst-Action-REST-1
   ||.21-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2017-12-07 06:46:50



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1007942

-- 
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

[Bug 1522701] Upgrade perl-Future to 0.37

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522701

Emmanuel Seyman  changed:

   What|Removed |Added

 Status|NEW |CLOSED
   Fixed In Version||perl-Future-0.37-1.fc28
 Resolution|--- |RAWHIDE
Last Closed||2017-12-07 06:45:02



--- Comment #1 from Emmanuel Seyman  ---
Built for rawhide:
https://koji.fedoraproject.org/koji/buildinfo?buildID=1007936

-- 
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

Re: excess automated emails from Fedora

[Daniel Pocock]

On 05/12/17 23:53, Kevin Fenzi wrote:
> On 12/05/2017 01:56 AM, Daniel Pocock wrote:
>> When somebody writes a comment in Bugzilla, I am receiving an email from
>> Bugzilla and another email from FMN: two emails for each comment.  I
>> haven't seen this type of behavior in any other project.
> This is a bit of an oddity as we don't control bugzilla, so I guess in
> this case we should not be sending anything via FMN by default since we
> cannot supress the bugzilla email.

Yes, every Bugzilla I've ever used enables emails by default so unless
somebody is going to disable that in Bugzilla, it should probably be
disabled in FMN

>> The emails from build...@fedoraproject.org don't appear to come from
>> FMN, here is a sample from the headers:
> yep, this is known. There are plans to re-write that script, but no one
> has stepped up to do it yet.
> ...snip...


It is always useful to have small tasks like tweaking that script for
people to demonstrate their skills when applying for GSoC, is this
tracked in Bugzilla somewhere already?


>> That is a technical policy, I was thinking more about a high-level
>> community-oriented policy on notifications / use of communications channels.
> I don't know of any.
> ...snip...


Where would be the next step to start or propose a policy like that?

>>
>> iCalendar doesn't involve sending notifications: it is about
>> representing the state of things.  Does FMN keep state or is it only a
>> mechanism for relaying notifications?
> it's only sending notifications based on fedmsg's it's gotten.
>  ...snip...


From an architecture perspective that is quite OK and a lot easier to
maintain.  Assuming it will continue to be like that, it means an
iCalendar solution would have to be something parallel to FMN.

>> From the perspective of FMN architecture, I suspect that some decision
>> would need to be made about which component(s) keep the state and how it
>> is transformed.  Examples:
>>
>> - if a build breaks, should the build system talk to Bugzilla's API
>> directly, opening a bug and closing it again next time the build succeeds?
>>
>> - or should the state of the last build be directly available as an
>> iCalendar feed and interested parties have to monitor both the Bugzilla
>> iCalendar the iCalendar URL from the build system?  Most tools like
>> Mozilla Lightning can monitor multiple task-list URLs like that but it
>> is tedious for every developer to set that up in their client.
>>
>> - or can FMN be extended to take state from multiple sources (both the
>> build system and Bugzilla) and merge those things into a single
>> iCalendar file, the same way that Planet runs from time to time and
>> merges multiple RSS feeds into one list?
>>
>> - or should some other system be built for that purpose and FMN just
>> relays notifications?
> It would need to be something else... FMN just sees a specific discrete
> fedmsg and notifies the user about it.

OK, so that eliminates the third option in that list but the other
options are all possible.

>
>> My observation is that the people who "like" email are simply not aware
>> of the other options.  There is a perception that it is easy and/or the
>> lowest common denominator.  It is very easy for script developers to
>> write a couple of lines of code to generate an email.  Over time email's
>> inefficiency is a huge cost to the Fedora project and any other
>> organization doing things this way.
>>
>> Think about it like this: somebody goes away for a 6 week extended
>> vacation and they come back to find 1000 automated email messages
>> waiting, I worked in one company where that was the way things were
>> done.  The consequences:
>>
>> - the emails are sorted chronologically, not in priority order, so the
>> user doesn't know which emails to look at first
>>
>> - they don't know which emails have been fixed by somebody else
>>
>> - they don't know which emails somebody else is already investigating
>>
>> - if 50 of those emails relate to a single problem or incident, it is
>> not obvious which email represents the root cause of the problem
>>
>> The person coming back to that inbox might spend 1 day just checking the
>> emails.  Or maybe 2-3 hours each day during the week after their
>> vacation, without really working on them, just trying to work out which
>> issues were still open, which emails are duplicates, prioritizing them, etc.
>>
>> Even when people don't go on vacation, they are losing a bit of time
>> every day on such filtering chores.  Add it all up and it is a huge cost
>> to organizations.  As a large organization, Fedora "loses" more time
>> this way than a small organization.
>>
>> In contrast, another company I worked in had a strict policy against
>> emails, things couldn't be released into production unless they worked
>> with the dashboard.  Any developer, sysadmin or manager could look at
>> the dashboard in the morning and quickly see the top 3 issues nobody was
>> working on.
> I find the idea 

Re: excess automated emails from Fedora

[Daniel Pocock]

On 06/12/17 00:21, Kevin Fenzi wrote:
> Sorry to reply to myself here, but I meant to reply to this part and
> forgot:
>
> On 12/05/2017 02:53 PM, Kevin Fenzi wrote:
>> On 12/05/2017 01:56 AM, Daniel Pocock wrote:
>>
>>> My observation is that the people who "like" email are simply not aware
>>> of the other options.  There is a perception that it is easy and/or the
>>> lowest common denominator.  It is very easy for script developers to
>>> write a couple of lines of code to generate an email.  Over time email's
>>> inefficiency is a huge cost to the Fedora project and any other
>>> organization doing things this way.
> I'm not sure I agree with this. Dashboards and point in time reporting
> provides great information for some cases, but discrete history at each
> change is also sometimes the information you want.

Looking at the options in the other email, one of them was:

"if a build breaks, should the build system talk to Bugzilla's API
directly, opening a bug and closing it again next time the build succeeds?"

That approach would satisfy the requirement about keeping history and
the current state would always be visible through Bugzilla's iCalendar
API (without any modification to Bugzilla)

For the script that sends the dependency emails from buildsys, is there
a place to report this as a feature request?  Is it in Bugzilla or
Github issues?

>>> Think about it like this: somebody goes away for a 6 week extended
>>> vacation and they come back to find 1000 automated email messages
>>> waiting, I worked in one company where that was the way things were
>>> done.  The consequences:
>>>
>>> - the emails are sorted chronologically, not in priority order, so the
>>> user doesn't know which emails to look at first
>>>
>>> - they don't know which emails have been fixed by somebody else
>>>
>>> - they don't know which emails somebody else is already investigating
>>>
>>> - if 50 of those emails relate to a single problem or incident, it is
>>> not obvious which email represents the root cause of the problem
> Sure. I personally filter emails into a number of buckets. So, when I
> came back and had 1000 emails, most of them would already be filtered.
> So, I would know I don't need to immediately look at mailing lists or
> other things that are lower priority.


I also sort emails but it takes a certain amount of effort for every
developer to set up their rules and in the end it doesn't answer all of
those questions, e.g. it doesn't tell you which emails have already been
handled by somebody else while you were on vacation.

>>> The person coming back to that inbox might spend 1 day just checking the
>>> emails.  Or maybe 2-3 hours each day during the week after their
>>> vacation, without really working on them, just trying to work out which
>>> issues were still open, which emails are duplicates, prioritizing them, etc.
> I get a lot of email, but I don't think I have ever had to spend weeks
> going through backlog.
>

I once worked in a company where I got over 100 emails on my first day
and averaged 2,000 per month.  My predecessor and his manager had been
putting "| mail" into scripts and cron jobs for over 10 years.  While it
sounds absurd, this is how things end up if developers don't consciously
and deliberately do things thoughtfully.

This is why I feel it is so important for leading free software projects
to be good role models in how we use email.


>>> Even when people don't go on vacation, they are losing a bit of time
>>> every day on such filtering chores.  Add it all up and it is a huge cost
>>> to organizations.  As a large organization, Fedora "loses" more time
>>> this way than a small organization.
>>>
>>> In contrast, another company I worked in had a strict policy against
>>> emails, things couldn't be released into production unless they worked
>>> with the dashboard.  Any developer, sysadmin or manager could look at
>>> the dashboard in the morning and quickly see the top 3 issues nobody was
>>> working on.
> Yeah, but what about:
>
> * You have added another maintainer to a package you maintain. You want
> to watch their commits and tell them when you see something they should
> change or do better on.

- you could set a reminder for yourself to check their commits each morning

- you could use fedmsg to create a rule for that, maybe with an expiry
date, it would send you chat notifications when you are logged in but
wouldn't leave a trail of emails

- the chat message thing might know when you log in again and send a
single notification about how many commits you missed overnight or whatever

- or FMN could even create a task for you when there are new commits and
if you don't close the task and more commits are made, it appends them
to the existing task rather than sending new alerts

> Or
>
> * You want to see the exact series of events that led up to a package
> being fixed.

This would be possible if everything was forced to go through Bugzilla
or if FMN dumps everything into 

[Bug 1520949] Upgrade perl-Test2-Suite to 0.000094

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1520949

Petr Pisar  changed:

   What|Removed |Added

 Status|MODIFIED|CLOSED
 Resolution|--- |RAWHIDE
Last Closed||2017-12-07 05:29:29



--- Comment #3 from Petr Pisar  ---
The two packages were blocked in F28.

-- 
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

Re: Django 2.0 released, and what it means to you

[Matthias Runge]

On Wed, Dec 06, 2017 at 10:26:11AM +0100, Matthias Runge wrote:
> On Wed, Dec 06, 2017 at 09:56:28AM +0100, Lumir Balhar wrote:
> > On 12/05/2017 04:27 PM, Miro Hrončok wrote:
> > > Maybe a Fedora Change coordinating this would be nice?
> 
> probably a good idea.

To follow-up on this, I'm drafting a change[1]. Since my
responsibilities changed, this has a quite low priority for me.
Any help is greatly appreciated!

Best,
Matthias
[1] https://fedoraproject.org/wiki/User:Mrunge/Django20
-- 
Matthias Runge 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522709



--- Comment #4 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-19c15a7e6e

-- 
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

[Bug 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522709



--- Comment #3 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-65a2bcaaed

-- 
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

Re: Django 2.0 released, and what it means to you

[Piotr Popieluch]

On Wed, Dec 6, 2017 at 12:36 PM, Nicolas Chauvet  wrote:

> 2017-12-06 10:26 GMT+01:00 Matthias Runge :
> > On Wed, Dec 06, 2017 at 09:56:28AM +0100, Lumir Balhar wrote:
> >> On 12/05/2017 04:27 PM, Miro Hrončok wrote:
> >> > Maybe a Fedora Change coordinating this would be nice?
> >
> > probably a good idea.
> >
> >> > Those are packages that require python(2)-django and are themselves
> not
> >> > prefixed with python(2)-django:
> >> >
> >> > graphite-web
>

Last week a patch got merged to Graphite-web to support Python 3.  Not sure
when Django 2 will be supported.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

New "tests" namespace to share test code

[Petr Splichal]

Hi!

While working on adding CI tests [0] using the Standard Test
Interface a need arose to have a shared git repository where tests
could be stored:

 * A large number of test files makes a dist-git repository more
   difficult to maintain

 * Tests might follow a different branching pattern than the
   dist-git repo, leading to code duplication

 * Shared maintenance for tests sometimes benefits from different
   access levels than the release dist-git repository

The plan is to create a new “tests” namespace in Fedora git/pagure
dedicated to storing the shared test code. To enable execution of
these tests by the CI pipeline, tests.yml file in dist-git will be
used to link the tests in the standard way as defined by the
Standard Test Interface [1].

This approach should help to efficiently maintain tests & minimize
test code duplication. Using a dedicated git repo for test code
also means to keep dist-git more as a place for storing metadata
only: Build metadata (spec file = how to build the package) and
test metadata (tests.yml = how to test the package) rather than
mixing spec files with test code itself.

Please note that this does not mean that all tests should now go
into this new namespace. You can still link tests directly from
upstream (like GitHub) or any other source. Also, for unit tests
it makes more sense to be kept directly with the project source
and executed there. Shared tests namespace in Fedora will be
suitable especially for functional and integration testing which
should help to continuously ensure the OS works as a whole.

For more detailed motivation and real-life examples see the Share
Test Code proposal on the Fedora CI list [2]. If you have any
questions or comments feel free to share them here or in the
pagure issue requesting the new namespace:

https://pagure.io/fedora-infrastructure/issue/6478

Thanks.

psss...

[0] https://fedoraproject.org/wiki/CI
[1] https://fedoraproject.org/wiki/Changes/InvokingTests
[2] 
https://lists.fedoraproject.org/archives/list/c...@lists.fedoraproject.org/thread/55U6V6UHA54MJLD2F6JF46EOLMVRUAE7/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522709



--- Comment #2 from Fedora Update System  ---
perl-BibTeX-Parser-1.01-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-101cddfd01

-- 
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

[Bug 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522699



--- Comment #3 from Fedora Update System  ---
perl-experimental-0.019-1.fc26 has been submitted as an update to Fedora 26.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-120341939f

-- 
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

[Bug 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522699



--- Comment #4 from Fedora Update System  ---
perl-experimental-0.019-1.fc25 has been submitted as an update to Fedora 25.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-99702e925c

-- 
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

[Bug 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522699



--- Comment #2 from Fedora Update System  ---
perl-experimental-0.019-1.fc27 has been submitted as an update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-bb7f68cfa7

-- 
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

[Bug 1522709] Upgrade perl-BibTeX-Parser to 1.01

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522709

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-BibTeX-Parser-1.01-1.f
   ||c28



--- Comment #1 from Petr Pisar  ---
An enhancement release suitable for all Fedoras.

-- 
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

[Bug 1522696] Upgrade perl-Dist-Zilla-Plugin-Git-Contributors to 0.032

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522696



--- Comment #2 from Fedora Update System  ---
perl-Dist-Zilla-Plugin-Git-Contributors-0.032-1.fc27 has been submitted as an
update to Fedora 27.
https://bodhi.fedoraproject.org/updates/FEDORA-2017-9d4213887b

-- 
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

[Bug 1522699] Upgrade perl-experimental to 0.019

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522699

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-experimental-0.019-1.f
   ||c28



--- Comment #1 from Petr Pisar  ---
A bug-fix suitable for all Fedoras.

-- 
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

Re: Help Reviewing a FreeOTP (Android) Pull Request in Korean

[Rafal Luzynski]

6.12.2017 15:47 Nathaniel McCallum  wrote:
>
>
> Do you speak (I think) Korean and English? Can you code? If so, I
> could use your help.
>
> The Fedora-associated FreeOTP project has received this pull request:
> https://github.com/freeotp/freeotp-android/pull/165
>
> The comments and commit descriptions are almost entirely in Korean and
> I don't know how to make heads or tails of them. Communication with
> the patch submitter is also difficult since I don't speak Korean and
> they don't speak English. However, I'd really like to give the
> submitter a fair shot.
>
> Is there anyone in the Fedora community that would be willing to
> assist? This is a great opportunity to demonstrate the diversity of
> open source!
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Crossposting to trans@ in hope someone may help.

Regards,

Rafal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

[Bug 1522696] Upgrade perl-Dist-Zilla-Plugin-Git-Contributors to 0.032

[bugzilla]

https://bugzilla.redhat.com/show_bug.cgi?id=1522696

Petr Pisar  changed:

   What|Removed |Added

 Status|ASSIGNED|MODIFIED
   Fixed In Version||perl-Dist-Zilla-Plugin-Git-
   ||Contributors-0.032-1.fc28



--- Comment #1 from Petr Pisar  ---
A bug-fix release suitable for Fedora ≥ 27.

-- 
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

is there logstash alternative in Fedora?

[Michal Novotny]

Hello,

I am looking for an alternative for Java logstash application (not in
Fedora) that can parse logs (e.g. httpd access.log) and collect stats about
number of occurrences for a given search pattern (basically it can e.g.
group by IP and give number of lines for each IP and then post it to some
url address). Is there anything like this currently? I am about to
implement it but wanted to make sure I won't be doing something which
already exists.

Thank you
clime
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org