Proven to be sickened

[Michael J Gruber]

So, due to me following my package (notmuch) upstream and testing early
against upstream's git, reporting and working with upstream, I noticed a
FTBFS and helped fixing it. Nothing urgent since it was basically just a
test failing for the wrong reasons.

Within a few days, upstream releases a patch release. Within hours, I'm
testing (again, since it's basically what was on git already) on copr and
koji, writing a nice commit message, push to rawhide ...

... and get a reject because someone thought that pushing directly without
asking or at least notifying the maintainer would be in order:

https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffd...

Why? For a FTBFS due to a test? No bugzilla, no FTI, no security issue
whatsoever?

I am sick of this. Really. I am so sick of this way of stomping on each
others' feet.

It's made worse by failing automated notifications, of course. Not from
pagure about the push nor from koji about the build nor from bodhi about
the update.

Dunno whether it's the new fmn or what. That works for *my* actions with
pagure/bodhi/koji but fails to report copr actions to me, and
apparently also actions by others.

Thanks for listening ...

Michael

[Sérgio Basto]

On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
>  So, due to me following my package (notmuch) upstream and testing
>  early against upstream's git, reporting and working with upstream, I
>  noticed a FTBFS and helped fixing it. Nothing urgent since it was
>  basically just a test failing for the wrong reasons.
>  
>  Within a few days, upstream releases a patch release. Within hours,
>  I'm testing (again, since it's basically what was on git already) on
>  copr and koji, writing a nice commit message, push to rawhide ...
>  
>  ... and get a reject because someone thought that pushing directly
>  without asking or at least notifying the maintainer would be in
>  order:
>  
>
> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffd...

>  Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
>  issue whatsoever?
>   
You may kindly ask to mtasaka why did it ? , and also alert him that
package is well maintain and have a quick response and kindly ask to do
PR instead , he is one provenpackager and I sure that he did that in
hope of improve the package, I'm sure that he will understand. 

Best regards,



>  I am sick of this. Really. I am so sick of this way of stomping on
>  each others' feet.
>  
>  It's made worse by failing automated notifications, of course. Not
>  from pagure about the push nor from koji about the build nor from
>  bodhi about the update.
>  
>  Dunno whether it's the new fmn or what. That works for *my* actions
>  with pagure/bodhi/koji but fails to report copr actions to me, and
>  apparently also actions by others.
>  
>  Thanks for listening ...
>  
>  Michael
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines:
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Mamoru TASAKA]

Sérgio Basto wrote on 2023/12/02 0:49:
>  On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
> > So, due to me following my package (notmuch) upstream and testing
> > early against upstream's git, reporting and working with upstream, I
> > noticed a FTBFS and helped fixing it. Nothing urgent since it was
> > basically just a test failing for the wrong reasons.
> >
> > Within a few days, upstream releases a patch release. Within hours,
> > I'm testing (again, since it's basically what was on git already) on
> > copr and koji, writing a nice commit message, push to rawhide ...
> >
> > ... and get a reject because someone thought that pushing directly
> > without asking or at least notifying the maintainer would be in
> > order:
> >
> >
> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffd...
>  
>  
> > Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
> > issue whatsoever?
> >
>  
>  You may kindly ask to mtasaka why did it ? , and also alert him that
>  package is well maintain and have a quick response and kindly ask to do
>  PR instead , he is one provenpackager and I sure that he did that in
>  hope of improve the package, I'm sure that he will understand.
>  
>  Best regards, 
So to explain, notmuch was FTBFS.
And we are going to rebuild packages which depends on libruby.so.3.2 as
announced as:

https://fedoraproject.org/wiki/Changes/Ruby_3.3

We are testing beforehand whether packages can rebuild against new ruby
beforehand, and trying to fix **just** FTBFS beforehand because if the package
has FTBFS anyway (regardless of whether the reason is related to ruby or
not, such package will have broken deps after mass rebuild).

notmuch is this target.

Regards,
Mamoru

>  
>  
>  
> > I am sick of this. Really. I am so sick of this way of stomping on
> > each others' feet.
> >
> > It's made worse by failing automated notifications, of course. Not
> > from pagure about the push nor from koji about the build nor from
> > bodhi about the update.
> >
> > Dunno whether it's the new fmn or what. That works for *my* actions
> > with pagure/bodhi/koji but fails to report copr actions to me, and
> > apparently also actions by others.
> >
> > Thanks for listening ...
> >
> > Michael
> > --

[Michal Schorm]

In my experience through the years, I've found very little proven
packagers that would work in what *I would see* as the right way.

I too despise random interventions from the higher power to my packages.
I rejoiced when the new process of removing inactive proven packagers
took place.

And I'd love to see the proven packagers losing their rights regularly
for breaking the guidelines. (Especially when there's nothing much
stopping them to request the proven packager status again and again,
but I hope in the small PITA of doing that might give them time for a
reflection on why they lost it and try better next time)

"Prior to making changes, provenpackagers should try to communicate
with owners of a package in bugzilla, dist-git pull request, IRC,
matrix, or email. They should be careful not to change other people’s
packages needlessly and try to do the minimal changes required to fix
problems, as explained more in depth in Who is Allowed to Modify Which
Packages."
https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/

