Patches for trivial bugs sitting in bugzilla -> trivial patch policy?

[Sandro Mani]

Hi,

 From time to time, I see trivial patches posted in bugzilla which end 
up sitting there because the maintainer is too busy / gets bombarded 
with tons of bugzilla mails and misses that particular one / whatever 
reason. As a packager, sometimes it seems very hard to get such trivial 
patches applied. What you can do is

- You can keep pinging bugzilla
- You can apply for commit rights, which might be excessive for just 
this one patch, and still requires the maintainer to answer.
- You can start the non-responsive maintainer procedure, even if you 
know perfectly well that the maintainer is still active. Or you might 
suspect that the maintainer is inactive, but you'd rather not have to 
wait for an entire month, because this one bug is blocking your work.
- You can start asking on irc for a proven packager to jump in and hope 
a proven packager is online and has time at that moment.
- You can post on -devel, though again, unless someone has time right 
now it gets forgotten an people move on.
- Repeat the above n times until someone shouts at you and flags your 
email as spam :)

So wondering, if there is a way we can improve the situation. One idea 
which comes to mind would be something like "trivial patch policy"
- after i.e. one week of inactivity one can flag such a bug as a trivial 
bug. You can only do so if you are a packager and post a patch (which 
also updates the SPEC, so just a matter of apply patch, fedpkg commit & 
build).
- for anything else than packaging issues, the patch may only be a well 
justified upstream commit backport
- a proven packagers gets notified about the issue, validates the patch 
and if ok fires the update. The entire thing might work similar to how a 
New Package / Package Change request works, by posting something like 
this to the bug:
   Trivial Patch Request
   =====================
   Patch[branch]:
   Patch[other_branch]:
   Reason:
   Upstream commit:
   Submitter:


 From my experience such situations do not occur too frequently, but 
when they happen, they can be hard to deal with.

Comments?

Thanks,
Sandro

[Simone Caronni]

+1 from me!
On Jun 26, 2014 5:51 PM, "Sandro Mani" <manisandro(a)gmail.com&gt; wrote:

>  Hi,
>
>  From time to time, I see trivial patches posted in bugzilla which end up
>  sitting there because the maintainer is too busy / gets bombarded with tons
>  of bugzilla mails and misses that particular one / whatever reason. As a
>  packager, sometimes it seems very hard to get such trivial patches applied.
>  What you can do is
>
>  - You can keep pinging bugzilla
>  - You can apply for commit rights, which might be excessive for just this
>  one patch, and still requires the maintainer to answer.
>  - You can start the non-responsive maintainer procedure, even if you know
>  perfectly well that the maintainer is still active. Or you might suspect
>  that the maintainer is inactive, but you'd rather not have to wait for an
>  entire month, because this one bug is blocking your work.
>  - You can start asking on irc for a proven packager to jump in and hope a
>  proven packager is online and has time at that moment.
>  - You can post on -devel, though again, unless someone has time right now
>  it gets forgotten an people move on.
>  - Repeat the above n times until someone shouts at you and flags your
>  email as spam :)
>
>  So wondering, if there is a way we can improve the situation. One idea
>  which comes to mind would be something like "trivial patch policy"
>  - after i.e. one week of inactivity one can flag such a bug as a trivial
>  bug. You can only do so if you are a packager and post a patch (which also
>  updates the SPEC, so just a matter of apply patch, fedpkg commit & build).
>  - for anything else than packaging issues, the patch may only be a well
>  justified upstream commit backport
>  - a proven packagers gets notified about the issue, validates the patch
>  and if ok fires the update. The entire thing might work similar to how a
>  New Package / Package Change request works, by posting something like this
>  to the bug:
>    Trivial Patch Request
>    =====================
>    Patch[branch]:
>    Patch[other_branch]:
>    Reason:
>    Upstream commit:
>    Submitter:
>
>
>  From my experience such situations do not occur too frequently, but when
>  they happen, they can be hard to deal with.
>
>  Comments?
>
>  Thanks,
>  Sandro
>
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Richard Hughes]

On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
>  +1 from me! 
If it's a trivial patch then I think it makes sense to just do it.
> From someone that touches hundreds of different projects every month,
I've found it's better to ask forgiveness than permission :)

Richard

[gil]

Il 26/06/2014 18:17, Richard Hughes ha scritto:
>  On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt;
> wrote:
> > +1 from me!
>  If it's a trivial patch then I think it makes sense to just do it.
>   From someone that touches hundreds of different projects every month,
>  I've found it's better to ask forgiveness than permission :)
>
>  Richard 
+1 for me
gil

[Kevin Fenzi]

On Thu, 26 Jun 2014 17:17:07 +0100
Richard Hughes <hughsient(a)gmail.com&gt; wrote:

>  On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt;
> wrote:
>  > +1 from me!
>  
>  If it's a trivial patch then I think it makes sense to just do it.
>  From someone that touches hundreds of different projects every month,
>  I've found it's better to ask forgiveness than permission :) 
Yeah, but the proposal is talking about when someone is not a
provenpackager and doesn't have permissions to just apply them. ;( 

I'm not sure the entire group of provenpackagers would like to be
notified of such trivial patches waiting. Is there a group of
provenpackagers who would be willing to query for and apply these?

Another idea that leaps to mind is to add more provenpackagers... 
have we set the bar too high so no one wants to apply?

kevin

[Sandro Mani]

On 26.06.2014 18:42, Kevin Fenzi wrote:
>  On Thu, 26 Jun 2014 17:17:07 +0100
>  Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>
> > On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
> >> +1 from me!
> > If it's a trivial patch then I think it makes sense to just do it.
> >  From someone that touches hundreds of different projects every month,
> > I've found it's better to ask forgiveness than permission :)
>  Yeah, but the proposal is talking about when someone is not a
>  provenpackager and doesn't have permissions to just apply them. ;(
>
>  I'm not sure the entire group of provenpackagers would like to be
>  notified of such trivial patches waiting. Is there a group of
>  provenpackagers who would be willing to query for and apply these? 
I'd assume
it would be a group of packagers who would volunteer to do 
so. Just to be clear: I'm not a proven packager at this time, but since 
I'm proposing this I'd obviously also be happy to help out.
>  Another idea that leaps to mind is to add more provenpackagers...
>  have we set the bar too high so no one wants to apply? 
I guess unless you don't
have a real reason to do so (i.e. don't work on 
packages which can influence many other components of the distribution), 
you don't see an immediate reason to.

[Till Maas]

On Thu, Jun 26, 2014 at 10:42:17AM -0600, Kevin Fenzi wrote:

>  I'm not sure the entire group of provenpackagers would like to
> be
>  notified of such trivial patches waiting. Is there a group of
>  provenpackagers who would be willing to query for and apply these? 
I am.

>  Another idea that leaps to mind is to add more provenpackagers... 
>  have we set the bar too high so no one wants to apply? 
IMHO there is not a huge group needed to handle on-demand provenpackager
tasks (as long as it is only required to review and apply a patch to
dist-git and potential debugging/scratch building is done before).

Regards
Till

[Sandro Mani]

