-----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/
Hi,
On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallaghersgallagh@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
-----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 Gallaghersgallagh@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@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/
Hi,
On Wed, Aug 5, 2009 at 6:23 PM, Stephen Gallaghersgallagh@redhat.com wrote:
On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallaghersgallagh@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
-----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 Gallaghersgallagh@redhat.com wrote:
On Wed, Aug 5, 2009 at 6:00 PM, Stephen Gallaghersgallagh@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?
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/
Hi,
On Thu, Aug 6, 2009 at 9:46 AM, Stephen Gallaghersgallagh@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?
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
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.
sssd-devel@lists.fedorahosted.org
-
Mathias Gug -
Simo Sorce -
Stephen Gallagher