In this particular case, if the commit was urgently needed by the
proven packager, I'd expect at least an explanation in the commit
message, what bigger whole this is part of (link to BZs or Fedora
change, or something).
If it wasn't urgent, I'd say PR would be in place instead. (with the
same reasoning included in the commit message)

I was raised (as a maintainer) watching closely the proven packager
'praiskup', which uses his powers conscientiously like no other proven
packager I've ever experienced. Especially early in my packager
career, I've gone to him many times, asking for proven packager
intervention that would come handy to me. I was refused every time,
with a good explanation of the processes I should take before residing
to the very last option - the proven packager intervention. It taught
me a lot. Through the years I was even thinking about becoming a
proven packager myself several times. However I haven't requested it
in the end, because, even when I did changes across dozens and dozen
of packages, there was never ever a time, where I would *need* to
reside to the proven packager powers to get my work done, as the
standard ways of contacting regular owners of the packages before that
always worked. (PR then BZ, then mail, then mailing list. I haven't
even needed to activate 'Policy for nonresponsive package
maintainers'.)

But I have a strong feeling the proven packagers powers are commonly
used because they are handy, instead of them being necessary.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Fri, Dec 1, 2023 at 11:35 PM Mamoru TASAKA <mtasaka(a)fedoraproject.org&gt; wrote:
>  Sérgio Basto wrote on 2023/12/02 0:49:
>  > On Fri, 2023-12-01 at 16:26 +0100, Michael J Gruber wrote:
>  >> So, due to me following my package (notmuch) upstream and testing
>  >> early against upstream's git, reporting and working with upstream, I
>  >> noticed a FTBFS and helped fixing it. Nothing urgent since it was
>  >> basically just a test failing for the wrong reasons.
>  >>
>  >> Within a few days, upstream releases a patch release. Within hours,
>  >> I'm testing (again, since it's basically what was on git already) on
>  >> copr and koji, writing a nice commit message, push to rawhide ...
>  >>
>  >> ... and get a reject because someone thought that pushing directly
>  >> without asking or at least notifying the maintainer would be in
>  >> order:
>  >>
>  >>
> https://src.fedoraproject.org/rpms/notmuch/c/f0d84b417694430874a150293ffd...
>  >
>  >
>  >> Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
>  >> issue whatsoever?
>  >>
>  >
>  > You may kindly ask to mtasaka why did it ? , and also alert him that
>  > package is well maintain and have a quick response and kindly ask to do
>  > PR instead , he is one provenpackager and I sure that he did that in
>  > hope of improve the package, I'm sure that he will understand.
>  >
>  > Best regards,
>
>  So to explain, notmuch was FTBFS.
>  And we are going to rebuild packages which depends on libruby.so.3.2 as
>  announced as:
>
>  https://fedoraproject.org/wiki/Changes/Ruby_3.3
>
>  We are testing beforehand whether packages can rebuild against new ruby
>  beforehand, and trying to fix **just** FTBFS beforehand because if the package
>  has FTBFS anyway (regardless of whether the reason is related to ruby or
>  not, such package will have broken deps after mass rebuild).
>
>  notmuch is this target.
>
>  Regards,
>  Mamoru
>
>  >
>  >
>  >
>  >> I am sick of this. Really. I am so sick of this way of stomping on
>  >> each others' feet.
>  >>
>  >> It's made worse by failing automated notifications, of course. Not
>  >> from pagure about the push nor from koji about the build nor from
>  >> bodhi about the update.
>  >>
>  >> Dunno whether it's the new fmn or what. That works for *my* actions
>  >> with pagure/bodhi/koji but fails to report copr actions to me, and
>  >> apparently also actions by others.
>  >>
>  >> Thanks for listening ...
>  >>
>  >> Michael
>  >> --
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Felix Schwarz]

Am 02.12.23 um 09:46 schrieb Michal Schorm:
>  In my experience through the years, I've found very little
> proven
>  packagers that would work in what *I would see* as the right way. 
I fully agree with you but I wanted to mention Miro + the Python team. From my 
experience in the Python packaging space it works pretty well there.

I regularly see new PRs by the "Python wranglers" for packages I (co-)maintain 
even though (technically) they could just push directly.

Felix

[Jason L Tibbitts III]

So I've been in this situation, both on the receiving end of nasty flames
because I dared touch someone else's package and having duplicated work
because I didn't check before trying to update something.

> >>>> Michael J Gruber <mjg(a)fedoraproject.org&gt;
> writes: 
>  So, due to me following my package (notmuch) 
The idea is that it's really the community's package, but you have
indicated that you will take a primary role.  That doesn't mean that
nobody else will ever touch the package.  Communication is encouraged,
of course.

https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintena...

>  ... and get a reject because someone thought that pushing directly
>  without asking or at least notifying the maintainer would be in order: 
This is collaborative maintenance.  Occasionally you get ninja'd.  It
happens.  Certainly it's annoying when it happens but it's not evidence
that anyone did anything wrong.

If there is something wrong with the work of the maintainer who got
there before you did, then you can always push a revert, bump and build
your own copy.  And of course have a discussion with them.

If there isn't anything wrong with the work of the other maintainer,
then I guess I don't understand.  They did something in an honest
attempt to save you the trouble and because of unfortunate timing they
didn't actually save you any trouble.  But you aren't in a different
position than if they hadn't tried to help.  (Excluding the time it took
to start this discussion, of course.)