On 26.06.2014 19:04, Till Maas wrote:
>  IMHO there is not a huge group needed to handle on-demand
> provenpackager
>  tasks (as long as it is only required to review and apply a patch to
>  dist-git and potential debugging/scratch building is done before).
>  
Good point, adding to the previous conditions I'd add that the user must 
also provide a link to a scratch build.

[Bruno Wolff III]

On Thu, Jun 26, 2014 at 10:42:17 -0600,
  Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> Another idea that leaps to mind is to add more provenpackagers...
> have we set the bar too high so no one wants to apply? 
Trivial bug fixing across the project seems to be a reasonable justification 
for giving out proven packager status. As long as people know their 
limitations so that not too many mistakes get made.

[Ralf Corsepius]

On 06/26/2014 09:40 PM, Bruno Wolff III wrote:
>  On Thu, Jun 26, 2014 at 10:42:17 -0600,
>    Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> >
> > Another idea that leaps to mind is to add more provenpackagers...
> > have we set the bar too high so no one wants to apply?
>
>  Trivial bug fixing across the project seems to be a reasonable
>  justification for giving out proven packager status. 
Full ack.

>  As long as people
>  know their limitations so that not too many mistakes get made. 
Your last sentence
is the point, which makes me reluctant on the OPs 
proposal.

Unfortunately, Fedora has seen too many people who were not aware about 
the limitations of their skills and too many people, who were mixing up 
personal preference and stylishness with actual bugs.

Ralf

[Sandro Mani]

On 26.06.2014 21:40, Bruno Wolff III wrote:
>  On Thu, Jun 26, 2014 at 10:42:17 -0600,
>   Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
> >
> > Another idea that leaps to mind is to add more provenpackagers...
> > have we set the bar too high so no one wants to apply?
>
>  Trivial bug fixing across the project seems to be a reasonable 
>  justification for giving out proven packager status. As long as people 
>  know their limitations so that not too many mistakes get made. 
So just to clarify
here: the idea behind my proposal is not necessarily 
to aid people who often fix large number of small bugs across packages, 
for such people it is best if they applied for proven packager status. 
What I'm more interested in is improving the situation where a "common" 
user comes across this one very annoying bug, decides he wants to help 
out and fix it, and then ends up seeing his patch rotting away because 
no-one seems to care. Such situations can be frustrating and also 
discourage from submitting fixes in the future.

  Sandro

[Michael Catanzaro]

On Fri, 2014-06-27 at 12:48 +0200, Sandro Mani wrote:
>  So just to clarify here: the idea behind my proposal is not
>  necessarily 
>  to aid people who often fix large number of small bugs across
>  packages, 
>  for such people it is best if they applied for proven packager
>  status. 
>  What I'm more interested in is improving the situation where a
>  "common" 
>  user comes across this one very annoying bug, decides he wants to
>  help 
>  out and fix it, and then ends up seeing his patch rotting away
>  because 
>  no-one seems to care. Such situations can be frustrating and also 
>  discourage from submitting fixes in the future. 
Fedora can learn a lot from openSUSE here. In openSUSE the frustrated
user submits a merge request, and it gets looked at rather quickly,
since merge requests are rare while Bugzilla comments are common.
There's absolutely no need for a packager to be willing to give others
access to his package (though in openSUSE, groups of maintainers
maintain groups of packages, which probably works better since there are
more people to respond).

[drago01]

On Thu, Jun 26, 2014 at 6:42 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:
>  On Thu, 26 Jun 2014 17:17:07 +0100
>  Richard Hughes <hughsient(a)gmail.com&gt; wrote:
>
> > On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
> > > +1 from me!
> >
> > If it's a trivial patch then I think it makes sense to just do it.
> > From someone that touches hundreds of different projects every month,
> > I've found it's better to ask forgiveness than permission :)
>
>  Yeah, but the proposal is talking about when someone is not a
>  provenpackager and doesn't have permissions to just apply them. ;( 
We need to fix that.

[Mukundan Ragavan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


I think having a "trivial patch" policy and proven packager route of
implementation is a great idea!

On 06/26/2014 11:42 AM, Kevin Fenzi wrote:
>  provenpackagers who would be willing to query for and apply these?
>  
>  Another idea that leaps to mind is to add more provenpackagers... 
>  have we set the bar too high so no one wants to apply?
>   
Isn't it best for the project as a whole to have the bar for proven
packager high? :)

Mukundan.

- -- 
GPG key-ID: 00E8658D
====================
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCgAGBQJTrIIpAAoJEIfjPv0A6GWNTmcQAIGQ+HaTR36pU1gOydNJhTim
> clypJ8mCmKC81uWUvI8cFjN2y61gAf9vLsrSkbIP4vZoVIVhFODtWSuYrDhgdwaK
> 82+QZ89wvKqfq/aWSS8mlo1MJJ3vm7OhnI7zH+pbrVnbUmKbOd9tXapePJt6koXC
> S1Wyz/hBvqmXdafl/wGMFTBwieOe+bDRZTa6NNP4G8CksL1CNlg6L7oP3JWXtI0R
> 0dF3l9GUDSQGAN1+lQuGkmArTmiCqjr/lXQZR9OKMdcmXQhuEl+9kJd6klcMKI6r
> o6Qm5/4Pf3VKRixhUec88IA30YUDeqJP4IgNGv64fwI8uJgX65Fipxf7NxDyMJt9
> em0EOKNKjQtwnb3R0zr+YDbaWUCFCZVuiTFTHkaG5ojwezWE11+nJ5zaiI9i6WOJ
> rxl7bbhG29MEBhnJaiDnm4Zdk38IEuCld6zcIe8tM0E7vkNTzLQ2BMyPyS5Jnwx6
> UzuCfpzgMgfEMpE/j6r22prsEhbN/XEcd+vGkZpnFH1R/tTQcTFauiAc1UNODjpW
> A9TqidqHH/1wxCeVuZYupsAh2pYy18cC1MrrbkJ2OZl+qacog2xpz2O11p6gDKi+
> dkt31JF6Ftgc7CIuMYuNVU3WmKyUcXFROd6dpmmykN3ouDR14Iq7FWea0OM8Dsjh
> UHCBmAQitu/csPghf2u7
> =FOGa
> -----END PGP SIGNATURE-----

[Olav Vitters]

On Thu, Jun 26, 2014 at 03:27:21PM -0500, Mukundan Ragavan wrote:
>  Isn't it best for the project as a whole to have the bar for
> proven
>  packager high? :) 
I think it is detrimental. If someone has loads of time to do bugfixes
across packages, let them. I do loads and loads of trivial bugfixes (not
in Fedora). Stuff like cleaning spec files of old things. Changing
"http" into "https". Updating the URLs. Very trivial. The knowledge
required to do such things is trivial, the work usually is mundane.

What you need is to notice when someone is doing more that they can
handle and educate them (this is different than taking permissions away
asap).

High bar to me just means either things don't get done, or existing
people get overworked. Any project always needs new blood, they're going
to make mistakes. Possibility of mistakes shouldn't be used to block new
people IMO.
-- 
Regards,
Olav

[drago01]

