On 09/22/2011 05:23 PM, David Taylor wrote:
On Thu, Sep 22, 2011 at 3:36 AM, Ate Douma<a...@douma.nu> wrote:
(note: moved this response to jetspeed-dev@ as I don't think it concerns
pluto-dev@)
Ah, your cross post got me
On 09/20/2011 07:55 AM, David Taylor wrote:
Ate, I thought you were planning on updating the LDAP documentation
before releasing 2.2.....
Hi David,
Yes, that has been my intention, but so far I haven't been able to allocate
time for this yet. And as none of our customers are waiting for this either,
it has to come out of my own personal time.
Well, if you don't have time to work on it, that is understandable.
Let someone else do it. There needs to be a documented step by step
process for cutting a release so that any committer who is not busy
can step up. Its been a few releases since I released any Apache
project, to be honest I don't remember all the steps. Seems this
document is not up-to-date and actually has old procedures:
docs/release/RELEASE-TODO.txt
Could you possibly update the document (for Jetspeed and Pluto as
well), while its fresh in your mind, I really don't mean to make more
work for you....
Yes I can and will do that.
The procedure for Pluto is pretty simple and standard.
Good and extensive documentation for this can also be found at Apache Rave
(Incubating), http://incubator.apache.org/rave/release-management.html.
I can trim that down as a straight forward set of instructions and put it
somewhere in the portals svn tree.
And Jetspeed-2 is actually not much different with the exception that we employ
custom pom (jetspeed-mvn-*-pom.xml) files which Maven isn't aware of and
therefore cannot automatically synchronize during the release process. So, those
files needs to be updated manually before, and after the standard release
procedure. But that's about the only difference as far as I remember.
Anyway, I'll add instructions for this as well.
As a voluntary task I need to balance that against other responsibilities
and currently there are simply too many other things taking precedence.
That is unsatisfactory of course, definitely for me as well, but it is how
things work with voluntary contributions.
I still do intent to pick this up but I can't and won't make specific
promises anymore for when it will be done.
Concerning the jetspeed 2.2.2 release, the LDAP integration certainly is a
nice feature, but as said we don't have any customers waiting for this
documentation, while there is a need for the new Jetspeed release.
The problem is that the current documentation is no longer accurate.
It leads people into a trap, they get stuck, and no one responds on
jetspeed-user mailing list to help them. See Jerome Dupont's questions
on jetspeed-user this summer. Because LDAP integration requires step
by step procedures, it should never have been released without proper
documentation
Acknowledged. However that doesn't change my ability to do something about it
right now. And for the record, there are more existing docs which still are
based on Jetspeed 2.1.x, e.g. largely outdated, so its not like only an issue
with the LDAP docs.
Woonsan already got the portal-bridges-script-2.0 release vote going (should
be completed today I think) and I initiated the release for pluto-2.0.3 late
last night.
The next phase will be the release preparation for the apa-* modules and
thereafter sometimes next week the final release for jetspeed.
However, there are still a few issues open on Jetspeed for which it is
unclear to me how/when these can be resolved or else moved to the next
version.
As 3 of those are currently assigned to you, can you provide some indication
for these?
The JetUI documentation took a lot of my time.
I could see that: very extensive and looking great! Good job.
I will continue going
through all bugs and close them out by early next week
Cool, thanks for that.
Finally, we need one last but required improvement for the
jetspeed-installer: dynamically configuring the Jetspeed admin and Tomcat
manager/deployer account passwords at install time. Currently these are
hard-coded and thereby pose a potential security risk which we should fix
before this release.
I'll create a separate JIRA issue for it later today.
Yup, I remember that one. I was thinking it would be a required entry
field on a new panel in the Jetspeed installer. I guess its a security
risk to even provide default values...
See: https://issues.apache.org/jira/browse/JS2-1258
For the record, after I created this issue I gave it some more thought and I'm
now included to just disable the Tomcat Manager usage and provide some
instructions how a user can enable it themselves. Wiring this within the
JetspeedInstaller isn't so trivial, especially not if also the admin password
needs to be user seeded. The Installer also has the capability to (only) reset
the database or import/export/migrate it. That complicates this considerably.
But I'll come back on that later.
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscr...@portals.apache.org
For additional commands, e-mail: jetspeed-dev-h...@portals.apache.org
