You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@directory.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2015/04/24 12:07:12 UTC
Kerby release
When do we anticipate a first release of Apache Kerby? No pressure from my
side, just wondering what the timeline is.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Colm,
Great proposal. Your list is good and I will find time to complement to it. For now my biggest concern is that the preauth framework is still on early going and not stabilized yet. Some APIs in both client and KDC side aren’t finalized. I’m worried about this because once we have a release, then we lose the most flexibility to refine the codes. We also need to implement the LDAP backend to connect Kerby with ApacheDS. I thought it’s good to have the first release in mind, discuss and sort out though.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 7:01 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
That timeline seems fine to me. What I suggest is to create a new version in the DIRKRB JIRA, and start assigning issues that must be fixed by the first release to it. Other issues can leave the "fix for" version blank. From what I've seen so far of the project, the following are essential:
a) Sort out not-yet-commons-ssl dependency (perhaps this could be left out altogether for the first release)
b) Resolve all issues surrounding code copied into Kerby from other projects (I think I've seen a few comments that indicate this)
c) Support UDP in the transport handlers
d) More robust error handling in the transport handlers
e) More extensive interop testing with other APIs/KDCs
Colm.
On Fri, Apr 24, 2015 at 11:49 AM, Zheng, Kai <ka...@intel.com>> wrote:
Thanks Colm for raising the question.
From my point of view, many codes of the project are to be stabilized and tested. I’m a little sad I can’t be on the project in good much time. In a quick estimation, maybe in 2 months or so? Let’s see and try our best, maybe in another month will leave us much clear and answer this question well, ☺. How others would think? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Friday, April 24, 2015 6:07 PM
To: Apache Directory Developers List
Subject: Kerby release
When do we anticipate a first release of Apache Kerby? No pressure from my side, just wondering what the timeline is.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/06/15 11:59, Zheng, Kai a écrit :
> OK see. So I guess for obsolete branches, we should clean up if we don't use them any longer. I will get rid of mine. Thanks.
Sure you can cut them. They will remain available anyway :-)
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
OK see. So I guess for obsolete branches, we should clean up if we don't use them any longer. I will get rid of mine. Thanks.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 11, 2015 5:53 PM
To: dev@directory.apache.org
Subject: Re: Kerby release
Le 11/06/15 11:31, Zheng, Kai a écrit :
> I'm going to create some branches related to the release.
>
> 1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK?
> remotes/origin/cleanssl
> remotes/origin/dsdev
> remotes/origin/fixdes
> remotes/origin/installation
> remotes/origin/javadoc
> remotes/origin/kinit
> remotes/origin/maven-refactor
> remotes/origin/newlayout
> remotes/origin/test-enc-message
No, please, *do* create branches in the official repo for personal dev.
This allow anyone to have a look.
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/06/15 11:31, Zheng, Kai a écrit :
> I'm going to create some branches related to the release.
>
> 1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK?
> remotes/origin/cleanssl
> remotes/origin/dsdev
> remotes/origin/fixdes
> remotes/origin/installation
> remotes/origin/javadoc
> remotes/origin/kinit
> remotes/origin/maven-refactor
> remotes/origin/newlayout
> remotes/origin/test-enc-message
No, please, *do* create branches in the official repo for personal dev.
This allow anyone to have a look.
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
To make things easy, could we have additional target versions in JIRA so we can assign related issues for the two feature branches?
pkinit-support
event-network-support
perhaps 2.0.0 by the way
Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Saturday, June 13, 2015 7:08 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
Hi Kerby developers,
Please note the master branch performed a cleanup and was then split into 3 branches:
* event-network-support branch, that contains and maintains the on-going codes based on kerby-event
* pkinit-support branch, that contains and maintains the 3rd party not-so-commons-ssl library and pki-provider codes along with on-going pkinit support
* The new master branch, that will be prepared for the first release 1.0.0-rc1
Please commit related codes into the 3 branches accordingly. Mostly we commit general codes in the master branch, and event related codes in the event-netowrk-support branch, and pkinit related codes in the pkinit-branch branch. The latter two feature branches will be kept sync-ed with the mater branch maybe regularly but surely when needed.
pkinit-support is scheduled for 2.0.0 and will be merged back to master if finished then.
This should address the major comments from Colm in the initial discussion. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 11, 2015 5:31 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
I'm going to create some branches related to the release.
1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK?
remotes/origin/cleanssl
remotes/origin/dsdev
remotes/origin/fixdes
remotes/origin/installation
remotes/origin/javadoc
remotes/origin/kinit
remotes/origin/maven-refactor
remotes/origin/newlayout
remotes/origin/test-enc-message
2. Would have the following branches
master branch with necessary clean up:
1) Remove all PKINIT related codes as the feature is still half-baked yet, this will mean to remove the not-yet-commons-ssl library codes;
2) Remove kerby-event related codes as the feature isn't mature yet and we'll get it done in a future major release;
3) Clean up any other problematic codes with double check for the release.
pkinit-support branch, to contain the codes for PKINIT feature and we will develop the feature in the branch in future. Will keep synced and well maintained; event-support branch, to contain the codes for the event model support, we will develop the feature in the branch in future. Will keep synced and well maintained.
Recently we'll mainly work for the release so the codes should be committed in the master branch directly. When appropriate, we may cut a branch for the 1.0.0-rc1 release based on it.
Sounds good to go? Please comment if any concern regarding the process, thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 11, 2015 4:43 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 04, 2015 8:46 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
Thanks Emmanuel.
>> The way to do it is to have special Maven prodiles to build all the packages you want.
I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way.
>>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ?
Looks perfect to me!
>> Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 8:17 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Wdyt ?
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Hi Kerby developers,
Please note the master branch performed a cleanup and was then split into 3 branches:
* event-network-support branch, that contains and maintains the on-going codes based on kerby-event
* pkinit-support branch, that contains and maintains the 3rd party not-so-commons-ssl library and pki-provider codes along with on-going pkinit support
* The new master branch, that will be prepared for the first release 1.0.0-rc1
Please commit related codes into the 3 branches accordingly. Mostly we commit general codes in the master branch, and event related codes in the event-netowrk-support branch,
and pkinit related codes in the pkinit-branch branch. The latter two feature branches will be kept sync-ed with the mater branch maybe regularly but surely when needed.
pkinit-support is scheduled for 2.0.0 and will be merged back to master if finished then.
This should address the major comments from Colm in the initial discussion. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 11, 2015 5:31 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
I'm going to create some branches related to the release.
1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK?
remotes/origin/cleanssl
remotes/origin/dsdev
remotes/origin/fixdes
remotes/origin/installation
remotes/origin/javadoc
remotes/origin/kinit
remotes/origin/maven-refactor
remotes/origin/newlayout
remotes/origin/test-enc-message
2. Would have the following branches
master branch with necessary clean up:
1) Remove all PKINIT related codes as the feature is still half-baked yet, this will mean to remove the not-yet-commons-ssl library codes;
2) Remove kerby-event related codes as the feature isn't mature yet and we'll get it done in a future major release;
3) Clean up any other problematic codes with double check for the release.
pkinit-support branch, to contain the codes for PKINIT feature and we will develop the feature in the branch in future. Will keep synced and well maintained; event-support branch, to contain the codes for the event model support, we will develop the feature in the branch in future. Will keep synced and well maintained.
Recently we'll mainly work for the release so the codes should be committed in the master branch directly. When appropriate, we may cut a branch for the 1.0.0-rc1 release based on it.
Sounds good to go? Please comment if any concern regarding the process, thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 11, 2015 4:43 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 04, 2015 8:46 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
Thanks Emmanuel.
>> The way to do it is to have special Maven prodiles to build all the packages you want.
I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way.
>>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ?
Looks perfect to me!
>> Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 8:17 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Wdyt ?
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
I'm going to create some branches related to the release.
1. Will clean up or remove the following branches. Please let me know if you have any concern. I suggest we don't create such branches in the official repo just for personal development activities. OK?
remotes/origin/cleanssl
remotes/origin/dsdev
remotes/origin/fixdes
remotes/origin/installation
remotes/origin/javadoc
remotes/origin/kinit
remotes/origin/maven-refactor
remotes/origin/newlayout
remotes/origin/test-enc-message
2. Would have the following branches
master branch with necessary clean up:
1) Remove all PKINIT related codes as the feature is still half-baked yet, this will mean to remove the not-yet-commons-ssl library codes;
2) Remove kerby-event related codes as the feature isn't mature yet and we'll get it done in a future major release;
3) Clean up any other problematic codes with double check for the release.
pkinit-support branch, to contain the codes for PKINIT feature and we will develop the feature in the branch in future. Will keep synced and well maintained;
event-support branch, to contain the codes for the event model support, we will develop the feature in the branch in future. Will keep synced and well maintained.
Recently we'll mainly work for the release so the codes should be committed in the master branch directly. When appropriate, we may cut a branch for the 1.0.0-rc1 release based on it.
Sounds good to go? Please comment if any concern regarding the process, thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 11, 2015 4:43 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 04, 2015 8:46 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
Thanks Emmanuel.
>> The way to do it is to have special Maven prodiles to build all the packages you want.
I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way.
>>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ?
Looks perfect to me!
>> Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 8:17 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Wdyt ?
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Sounds good. I'm already going in the way. Thanks.
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 11, 2015 5:54 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 11/06/15 11:39, Zheng, Kai a écrit :
> Thanks Emmanuel for the quick response! That's quite enough, maybe it's still good to have 2.0.0 as you said previously, because for some long term features we probably would use it instead of 2.0.0-RC1?
We can create a 2.0.0 later. No urge. Everything taht will not be included in 1.0.0 will be moved into 2.0.0-RC1 atm, then reshuffled later.
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/06/15 11:39, Zheng, Kai a écrit :
> Thanks Emmanuel for the quick response! That's quite enough, maybe it's still good to have 2.0.0 as you said previously, because for some long term features we probably would use it instead of 2.0.0-RC1?
We can create a 2.0.0 later. No urge. Everything taht will not be
included in 1.0.0 will be moved into 2.0.0-RC1 atm, then reshuffled later.
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Emmanuel for the quick response! That's quite enough, maybe it's still good to have 2.0.0 as you said previously, because for some long term features we probably would use it instead of 2.0.0-RC1?
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 11, 2015 5:16 PM
To: dev@directory.apache.org
Subject: Re: Kerby release
Le 11/06/15 10:43, Zheng, Kai a écrit :
> For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
> I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
I have created the following version s in JIRA :
1.0.0-RC1
1.0.0-RC2 (just in case)
1.0.0-GA
2.0.0-RC1
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 11/06/15 10:43, Zheng, Kai a écrit :
> For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
> I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
I have created the following version s in JIRA :
1.0.0-RC1
1.0.0-RC2 (just in case)
1.0.0-GA
2.0.0-RC1
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
For DIRKRB component in the JIRA, now would we have target versions like 1.0.0-RC1, 1.0.0-GA (for the final version), and 2.0.0 version as discussed? With such, we are then able to sort out all the issues to appropriate target versions.
I thought it may need some tweak? I'm not sure. If not doable we have to think otherwise. Thanks.
Regards,
Kai
-----Original Message-----
From: Zheng, Kai [mailto:kai.zheng@intel.com]
Sent: Thursday, June 04, 2015 8:46 PM
To: Apache Directory Developers List
Subject: RE: Kerby release
Thanks Emmanuel.
>> The way to do it is to have special Maven prodiles to build all the packages you want.
I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way.
>>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ?
Looks perfect to me!
>> Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 8:17 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Wdyt ?
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Emmanuel.
>> The way to do it is to have special Maven prodiles to build all the packages you want.
I see. Will investigate how the desired binary jars for kerb-client, kerb-server, and etc. can be built in this way.
>>I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a 2.0.0 version for future changes. Is that fine ?
Looks perfect to me!
>> Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Having the ASN1 part done first as an exercise makes sense. After that, we can do similar steps for kerby-kerb library and then finally kerby-kdc distribution.
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 8:17 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby component : ASN.1. We can use that as an exercise, and I'd like to use it in ApacheDS, as a separate module.
Wdyt ?
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 04/06/15 02:38, Zheng, Kai a écrit :
> Thanks Colm and Emmanuel for the thoughts and help!
>
>>> The numering scheme we use for ApacheDS is a bit complex and its history is long...
> The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
Considering that we already don't support 1.0, it's clear that 2.0 will
not provide any backward support ;-)
>
>>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
> I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
Ok, let me be a bit clearer : we should absolutely focus on sources, but
we *can* provide binaries ! Actually, this is what we do.
The way to do it is to have special Maven prodiles to build all the
packages you want.
>
>>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
> This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
>
> So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?).
I can create those versions in JIRA. The problem is that we already have
existing version for Kerberos :
https://issues.apache.org/jira/browse/DIRKRB/?selectedTab=com.atlassian.jira.jira-projects-plugin:versions-panel
Which is a bit strange considering we never ever released any Kerberos
code !
I think it's related to the ApacheDS releases. I will remove those versions.
I think we need a 1.0.0-RC1, a 1.0.0-GA (for the final version), and a
2.0.0 version for future changes. Is that fine ?
> I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Atm, what I'd like to have is a release on one of the core Kerby
component : ASN.1. We can use that as an exercise, and I'd like to use
it in ApacheDS, as a separate module.
Wdyt ?
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Colm and Emmanuel for the thoughts and help!
>>The numering scheme we use for ApacheDS is a bit complex and its history is long...
The very good history and I see why. Maybe we could have a major release like 2.0.0 claiming no backward support?
>> I would suggest you cut a 1.0-RC1 when you feel like ready, and after one or two iteration, when some obvious bugs have been fixed, go for a final 1.0.0 version. After that, better moving to a 2.0.0 quickly than starting with 2.1, 2.1.1, etc. A la Chrome/Firefox...
The way is great. +1 totally. Thanks!
>> Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
I see. So as Colm explained, maybe we could have some container modules for such convenient packages?
>> I can definitively give a hand, as I have been releasing most of the other projects for years now...
This really sounds great to me. I'm much confident now, with your taking and also Colm's help. I will try my best for the release in the following.
So for next step, we will need a master JIRA for the release, and a target version (1.0-RC1 ?). I would help sort out all the issues in the question for us to discuss and determine further. For each one desired for the release, we would ensure assignment and commitment in some certain time with higher priority, as Colm proposed initially in this thread. Sound good to go?
Regards,
Kai
-----Original Message-----
From: Emmanuel Lécharny [mailto:elecharny@gmail.com]
Sent: Thursday, June 04, 2015 12:31 AM
To: dev@directory.apache.org
Subject: Re: Kerby release
Le 03/06/15 16:41, Colm O hEigeartaigh a écrit :
> Hi Kai,
>
> Answers inline.
>
>> 1. What version would we have for the release, some options from my
>> view: 1.0, 0.1, or 1.0-M1 and so on. I saw we just released Apache
>> Directory Server 2.0.0-M20, would Kerby project follow this style or
>> otherwise? M20 looks too long for a major release IMHO.
>>
> It's just a matter of personal preference I suppose. If it were up to
> me, I would call it 1.0.0, or possibly 1.0.0-M1 if you feel that it is
> not usable in production yet.
The numering scheme we use for ApacheDS is a bit complex and its history is long...
We released ApacheDS 1.0 a long time ago (almost 10 years), then we decided stupidely to switch to 1.5, as Tomcat did with tomcat-5.5 :
basically, we also switched to Java 5, and decided that it should reflect in the numering, thus the 1.5.
Obviously, this was a mistake, as we advertized it as non stable ! (X.0 were supposed to be stable, X.5 were supposed to be unstable. Go fish...). At some point, we decided to stop with this non-sense, and to switch to milestones. The next version after 1.5.7 was 2.0.0-M1. We weren't expecting having that many mailstones, but at some point, we always had something critical to fix, and we kept going with new milestones.
One of the reasons was that we knew that once we go to a final 2.0, we will have to provide some tooling to migrate from 2.x to 2.x+1, and we were not ready for that.
There is no reason to have that many milstones with kerby. I would suggest you cut a 1.0-RC1 when you feel like ready, and after one or two iteration, when some obvious bugs have been fixed, go for a final 1.0.0 version. After that, better moving to a 2.0.0 quickly than starting with 2.1, 2.1.1, etc. A la Chrome/Firefox...
>
>> 2. What’s the artifacts we would have for the release? How about:
>>
>> 1) JARs (to be published): Client side Kerberos library in a jar;
>> KDC side Kerberos library in a jar; Kerby facilities (Netty, LDAP,
>> Zookeeper backends and so on) in a jar
>>
> We will just use Maven to drive the release process. Normally, for
> projects at Apache it's just a matter of "mvn release:prepare; mvn release:perform".
> This takes care of tagging the release, signing the jars, and
> uploading them to repository.apache.org, where you "close" them and
> get it ready for a vote.
Keep in mind that we release sources ! Now, you can also build some convenient packages, but this will be a side product.
>> 3. Would anyone take and help with the release?
>>
> I can help out, but not "take" the release as such :-)
I can definitively give a hand, as I have been releasing most of the other projects for years now...
Re: Kerby release
Posted by Emmanuel Lécharny <el...@gmail.com>.
Le 03/06/15 16:41, Colm O hEigeartaigh a écrit :
> Hi Kai,
>
> Answers inline.
>
>> 1. What version would we have for the release, some options from my
>> view: 1.0, 0.1, or 1.0-M1 and so on. I saw we just released Apache
>> Directory Server 2.0.0-M20, would Kerby project follow this style or
>> otherwise? M20 looks too long for a major release IMHO.
>>
> It's just a matter of personal preference I suppose. If it were up to me, I
> would call it 1.0.0, or possibly 1.0.0-M1 if you feel that it is not usable
> in production yet.
The numering scheme we use for ApacheDS is a bit complex and its history
is long...
We released ApacheDS 1.0 a long time ago (almost 10 years), then we
decided stupidely to switch to 1.5, as Tomcat did with tomcat-5.5 :
basically, we also switched to Java 5, and decided that it should
reflect in the numering, thus the 1.5.
Obviously, this was a mistake, as we advertized it as non stable ! (X.0
were supposed to be stable, X.5 were supposed to be unstable. Go
fish...). At some point, we decided to stop with this non-sense, and to
switch to milestones. The next version after 1.5.7 was 2.0.0-M1. We
weren't expecting having that many mailstones, but at some point, we
always had something critical to fix, and we kept going with new milestones.
One of the reasons was that we knew that once we go to a final 2.0, we
will have to provide some tooling to migrate from 2.x to 2.x+1, and we
were not ready for that.
There is no reason to have that many milstones with kerby. I would
suggest you cut a 1.0-RC1 when you feel like ready, and after one or two
iteration, when some obvious bugs have been fixed, go for a final 1.0.0
version. After that, better moving to a 2.0.0 quickly than starting with
2.1, 2.1.1, etc. A la Chrome/Firefox...
>
>> 2. What’s the artifacts we would have for the release? How about:
>>
>> 1) JARs (to be published): Client side Kerberos library in a jar;
>> KDC side Kerberos library in a jar; Kerby facilities (Netty, LDAP,
>> Zookeeper backends and so on) in a jar
>>
> We will just use Maven to drive the release process. Normally, for projects
> at Apache it's just a matter of "mvn release:prepare; mvn release:perform".
> This takes care of tagging the release, signing the jars, and uploading
> them to repository.apache.org, where you "close" them and get it ready for
> a vote.
Keep in mind that we release sources ! Now, you can also build some
convenient packages, but this will be a side product.
>> 3. Would anyone take and help with the release?
>>
> I can help out, but not "take" the release as such :-)
I can definitively give a hand, as I have been releasing most of the
other projects for years now...
Re: Kerby release
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Kai,
Answers inline.
> 1. What version would we have for the release, some options from my
> view: 1.0, 0.1, or 1.0-M1 and so on. I saw we just released Apache
> Directory Server 2.0.0-M20, would Kerby project follow this style or
> otherwise? M20 looks too long for a major release IMHO.
>
It's just a matter of personal preference I suppose. If it were up to me, I
would call it 1.0.0, or possibly 1.0.0-M1 if you feel that it is not usable
in production yet.
> 2. What’s the artifacts we would have for the release? How about:
>
> 1) JARs (to be published): Client side Kerberos library in a jar;
> KDC side Kerberos library in a jar; Kerby facilities (Netty, LDAP,
> Zookeeper backends and so on) in a jar
>
We will just use Maven to drive the release process. Normally, for projects
at Apache it's just a matter of "mvn release:prepare; mvn release:perform".
This takes care of tagging the release, signing the jars, and uploading
them to repository.apache.org, where you "close" them and get it ready for
a vote.
> 2) Kerby KDC distribution installation packages, a tar (client side
> tools, server side services and tools, conf, doc and etc.)
>
Similar to above, we will need to build the distribution via maven. So it
looks like there is some work to be done here.
> 3. Would anyone take and help with the release?
>
I can help out, but not "take" the release as such :-)
Colm.
>
>
> Thanks for thinking about this.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Friday, April 24, 2015 7:01 PM
> *To:* Apache Directory Developers List
> *Subject:* Re: Kerby release
>
>
>
>
>
> That timeline seems fine to me. What I suggest is to create a new version
> in the DIRKRB JIRA, and start assigning issues that must be fixed by the
> first release to it. Other issues can leave the "fix for" version blank.
> From what I've seen so far of the project, the following are essential:
>
> a) Sort out not-yet-commons-ssl dependency (perhaps this could be left out
> altogether for the first release)
>
> b) Resolve all issues surrounding code copied into Kerby from other
> projects (I think I've seen a few comments that indicate this)
>
> c) Support UDP in the transport handlers
>
> d) More robust error handling in the transport handlers
>
> e) More extensive interop testing with other APIs/KDCs
>
> Colm.
>
>
>
> On Fri, Apr 24, 2015 at 11:49 AM, Zheng, Kai <ka...@intel.com> wrote:
>
> Thanks Colm for raising the question.
>
>
>
> From my point of view, many codes of the project are to be stabilized and
> tested. I’m a little sad I can’t be on the project in good much time. In a
> quick estimation, maybe in 2 months or so? Let’s see and try our best,
> maybe in another month will leave us much clear and answer this question
> well, J. How others would think? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Friday, April 24, 2015 6:07 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby release
>
>
>
> When do we anticipate a first release of Apache Kerby? No pressure from my
> side, just wondering what the timeline is.
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Sorry quite late to follow this.
Colm suggested the good approach and listed the right issues we need to address for the release. It’s good to address them and consider the release now.
I have some questions first when considering the 1st release of Kerby.
1. What version would we have for the release, some options from my view: 1.0, 0.1, or 1.0-M1 and so on. I saw we just released Apache Directory Server 2.0.0-M20, would Kerby project follow this style or otherwise? M20 looks too long for a major release IMHO.
2. What’s the artifacts we would have for the release? How about:
1) JARs (to be published): Client side Kerberos library in a jar; KDC side Kerberos library in a jar; Kerby facilities (Netty, LDAP, Zookeeper backends and so on) in a jar
2) Kerby KDC distribution installation packages, a tar (client side tools, server side services and tools, conf, doc and etc.)
3. Would anyone take and help with the release?
Thanks for thinking about this.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 7:01 PM
To: Apache Directory Developers List
Subject: Re: Kerby release
That timeline seems fine to me. What I suggest is to create a new version in the DIRKRB JIRA, and start assigning issues that must be fixed by the first release to it. Other issues can leave the "fix for" version blank. From what I've seen so far of the project, the following are essential:
a) Sort out not-yet-commons-ssl dependency (perhaps this could be left out altogether for the first release)
b) Resolve all issues surrounding code copied into Kerby from other projects (I think I've seen a few comments that indicate this)
c) Support UDP in the transport handlers
d) More robust error handling in the transport handlers
e) More extensive interop testing with other APIs/KDCs
Colm.
On Fri, Apr 24, 2015 at 11:49 AM, Zheng, Kai <ka...@intel.com>> wrote:
Thanks Colm for raising the question.
From my point of view, many codes of the project are to be stabilized and tested. I’m a little sad I can’t be on the project in good much time. In a quick estimation, maybe in 2 months or so? Let’s see and try our best, maybe in another month will leave us much clear and answer this question well, ☺. How others would think? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org<ma...@apache.org>]
Sent: Friday, April 24, 2015 6:07 PM
To: Apache Directory Developers List
Subject: Kerby release
When do we anticipate a first release of Apache Kerby? No pressure from my side, just wondering what the timeline is.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Kerby release
Posted by Colm O hEigeartaigh <co...@apache.org>.
That timeline seems fine to me. What I suggest is to create a new version
in the DIRKRB JIRA, and start assigning issues that must be fixed by the
first release to it. Other issues can leave the "fix for" version blank.
>From what I've seen so far of the project, the following are essential:
a) Sort out not-yet-commons-ssl dependency (perhaps this could be left out
altogether for the first release)
b) Resolve all issues surrounding code copied into Kerby from other
projects (I think I've seen a few comments that indicate this)
c) Support UDP in the transport handlers
d) More robust error handling in the transport handlers
e) More extensive interop testing with other APIs/KDCs
Colm.
On Fri, Apr 24, 2015 at 11:49 AM, Zheng, Kai <ka...@intel.com> wrote:
> Thanks Colm for raising the question.
>
>
>
> From my point of view, many codes of the project are to be stabilized and
> tested. I’m a little sad I can’t be on the project in good much time. In a
> quick estimation, maybe in 2 months or so? Let’s see and try our best,
> maybe in another month will leave us much clear and answer this question
> well, J. How others would think? Thanks.
>
>
>
> Regards,
>
> Kai
>
>
>
> *From:* Colm O hEigeartaigh [mailto:coheigea@apache.org]
> *Sent:* Friday, April 24, 2015 6:07 PM
> *To:* Apache Directory Developers List
> *Subject:* Kerby release
>
>
>
> When do we anticipate a first release of Apache Kerby? No pressure from my
> side, just wondering what the timeline is.
>
> Colm.
>
>
>
> --
>
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
RE: Kerby release
Posted by "Zheng, Kai" <ka...@intel.com>.
Thanks Colm for raising the question.
From my point of view, many codes of the project are to be stabilized and tested. I’m a little sad I can’t be on the project in good much time. In a quick estimation, maybe in 2 months or so? Let’s see and try our best, maybe in another month will leave us much clear and answer this question well, ☺. How others would think? Thanks.
Regards,
Kai
From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
Sent: Friday, April 24, 2015 6:07 PM
To: Apache Directory Developers List
Subject: Kerby release
When do we anticipate a first release of Apache Kerby? No pressure from my side, just wondering what the timeline is.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com