directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject ADS 2.0 : what, how and when?
Date Wed, 05 Jan 2011 14:45:27 GMT
dHi guys,

<warning, long mail ;)>

as the 2.0 release is on its (slow) way, it's probably time to check if 
we are ready for such a release. I see three different things we have to 
discuss :

1) What : in other words, what is the perimeter of such a release ? What 
should be put in the box ?
2) How : or is there a roadmap that can help us to fulfill this 
commitment, and who is takng responsability of each part of this roadmap.
3) When : usually, the answer to a user asking us about the release date 
is "When it's ready". However, there are probably some timeframe we can 
discuss.

Let's start with the 'What' part first.

What
----
(FTR, The last release we did, Apache Directory Server 1.5.7 was issued 
on april, 24th, 2010)

Hopefully, we have JIRA which stores the issues, tasks and wishes, and 
it's the first input we will use to determinate the 'what'. Let's move 
back to the past a bit. In may, 26th, 2010, a mail about the version 
scheme was sent and discussed on the directory ML [1][2]. What was 
proposed back and agreed then was :
- skip ADS-1.5.8 and target a 2.0.0-RC1 instead
- skip shared-0.9.20 and target for a 1.0.0-RC1 instead
- Keep the RC in order to give us the opportunity to stabilize the code 
*and* the documentation
What was also raised at this time is that once we will jump for a 
2.0(server) and 1.0(api), we will be stuck with the exposed interfaces 
for a very long time, so we'd better be careful. This still stand.

We then started to move forward, cleaning some parts that needed it, 
following the classic #bug report  :
- installers were totally rewrote [8]
- configuration has been completely re-factored, it's now stored in DIT
- all the 1.5.8/1.5.9 issues have been moved to 2.0.0-RC1 in JIRA
- performances of each operations were greatly improved (by a factor 2 
to 4) [5]
- some discussions about the JDBM backend occured, we agreed we should 
have a MVCC backend sooner or later, but no clear decision was even 
stated about when we should do that. However, recollecting my memory, it 
seems that it's out of question for 2.0.
- Multi-Master replication has been added [2]
- we moved documentation from Confluence to use Dockbook instead [6]
- PasswordPolicy have been added
- the ACI subsystem has been reviewed [3]
- some refactoring of shared has been discussed and started [4]
- the various LDAP messages data structure have been merged (a long 
expected task)
- some discussion started about the shared/API merge [7][9][10]
- the kerberos codec has been completely rewritten [11]
- AdministrativeModel implementation refactoring has been started 
(support of IAP is at stake)

All those parts have been heavily discussed, as discussion about a 2.0 
release started back in january 2009 ! [12] This effort has been pursued 
and in may 2010, we started a bug parade [13] (reports are available on 
[14], [15], [16], [17], [18]). Then we hit some serious issues in the 
code that needed more than a few lines of code, bt some serious 
refactoring (namely, config in DIT, ACI subsystem, Kerberos refactoring, 
AdministrativeModel). Those huge refactoring stopped the release effort 
until they are done.

Right now, we are almost ready to start again to run the bug parade, 
once the Administrative Model is finished (still working on that).

Sooo... time to review what's missing, and what's need some love now. 
This is the 'What' part we all are looking at, and the best point to 
start it will be to look at opened JIRAes. Otherwise, we still have to 
discuss some serious re-factoring to be done in Shared.

Back in december, Alex started to review Shared, we discussed about it, 
and we agreed that the work started on september was not enough. The 
rationals are clear :
- shared and API *are* the same thing. We want to merge the client-API 
and shared to provide a LdapAPI (and we even started a new project for 
that).
- many classes are useless, and need to be removed. Alex started to do 
that in a shared branch
- some modules are to be reworked, we should probably rename some, and 
Alex is experimenting in the shared branch
- we also have to discuss about moving some classes out of shared 
(DnNode, and may be a few more) or moving in some others (Subentry 
classes in core-api). This is a part we can have some disagreement, but 
it's not really a big deal at the end.

There may be some other elements, but nothing is yet decided, so it's 
fine to add there what is missing.

Otherwise, we have to remember that we have 3 different 'release' at 
stake here :
- ADS 2.0
- Studio 2.0
- LdapAPI 1.0 (ex-shared)

LdapAPI is absolutely *critical*. Once it's out, there is no way for us 
to change it, because it will be heavily sued, as it's meant to be a 
replacement for JNDI, and many of the outdated LDAP API. So we have to 
be extraordinary cautious in this area.

However, and that's the good point, we can spend as much time as needed 
to get LdapAPI 1.0 out, as it won't be a show-stopper for ADS and 
Studio. It doesn't matter if we continue with a shared-0.9.20 in ADS 2.0 
or in Studio 2.0, because ADS will be used way more often as a 
standalone server, or even if it's embedded, the exposed interface will 
be the core-API part, which is not part of LdapAPI (except a few classes 
which will need some careful review).

That's if for the 'what', at least from my perception of the 'what'. 
Please feel free to add any relevant information here.


How
---
The 'how' is clearly simpler, as it's a matter of defining the schedule. 
as of today, we have tried to start a 2.0 release at least twice, and we 
stopped it twice, because some areas were so badly problematic that they 
needed some heavy refactoring. I hope we will soon be out of this maze.

