sssd Planning for SSSD 0.5.0 and beyond

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

It's been quite some time since we last had an upstream release (0.4.1
was released on June 8th) and we've made quite a lot of progress.

I'd like to aim for having a 0.5.0 release very soon (before the end of
August, ideally). So it's time to discuss what are the features we
absolutely want to have in the next release. I'm going to suggest some,
and I'd like additional input from any interested individuals.

* Fully functional LDAP backend providing identification, authentication
and password change features. (Simo, Sumit: how close are we on this?)
* Prototype of the kerberos backend providing authentication and
password change features (Sumit: what's the status on this?)
* Successful build on Ubuntu Karmic (working as of today)
* Live configuration updates when the sssd.conf is edited (completed for
the core SSSD, but the backends need to take advantage)
* Python library to manipulate SSSD configuration (needed for authconfig
integration)

If this seems too ambitious, I'm all ears.

Looking forward to 0.6.0 and later:
We have been making a lot of progress in the ELAPI (event logging API)
and Audit features, but they're still not baked enough for 0.5.0. I
think that one of the primary goals for 0.6.0 should be integration with
the ELAPI for traditional logging and syslog, with support for the Audit
daemon coming later (0.6.1 or 0.7.0)


As far as scheduling, as I've said, I'd like to get a release before the
end of August. The Ubuntu Karmic feature freeze occurs on August 27th,
and the Ubuntu folks have expressed a definite interest in having the
SSSD in Karmic Koala, so I'd like to shoot for an August 24th release of
0.5.0, giving us a three-day margin for error.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkp5uqkACgkQeiVVYja6o6PoBgCfeDvrR93eWbEpaEmHv7EkgLrw
> 4bsAnjgc/57zoVOPpHvw3bEZumjoBnLk
> =jT1A
> -----END PGP SIGNATURE-----

[Mathias Gug]

Hi,

On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
>  * Successful build on Ubuntu Karmic (working as of today) 
Are you interested in having the debian packaging code (ie a debian/
directory) in the upstream branch (and tarball)?

--
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/05/2009 01:14 PM, Mathias Gug wrote:
>  Hi,
>  
>  On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
> > * Successful build on Ubuntu Karmic (working as of today)
>  
>  Are you interested in having the debian packaging code (ie a debian/
>  directory) in the upstream branch (and tarball)?
>  
>  --
>  Mathias Gug
>  Ubuntu Developer  http://www.ubuntu.com
>  _______________________________________________
>  sssd-devel mailing list
>  sssd-devel(a)lists.fedorahosted.org
>  https://fedorahosted.org/mailman/listinfo/sssd-devel 
That's something we could consider having in a /contrib directory in the
tree. We already have support for building Fedora-compatible RPMs in the
upstream repo, so I don't think we'd be likely to refuse a patch to
provide similar for Debian. However, I can't guarantee that the upstream
maintainers will keep the Debian parts up to date if we change
dependency requirements or similar.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkp5wCUACgkQeiVVYja6o6Mk/wCfU3eNqPY3d1rdK8jryntjSLJK
> oloAmweHlPV72eh/jG4E2OvX60wE5D9b
> =jADi
> -----END PGP SIGNATURE-----

[Mathias Gug]

Hi,

On Wed, Aug 5, 2009 at 6:23 PM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
> > On Wed, Aug 5, 2009 at 6:00 PM, Stephen
> Gallagher<sgallagh(a)redhat.com> wrote:
> >> * Successful build on Ubuntu Karmic (working as of today)
> >
> > Are you interested in having the debian packaging code (ie a debian/
> > directory) in the upstream branch (and tarball)?
> >
>
>  That's something we could consider having in a /contrib directory in the
>  tree. We already have support for building Fedora-compatible RPMs in the
>  upstream repo, so I don't think we'd be likely to refuse a patch to
>  provide similar for Debian. 
Right. It would make more sense to have the debian packaging bits
directly in a debian/ directory at the root of the source code as this
is where it will end up anyway.

>  However, I can't guarantee that the upstream
>  maintainers will keep the Debian parts up to date if we change
>  dependency requirements or similar. 
It seems that it may make more sense to maintain the debian packaging
bits in a different branch. I've already setup an import of the git
branch on LP [1]. My proposal is to maintain the debian packaging
branch there as a branch from the git import - what do you think?

[1]: https://code.launchpad.net/~vcs-imports/sssd/trunk

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/06/2009 04:16 AM, Mathias Gug wrote:
>  Hi,
>  
>  On Wed, Aug 5, 2009 at 6:23 PM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
> >> On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallagher<sgallagh(a)redhat.com>
> wrote:
> >>> * Successful build on Ubuntu Karmic (working as of today)
> >> Are you interested in having the debian packaging code (ie a debian/
> >> directory) in the upstream branch (and tarball)?
> >>
> > That's something we could consider having in a /contrib directory in the
> > tree. We already have support for building Fedora-compatible RPMs in the
> > upstream repo, so I don't think we'd be likely to refuse a patch to
> > provide similar for Debian.
>  
>  Right. It would make more sense to have the debian packaging bits
>  directly in a debian/ directory at the root of the source code as this
>  is where it will end up anyway.
>  
> > However, I can't guarantee that the upstream
> > maintainers will keep the Debian parts up to date if we change
> > dependency requirements or similar.
>  
>  It seems that it may make more sense to maintain the debian packaging
>  bits in a different branch. I've already setup an import of the git
>  branch on LP [1]. My proposal is to maintain the debian packaging
>  branch there as a branch from the git import - what do you think?
>  
>  [1]: https://code.launchpad.net/~vcs-imports/sssd/trunk
>   
Yeah, that may ultimately be the best course of action. How often do you
intend to keep the trees in sync? Only on upstream releases, nightly
snapshots, or something in-between?

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEUEARECAAYFAkp63rwACgkQeiVVYja6o6O7eQCYjKuKkAc/EUgccTx1tlL3PYKU
> AQCeLRThTNu+lOeF4WCLcnCC+gS7qHM=
> =oauG
> -----END PGP SIGNATURE-----

[Mathias Gug]

Hi,

On Thu, Aug 6, 2009 at 9:46 AM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
> > It seems that it may make more sense to maintain the debian
> packaging
> > bits in a different branch. I've already setup an import of the git
> > branch on LP [1]. My proposal is to maintain the debian packaging
> > branch there as a branch from the git import - what do you think?
> >
> > [1]: https://code.launchpad.net/~vcs-imports/sssd/trunk
> >
>
>  Yeah, that may ultimately be the best course of action. How often do you
>  intend to keep the trees in sync? Only on upstream releases, nightly
>  snapshots, or something in-between?
>  
The bzr import branch on LP is automatically synced every 6 hours from
the MASTER branch from the Git repo at
git://git.fedorahosted.org/git/sssd.git. I'm also working on providing
a daily build of the MASTER tree in a PPA [1].

[1]: https://help.launchpad.net/Packaging/PPA

--
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

[Simo Sorce]

On Wed, 2009-08-05 at 13:00 -0400, Stephen Gallagher wrote:
>  
>  * Fully functional LDAP backend providing identification,
>  authentication
>  and password change features. (Simo, Sumit: how close are we on this?) 
We are close but there is still some work I need to finish around the
sysdb data (stop using legacy formats for storage and always convert to
member/memberof). This shouldn't take long, and I plan to work on it
next week. So I guess there is a chance to release a 0.5.0 for Aug 24th
unless something else pops up.

Simo.