On Thu, Jun 26, 2014 at 10:27 PM, Mukundan Ragavan
<nonamedotc(a)fedoraproject.org&gt; wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA512
>
>
>  I think having a "trivial patch" policy and proven packager route of
>  implementation is a great idea!
>
>  On 06/26/2014 11:42 AM, Kevin Fenzi wrote:
> > provenpackagers who would be willing to query for and apply these?
> >
> > Another idea that leaps to mind is to add more provenpackagers...
> > have we set the bar too high so no one wants to apply?
> >
>
>  Isn't it best for the project as a whole to have the bar for proven
>  packager high? :) 
No its very harmful. It drives contributors away because they cannot
.. well contribute.

[Jeff Backus]

On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi <kevin(a)scrye.com&gt; wrote:

>  I'm not sure the entire group of provenpackagers would like to be
>  notified of such trivial patches waiting. Is there a group of
>  provenpackagers who would be willing to query for and apply these?
>
>  
Maybe a simple way to allow non-provenpackagers to highlight these "trivial
bug" patches would be via a perma-bug a-la FE-NEEDSPONSOR? That way there
is a centralized place inclined provenpackages can check which doesn't
require following a mailing list and is simple enough even us n00bs can
figure it out. :)

I presume the implementation cost is miniscule, so might at least be worth
an experiment.

Regards,
Jeff

-- 
Jeff Backus
jeff.backus(a)gmail.com
http://github.com/jsbackus

[Sandro Mani]

On 26.06.2014 22:47, Jeff Backus wrote:
>  On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi <kevin(a)scrye.com 
>  <mailto:[e-mail]>> wrote:
>
>
>      I'm not sure the entire group of provenpackagers would like to be
>      notified of such trivial patches waiting. Is there a group of
>      provenpackagers who would be willing to query for and apply these?
>
>
>  Maybe a simple way to allow non-provenpackagers to highlight these 
>  "trivial bug" patches would be via a perma-bug a-la FE-NEEDSPONSOR? 
>  That way there is a centralized place inclined provenpackages can 
>  check which doesn't require following a mailing list and is simple 
>  enough even us n00bs can figure it out. :)
>
>  I presume the implementation cost is miniscule, so might at least be 
>  worth an experiment.
>  
So the thing that should be avoided IMO is not defining well enough how 
the procedure should work, to avoid getting swamped with patches which 
require additional work to apply. The requirement to fill out post a 
"New Package Request" style form to the bug should allow most of the 
work to be scripted, and ideally the proven packager would just need to 
look at the patch, and if happy, fire the script.

So maybe such a policy could look something like this [1]. Contrarily to 
what I wrote initially, I think it might actually make sense to allow 
also non-packagers to file such requests, and it would provide another 
way of showing off experience which will eventually lead to one getting 
sponsored.

  Sandro

[1] 
https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29

[Kevin Fenzi]

On Fri, 27 Jun 2014 00:39:52 +0200
Sandro Mani <manisandro(a)gmail.com&gt; wrote:

>  So the thing that should be avoided IMO is not defining well enough
>  how the procedure should work, to avoid getting swamped with patches
>  which require additional work to apply. The requirement to fill out
>  post a "New Package Request" style form to the bug should allow most
>  of the work to be scripted, and ideally the proven packager would
>  just need to look at the patch, and if happy, fire the script.
>  
>  So maybe such a policy could look something like this [1]. Contrarily
>  to what I wrote initially, I think it might actually make sense to
>  allow also non-packagers to file such requests, and it would provide
>  another way of showing off experience which will eventually lead to
>  one getting sponsored.
>  
>    Sandro
>  
>  [1] 
>  https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29 
A few comments: 

- Not sure 'trivial' really covers the things you list in examples.
  FTBFS could be more than trivial depending on the patch. Perhaps the
  entire thing could be 'simple patches' or 'easy patches' 

- 'flags' are a pain to get bugzilla folks to add and manage. How about
  a blocker bug instead? Then interested maintainers could simply cc to
  the blocker bug to notice when new things are added. You just add the
  patch bug to the blocks of the tracker. 

- Should this be rawhide only? That would avoid 'trivial' patches that
  cause a problem from affecting users that aren't as able to debug
  them. 

kevin

[Sandro Mani]

On 27.06.2014 00:55, Kevin Fenzi wrote:
>  On Fri, 27 Jun 2014 00:39:52 +0200
>  Sandro Mani <manisandro(a)gmail.com&gt; wrote:
>
> > So the thing that should be avoided IMO is not defining well enough
> > how the procedure should work, to avoid getting swamped with patches
> > which require additional work to apply. The requirement to fill out
> > post a "New Package Request" style form to the bug should allow most
> > of the work to be scripted, and ideally the proven packager would
> > just need to look at the patch, and if happy, fire the script.
> >
> > So maybe such a policy could look something like this [1]. Contrarily
> > to what I wrote initially, I think it might actually make sense to
> > allow also non-packagers to file such requests, and it would provide
> > another way of showing off experience which will eventually lead to
> > one getting sponsored.
> >
> >    Sandro
> >
> > [1]
> > https://fedoraproject.org/wiki/User:Smani/Trivial_Patch_Policy_%28draft%29
>  A few comments:
>
>  - Not sure 'trivial' really covers the things you list in examples.
>     FTBFS could be more than trivial depending on the patch. Perhaps the
>     entire thing could be 'simple patches' or 'easy patches' 
Right.
So the list Yaakov Selkowitz posted elsewhere in this thread 
gives a good set of possible FTBFS causes. I'm not sure all FTBFS should 
be covered by such a policy, but if it is only a matter of fixing bad 
BRs, format security issues or makefile issues, these should fall under 
the accepted category. If the FTBFS fix involves porting for API/ABI 
breaks, then IMO that does not fall under this category. But yeah, 
simple might be more appropriate terminology.
>  - 'flags' are a pain to get bugzilla folks to add and manage. How about
>     a blocker bug instead? Then interested maintainers could simply cc to
>     the blocker bug to notice when new things are added. You just add the
>     patch bug to the blocks of the tracker. 
I guess this would work just as well!
>  - Should this be rawhide only? That would avoid 'trivial'
> patches that
>     cause a problem from affecting users that aren't as able to debug
>     them. 
What about rawhide for all and stable releases for packagers only?


Draft updated accordingly.

Thanks,
Sandro

[Kevin Fenzi]

On Fri, 27 Jun 2014 01:27:23 +0200
Sandro Mani <manisandro(a)gmail.com&gt; wrote:

>  On 27.06.2014 00:55, Kevin Fenzi wrote: 
...snip...
>  > - Not sure 'trivial' really covers the things you list
> in examples.
>  >    FTBFS could be more than trivial depending on the patch. Perhaps
>  > the entire thing could be 'simple patches' or 'easy patches'
>  Right. So the list Yaakov Selkowitz posted elsewhere in this thread 
>  gives a good set of possible FTBFS causes. I'm not sure all FTBFS
>  should be covered by such a policy, but if it is only a matter of
>  fixing bad BRs, format security issues or makefile issues, these
>  should fall under the accepted category. If the FTBFS fix involves
>  porting for API/ABI breaks, then IMO that does not fall under this
>  category. But yeah, simple might be more appropriate terminology. 
Yeah, makes sense. 

