directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zheng, Kai" <kai.zh...@intel.com>
Subject RE: Kerby release
Date Sat, 13 Jun 2015 11:08:16 GMT
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 ?


Mime
View raw message