[COPIED FROM USERS LIST, THIS IS HERE IN THE DEV LIST IS THE RIGHT POST TO FOLLOW UP]
Hi everyone!
Hi!
I understand those votes from active committers which are
+1 from Martin +1 from Ingo +1 from Peter
mean:
1. We actually should start a release process now
that's great, but I think we should outline a list of showstoppers and decide what to do, see below for an attemp on that list.
2. I should be the release manager
sounds good to me. Apache is a do-ocracy: who volunteers get the power (also the blame or the fame, whichever comes first ;-)
If this is common understanding I'd like to start by discussing open issues in follow up posts. So, while others are welcome to start follow up threads, please restrict yourself to the topic of discussing this release in these follow ups.
To the current status:
I am optimistic I will get an acount and be granted commit access soon,
as recent email communication with the PMC indicate this. As soon as
this happens I will commit all my patches (only concerning stores, so do
not worry and will also present the current status of the merged
J2EE/JDBC store for public review. As soon as the store is more or less stable I will adapt both this one and the file store to the new ACL implementation (provided adaption is needed). I am too chicken-hearted to check the new ACL stuff out, before having fixed the store
Yeah, one thing at the time.
That's it for now, details in the follow ups.
I think we need a little plan of action. (of course, since I'm not an active committer, I don't get to vote, but at least I'll share some of my experience in these things).
new generation number ---------------------
From a user perspective, Slide appeared dead for too long. Doing a release with a 2.0 number will give the impression that things are changing on this regard and it's a thing that people will like, even if the architecture hasn't changed.
bad marketing -------------
I believe Slide has currently a major bug in its own self-marketing: no matter how you look at it, Slide is *NOT* a content management system. Probably Remy (or Yassaf/Keith/Ismael don't know who came up with this) didn't know what a content management system was, but one thing is for sure: Slide is a content repository not a content management system.
A CMS includes things like content authoring, content auditing, workflow management, presentation logic, *and* content repositories. The repository is only a (critical! important! vital!) piece of the CMS puzzle, but it's foolish to consider a content repository enough to implement a serious CMS.
I think it's vital, for the success of a project, not to fool around with its own marketing.
I would like to invite this community to discuss the "remarketing" of slide and propose "retargetting" of the project.
[note: this will also make it easier to market Slide as the reference implementation of the JSR-170 in the future. FYI: I am the ASF representative for JSR-170 in the expert group]
solidification --------------
users that checkout the code for the first time, have a hard time understanding what parts of the code are maintained and what are not. I would like to propose a few things here:
1) clear separation of the server part from the client part. When you download the slide CVS, you get server and client at the same time, with the same build, docs and all that. I think we should clearly separate those things out. Potentially, in the future, Slide could become a "top level" ASF project (think slide.apache.org) and we might further change into slide-server and slide-client as CVS modules. I think separation will increase the ability for others to get in and help.
2) separation of the life code from the dead one. For this, the suggestion is the creation of a "/scratchpad" folder in the root of the jakarta-slide CVS module and place all dead code there. Alternatively, it's possible to use the existing "/proposal" folder. Candidates for dead code consideration are:
a) the unmaintained stores b) the GUI for the webdav client
build process -------------
I think users should be able to do
cvs co jakarta-slide ant ./slide
and get it running. The required (non-optional) jars should be included in the download or fetched by the build script from jar repositories (the only problem seems to be JTA which is under the Sun license, so we can't put it in CVS, but the Geronimo guys already reimplemented it under the apache license, so we can use that).
what do you think?
-- Stefano.
smime.p7s
Description: S/MIME cryptographic signature