>  > - 'flags' are a pain to get bugzilla folks to add and
> manage. How
>  > about a blocker bug instead? Then interested maintainers could
>  > simply cc to the blocker bug to notice when new things are added.
>  > You just add the patch bug to the blocks of the tracker.
>  I guess this would work just as well!
>  > - Should this be rawhide only? That would avoid 'trivial' patches
>  > that cause a problem from affecting users that aren't as able to
>  > debug them.
>  What about rawhide for all and stable releases for packagers only? 
Or perhaps (since they are simple/trivial) they could be applied in
stable releases, but not pushed as updates? They would go out with the
next update the maintainer pushed...

BTW, thanks for working on this. :) 

kevin

[Michael Catanzaro]

This is a really good idea.

On Thu, 2014-06-26 at 16:55 -0600, Kevin Fenzi wrote:
>  - Should this be rawhide only? That would avoid 'trivial'
> patches that
>    cause a problem from affecting users that aren't as able to debug
>    them.  
No, since the primary use for this would probably be backporting
upstream fixes. At least that's what I would use it for (if it's
available to non-packagers; I'm not a packager).

[Miloslav Trmač]

----- Original Message -----
>  - Should this be rawhide only? That would avoid 'trivial'
> patches that
>    cause a problem from affecting users that aren't as able to debug
>    them. 
Probably (or perhaps it could be up to the provenpackager applying the patch, but with
rawhide-only being the expected default).  One of the reasons the owner might not have
immediately applied the patch is that the situation is more complex than it seems (though
in that case commenting on the bug report would have been desirable), so we should be
somewhat careful about shipping changes preapred by non-experts to end-users.  Restricting
to rawhide would give us more time and freedom to discover and fix undesirable side
effects, if any.
    Mirek

[Ralf Corsepius]

On 06/27/2014 05:50 PM, Miloslav Trmač wrote:
>  ----- Original Message -----
> > - Should this be rawhide only? That would avoid 'trivial' patches that
> >    cause a problem from affecting users that aren't as able to debug
> >    them.
>
>  Probably (or perhaps it could be up to the provenpackager applying the patch, but with
> rawhide-only being the expected default). 
So far it's up to the individual who
applies a patch (and the 
maintainer), whether he pushes an update to non-rawhide.

Experience tells, this rarely is an actual problem.

>  One of the reasons the owner might not have immediately applied the
> patch is that the situation is more complex than it seems (though in that case commenting
> on the bug report would have been desirable), so we should be somewhat careful about
> shipping changes preapred by non-experts to end-users.  Restricting to rawhide would give
> us more time and freedom to discover and fix undesirable side effects, if any. 
I guess, you are aware that all non-rawhide package pushes currently go 
through a at minimum 1 week delay in updates-testing, which should give 
interested/affect users sufficient time to intervene in case something 
was missed?

Experience also tells here, this rarely is an actual problem.

Ralf

[Florian Weimer]

On 06/26/2014 06:42 PM, Kevin Fenzi wrote:
>  Another idea that leaps to mind is to add more provenpackagers...
>  have we set the bar too high so no one wants to apply? 
Debian has packages in collab-maint, where any Debian Developer can make 
changes and upload them.  In Debian, this is purely a social convention 
because the project doesn't have ACLs for Debian Developers, but there 
is a strong notion of package ownership despite the lack of technical 
enforcement.

Perhaps Fedora package maintainers could set a flag on their package 
which would grant access to anyone who maintains any other package? 
This way, package maintainers could gradually reduce the need for 
provenpackager privileges (similar to what Debian did with the 
introduction of the Debian Maintainer role, which is also governed by 
package ACLs).

-- 
Florian Weimer / Red Hat Product Security

[Kevin Fenzi]

On Fri, 27 Jun 2014 10:47:09 +0200
Florian Weimer <fweimer(a)redhat.com&gt; wrote:

>  On 06/26/2014 06:42 PM, Kevin Fenzi wrote:
>  > Another idea that leaps to mind is to add more provenpackagers...
>  > have we set the bar too high so no one wants to apply?
>  
>  Debian has packages in collab-maint, where any Debian Developer can
>  make changes and upload them.  In Debian, this is purely a social
>  convention because the project doesn't have ACLs for Debian
>  Developers, but there is a strong notion of package ownership despite
>  the lack of technical enforcement.
>  
>  Perhaps Fedora package maintainers could set a flag on their package 
>  which would grant access to anyone who maintains any other package? 
>  This way, package maintainers could gradually reduce the need for 
>  provenpackager privileges (similar to what Debian did with the 
>  introduction of the Debian Maintainer role, which is also governed by 
>  package ACLs). 
I think this is overcomplex, IMHO. I think in general people who are
granted provenpackager do a good job, and where they don't they can be
educated and helped. Most any mistake can be corrected... 

kevin

[Yaakov Selkowitz]

On 2014-06-26 11:17, Richard Hughes wrote:
>  On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt;
> wrote:
> > +1 from me!
>
>  If it's a trivial patch then I think it makes sense to just do it.
>   From someone that touches hundreds of different projects every month,
>  I've found it's better to ask forgiveness than permission :) 
As previously stated, that only works if you are a provenpackager.  The 
question is for those of us who are not, but are trying to help.

This seems to be particularly needed around mass rebuilds, which IMHO 
should be an "all-hands-on-deck" time.  For example, I've been going 
through the sizable F21FTBFS list[1][2], looking for arm-specific bugs 
and fixing what else I can along the way.  So far most of my ~100 
patches are just bitrotting in bugzilla, while branching is less than 
two weeks away.

As a newcomer to Fedora development, is there something else I should 
doing to get these patches reviewed and committed?


Yaakov Selkowitz

[1] http://ausil.fedorapeople.org/f21-failures.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1105908

[Kevin Fenzi]

On Thu, 26 Jun 2014 13:01:05 -0500
Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:

>  On 2014-06-26 11:17, Richard Hughes wrote:
>  > On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
>  >> +1 from me!
>  >
>  > If it's a trivial patch then I think it makes sense to just do it.
>  >  From someone that touches hundreds of different projects every
>  > month, I've found it's better to ask forgiveness than permission :)
>  
>  As previously stated, that only works if you are a provenpackager.
>  The question is for those of us who are not, but are trying to help.
>  
>  This seems to be particularly needed around mass rebuilds, which IMHO 
>  should be an "all-hands-on-deck" time.  For example, I've been going 
>  through the sizable F21FTBFS list[1][2], looking for arm-specific
>  bugs and fixing what else I can along the way.  So far most of my
>  ~100 patches are just bitrotting in bugzilla, while branching is less
>  than two weeks away.
>  
>  As a newcomer to Fedora development, is there something else I should 
>  doing to get these patches reviewed and committed? 
I'm pretty swamped, but I'm happy to go through them as time permits
and help apply/build them. 

I assume they are attached to each of the FTBFS bugs?

If other provenpackgers have time it would be great to apply these
before branching. 

kevin

[Yaakov Selkowitz]