>  I am sick of this. Really. I am so sick of this way of stomping on
>  each others' feet. 
I can only say that the best thing to do in this situation is to say
"thanks; would you mind sending me a note on [IRC|Matrix|email] in the
future so we don't duplicate effort?" and move on.  Surely it's not
worth strong emotions.

>  It's made worse by failing automated notifications, of course.
> Not
>  from pagure about the push nor from koji about the build nor from
>  bodhi about the update. 
Now that is a true issue, and perhaps the real underlying issue here.
If you invested time that you didn't need to invest because you didn't
receive a notification that the work had already been done, then that is
problematic.  And yes, it would be incredibly beneficial to
collaboration if that were fixed, if only because it would help to
prevent situations such as the one under discussion.  But please don't
take that out on the person who had no motivation other than to help you
out.

 - J<

[Michael J Gruber]

Jason L Tibbitts III venit, vidit, dixit 2023-12-01 22:41:54:
>  So I've been in this situation, both on the receiving end of
> nasty flames
>  because I dared touch someone else's package and having duplicated work
>  because I didn't check before trying to update something.
>  
>  >>>>> Michael J Gruber <mjg(a)fedoraproject.org&gt; writes:
>  
>  > So, due to me following my package (notmuch)
>  
>  The idea is that it's really the community's package, but you have
>  indicated that you will take a primary role.  That doesn't mean that
>  nobody else will ever touch the package.  Communication is encouraged,
>  of course.
>  
>
> https://docs.fedoraproject.org/en-US/packaging-guidelines/#_spec_maintena...
>  
>  > ... and get a reject because someone thought that pushing directly
>  > without asking or at least notifying the maintainer would be in order:
>  
>  This is collaborative maintenance.  Occasionally you get ninja'd.  It
>  happens.  Certainly it's annoying when it happens but it's not evidence
>  that anyone did anything wrong.
>  
>  If there is something wrong with the work of the maintainer who got
>  there before you did, then you can always push a revert, bump and build
>  your own copy.  And of course have a discussion with them.
>  
>  If there isn't anything wrong with the work of the other maintainer,
>  then I guess I don't understand.  They did something in an honest
>  attempt to save you the trouble and because of unfortunate timing they
>  didn't actually save you any trouble.  But you aren't in a different
>  position than if they hadn't tried to help.  (Excluding the time it took
>  to start this discussion, of course.)
>  
>  > I am sick of this. Really. I am so sick of this way of stomping on
>  > each others' feet.
>  
>  I can only say that the best thing to do in this situation is to say
>  "thanks; would you mind sending me a note on [IRC|Matrix|email] in the
>  future so we don't duplicate effort?" and move on.  Surely it's not
>  worth strong emotions.
>  
>  > It's made worse by failing automated notifications, of course. Not
>  > from pagure about the push nor from koji about the build nor from
>  > bodhi about the update.
>  
>  Now that is a true issue, and perhaps the real underlying issue here.
>  If you invested time that you didn't need to invest because you didn't
>  receive a notification that the work had already been done, then that is
>  problematic.  And yes, it would be incredibly beneficial to
>  collaboration if that were fixed, if only because it would help to
>  prevent situations such as the one under discussion.  But please don't
>  take that out on the person who had no motivation other than to help you
>  out. 
You are all missing the point that this is not about a (co-) maintainer
but a proven packager. And that "regular maintainership" is not what
this role is for. And it's definitely not what most of them do.

Even as (co-)maintainer I see this as team work, at least among
those who signal interest. If "main admin" doesn't signal that then
what does?

But hey, I can learn, such as not to care either. Just push and build
where you have access. So much easier.

Done with this for now.

Michael

[Zbigniew Jędrzejewski-Szmek]

On Fri, Dec 01, 2023 at 03:41:54PM -0600, Jason L Tibbitts III wrote:
[snip]
>  If there isn't anything wrong with the work of the other
> maintainer,
>  then I guess I don't understand.  They did something in an honest
>  attempt to save you the trouble and because of unfortunate timing they
>  didn't actually save you any trouble.  But you aren't in a different
>  position than if they hadn't tried to help.  (Excluding the time it took
>  to start this discussion, of course.) 
I'm very much with Jason on this… It's a nice clean fix to FTBFS.
If the maintainer did some work in parallel, then in the worst case
they need to do a git pull and remove the patch. In general, I'd be
very happy if somebody fixed an issue in one of my packages.

Zbyszek

[Maxwell G]

On Fri Dec 1, 2023 at 16:26 +0100, Michael J Gruber wrote:
>  So, due to me following my package (notmuch) upstream and testing
> early
>  against upstream's git, reporting and working with upstream, I noticed a
>  FTBFS and helped fixing it. Nothing urgent since it was basically just a
>  test failing for the wrong reasons.
>  
<snip>
>  Why? For a FTBFS due to a test? No bugzilla, no FTI, no security
> issue
>  whatsoever? 
FTBFS/FTI bugs are considered serious Unhandled issues[1] that
provenpackagers are deputized to fix. The package FTBFS and merging the
Ruby update side tag without fixing the FTBFS would've caused it FTI and
broken other packages. One of these is aerc which I help maintain, so
I'm happy that Mamoru took the time to fix it. Many packagers view FTBFS
bugs as low priority issues, but when they're not addressed, they can
cause larger issues that affect other packages in the distribution.