Currently, if we think about the way to schedule the path toward 2.0, 
here is how I see it :
- trunk-AP is a branch used to refactor the AdministrativeModel. It's a 
complex task, which will probably take 2 more weeks. i'm merging back 
any change done in the server to avoid having some issues when I'll do 
the merge back to the server
- alex-refactoring is a branch where Alex is doing some experiment and 
cleanup on shared. It will probably be done fast, and then we can also 
consider discussing the potential impacts of such refactoring. it's 
important to stress out that those change are crucial, and they *have* 
to be done. However, as shared is used all over the server and studio, 
it will probably need a staging during which we will only get the merge 
done.
- In the mean time, we agreed that AP refactoring should be done asap, 
because it depends on shared (thanks to subversion, merging a branch can 
be a nightmare... We should consider switching to Git at some point 
after 2.0 :)

Once those 3 steps are done, I do think we are ready for a 2.0-RC1 bug 
parade. We have :
- DIR : 13 issues [19]
- DIRSERVER : 136 issues [20]
- DIRSHARED : 8 issues [24]
- DIRAPI : 14 issues [21], [22]
- DIRKRB : 10 issues [23]

Not all of them are bugs, hopefully ! We "only" have 54 bugs out of 
those 181 issues.

So the 'how' part is just about discussing the timing, and organization 
(what should be done in branch, when should it be merged back, etc). I 
don't think it will be an obstacle.

When
----
The most difficult part ! The ASF is not a place were people can get a 
clear date, like M$ does. We don't release for a date, we release when 
"it's ready".

However, we can't also stay in a never ending story, with continuous 
addition of features. The very nature of our work make it impossible to 
be satisfied by what we deliver, and we should accept the idea that we 
won't provide the absolute perfection. We all know that...

That being said, and sorry if it sounds like a lecture, because it's 
not, we have to get something out soon, and we should now be able to 
define some milestones.

Here is how I see the planning :

***Server***
- 2.0.0-RC1 should be ready by end of january, end of february. Enough 
said if I estimate the effort to something around 4 to 8 weeks.
- 2.0.0-RC2 could take as long a 3 months. We haven't yet mentioned 2 
things that are absolutely essentials : documentation and migration from 
1.5.7. I think that those 3 months will be a perfect delay to get those 
two things done, plus of course fixing bugs, and such tasks. This leads 
us to june.
- 2.0-GA could be ready by september. This is another 3 months, and we 
can use this time to conduct heavy tests, and improve the Disaster 
Recovery System, side components (like an HTTP admin based component), 
shaking the Multi-Master replication, etc.

***Studio***
- 2.0.0-RC1 can be out at the same time or slightly after 2.0.0 is out. 
i'm not the expert in this area, I would let Stefan and Pierre-Arnaud 
giving us a better perspective on this

***LDAPApi*** (ex shared/clientAPI)
- 0.9.20 delivered when ADS 2.0.0-RC1 is out
- as many 0.9.2x as needed to get a stabilized version of the API,
- 1.0-RC1 probably by september too. I may be a bit pessimistic here, 
and be happy to be demonstrated pessimistic, but here I share Alex' 
concern about the API freeze. Once 1.0 is out, we will have to live with 
it for *years*
- 1.0-GA maybe by the end of this year.

---Conclusion---
Pfff... that was a long mail. I have tried to add as much as factual 
elements on it, so that there is no misconception about this roadmap. Of 
course, this is not written in marble, it was much more intended as a 
snapshot of the current development state.

All of these points can be discussed, the 'what', the 'how' and even the 
'when'. We don't have a Poject Leader, we are just a community, and it's 
the only way we can get this server out.

I hope I have phrased what I have in mind in a way that is not 
controversial, because it was not my intention, but if you think I have 
mis-represented, or forgot anything, please feel free to mention it.


Last, not least, I wish all of you a Happy New year, and I hope we can 
get ADS 2.0 out and in good shape, because we have worked like dogs for 
it, and we deserve to chew a bone now :)


[1] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201005.mbox/%3C4BFC74F5.1040009@gmail.com%3E
[2] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201005.mbox/%3CAANLkTik8d1bfe8iFPrFZNtbiFX4XQc-4__ArjXB3Fxn-@mail.gmail.com%3E
[3] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3C4C2D986F.3040802@gmail.com%3E
[4] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3C4C358AF2.5090001@gmail.com%3E
[5] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3CAANLkTimw2_mjSn45sgKkf9ws73AT+EYx=8e0AH=kbq6V@mail.gmail.com%3E
[6] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201008.mbox/%3C4C601B26.7020801@otego.com%3E
[7] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3C4C88F910.7010005@gmail.com%3E
[8] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3C0F039A8D-3221-45B9-9E96-493C546077C4@marcelot.net%3E
[9] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3C4C9363DE.7010601@gmail.com%3E
[10] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3C4C94F265.5030901@gmail.com%3E
[11] 
http://mail-archives.apache.org/mod_mbox/directory-dev/201011.mbox/%3C4CD3499C.7080404@gmail.com%3E
[12] http://www.mail-archive.com/dev@directory.apache.org/msg23050.html
[13] http://www.mail-archive.com/dev@directory.apache.org/msg28191.html
[14] http://www.mail-archive.com/dev@directory.apache.org/msg28420.html
[15] http://www.mail-archive.com/dev@directory.apache.org/msg28466.html
[16] http://www.mail-archive.com/dev@directory.apache.org/msg28540.html
[17] http://www.mail-archive.com/dev@directory.apache.org/msg28830.html
[18] http://www.mail-archive.com/dev@directory.apache.org/msg28907.html
[19] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10400&fixfor=-1)
[20] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310260&fixfor=12313387
[21] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310962&fixfor=12314838
[22] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310962&fixfor=12315974
[23] https://issues.apache.org/jira/browse/DIRKRB
[24] 
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=12310770&fixfor=12313151
[25]


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message