On 2014-06-26 15:33, Kevin Fenzi wrote:
>  On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz wrote:
> > This seems to be particularly needed around mass rebuilds, which IMHO
> > should be an "all-hands-on-deck" time.  For example, I've been going
> > through the sizable F21FTBFS list[1][2], looking for arm-specific
> > bugs and fixing what else I can along the way.  So far most of my
> > ~100 patches are just bitrotting in bugzilla, while branching is less
> > than two weeks away.
> >
> > As a newcomer to Fedora development, is there something else I should
> > doing to get these patches reviewed and committed?
>
>  I'm pretty swamped, but I'm happy to go through them as time permits
>  and help apply/build them.
>
>  I assume they are attached to each of the FTBFS bugs? 
Or to the previously reported bugs (usually -Werror=format-security), 
upon which they are now marked as dependent.  I tested the patches with 
mock before posting.

Here are my unreviewed patches from last week or earlier, oldest to newest:

https://bugzilla.redhat.com/show_bug.cgi?id=1106267
https://bugzilla.redhat.com/show_bug.cgi?id=1037113
https://bugzilla.redhat.com/show_bug.cgi?id=1106672
https://bugzilla.redhat.com/show_bug.cgi?id=1106724
https://bugzilla.redhat.com/show_bug.cgi?id=1037027
https://bugzilla.redhat.com/show_bug.cgi?id=1106709
https://bugzilla.redhat.com/show_bug.cgi?id=1106627
https://bugzilla.redhat.com/show_bug.cgi?id=1037142
https://bugzilla.redhat.com/show_bug.cgi?id=1106999
https://bugzilla.redhat.com/show_bug.cgi?id=1106110
https://bugzilla.redhat.com/show_bug.cgi?id=1107056
https://bugzilla.redhat.com/show_bug.cgi?id=1106682
https://bugzilla.redhat.com/show_bug.cgi?id=1105998
https://bugzilla.redhat.com/show_bug.cgi?id=1107402
https://bugzilla.redhat.com/show_bug.cgi?id=1106318
https://bugzilla.redhat.com/show_bug.cgi?id=1037057
https://bugzilla.redhat.com/show_bug.cgi?id=1107365
https://bugzilla.redhat.com/show_bug.cgi?id=1106295
https://bugzilla.redhat.com/show_bug.cgi?id=1106983
https://bugzilla.redhat.com/show_bug.cgi?id=1037361
https://bugzilla.redhat.com/show_bug.cgi?id=1107410
https://bugzilla.redhat.com/show_bug.cgi?id=1107232
https://bugzilla.redhat.com/show_bug.cgi?id=1037369
https://bugzilla.redhat.com/show_bug.cgi?id=1106307
https://bugzilla.redhat.com/show_bug.cgi?id=1106116
https://bugzilla.redhat.com/show_bug.cgi?id=1105976
https://bugzilla.redhat.com/show_bug.cgi?id=1037084
https://bugzilla.redhat.com/show_bug.cgi?id=1106751
https://bugzilla.redhat.com/show_bug.cgi?id=1037245
https://bugzilla.redhat.com/show_bug.cgi?id=1107101
https://bugzilla.redhat.com/show_bug.cgi?id=1106182
https://bugzilla.redhat.com/show_bug.cgi?id=1105923
https://bugzilla.redhat.com/show_bug.cgi?id=1107057
https://bugzilla.redhat.com/show_bug.cgi?id=1107080
https://bugzilla.redhat.com/show_bug.cgi?id=1037190
https://bugzilla.redhat.com/show_bug.cgi?id=1105994
https://bugzilla.redhat.com/show_bug.cgi?id=1105945
https://bugzilla.redhat.com/show_bug.cgi?id=1106011
https://bugzilla.redhat.com/show_bug.cgi?id=1106235
https://bugzilla.redhat.com/show_bug.cgi?id=1107042
https://bugzilla.redhat.com/show_bug.cgi?id=1106795
https://bugzilla.redhat.com/show_bug.cgi?id=1106018
https://bugzilla.redhat.com/show_bug.cgi?id=1037184
https://bugzilla.redhat.com/show_bug.cgi?id=1037185
https://bugzilla.redhat.com/show_bug.cgi?id=1037186
https://bugzilla.redhat.com/show_bug.cgi?id=1037390
https://bugzilla.redhat.com/show_bug.cgi?id=1037394
https://bugzilla.redhat.com/show_bug.cgi?id=1107271
https://bugzilla.redhat.com/show_bug.cgi?id=1106024
https://bugzilla.redhat.com/show_bug.cgi?id=1106029
https://bugzilla.redhat.com/show_bug.cgi?id=1037083
https://bugzilla.redhat.com/show_bug.cgi?id=1106247
https://bugzilla.redhat.com/show_bug.cgi?id=1107282
https://bugzilla.redhat.com/show_bug.cgi?id=1037207
https://bugzilla.redhat.com/show_bug.cgi?id=1037382
https://bugzilla.redhat.com/show_bug.cgi?id=1037396
https://bugzilla.redhat.com/show_bug.cgi?id=1105990

>  If other provenpackgers have time it would be great to apply these
>  before branching. 
Thanks,

Yaakov Selkowitz

[Richard Hughes]

On 26 June 2014 23:53, Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:
>  Here are my unreviewed patches from last week or earlier, oldest to
> newest: 
Someone make this person a provenpackager.

Richard.

[Dan Horák]

On Thu, 26 Jun 2014 17:53:08 -0500
Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:

>  On 2014-06-26 15:33, Kevin Fenzi wrote:
>  > On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz wrote:
>  >> This seems to be particularly needed around mass rebuilds, which
>  >> IMHO should be an "all-hands-on-deck" time.  For example, I've
>  >> been going through the sizable F21FTBFS list[1][2], looking for
>  >> arm-specific bugs and fixing what else I can along the way.  So
>  >> far most of my ~100 patches are just bitrotting in bugzilla, while
>  >> branching is less than two weeks away.
>  >>
>  >> As a newcomer to Fedora development, is there something else I
>  >> should doing to get these patches reviewed and committed?
>  >
>  > I'm pretty swamped, but I'm happy to go through them as time permits
>  > and help apply/build them.
>  >
>  > I assume they are attached to each of the FTBFS bugs?
>  
>  Or to the previously reported bugs (usually -Werror=format-security), 
>  upon which they are now marked as dependent.  I tested the patches
>  with mock before posting.
>  
>  Here are my unreviewed patches from last week or earlier, oldest to
>  newest:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106267
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037113
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106672
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106724
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037027
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106709
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106627
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037142
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106999
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106110
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107056
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106682
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105998
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107402
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106318
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037057
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107365
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106295
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106983
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037361
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107410
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107232
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037369
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106307
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106116
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105976
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037084
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106751
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037245
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107101
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106182
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105923
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107057
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107080
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037190
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105994
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105945
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106011
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106235
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107042
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106795
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106018
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037184
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037185
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037186
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037390
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037394
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107271
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106024
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106029
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037083
>  https://bugzilla.redhat.com/show_bug.cgi?id=1106247
>  https://bugzilla.redhat.com/show_bug.cgi?id=1107282
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037207
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037382
>  https://bugzilla.redhat.com/show_bug.cgi?id=1037396
>  https://bugzilla.redhat.com/show_bug.cgi?id=1105990
>  
>  > If other provenpackgers have time it would be great to apply these
>  > before branching. 
oh, that's an impressive list, but I would like see to one more thing
there - links to upstream bug reports where relevant (eg. fixing
configure stuff), because we usually need them fixed in upstreams too


		Dan

