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.1040...@gmail.com%3e
[2]
http://mail-archives.apache.org/mod_mbox/directory-dev/201005.mbox/%3caanlktik8d1bfe8ifprfzntbifx4xqc-4__arjxb3f...@mail.gmail.com%3e
[3]
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3c4c2d986f.3040...@gmail.com%3e
[4]
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3c4c358af2.5090...@gmail.com%3e
[5]
http://mail-archives.apache.org/mod_mbox/directory-dev/201007.mbox/%3caanlktimw2_mjsn45sgkkf9ws73at+eyx=8e0ah=kb...@mail.gmail.com%3e
[6]
http://mail-archives.apache.org/mod_mbox/directory-dev/201008.mbox/%3c4c601b26.7020...@otego.com%3e
[7]
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3c4c88f910.7010...@gmail.com%3e
[8]
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3c0f039a8d-3221-45b9-9e96-493c54607...@marcelot.net%3e
[9]
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3c4c9363de.7010...@gmail.com%3e
[10]
http://mail-archives.apache.org/mod_mbox/directory-dev/201009.mbox/%3c4c94f265.5030...@gmail.com%3e
[11]
http://mail-archives.apache.org/mod_mbox/directory-dev/201011.mbox/%3c4cd3499c.7080...@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