>  Dunno whether it's the new fmn or what. That works for *my*
> actions with
>  pagure/bodhi/koji but fails to report copr actions to me, and
>  apparently also actions by others. 
Yeah, you may have to go to https://nofications.fedoraproject.org and
readjust your settings.

[1]:
https://docs.fedoraproject.org/en-US/fesco/Who_is_allowed_to_modify_which...

-- 
Best,

Maxwell G (@gotmax23)
Pronouns: He/They

[Kevin Kofler]

Michael J Gruber wrote:
>  I am sick of this. Really. I am so sick of this way of stomping on
> each
>  others' feet. 
My pet peeve is provenpackagers or comaintainers who add unwanted automagic 
(autorelease, autosetup, autochangelog) to my packages. I do not want any of 
that in my packages, it just makes my work harder (or in practice, just 
wastes my time for the revert that I am inevitably going to do).

        Kevin Kofler

[Gary Buhrmaster]

On Tue, Dec 5, 2023 at 3:48 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org&gt; wrote:

>  My pet peeve is provenpackagers or comaintainers who add unwanted
> automagic
>  (autorelease, autosetup, autochangelog) to my packages. I do not want any of
>  that in my packages, it just makes my work harder (or in practice, just
>  wastes my time for the revert that I am inevitably going to do). 
I do not have a dog in this particular fight,
but I do have a strong belief that the primary
developer of a package, or the primary
admin of a package, gets to decide the
syntactical "sugar" of the code(s) involved
(I have seen PR's based on capitalization
styles, and indentation styles, too).

Those that want to change those need to
arrange to take formal ownership of the
development codes and/or packaging
before they get change what the primary
has decided to do.

[Jason Tibbitts]

> >>>> Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt; writes: 
>  My pet peeve is provenpackagers or comaintainers who add unwanted
>  automagic (autorelease, autosetup, autochangelog) to my packages. 
That really shouldn't be happening for anything which wasn't officially
made mandatory or forbidden or whatnot.  Sure, I went through and
removed Group: tags long ago, and the same was done for ldconfig
scriptlets and such, but that was only after the whole thing had gone
through the change process.  I can't imagine it would be appropriate for
a provenpackager (who isn't also explicitly listed as a maintainer for a
specific package) to just make a fundamental change to package
maintenance like that with no discussion.  I would think that if it did
happen, it would definitely warrant an apology.

But, fixing bugs and FTBFS issues?  That's absolutely part of what we
would expect provenpackagers to be doing.

 - J<

[Vít Ondruch]

Dne 05. 12. 23 v 5:56 Jason Tibbitts napsal(a):
> >>>>> Kevin Kofler via devel
> <devel(a)lists.fedoraproject.org&gt; writes:
> > My pet peeve is provenpackagers or comaintainers who add unwanted
> > automagic (autorelease, autosetup, autochangelog) to my packages.
>  That really shouldn't be happening for anything which wasn't officially
>  made mandatory or forbidden or whatnot.  Sure, I went through and
>  removed Group: tags long ago, and the same was done for ldconfig
>  scriptlets and such, but that was only after the whole thing had gone
>  through the change process.  I can't imagine it would be appropriate for
>  a provenpackager (who isn't also explicitly listed as a maintainer for a
>  specific package) to just make a fundamental change to package
>  maintenance like that with no discussion.  I would think that if it did
>  happen, it would definitely warrant an apology.
>  
I just want to say that during my proven packager years, I certainly did 
substantial changes to other's packages, but I was pretty sure that the 
package was not maintained by anybody except proven packagers. I still 
find surprising, that we can have packages like that.

E.g. looking at 
https://src.fedoraproject.org/rpms/rubygem-json/commits/rawhide

How comes the package was not orphaned by some automated process yet, to 
find a rightful maintainer?


Can we also make a rule that if package reaches e.g. release 10 with 
only mass rebuild commits, it will be orphaned? I have a few examples at 
hand:

https://src.fedoraproject.org/rpms/rubygem-ansi/commits/rawhide

https://src.fedoraproject.org/rpms/rubygem-daemons/tree/rawhide

https://src.fedoraproject.org/rpms/rubygem-elasticsearch-transport/commit...

I am not going to continue, but from these 3, the rubygem-daemons looks 
reasonable (but without enabled test, so nobody can tell if the package 
works) to today standards, because it was touched by proven packager 
years ago.

How I know about these cases? Because from time to time I look at the 
packages which are not migrated to SPDX yet. Will these be migrated? I 
don't think so. Should proven packagers do that?


There are also cases such as 
https://koschei.fedoraproject.org/package/rubygem-async_sinatra which is 
FTBFS for a while already. Should I fix the package as a proven packager 
knowing it is broken (also knowing the reasons for the breakage and the 
fix should not be hard), or should I leave it, because it does not seems 
to be maintained, while I don't think the maintainer is completely inactive.


Granted, these are dissimilar to initial Michaels's issue. But how can I 
be sure that if I touch some of the packages, I won't be told that they 
were in such state for purpose?


Sorry for bit of OT.



Vít