[Till Maas]

On Fri, Jun 27, 2014 at 10:05:31AM +0200, Dan Horák wrote:

>  oh, that's an impressive list, but I would like see to one more
> thing
>  there - links to upstream bug reports where relevant (eg. fixing
>  configure stuff), because we usually need them fixed in upstreams too 
Yes, I missed this as well. Also IIRC the guidelines demand an patch
status comment for each patch in the spec file, so just adding patch
without noting why it is not upstreamable or information about when/how
it was upstreamed is bad and should IMHO not be done by provenpackagers.

Regards
Till

[Yaakov Selkowitz]

On 2014-06-27 10:17, Till Maas wrote:
>  Yes, I missed this as well. Also IIRC the guidelines demand an patch
>  status comment for each patch in the spec file, so just adding patch
>  without noting why it is not upstreamable or information about when/how
>  it was upstreamed is bad and should IMHO not be done by provenpackagers. 
When patching others' code, I generally follow the existing style; I can 
tell you that *many* packages don't have these patch comments.  Thanks 
for bringing this to my attention.

But that does raise the question of whose responsibility it is to 
upstream patches, the contributor or the package maintainer?


Yaakov Selkowitz

[Rahul Sundaram]

Hi


On Fri, Jun 27, 2014 at 11:36 AM, Yaakov Selkowitz wrote:

>  On 2014-06-27 10:17, Till Maas wrote:
>
> > Yes, I missed this as well. Also IIRC the guidelines demand an patch
> > status comment for each patch in the spec file, so just adding patch
> > without noting why it is not upstreamable or information about when/how
> > it was upstreamed is bad and should IMHO not be done by provenpackagers.
> >
>
>  When patching others' code, I generally follow the existing style; I can
>  tell you that *many* packages don't have these patch comments.  Thanks for
>  bringing this to my attention.
>  
The guidelines don't demand it but it is recommended

https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelin...

https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Work_w...

https://fedoraproject.org/wiki/Staying_close_to_upstream_projects

Rahul

[Ralf Corsepius]

On 06/27/2014 05:50 PM, Rahul Sundaram wrote:
>  Hi
>
>
>  On Fri, Jun 27, 2014 at 11:36 AM, Yaakov Selkowitz wrote:
>
>      On 2014-06-27 10:17, Till Maas wrote:
>
>          Yes, I missed this as well. Also IIRC the guidelines demand an patch
>          status comment for each patch in the spec file, so just adding patch
>          without noting why it is not upstreamable or information about
>          when/how
>          it was upstreamed is bad and should IMHO not be done by
>          provenpackagers.
>
>
>      When patching others' code, I generally follow the existing style; I
>      can tell you that *many* packages don't have these patch comments.
>        Thanks for bringing this to my attention.
>
>
>  The guidelines don't demand it but it is recommended 
Thanks for digging out these links - This matches with my memory, 
unfortuately I could not find them when responding eariler.

The intention of all this is to keep the amount of patches in Fedora low 
and to "pay it back to upstreams" iff possible.

However, in many (most?) cases this is not possible or feasible.

Ralf

[Till Maas]

On Fri, Jun 27, 2014 at 06:02:09PM +0200, Ralf Corsepius wrote:

>  The intention of all this is to keep the amount of patches in Fedora
> low and
>  to "pay it back to upstreams" iff possible.
>  
>  However, in many (most?) cases this is not possible or feasible. 
It is always possible to add a comment to the SPEC and it is enough to
justify why the patch cannot be upstreamed, if this is the case. This
saves fellow maintainers the time to investigate why the patch is not
upstreamed or does not have a comment.

Regards
Till

[Ralf Corsepius]

On 06/27/2014 05:17 PM, Till Maas wrote:
>  On Fri, Jun 27, 2014 at 10:05:31AM +0200, Dan Horák wrote:
>
> > oh, that's an impressive list, but I would like see to one more thing
> > there - links to upstream bug reports where relevant (eg. fixing
> > configure stuff), because we usually need them fixed in upstreams too
>
>  Yes, I missed this as well. Also IIRC the guidelines demand an patch
>  status comment for each patch in the spec file, so just adding patch
>  without noting why it is not upstreamable or information about when/how
>  it was upstreamed is bad and should IMHO not be done by provenpackagers. 
As in many cases before, I once more have to disagree with you, because 
this approach is not applicable in many cases nor helpful to Fedora and 
its users.

Ralf

[Till Maas]

On Fri, Jun 27, 2014 at 05:55:41PM +0200, Ralf Corsepius wrote:

>  As in many cases before, I once more have to disagree with you,
> because this 
Please refrain from personal attacks and note the Fedora code of
conduct:
https://fedoraproject.org/code-of-conduct


Thank you
Till

[Reindl Harald]

Am 30.06.2014 18:37, schrieb Till Maas:
>  On Fri, Jun 27, 2014 at 05:55:41PM +0200, Ralf Corsepius wrote:
>  
> > As in many cases before, I once more have to disagree with you, because this
>  
>  Please refrain from personal attacks and note the Fedora code of
>  conduct:
>  https://fedoraproject.org/code-of-conduct 
please refrain from taking anything as personal attack

[Josh Boyer]

On Mon, Jun 30, 2014 at 12:37 PM, Till Maas <opensource(a)till.name&gt; wrote:
>  On Fri, Jun 27, 2014 at 05:55:41PM +0200, Ralf Corsepius wrote:
>
> > As in many cases before, I once more have to disagree with you, because this
>
>  Please refrain from personal attacks and note the Fedora code of
>  conduct:
>  https://fedoraproject.org/code-of-conduct 
Ralf didn't attack you personally or otherwise.  He disagreed with
you.  Disagreement is common place and honestly his phrasing was
perfectly acceptable.

josh

[Till Maas]

On Mon, Jun 30, 2014 at 12:54:42PM -0400, Josh Boyer wrote:
>  On Mon, Jun 30, 2014 at 12:37 PM, Till Maas
> <opensource(a)till.name&gt; wrote:
>  > On Fri, Jun 27, 2014 at 05:55:41PM +0200, Ralf Corsepius wrote:
>  >
>  >> As in many cases before, I once more have to disagree with you, because this
>  >
>  > Please refrain from personal attacks and note the Fedora code of
>  > conduct:
>  > https://fedoraproject.org/code-of-conduct
>  
>  Ralf didn't attack you personally or otherwise.  He disagreed with
>  you.  Disagreement is common place and honestly his phrasing was
>  perfectly acceptable. 
If he just writes that he disagrees with me, I agree with you. But
highlighting that he disagreed with me many times in the past is
personal and has no relevance to whether or not comments should be added
to patches in SPEC files.

Regards
Till

[Reindl Harald]

