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
+1 from me! On Jun 26, 2014 5:51 PM, "Sandro Mani" manisandro@gmail.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
Il 26/06/2014 18:17, Richard Hughes ha scritto:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
On Thu, 26 Jun 2014 17:17:07 +0100 Richard Hughes hughsient@gmail.com wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
On 26.06.2014 18:42, Kevin Fenzi wrote:
On Thu, 26 Jun 2014 17:17:07 +0100 Richard Hughes hughsient@gmail.com wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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.
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
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.
On Thu, Jun 26, 2014 at 10:42:17 -0600, Kevin Fenzi kevin@scrye.com 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.
On 06/26/2014 09:40 PM, Bruno Wolff III wrote:
On Thu, Jun 26, 2014 at 10:42:17 -0600, Kevin Fenzi kevin@scrye.com 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
On 26.06.2014 21:40, Bruno Wolff III wrote:
On Thu, Jun 26, 2014 at 10:42:17 -0600, Kevin Fenzi kevin@scrye.com 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
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).
On Thu, Jun 26, 2014 at 6:42 PM, Kevin Fenzi kevin@scrye.com wrote:
On Thu, 26 Jun 2014 17:17:07 +0100 Richard Hughes hughsient@gmail.com wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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.
-----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 ====================
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.
On Thu, Jun 26, 2014 at 10:27 PM, Mukundan Ragavan nonamedotc@fedoraproject.org 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.
On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi kevin@scrye.com 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
On 26.06.2014 22:47, Jeff Backus wrote:
On Thu, Jun 26, 2014 at 12:42 PM, Kevin Fenzi <kevin@scrye.com mailto:kevin@scrye.com> 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
On Fri, 27 Jun 2014 00:39:52 +0200 Sandro Mani manisandro@gmail.com 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
On 27.06.2014 00:55, Kevin Fenzi wrote:
On Fri, 27 Jun 2014 00:39:52 +0200 Sandro Mani manisandro@gmail.com 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
On Fri, 27 Jun 2014 01:27:23 +0200 Sandro Mani manisandro@gmail.com 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
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).
----- 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
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
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).
On Fri, 27 Jun 2014 10:47:09 +0200 Florian Weimer fweimer@redhat.com 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
On 2014-06-26 11:17, Richard Hughes wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz yselkowi@redhat.com wrote:
On 2014-06-26 11:17, Richard Hughes wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
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
On 26 June 2014 23:53, Yaakov Selkowitz yselkowi@redhat.com wrote:
Here are my unreviewed patches from last week or earlier, oldest to newest:
Someone make this person a provenpackager.
Richard.
On Thu, 26 Jun 2014 17:53:08 -0500 Yaakov Selkowitz yselkowi@redhat.com 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
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
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
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/Guidelines#...
https://fedoraproject.org/wiki/Package_maintainer_responsibilities#Work_with...
https://fedoraproject.org/wiki/Staying_close_to_upstream_projects
Rahul
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
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
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
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
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
On Mon, Jun 30, 2014 at 12:37 PM, Till Maas opensource@till.name 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
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@till.name 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
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@till.name 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....
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
On 26/06/14 22:33, Kevin Fenzi wrote:
On Thu, 26 Jun 2014 13:01:05 -0500 Yaakov Selkowitz yselkowi@redhat.com wrote:
On 2014-06-26 11:17, Richard Hughes wrote:
On 26 June 2014 17:02, Simone Caronni negativo17@gmail.com 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
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
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.
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
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.
----- 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
On Fri, 27 Jun 2014 11:55:37 -0400 (EDT) Miloslav Trmač mitr@redhat.com 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
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
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
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@gmail.com 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-20140324/t... [2] https://fedoraproject.org/wiki/User:Mizdebsk/HowToSubmitPatches
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
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.
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
-
Bruno Wolff III -
Dan Horák -
drago01 -
Florian Weimer -
gil -
Jeff Backus -
Josh Boyer -
Kevin Fenzi -
Lubomir Rintel -
Marcela Mašláňová -
Michael Catanzaro -
Mikolaj Izdebski -
Miloslav Trmač -
Mukundan Ragavan -
Olav Vitters -
Rahul Sundaram -
Ralf Corsepius -
Reindl Harald -
Richard Hughes -
Sandro Mani -
Simone Caronni -
Till Maas -
Yaakov Selkowitz