>  But, fixing bugs and FTBFS issues?  That's absolutely part of what we
>  would expect provenpackagers to be doing.
>
>    - J<
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>

[Daniel P. Berrangé]

On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:

[snip]

>  Granted, these are dissimilar to initial Michaels's issue. But
> how can I be
>  sure that if I touch some of the packages, I won't be told that they were in
>  such state for purpose? 
IMHO all changes should be opened as merge requests in pagure. This gives
the regular package maintainers a window of opportunity to review the
change before it is merged. If there's no response from the package
maintainer after a couple of weeks then a proven packager can go ahead
and approve the merge request.

Essentially proven packagers can follow the same workflow as anyone else
does for contributing to a package that they are not a (co)maintainer of.
They just need the extra priv of being able to approve their own MR at
their discretion. Pushing directly to git, bypassing merge requests,
should not be required in order to achieve what provenpackagers exist
to do.

At the same time I think it is good to remember that Fedora package
maintainers should think of themselves as guardians, not owners, and
thus should expect to receive contributions from others, including
provenpackagers, doing cleanups to follow Fedora guidelines better.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Richard W.M. Jones]

On Tue, Dec 05, 2023 at 10:35:35AM +0000, Daniel P. Berrangé wrote:
>  On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
>  
>  [snip]
>  
>  > Granted, these are dissimilar to initial Michaels's issue. But how can I be
>  > sure that if I touch some of the packages, I won't be told that they were in
>  > such state for purpose?
>  
>  IMHO all changes should be opened as merge requests in pagure. This gives
>  the regular package maintainers a window of opportunity to review the
>  change before it is merged. If there's no response from the package
>  maintainer after a couple of weeks then a proven packager can go ahead
>  and approve the merge request.
>  
>  Essentially proven packagers can follow the same workflow as anyone else
>  does for contributing to a package that they are not a (co)maintainer of.
>  They just need the extra priv of being able to approve their own MR at
>  their discretion. Pushing directly to git, bypassing merge requests,
>  should not be required in order to achieve what provenpackagers exist
>  to do. 
This workflow doesn't really work for mass rebuilds / mass maintenance
of OCaml packages (I guess it's similar for other language packages).
We want to be able to rebuild or fix all packages that contain OCaml
code, and we have a bunch of scripts to do that including the push and
build in a side tag.

>  At the same time I think it is good to remember that Fedora package
>  maintainers should think of themselves as guardians, not owners, and
>  thus should expect to receive contributions from others, including
>  provenpackagers, doing cleanups to follow Fedora guidelines better. 
Yes indeed.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

[Michael J Gruber]

Richard W.M. Jones venit, vidit, dixit 2023-12-05 12:03:36:
>  On Tue, Dec 05, 2023 at 10:35:35AM +0000, Daniel P. Berrangé wrote:
>  > On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
>  > 
>  > [snip]
>  > 
>  > > Granted, these are dissimilar to initial Michaels's issue. But how can I
> be
>  > > sure that if I touch some of the packages, I won't be told that they were
> in
>  > > such state for purpose?
>  > 
>  > IMHO all changes should be opened as merge requests in pagure. This gives
>  > the regular package maintainers a window of opportunity to review the
>  > change before it is merged. If there's no response from the package
>  > maintainer after a couple of weeks then a proven packager can go ahead
>  > and approve the merge request.
>  > 
>  > Essentially proven packagers can follow the same workflow as anyone else
>  > does for contributing to a package that they are not a (co)maintainer of.
>  > They just need the extra priv of being able to approve their own MR at
>  > their discretion. Pushing directly to git, bypassing merge requests,
>  > should not be required in order to achieve what provenpackagers exist
>  > to do. 
Yes. My main point was communication, i.e. the "how", not the "what"
of
those changes. The "what" may influence the "how", of course. An
urgent
security fix does not leave time for upfront communication. But there
should always be time for communication afterwards.

>  This workflow doesn't really work for mass rebuilds / mass
> maintenance
>  of OCaml packages (I guess it's similar for other language packages).
>  We want to be able to rebuild or fix all packages that contain OCaml
>  code, and we have a bunch of scripts to do that including the push and
>  build in a side tag. 
That makes it even more important to communicate: you don't want a
packager to build into rawhide while your side tag is cooking.

Note that "communicate" can be as simple as a commit message "bump for
xy mass rebuild" or "fix FTBFS for xy rebuild", maybe together with a
link to the announcement. If there was an announcement ...
That is something you can do automatically. You only have to take the time
*once* to template a proper dist-git commit message.

>  > At the same time I think it is good to remember that Fedora
> package
>  > maintainers should think of themselves as guardians, not owners, and
>  > thus should expect to receive contributions from others, including
>  > provenpackagers, doing cleanups to follow Fedora guidelines better.
>  
>  Yes indeed. 
Yes, it goes both ways, and requires communication. That's all.

And, just to clarify: I probably wouldn't have reacted the way I did if
I hadn't experienced something like that over and over again. And that
included quelling test suites completely and other niceties (from
various pp's).

Michael

[Michal Schorm]

On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
>  IMHO all changes should be opened as merge requests in pagure. This
> gives
>  the regular package maintainers a window of opportunity to review the
>  change before it is merged. If there's no response from the package
>  maintainer after a couple of weeks then a proven packager can go ahead
>  and approve the merge request. 
Well said.

I'd advise to create PR - wait week or 2,
if left without response - create BZ for the specific PR as not
everyone watches PRs and PR notifications, and wait week or two,
if left without response - send a direct mail to the package maintainer.

But having at least the PR and a useful commit message would be much
appreciated.

>  At the same time I think it is good to remember that Fedora package
>  maintainers should think of themselves as guardians, not owners, and
>  thus should expect to receive contributions from others, including
>  provenpackagers, doing cleanups to follow Fedora guidelines better. 
In the case of Fedora, for any part of the project - we should expect
to receive contributions.
I'd also level up and say, we all should encourage contributions to
any part of Fedora.

Every maintainer may be in for a different goal, so it may not be
applicable to everyone, but I like the parable to maintainer being
more of a guardian.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Tue, Dec 5, 2023 at 11:36 AM Daniel P. Berrangé <berrange(a)redhat.com&gt; wrote:
>
> On Tue, Dec 05, 2023 at 11:18:57AM +0100, Vít Ondruch wrote:
>
> [snip]
>
> > Granted, these are dissimilar to initial Michaels's issue. But how can I be
> > sure that if I touch some of the packages, I won't be told that they were
in
> > such state for purpose?
>
>  IMHO all changes should be opened as merge requests in pagure. This
> gives
>  the regular package maintainers a window of opportunity to review the
>  change before it is merged. If there's no response from the package
>  maintainer after a couple of weeks then a proven packager can go ahead
>  and approve the merge request. 
>
> Essentially proven packagers can follow the same workflow as anyone else
> does for contributing to a package that they are not a (co)maintainer of.
> They just need the extra priv of being able to approve their own MR at
> their discretion. Pushing directly to git, bypassing merge requests,
> should not be required in order to achieve what provenpackagers exist
> to do.
>
>  At the same time I think it is good to remember that Fedora package
>  maintainers should think of themselves as guardians, not owners, and
>  thus should expect to receive contributions from others, including
>  provenpackagers, doing cleanups to follow Fedora guidelines better. 
>
> With regards,
> Daniel
> --
> |: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
> |: https://libvirt.org         -o-            https://fstop138.berrange.com :|
> |: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|
> --
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Steffan]

On Thu, Dec 7, 2023 at 3:26 AM Michal Schorm <mschorm(a)redhat.com&gt; wrote:

>  I'd advise to create PR - wait week or 2,
>  if left without response - create BZ for the specific PR as not
>  everyone watches PRs and PR notifications, and wait week or two,
>  if left without response - send a direct mail to the package maintainer.
>  
Any automation around a notification workflow like this would be helpful.
I've been using the dist-git PR flow and find it very useful.

Once I learned how to use fedpkg to do most of the work for me (i.e.
`fedpkg fork`, etc.), it usually feels like maintaining my existing
packages.

Where I have felt the process lacks is automated coordination with the
package maintainers.

-- 
Jonathan Steffan

[Florian Weimer]

* Kevin Kofler via devel:

>  Michael J Gruber wrote:
> > I am sick of this. Really. I am so sick of this way of stomping on each
> > others' feet.
>
>  My pet peeve is provenpackagers or comaintainers who add unwanted
>  automagic (autorelease, autosetup, autochangelog) to my packages. I do
>  not want any of that in my packages, it just makes my work harder (or
>  in practice, just wastes my time for the revert that I am inevitably
>  going to do). 
If the package does not contain any patches yet, it's not really
possible to infer the maintainer intentions.  %setup vs %autosetup
doesn't matter much in that case, so it doesn't really tell us anything.
Likewise if the package uses %autosetup, but without -p1, and there are
no patches.  Does the maintainer really prefer those awkarward -p-less
patches?  We don't know.

Asking individual maintainers for trivial changes does not scale.  The
alternative would be not to address FTBFS and other build issues, maybe
file bugs, and rely on active maintainers instead.  But I don't think
that can work for Fedora, practically speaking.  Fedora lacks Debian's
ban on forcing packagers to do certain work.  In the past, FESCo has
used that to order that certain packagers must keep carrying out certain
work they do not want to do, but I think that only means anything if the
victim packager is a Red Hatter on certain teams, I think.  Others will
just quit if they disagree.

Thanks,
Florian

[Michal Schorm]

On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  Asking individual maintainers for trivial changes does not scale. 
> The
>  alternative would be not to address FTBFS and other build issues, maybe
>  file bugs, and rely on active maintainers instead. 
The alternative we want to achieve is:
(1) write useful commit messages, so the reasons and goal of the
proven package's commit would be clear
and
(2) give the maintainers the possibility to react. E.g. with a PR.
No one responded to the PR in a week? Force merge it with proven
packager rights.

Even though I would want a longer time window and multiple iterations
of trying to contact the maintainer,
putting the PR up just for a week would make the current situation
considerably better than it is.

I would expect the maintainers to only react on PRs in three general ways:
(1) asking for more information = likely means you haven't explained
the commit or the problem well
that marks problem on your side
(2) rejecting the PR for a good reason = likely means there's a
problem with the implementation of your solution.
that marks problem on your side
(3) coming up with an alternative solution = likely means you haven't
thought of package specific approaches
You might find out the packager has a better idea how to solve the
problem in general.
Or you just collaborated nicely.

Each way leads to a valuable end, I believe.

There may be more ways to react (e.g. not react at all), but for now
let's assume they are not significant, as you'd end up anyway using
the proven packagers rights to force merge.

Michal

--

Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat

--

On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer <fweimer(a)redhat.com&gt; wrote:
>  * Kevin Kofler via devel:
>
>  > Michael J Gruber wrote:
>  >> I am sick of this. Really. I am so sick of this way of stomping on each
>  >> others' feet.
>  >
>  > My pet peeve is provenpackagers or comaintainers who add unwanted
>  > automagic (autorelease, autosetup, autochangelog) to my packages. I do
>  > not want any of that in my packages, it just makes my work harder (or
>  > in practice, just wastes my time for the revert that I am inevitably
>  > going to do).
>
>  If the package does not contain any patches yet, it's not really
>  possible to infer the maintainer intentions.  %setup vs %autosetup
>  doesn't matter much in that case, so it doesn't really tell us anything.
>  Likewise if the package uses %autosetup, but without -p1, and there are
>  no patches.  Does the maintainer really prefer those awkarward -p-less
>  patches?  We don't know.
>
>  Asking individual maintainers for trivial changes does not scale.  The
>  alternative would be not to address FTBFS and other build issues, maybe
>  file bugs, and rely on active maintainers instead.  But I don't think
>  that can work for Fedora, practically speaking.  Fedora lacks Debian's
>  ban on forcing packagers to do certain work.  In the past, FESCo has
>  used that to order that certain packagers must keep carrying out certain
>  work they do not want to do, but I think that only means anything if the
>  victim packager is a Red Hatter on certain teams, I think.  Others will
>  just quit if they disagree.
>
>  Thanks,
>  Florian
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Sérgio Basto]

On Thu, 2023-12-07 at 11:41 +0100, Michal Schorm wrote:
>  On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer
> <fweimer(a)redhat.com&gt;
>  wrote:
>  > Asking individual maintainers for trivial changes does not scale. 
>  > The
>  > alternative would be not to address FTBFS and other build issues,
>  > maybe
>  > file bugs, and rely on active maintainers instead.
>  
>  The alternative we want to achieve is:
>  (1) write useful commit messages, so the reasons and goal of the
>  proven package's commit would be clear
>  and
>  (2) give the maintainers the possibility to react. E.g. with a PR.
>  No one responded to the PR in a week? Force merge it with proven
>  packager rights.
>   
TL;DR;

Maybe we should have a flag in the src.fp.o package for the maintainer
to request a PR before committing to have a window for review, or like
me, the maintainer would like to not be bothered with things that
proven package can do by itself .

Another thing is some proven packager which wants force the move to
autothings , which I don't like use it, ATM, because in my opinion
still have many problems . 

>  Even though I would want a longer time window and multiple
> iterations
>  of trying to contact the maintainer,
>  putting the PR up just for a week would make the current situation
>  considerably better than it is.
>  
>  I would expect the maintainers to only react on PRs in three general
>  ways:
>  (1) asking for more information = likely means you haven't explained
>  the commit or the problem well
>  that marks problem on your side
>  (2) rejecting the PR for a good reason = likely means there's a
>  problem with the implementation of your solution.
>  that marks problem on your side
>  (3) coming up with an alternative solution = likely means you haven't
>  thought of package specific approaches
>  You might find out the packager has a better idea how to solve the
>  problem in general.
>  Or you just collaborated nicely.
>  
>  Each way leads to a valuable end, I believe.
>  
>  There may be more ways to react (e.g. not react at all), but for now
>  let's assume they are not significant, as you'd end up anyway using
>  the proven packagers rights to force merge.
>  
>  Michal
>  
>  --
>  
>  Michal Schorm
>  Software Engineer
>  Core Services - Databases Team
>  Red Hat
>  
>  --
>  
>  On Thu, Dec 7, 2023 at 11:21 AM Florian Weimer <fweimer(a)redhat.com&gt;
>  wrote:
>  > 
>  > * Kevin Kofler via devel:
>  > 
>  > > Michael J Gruber wrote:
>  > > > I am sick of this. Really. I am so sick of this way of stomping
>  > > > on each
>  > > > others' feet.
>  > > 
>  > > My pet peeve is provenpackagers or comaintainers who add unwanted
>  > > automagic (autorelease, autosetup, autochangelog) to my packages.
>  > > I do
>  > > not want any of that in my packages, it just makes my work harder
>  > > (or
>  > > in practice, just wastes my time for the revert that I am
>  > > inevitably
>  > > going to do).
>  > 
>  > If the package does not contain any patches yet, it's not really
>  > possible to infer the maintainer intentions.  %setup vs %autosetup
>  > doesn't matter much in that case, so it doesn't really tell us
>  > anything.
>  > Likewise if the package uses %autosetup, but without -p1, and there
>  > are
>  > no patches.  Does the maintainer really prefer those awkarward -p-
>  > less
>  > patches?  We don't know.
>  > 
>  > Asking individual maintainers for trivial changes does not scale. 
>  > The
>  > alternative would be not to address FTBFS and other build issues,
>  > maybe
>  > file bugs, and rely on active maintainers instead.  But I don't
>  > think
>  > that can work for Fedora, practically speaking.  Fedora lacks
>  > Debian's
>  > ban on forcing packagers to do certain work.  In the past, FESCo
>  > has
>  > used that to order that certain packagers must keep carrying out
>  > certain
>  > work they do not want to do, but I think that only means anything
>  > if the
>  > victim packager is a Red Hatter on certain teams, I think.  Others
>  > will
>  > just quit if they disagree.
>  > 
>  > Thanks,
>  > Florian
>  > --
>  > _______________________________________________
>  > devel mailing list -- devel(a)lists.fedoraproject.org
>  > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  > Fedora Code of Conduct:
>  > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  > List Guidelines:
>  > https://fedoraproject.org/wiki/Mailing_list_guidelines
>  > List Archives:
>  > https://lists.fedoraproject.org/archives/list/[e-mail]
>  > Do not reply to spam, report it:
>  > https://pagure.io/fedora-infrastructure/new_issue
>  --
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines:
>  https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue 
-- 
Sérgio M. B.

[Gary Buhrmaster]

On Sun, Dec 10, 2023 at 5:39 PM Sérgio Basto <sergio(a)serjux.com&gt; wrote:

>  Maybe we should have a flag in the src.fp.o package for the
> maintainer
>  to request a PR before committing to have a window for review, or like
>  me, the maintainer would like to not be bothered with things that
>  proven package can do by itself .
>
>  Another thing is some proven packager which wants force the move to
>  autothings , which I don't like use it, ATM, because in my opinion
>  still have many problems . 
I think there is a difference between changes that have
a formal change proposal (I am thinking something like
removing make from the buildroot, which required many
packages to add a BR: make, and for which PP's did a
lot of the work for some packages), for which packagers
were given a sufficient period of time to make the change
on their own, and "philosophical"/"syntactical sugar"
changes, such as the current "autothings", for which
there is not an approved change for all packages
(FD: I would object to making the "autothings"
mandatory).

If a proven packager changes the syntactical sugar
without agreement by the current packager via a PR
they have exceeded their mandate, and should be
(first) asked to revert and formally apologize, and if
they repeat such, removed from the PP list (fool
me once, shame on you, fool me twice shame on
me).

FTBFS issues are, admittedly, complicated, but
such updates SHOULD be via a PR.  If a PP wants
to claim they cannot follow that process, they need
to demonstrate that a particular packager is not
responsive (there is a process for that) rather
then just deciding themselves it is too much trouble.

[Stephen Gallagher]

On Sun, Dec 10, 2023 at 9:49 PM Gary Buhrmaster
<gary.buhrmaster(a)gmail.com&gt; wrote:
...
>  FTBFS issues are, admittedly, complicated, but
>  such updates SHOULD be via a PR.  If a PP wants
>  to claim they cannot follow that process, they need
>  to demonstrate that a particular packager is not
>  responsive (there is a process for that) rather
>  then just deciding themselves it is too much trouble. 
While I generally agree that a merge request is a more polite and
elegant solution, if a package is listed as FTBFS (having had a bug
automatically opened) and some reasonable amount of time (two, three
weeks?) has passed, then I think it's perfectly reasonable to assume
that the maintainer is vacant (either entirely or because they lack
the available time to deal with it at this point). In that case, I
don't see it as a problem to jump in and fix the package as a
provenpackager if the fix is relatively minor (yes, this is
subjective). I'd hesitate at rebasing to a new version, but if the
issue is that a dependency changed its name or the newest gcc made a
warning into an error, I think that's a perfectly acceptable fix to
make. The ideal case is for it to go through a merge request, but if
the package happens to be blocking other work, I think expediency is
completely warranted.

[Kevin Fenzi]

On Mon, Dec 11, 2023 at 08:28:31AM -0500, Stephen Gallagher wrote:
>  
>  While I generally agree that a merge request is a more polite and
>  elegant solution, if a package is listed as FTBFS (having had a bug
>  automatically opened) and some reasonable amount of time (two, three
>  weeks?) has passed, then I think it's perfectly reasonable to assume
>  that the maintainer is vacant (either entirely or because they lack
>  the available time to deal with it at this point). In that case, I
>  don't see it as a problem to jump in and fix the package as a
>  provenpackager if the fix is relatively minor (yes, this is
>  subjective). I'd hesitate at rebasing to a new version, but if the
>  issue is that a dependency changed its name or the newest gcc made a
>  warning into an error, I think that's a perfectly acceptable fix to
>  make. The ideal case is for it to go through a merge request, but if
>  the package happens to be blocking other work, I think expediency is
>  completely warranted. 
I think the key here is that everyone needs to make sure and communicate
with others. 

If there's a FTBFS bugzilla bug and you are working on a good fix with
upstream, say so in the bug. If you are a provenpackager and you need to
fix a FTBFS quickly for some reason, look at the bug, if you see the
maintainer(s) mentioning they were working on it, ask in bug if you
could push a quick fix now and explain why you need it. Use good commit
messages. "Fix FTBFS" is not a good commit message, "Fix FTBFS with a
quick fix to xyz because we need to rebuild the package for rebuild of
package X, this may not be the final fix". Use the
packagename-maintainers aliases and notify when you are doing things. 
Even if everyone doesn't have time to react to communications, just
making the effort helps everyone know what happened and whats going on. 

kevin