Am 30.06.2014 19:06, schrieb Till Maas:
>  On Mon, Jun 30, 2014 at 12:54:42PM -0400, Josh Boyer wrote:
> > On Mon, Jun 30, 2014 at 12:37 PM, Till Maas <opensource(a)till.name&gt; wrote:
> >> On Fri, Jun 27, 2014 at 05:55:41PM +0200, Ralf Corsepius wrote:
> >>
> >>> As in many cases before, I once more have to disagree with you, because this
> >>
> >> Please refrain from personal attacks and note the Fedora code of
> >> conduct:
> >> https://fedoraproject.org/code-of-conduct
> >
> > Ralf didn't attack you personally or otherwise.  He disagreed with
> > you.  Disagreement is common place and honestly his phrasing was
> > perfectly acceptable.
>  
>  If he just writes that he disagrees with me, I agree with you. But
>  highlighting that he disagreed with me many times in the past is
>  personal and has no relevance to whether or not comments should be added
>  to patches in SPEC files. 
but it remains *far away* from personal attacks
if people want to be insulted they will find a reason....

[Till Maas]

On Mon, Jun 30, 2014 at 07:12:06PM +0200, Reindl Harald wrote:
>  
>  Am 30.06.2014 19:06, schrieb Till Maas: 
>  > If he just writes that he disagrees with me, I agree with you.
> But
>  > highlighting that he disagreed with me many times in the past is
>  > personal and has no relevance to whether or not comments should be added
>  > to patches in SPEC files.
>  
>  but it remains *far away* from personal attacks
>  if people want to be insulted they will find a reason.... 
Either it is a personal attack or not. You agreed the statement was
personal (at least starting your sentence with "but" implies agreement
to me) and IMHO it is clear that he was not supporting me, so all
conditions for a personal attack are fulfilled. It does not say anything
about the severity of the attack. Nevertheless, I would like to enjoy
factual discussions here. The Wikipedia page regarding personal attacks
withing their project summaries it nicely in the first two sentences:

http://en.wikipedia.org/wiki/Wikipedia:No_personal_attacks
| Do not make personal attacks anywhere in Wikipedia. Comment on
| content, not on the contributor.

Regards
Till

[Marcela Mašláňová]

On 26/06/14 22:33, Kevin Fenzi wrote:
>  On Thu, 26 Jun 2014 13:01:05 -0500
>  Yaakov Selkowitz <yselkowi(a)redhat.com&gt; wrote:
>
> > On 2014-06-26 11:17, Richard Hughes wrote:
> >> On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
> >>> +1 from me!
> >>
> >> If it's a trivial patch then I think it makes sense to just do it.
> >>   From someone that touches hundreds of different projects every
> >> month, I've found it's better to ask forgiveness than permission :)
> >
> > As previously stated, that only works if you are a provenpackager.
> > The question is for those of us who are not, but are trying to help.
> >
> > This seems to be particularly needed around mass rebuilds, which IMHO
> > should be an "all-hands-on-deck" time.  For example, I've been going
> > through the sizable F21FTBFS list[1][2], looking for arm-specific
> > bugs and fixing what else I can along the way.  So far most of my
> > ~100 patches are just bitrotting in bugzilla, while branching is less
> > than two weeks away.
> >
> > As a newcomer to Fedora development, is there something else I should
> > doing to get these patches reviewed and committed?
>
>  I'm pretty swamped, but I'm happy to go through them as time permits
>  and help apply/build them.
>
>  I assume they are attached to each of the FTBFS bugs?
>
>  If other provenpackgers have time it would be great to apply these
>  before branching.
>
>  kevin
>
>
>  
I'm not sure if it's so great idea for all bugzillas. Some packagers 
prefer to add patches first into upstream then carry a patch for many 
releases.

FTBFS bugs are different, I guess it's okay to fix them immediately. It 
can hardly do more harm.

Marcela

[Ralf Corsepius]

On 06/27/2014 08:26 AM, Marcela Mašláňová wrote:

>  I'm not sure if it's so great idea for all bugzillas. Some
> packagers
>  prefer to add patches first into upstream then carry a patch for many
>  releases. 
This consideration actually is pretty much irrelevant when it comes to 
bugs. The only thing that counts is Fedora end-user experience, to whom 
it's quite irrelevant who fixes a bug.

In other words, if bug affects users, these should be fixed in Fedora 
ASAP, no matter how.

>  FTBFS bugs are different, I guess it's okay to fix them
> immediately. It
>  can hardly do more harm. 
No, they need the same carefulness and same considerations
as any other 
bug fix.

Ralf

[Florian Weimer]

On 06/27/2014 08:58 AM, Ralf Corsepius wrote:
>  This consideration actually is pretty much irrelevant when it comes
> to
>  bugs. The only thing that counts is Fedora end-user experience, to whom
>  it's quite irrelevant who fixes a bug. 
Is this really true?  I'm under the impression that Fedora also cares 
about sustainable solutions.  These two goals sometimes conflict.  They 
have to be weighed against each other, but there is no general rule 
which goal is more important.

-- 
Florian Weimer / Red Hat Product Security

[Ralf Corsepius]

On 06/27/2014 10:46 AM, Florian Weimer wrote:
>  On 06/27/2014 08:58 AM, Ralf Corsepius wrote:
> > This consideration actually is pretty much irrelevant when it comes to
> > bugs. The only thing that counts is Fedora end-user experience, to whom
> > it's quite irrelevant who fixes a bug.
>
>  Is this really true? 
It's my personal opinion based on what I would assume to
be common 
sense, based on a distro's user-side expectation.

End-users are expecting function and bugs they are suffering from to be 
fixed, ASAP - Nothing else.

>   I'm under the impression that Fedora also cares
>  about sustainable solutions. 
Sure. This is the dev-focused perspective. But from an
end-user's 
perspective, this aspect is widely negligible.

>   These two goals sometimes conflict. 
Sure, these occasionally
do.

>   They
>  have to be weighed against each other, but there is no general rule
>  which goal is more important. 
As I see it, in practice in Fedora, these conflict,
because rawhide 
tries to be dev-focused (and end-user unstable), while Fedora N is 
end-user focused.

Ralf

[Michael Catanzaro]

On Fri, 2014-06-27 at 08:58 +0200, Ralf Corsepius wrote:
>  This consideration actually is pretty much irrelevant when it comes
>  to 
>  bugs. The only thing that counts is Fedora end-user experience, to
>  whom 
>  it's quite irrelevant who fixes a bug.
>  
>  In other words, if bug affects users, these should be fixed in Fedora 
>  ASAP, no matter how. 
I agree. If a maintainer objects to a patch, all he has to do is respond
to the bug report. This proposal should only cover the case where the
maintainer does not respond to the bug report within, say, one week
after the patch has been attached.

[Miloslav Trmač]

----- Original Message -----
>  On 06/27/2014 08:26 AM, Marcela Mašláňová wrote:
>  
>  > I'm not sure if it's so great idea for all bugzillas. Some packagers
>  > prefer to add patches first into upstream then carry a patch for many
>  > releases.
>  This consideration actually is pretty much irrelevant when it comes to
>  bugs. The only thing that counts is Fedora end-user experience, to whom
>  it's quite irrelevant who fixes a bug.
>  
>  In other words, if bug affects users, these should be fixed in Fedora
>  ASAP, no matter how. 
That’s only in some ideal case where we can get all the manpower we might need.

