I wonder if it wouldn't make sense to delay commits to stable branches until the time to release comes ?
Would it make it easier or harder to review and apply changes only at release time ?
Simo.
On Fri, Sep 13, 2013 at 12:41:41PM -0400, Simo Sorce wrote:
I wonder if it wouldn't make sense to delay commits to stable branches until the time to release comes ?
Would it make it easier or harder to review and apply changes only at release time ?
I think it would be harder. Since some patches cannot easily be cherry-pick but needs explicit backporting chances are that there are conflicts which all have to be sorted out at release time, making the release process more cumbersome.
I guess it is more likely that a patch will be forgotten.
If we commit the patches when they are available chances are higher that the branch is tested at least by some developers while preparing other patches for this branch.
bye, Sumit
Simo.
-- Simo Sorce * Red Hat, Inc * New York
Date: Fri, 13 Sep 2013 17:59:04 +0200 From: Jakub Hrozek jhrozek@redhat.com To: sssd-devel@lists.fedorahosted.org Subject: Re: [SSSD] [PATCH] nss: Add option to disable memcache
On Fri, Sep 13, 2013 at 05:26:23PM +0200, Jakub Hrozek wrote:
On Fri, Sep 13, 2013 at 02:31:50PM +0200, Michal Židek wrote:
On 09/12/2013 10:10 PM, Simo Sorce wrote:
On Thu, 2013-09-12 at 20:06 +0200, Michal Židek wrote:
On 09/12/2013 05:48 PM, Simo Sorce wrote:
On Thu, 2013-09-12 at 11:23 +0200, Jakub Hrozek wrote: >On Wed, Sep 11, 2013 at 05:54:01PM -0400, Simo Sorce wrote: >>On Wed, 2013-09-11 at 20:19 +0200, Michal Židek wrote: >>>Hello, >>> >>>I would like to have this option in SSSD for debugging purposes.
It is
>>>not documented, so it should be invisible for users (but I can
add it to
>>>man pages as well, if someone thinks it is useful to have it
there).
>> >>This would cause you to have stale mmap cache files on the system, >>wouldn't it make more sense to have an environment variable for
the
>>client libraries instead and have them ignore the mmap cache when
you
>>want to test something ? > >This sounds like a good idea. > >>It could also be documented as it may be a useful workaround
should a
>>user find a bug that hits the mmap_cache and wants a temporary way
to
>>avoid it even if with performance penalty for a specific
application.
>> >>Something like SSS_NSS_USE_MEMCACHE=yes/no >> >>defaulting to yes, if no env var is found.
Just found out that we have a check for _SSS_MC_SPECIAL in function sss_nss_mc_get_ctx. It makes the function fail returning the EPERM errno. I do not know what was the purpose of this variable, but it is exactly what we need.
Maybe we should just rename this variable, because it is not cleat from first glance, what it really does (see attached patch).
Uhmmm I forgot why I added it, I guess for testing :)
> >If I can speak for Michal -- we discussed that it might be nice to
be able
>to temporarily disable the memcache somehow, but if there was a
documented
>way, hitting memcache problems would simply disable it and don't
even
>report a bug. Kind of like users switching SELinux to Permissive.
Their choice. I think it is more valuable to have the option than not for fear of people not reporting bugs.
Ok. I added the man page change in the second patch.
Simo.
Patches are attached.
Thanks Michal
differences between files attachment (0001-Rename-_SSS_MC_SPECIAL.patch)
From 595c9892ad2079276855519e1fac086b9d52f685 Mon Sep 17 00:00:00 2001 From: Michal Zidek mzidek@redhat.com Date: Thu, 12 Sep 2013 19:45:39 +0200 Subject: [PATCH 1/2] Rename _SSS_MC_SPECIAL
If the environment variable _SSS_MC_SPECIAL is set to "NO", the mmap cache is skipped in the client code. The name is not very descriptive. This patch renames the variable to SSS_NSS_USE_MEMCACHE.
src/sss_client/nss_mc_common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/sss_client/nss_mc_common.c b/src/sss_client/nss_mc_common.c index 5d36c47..a0a70ab 100644 --- a/src/sss_client/nss_mc_common.c +++ b/src/sss_client/nss_mc_common.c @@ -108,8 +108,8 @@ errno_t sss_nss_mc_get_ctx(const char *name, struct sss_cli_mc_ctx *ctx) char *envval; int ret;
- envval = getenv("_SSS_MC_SPECIAL");
- if (envval && strcmp(envval, "NO") == 0) {
- envval = getenv("SSS_NSS_USE_MEMCACHE");
- if (envval && strcasecmp(envval, "NO") == 0) { return EPERM; }
-- 1.7.11.2
ACK
differences between files attachment (0002-man-sssd-Add-note-about-SSS_NSS_USE_MEMCACHE.patch)
From f7d07757b00eec75716ae7b43403f206d81466b6 Mon Sep 17 00:00:00 2001 From: Michal Zidek mzidek@redhat.com Date: Thu, 12 Sep 2013 19:51:55 +0200 Subject: [PATCH 2/2] man sssd: Add note about SSS_NSS_USE_MEMCACHE
src/man/sssd.8.xml | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/src/man/sssd.8.xml b/src/man/sssd.8.xml index 0aba418..3a0fc01 100644 --- a/src/man/sssd.8.xml +++ b/src/man/sssd.8.xml @@ -187,6 +187,14 @@ </variablelist> </refsect1>
<refsect1 id='notes'>
<title>NOTES</title><para>If the environment variable SSS_NSS_USE_MEMCACHE is setto "NO",
the client applications will not use the fast in memorydrop 'the' --^^^^ in front of client
otherwise ACK
cache.
</para></refsect1>
<xi:include xmlns:xi="http://www.w3.org/2001/XInclude"href="include/seealso.xml" />
</refentry> -- 1.7.11.2
Thank you. New patches are attached.
Michal
The language was fixed as Simo requested. ACK.
I think this would be nice to have even in stable branches.
Pushed to master, sssd-1-11, sssd-1-10 and sssd-1-9
I'm looking forward to releasing 1.10.2 to have one less branch to care about :-) _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Fri, Sep 13, 2013 at 12:41:41PM -0400, Simo Sorce wrote:
I wonder if it wouldn't make sense to delay commits to stable branches until the time to release comes ?
Would it make it easier or harder to review and apply changes only at release time ?
Simo.
-- Simo Sorce * Red Hat, Inc * New York
It *may* bring more stability, but as Sumit noted, at a cost.
Did you see any particular problem of a patch not well tested that went into the master? Or was it a general concern about the memcache patches?
btw how do larger projects (Samba?) handle this?
On Mon, 2013-09-16 at 11:10 +0200, Jakub Hrozek wrote:
On Fri, Sep 13, 2013 at 12:41:41PM -0400, Simo Sorce wrote:
I wonder if it wouldn't make sense to delay commits to stable branches until the time to release comes ?
Would it make it easier or harder to review and apply changes only at release time ?
Simo.
-- Simo Sorce * Red Hat, Inc * New York
It *may* bring more stability, but as Sumit noted, at a cost.
Did you see any particular problem of a patch not well tested that went into the master? Or was it a general concern about the memcache patches?
I was more thinking about cases where you may want to defer the decision of backporting a patch to a branch. By selecting patches at one time you 'might' be able to see a larger picture and have a more focused release, or change release direction at any point in time.
But no, so far I haven't seen a huge problem except for the need to keep tabs on multiple branches at the same time.
btw how do larger projects (Samba?) handle this?
Our release manager backports bugs to the next stable tree only if there is a bug that asks for it with a backport patch and acks from developers. She does that at her own pace. After RC only critical bugs are allowed in the stable branch before release.
Release management and development are quite separated in samba.
Simo.
sssd-devel@lists.fedorahosted.org
-
Jakub Hrozek -
Simo Sorce -
Sumit Bose