On 1/24/12 9:29 PM, Alex Karasulu wrote:
On Tue, Jan 24, 2012 at 8:53 PM, Emmanuel Lécharny<elecha...@apache.org>wrote:
On 1/24/12 7:25 PM, Alex Karasulu wrote:
On Tue, Jan 24, 2012 at 6:50 PM, Emmanuel Lecharny<elecha...@gmail.com>**
wrote:
On 1/24/12 5:25 PM, Alex Karasulu wrote:
On Tue, Jan 24, 2012 at 3:47 PM, Pierre-Arnaud Marcelot<p...@marcelot.net
*
*wrote:
On 24 janv. 2012, at 14:33, Emmanuel Lecharny wrote:
Hi guys,
last summer, a [VOTE] has been started about merging DIRShARED with
DIRAPI. We have had 5 +1 votes for it, but the operation was not
done,
because we didn't decide if API should be moved to SHARED or the
opposite.
I have just the opposite view. DIRAPI should be merged into DIRSHARED
but
for now I suggest a hold. These are really trivial matters and we should
not be inducing unnecessary turnover without a significant gain when we
have two big branches of critical importance in motion.
Can we just lay this to rest until mid-year this year and then have a
full
discussion about it?
Shared is a dead space right now. I really don't mind merging API into
shared, and killing API, except that for users, SHARED means absolutely
nothing, when API is the Jira project they will use for bugs they meet
when
using the LDAP API. So IMHO, API is really more important than SHARED,
even
if SHARED is potentially something we may want to keep around.
With you on this and I can support both views myself. What I am trying
to
say is ... I agree with you on some of these points but similar arguments
can be made in both directions just as well. Nothing screams out in either
direction from the semantics point of view: so in the end this is just
semantics.
The important point is to preserve some of the historical investments made
under these JIRA URLs and SVN paths. It's less disruptive and easier to
merge API into SHARED than the other way around and technically the LDAP
API is part of the code shared by both studio and apacheds.
IMHO there are bigger fish we need to fry than this one, being at best a
really minor issue. I'm weighing in on less disruption when no particular
direction has an overwhelming benefit.
Ok, just to sumup :
- currently, when we release what we call 'shared' internally, we call it
ldap-api on the web-site
- so now, our users are redirected to DIRAPI when it comes to fill a JIRA
on shared
- that imply we have a SHARED JIRA space which is not any more used
- I think we should move the SHARED issues to API atm, in order to fix
them, instead of forgetting them in the next release
Now, there are more to discuss :
- we should not just close SHARED, because it contain a lot of history.
Merging SHARED into API could be a pb, mainly losing this history.
- DIRAPI is not necessarily a good name. It should be LDAP-API, imho
- currently, shared is used by Studio, Apacheds, and as a standalone LDAP
API. I don't think we will change that sooner or later, and, for instance,
creating a ldap-client-api and an ldap-server-api does not make any sense.
But I don't think that in the long run, shared should be kept as a project
name. I'd rather use ldap-api (but this is just me)
At the end, it's not urgent (except the issues migration). If everybody
agrees about the opened issues migration to DIRAPI, I will be very fine.
For any other modifications, I would be happy to reboot this discussion
when we will be close to a RC, not during the milestones...
Is that ok ?
Let me try to express some of my thoughts as best as I can. For some reason
I've been unable to do it on this topic, maybe because I'm less interested
in it than other matters.
1). We have three TLP subprojects which we release from subversion:
https://svn.apache.org/repos/asf/directory/shared
https://svn.apache.org/repos/asf/directory/studio
https://svn.apache.org/repos/asf/directory/apacheds
One significant fact to note is that we release shared not directly but
indirectly as a result to release studio or apacheds. Nevertheless we do
need to perform proper releases out of shared in accordance with Apache
guidelines.
Not any more. We also release the LDAP API separately. (in fact, it's
not any different from shared)
2). Creating a new subproject like studio, apacheds or shared should really
constitute a vote since it will have to go through the release process.
We'll also have to make sure it's sustainable, meaning having 3 or so
people that can actively work on it from different companies yada yada yada
...
I agree. We need a more diverse community.
3). When releasing we need to track and report the bugs fixed, the features
added, and tasks completed with each release log. So for this reason it
makes sense to have a JIRA project for each of these TLP subprojects:
apacheds, shared, and studio.
+1
These are the reasons why non of the current recommendations sound optimal.
So let's review the recommendation options:
(a) keep both but move all issues even those in shared code base to the new
LDAP-API project
(b) merge SHARED into LDAP-API (or DIRAPI what have you)
In option (a) there exists no TLP subproject code base for the LDAP-API and
hence no code base for this JIRA Project: nothing is being released yet
issues are managed.
Not true : the LDAP API is released and has its own web site :
http://directory.apache.org/api/
We don't have that for shared (except that shared == LdapAPI...)
I understand there is a marketing reason for the name:
the product name is the LDAP API which includes some of the code in shared.
But this configuration is flawed based on what we release.
the LDAP API includes *all* the code in shared. It's just a different
name. And yes, it's a better name, from the marketing POV. This is very
clear. When we discussed about writing our own LDAP API (3 years ago)
because JNDI sucked too much and because we needed a decent API to
manage the replication, we decided to name it LDAP API, not shared.
In option (b) we're talking about doing away with SHARED (deleting the JIRA
Project) and just having an LDAP-API. This move then results in the SVN vs.
JIRA discrepancy: the released code base is the shared subproject and jira
calls it the ldap-api. Or we just rename the subproject in svn to ldap-api
but then this is going to create unfold trouble for branches still working
on shared branches.
There's a lot more fallout that I probably don't need
to list which people can extrapolate.
this is clearly not a light decision. However, we don't have that many
branches. Once those branches will be merged back to the trunk, we can
then decide if we would like to rename shared to ldap-api (or whatever
fits better).
We have plenty of time to discuss all the implication of such a choice,
if we are going to select it.
If we're to think about the release process and what we have today the best
configuration is to just leave DIRSHARED and move the DIRAPI issues into it
rather than succumbing to the marketing reasons for why users should go to
an LDAP-API JIRA rather than DIRSHARED.
Clearly a big -1 to this proposal. People would be lost. Right now,
nobody is filling issues in SHARED, they are using LDAP-API. Telling
them to create issues is creating the risk that people will not know
where to create a JIRA. Studio ? ApacheDS ?
IMO, Shared is and should remain an internal vision, not something we
expose to the public. That it was created at the origin of the project
does not make it a better name today. At the beginning, we didn't have a
ldap API. This is not anymore the case.
IMHO the API JIRA project should
never have been created (a DIRSHARED label could have been used instead)
and it was IMHO created as a result of overzealous project management
activity. I might have been responsible for this but I don't really
remember. It's now leading to more confusion over a relatively trivial
matter which we can fix by dealing with the DIRSHARED name which has been
there for ages and coincides well with our release process in line with our
subversion configuration.
But DIRAPI is around for 3 years now, and IMO is fits way better to what
we have. We should not stick to a 10 years old name which does not
represent any more the reality of this part of the project.
Keep in mind that we have created this sub-project (well, at least, the
web site, the ML and the JIRA, because the full LDAP-API code is just
'shared') to be able to collaborate with the Sun peeps (and we have done
quite a good progress when we were working together).
The LDAP API is the product name and that can be respected, we can still
make accommodations to have people use the DIRSHARED JIRA Project while
pimping out an LDAP API. It's the least evil choice we have. The other
options cause us more pain or just as much pain in different places in the
end. Not everything needs to be ultra special having it's own JIRA.
I have a completely different opinion here. But we can disagree, it's
not bad per se.
In the end I'd rather not discuss this topic but move on to some really
important things like reviewing some of the TxN work to understand it
better and help. Or work on the OSGi branch to help with that. So I ask as
a special favor of you all, let's just close this issue with this simple
way for now and focus on the really important matters.
We can wait, put this question on standby until we get ready for a first
RC. Then we will take all the needed time to discuss this, overall,
minor issue.
The TxN layer and OSGi development are way way more important.
Let's just delete
the DIRAPI JIRA project and move everything back into DIRSHARED. This was
the case for over half a decade until we all got excited about the LDAP
API: me included. We even created a mailing list for it then abandoned it
since things are best on user and dev lists.
The mailing list is still around. And it's now 3 years we have the LDAP
API being actively developped and exposed on the web site as a separate
project. I'm certainly not willing to kill -9 all that for the benefit
of some historic name...
In the big picture this is nothing at all.
I totally agree :) This is just a discussion, without any passion. No
need to decide anything right now.
Feel free to comment, nobody will be stab in the back for expressing an
opinion. At the end, when we will have fixed the main issues we are
really facing (ie, TxN, OSGi), we will have time to decide and to vote.
Thanks !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
