[opensuse-buildservice] bugzilla or OBS for pushing patches upstream
Hello All, I'm curious to know if there's a preferred method for pushing features/patches to packages upstream in the distribution. I created a feature/bug request in bugzilla to which the response was basically "patches are welcome". So I patched and tested this feature to the app and posted the patches to the bugzilla ticket and nothing, no response or followups. That's fine, i know people are busy and my request may not be of much importance to others, but I do feel this feature is valuable and it's availability will be a dependency on another packaging modification request I plan on creating. At this point would I be better served by branching the package in OBS, applying my patches, and creating an SR or just wait for the things to work there way through bugzilla? While I'd like to see this pushed out to all supported distro releases I realize this may not be an option, but with the 12.2 RC around the corner I'd be happy with it making that release. Thanks! -- Later, Darin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, 30 Mar 2012 09:17:04 -0400
Darin Perusich
Hello All,
I'm curious to know if there's a preferred method for pushing features/patches to packages upstream in the distribution. I created a feature/bug request in bugzilla to which the response was basically "patches are welcome". So I patched and tested this feature to the app and posted the patches to the bugzilla ticket and nothing, no response or followups. That's fine, i know people are busy and my request may not be of much importance to others, but I do feel this feature is valuable and it's availability will be a dependency on another packaging modification request I plan on creating.
At this point would I be better served by branching the package in OBS, applying my patches, and creating an SR or just wait for the things to work there way through bugzilla? While I'd like to see this pushed out to all supported distro releases I realize this may not be an option, but with the 12.2 RC around the corner I'd be happy with it making that release.
Thanks! -- Later, Darin Hi I normally branch, push patches upstream and reference in the spec file etc as required here; http://en.opensuse.org/openSUSE:Packaging_Patches_guidelines
-- Cheers Malcolm °¿° (Linux Counter #276890) SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default up 18:52, 3 users, load average: 0.07, 0.07, 0.06 CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Mar 30, 2012 at 09:17:04AM -0400, Darin Perusich wrote:
I'm curious to know if there's a preferred method for pushing features/patches to packages upstream in the distribution.
Unfortunately ther is no single way to make it right. For Samba we take everything and don't complain if you don't do it the right way. Cause we care only about getting issues solved. If we have to adjust a patch slightly and it's an easy task, we simply do it. If you offer us a patch for lets say the Samba 3.0 - which reached its upstream EOL quite some time back - we would say: Nice, but please also offer us a patch against the git.samba.org master branch as well. We have the move of our Samba stuff to a public git tree on our agenda. The SUSE Linux kernel is mainly mainrtained in git and from there the package sources are generated.
I created a feature/bug request in bugzilla to which the response was basically "patches are welcome". So I patched and tested this feature to the app and posted the patches to the bugzilla ticket and nothing, no response or followups. That's fine, i know people are busy and my request may not be of much importance to others, but I do feel this feature is valuable and it's availability will be a dependency on another packaging modification request I plan on creating.
Asking back here is correct. More help and inparticular more specifric you might get as soon as you include the particular software component you're working on.
At this point would I be better served by branching the package in OBS, applying my patches, and creating an SR or just wait for the things to work there way through bugzilla?
Your move to raise the issue here I consider a the right approaoch in general.
While I'd like to see this pushed out to all supported distro releases I realize this may not be an option, but with the 12.2 RC around the corner I'd be happy with it making that release.
Getting this into 12.2 is welcom. Getting a backported fix into released products is welcom too. Here the road to follow depends on what you'r egoing to patch. If you go to fix a Linux kernel issue it's less likely to lift more than the minor version. Same applies to same base package like glibc. Samba is at the other end of the dependency stack. Cheers, Lars -- Lars Müller [ˈlaː(r)z ˈmʏlɐ] Samba Team SUSE Linux, Maxfeldstraße 5, 90409 Nürnberg, Germany
Hi Lars,
On Fri, Mar 30, 2012 at 9:36 AM, Lars Müller
Asking back here is correct. More help and inparticular more specifric you might get as soon as you include the particular software component you're working on.
I'm trying to get these patches applied against pam-config, they extend it to support the ecryptfs pam modules bug 752851. Once ecryptfs support is available in pam-config I'll create another SR against ecryptfs-utils so it's calls "pam-config -a --ecryptfs" during %post and "pam-config -d --ecryptfs" during %postun. This is dependent on Bug 740110 which is currently under audit review for making /sbin/mount.ecryptfs_private setuid. Basically my end goal is to see the seamless integration of encryptfs into OpenSUSE as it is in Debian and Ubuntu.
At this point would I be better served by branching the package in OBS, applying my patches, and creating an SR or just wait for the things to work there way through bugzilla?
Your move to raise the issue here I consider a the right approaoch in general.
While I'd like to see this pushed out to all supported distro releases I realize this may not be an option, but with the 12.2 RC around the corner I'd be happy with it making that release.
Getting this into 12.2 is welcom. Getting a backported fix into released products is welcom too.
I think these enhancements are non-intrusive so hopefully they'll make it into all releases. Thanks! -- Later, Darin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Mar 30, 2012 at 10:01:01AM -0400, Darin Perusich wrote:
Hi Lars,
On Fri, Mar 30, 2012 at 9:36 AM, Lars Müller
wrote: Asking back here is correct. More help and inparticular more specifric you might get as soon as you include the particular software component you're working on.
I'm trying to get these patches applied against pam-config, they extend it to support the ecryptfs pam modules bug 752851. Once ecryptfs support is available in pam-config I'll create another SR against ecryptfs-utils so it's calls "pam-config -a --ecryptfs" during %post and "pam-config -d --ecryptfs" during %postun. This is dependent on Bug 740110 which is currently under audit review for making /sbin/mount.ecryptfs_private setuid.
Basically my end goal is to see the seamless integration of encryptfs into OpenSUSE as it is in Debian and Ubuntu.
Thorsten is usually quite diligent with his bugs, but was away this week. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
On Fri, Mar 30, 2012 at 10:06 AM, Marcus Meissner
Thorsten is usually quite diligent with his bugs, but was away this week.
Which is why I didn't mention the package initially, I didn't want to give the impression I was calling anyone out. -- Later, Darin -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-buildservice+owner@opensuse.org
participants (4)
-
Darin Perusich
-
Lars Müller
-
Malcolm
-
Marcus Meissner