Adding a non-upstream patch to a package by a non-owner of the package essentially commits
the owner of the package to either push the patch upstream or to keep rebasing it on top
of the upstream releases; something the package owner, based on past practice, didn’t sign
up for and might never have time for.

It seems strange that we would be willing to impose such non-optional work on a package
owner for a patch someone could have just as well sent upstream, when we don’t even impose
such non-optional work on the package owner for things they are directly responsible for
and have no other upstream, such as updating the package to follow changes in packaging
guidelines.

That’s not to say that Fedora should never have non-upstream patches, nor even that
provenpackagers should never apply non-upstream patches, but drive-by-patching by people
who are not on the hook for long-term mainteinance should IMHO _strongly_ default to
submitting patches upstream first or instead.
    Mirek

[Kevin Fenzi]

On Fri, 27 Jun 2014 11:55:37 -0400 (EDT)
Miloslav Trmač <mitr(a)redhat.com&gt; wrote:

>  That’s only in some ideal case where we can get all the manpower we
>  might need.
>  
>  Adding a non-upstream patch to a package by a non-owner of the
>  package essentially commits the owner of the package to either push
>  the patch upstream or to keep rebasing it on top of the upstream
>  releases; something the package owner, based on past practice, didn’t
>  sign up for and might never have time for.
>  
>  It seems strange that we would be willing to impose such non-optional
>  work on a package owner for a patch someone could have just as well
>  sent upstream, when we don’t even impose such non-optional work on
>  the package owner for things they are directly responsible for and
>  have no other upstream, such as updating the package to follow
>  changes in packaging guidelines.
>  
>  That’s not to say that Fedora should never have non-upstream patches,
>  nor even that provenpackagers should never apply non-upstream
>  patches, but drive-by-patching by people who are not on the hook for
>  long-term mainteinance should IMHO _strongly_ default to submitting
>  patches upstream first or instead. Mirek 
Well, I think you are talking here about a patch that changes the code
of the package. Many of the cases people were talking about for these
'trivial' or 'simple' patches didn't even touch the code... they
simply
modified the spec, so have little to do with upstream (unless they also
want to apply the fix to any spec they have). 

There's a lot of different cases here... 

kevin

[Sandro Mani]

On 27.06.2014 18:56, Kevin Fenzi wrote:
>  Well, I think you are talking here about a patch that changes the
> code
>  of the package. Many of the cases people were talking about for these
>  'trivial' or 'simple' patches didn't even touch the code... they
> simply
>  modified the spec, so have little to do with upstream (unless they also
>  want to apply the fix to any spec they have).
>  
Indeed, I think this would be interesting mostly for issues concerning 
the packaging aspect, not the code itself. The biggest exception to this 
are FTBFS issues, which may in certain occasions indeed touch the code, 
but usually the fix only requires generic knowledge of the respective 
programming language, not specific knowledge of the software package. 
For anything that touches code in a non-trivial way, I'd make it 
mandatory to have the code upstream first, to avoid a) the patch staying 
downstream forever and ending up being a burden to the maintainer and b) 
to ensure at least one pair of expert eyes looked and approved the code.

So to summarize, what should be accepted:
- Spec and build script changes for the following cases:
  * FTBFS issues
  * clear mistakes which causes issues for other packages
- Changes to the code:
   * In case of a FTBFS, only generic, trivial changes (format security 
changes would be an example)
   * In other cases, only small patches to fix specific serious problems 
(crashes, incorrect behavior), and *only* with an upstream commit.
* Changes to fix obvious distribution integration issues (i.e. desktop 
file with missing icon): such fixes might require changes to the spec, 
to a non-upstream source, or to the upstream source. In the latter case, 
the changes must be accepted upstream first.


Sandro

[Sandro Mani]

Since the discussion seems to have pretty much died down and the 
reaction favourable, at least to the point that there is agreement that 
such situations are problematic, I've submitted FESCo ticket with the 
proposal [1]. Thanks for all inputs so far, and happy to hear further 
suggestions.

Sandro


[1] https://fedorahosted.org/fesco/ticket/1320

[Mikolaj Izdebski]

On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote:
>  On 2014-06-26 11:17, Richard Hughes wrote:
> > On 26 June 2014 17:02, Simone Caronni <negativo17(a)gmail.com&gt; wrote:
> >> +1 from me!
> >
> > If it's a trivial patch then I think it makes sense to just do it.
> >  From someone that touches hundreds of different projects every month,
> > I've found it's better to ask forgiveness than permission :)
>  
>  As previously stated, that only works if you are a provenpackager.  The
>  question is for those of us who are not, but are trying to help. 
There's always an option of finding a provenpackager willing to apply
the patch.

Example: In March Michael Simacek prepared over 400 patches and sent
them to me in bulk. After review I applied them all. You can see the
commits at [1] (look for "Use Requires: java-headless rebuild" threads).

>  As a newcomer to Fedora development, is there something else I
> should
>  doing to get these patches reviewed and committed? 
I offered you on IRC applying any patches for Java packages, as this is
my area of expertise.  I suggested either emailing them in bulk or
following the procedure I use [2]. Have you considered this?

[1]
https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-2014032...
[2] https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Yaakov Selkowitz]

On 2014-06-27 07:09, Mikolaj Izdebski wrote:
>  On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote:
> > As a newcomer to Fedora development, is there something else I should
> > doing to get these patches reviewed and committed?
>
>  I offered you on IRC applying any patches for Java packages, as this is
>  my area of expertise.  I suggested either emailing them in bulk or
>  following the procedure I use [2]. Have you considered this? 
Thanks, I have Keyworded and CCd you on the Java bugs.


Yaakov Selkowitz

[Mikolaj Izdebski]

On 06/27/2014 09:39 PM, Yaakov Selkowitz wrote:
>  On 2014-06-27 07:09, Mikolaj Izdebski wrote:
> > On 06/26/2014 08:01 PM, Yaakov Selkowitz wrote:
> >> As a newcomer to Fedora development, is there something else I should
> >> doing to get these patches reviewed and committed?
> >
> > I offered you on IRC applying any patches for Java packages, as this is
> > my area of expertise.  I suggested either emailing them in bulk or
> > following the procedure I use [2]. Have you considered this?
>  
>  Thanks, I have Keyworded and CCd you on the Java bugs. 
I've reviewed all the patches, but only two of them were OK for me to
apply.  In case the patch was inappropriate or not good enough I have
replied to the bug with the reason.

-- 
Mikolaj Izdebski
Software Engineer, Red Hat
IRC: mizdebsk

[Lubomir Rintel]

On Thu, 2014-06-26 at 17:50 +0200, Sandro Mani wrote:
>  Hi,
>  
>   From time to time, I see trivial patches posted in bugzilla which end 
>  up sitting there because the maintainer is too busy / gets bombarded 
>  with tons of bugzilla mails and misses that particular one / whatever 
>  reason. As a packager, sometimes it seems very hard to get such trivial 
>  patches applied. 
...

As a package maintainer, who quite often sees trivial bug reports with
fix suggestions or patches attached, I often wish I could just silently
agree (or disagree with a git revert) with a change that someone else
pushed or maybe a pull the fix from a branch instead of manually
applying a change from Bugzilla.

Regards,
Lubo