[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Continuing the website saga
I would recommend against Drupal for forums, they don't look good, they lack
basic functionality in many browsers, the search function doesn't work very
well, and yet remain complex to maintain.
My recomendation would be RForum (http://rforum.andreas-s.net/rforum).
That merges the froum with the mailing list in http://www.ruby-forum.com/.
Or I could help to customize a Simple Machines Forum, to make the interfaces
less cluttered with crap, perhaps even include a mailing list module.
El Sábado 16 Septiembre 2006 01:20, Carsten Haitzler escribió:
> On Wed, 13 Sep 2006 10:32:00 +0100 Andrew Williams <email@example.com>
> OK - I have been waiting for the dust to settle (too much email to handle!)
> I will summarise what I think the WEBSITE needs (regular builds with errors
> are orthogonal to the WEBSITE - they can output web pages to be linked to
> The list of what we have and what handles it currently, do they need user
> 1. news posting - summaries on front page (XSM, auth)
> 2. content creation and editing (XSM, auth)
> 3. forums (drupal, auth)
> 4. bug db/reporting (mantis - i think, auth)
> 5. on-disk file repo for download (custom PHP)
> 6. documentation (XSM, auth)
> 7. webcvs (kevb/webcvs)
> 8. user uploads of themes etc. (XSM - done by hand, auth)
> we, as dan pointed out, need to unify authentication/user info - we can't
> go and have all the systems separate. they need to be unified - 1 login.
> frankly - i think we need to either look at making XSM do all of the above,
> or we need to canvas for a solution that does all of the above for us
> already. we do not need to go write our own cms/wiki/whatever we are not in
> the business of building "websites". we are in the business of writing
> "code". the website is a means to an end.
> xsm has served well - and i am happy to keep using it - if we can
> accomodate what we need easily. the bits not needing auth can be put in
> with XSM - those not using XSM and needing auth are the problem.
> so - we
> 1. bring xsm up to speed and merge everything in and do all that work
> 2. we look for an alternative (if one exists)
> 3. we write our own (oh bloody hell i hope not!)
> 4. we keep depating this until we all get bored and find something better
> to do.
> so our 2 real possibilities are 1 & 2.
> so - let's look at this in parallel. what are our chances of 1. and gettign
> xsm to manage things so we can have forums, bug tracker, etc. etc. cleanly
> (and our list of issues with xsm)
> and what are our alternatives - wiki's with bug trackers (trac?)? trac is
> very limiting in the page content land - if u want simple things its fine,
> but otherwise is lacking. twiki i understand is better BUT not sure about
> adding bug trackers etc. drupal is a monster. what about forums combined
> with these?...
> > dan sinclair wrote:
> > > Hello,
> > >
> > > Ok, haven't got a lot of responses (not that I gave it a huge amount of
> > > time, I'm inpatent) but, a follow on email to what we want out of the
> > > site.
> > >
> > > How do we get it.
> > >
> > > Lets us assume, for now, XSM is our CMS of choice. It will handle the
> > > static pages for all 'normal pages'. It will handle the news page
> > > (which, will hopefully be able to be displayed on both the home page
> > > for 2-3 articles and in the news page, Handy?).
> > sure thing. Any "list based" page can be summarised using simple markup
> > which can be inserted into something like the front page using the
> > template system.
> > > The FAQ will be XSM. If we
> > > want to hook up for the user to download the faq to their system we can
> > > grab the .xml file XSM generates and post process if needed (Handy, can
> > > we hook post processing scripts in so after a page is written out, fire
> > > script?) and stick this into specific spots in the webserver.
> > post processing is not currently available as a hook, but you can look
> > at mtime values on files. perhaps RSS might be useful here?
> > > The main docs pages will be in XSM. The API docs will be generated from
> > > CVS, with links from XSM. The other docs that are in CVS will also be
> > > autogen'd on commit with links from XSM.
> > >
> > > That make sense as a starting point?
> > yup :)
> > > So, what does that leave us with to sort out.
> > >
> > > 1- User forums. The easiest is to grab something previously created and
> > > use that. There are two issues.
> > > a) do we want to migrate data from edevelop, if so, how.
> > > b) user authentication. We want this to have the same authentication
> > > as XSM.
> > > So, we'll either need to modify this in the forum software, or do
> > > some fancy footwork.
> > > (XSM writes its user db and we parse that into the forum db, or
> > > into LDAP or something?)
> > XSM does want to use LDAP, perhaps this would be the push it needs :)
> > > 2- Wiki. Do we want a user wiki? Something for users to put their info
> > > on, put up a page for
> > > their efl apps, or their theme they're working on. If we want this,
> > > again, how do we integrate
> > > the user database with XSM. Probably a similar issue as 1. Which
> > > Wiki software do we use?
> > > Mediawiki?
> > >
> > > 3- Bug database. Basically same as above. How to integrate users, which
> > > bug software to
> > > use. We currently use Mantis. Do we stick with that? (Losing the
> > > current bug data is
> > > unacceptable so if we go to something else we _have_ to migrate.)
> > I personally like mantis, though I have grown to love Trac ;)
> > > 4- Release directory list. It sounds like we can hook php into XSM.
> > > This page will then just
> > > be controlled by XSM. (Assuming I'm correct on the XSM php front.)
> > Yeah, sure thing - if you want the file list generated on the file
> > system. There is a "files" doctype in XSM which allows you to upload
> > files for download (if you see what I mean) and you can categorise the
> > page. So both options are viable.
> > > I just thought of another feature we may want on the site. Autobuild
> > > information. Every 10 min or something rebuild everything, put up page
> > > with build errors, build warnings, etc. Possibly just a php script in
> > > XSM or tinderbox?
> > XSM could run scripts to present this, but currently it has no
> > scheduler, so it could not (yet) be used to fire off the rebuild event.
> > > Now. I _know_ everyone has their favorite bug database, favorite wiki
> > > software. Favorite hand to use while touching themselves. Thats fine. I
> > > want to here what you like. I only want to hear it _once_. I _don't_
> > > want to hear you bitch about what someone else likes.
> > >
> > > Right now, we need ideas on what to use and how we can hook the pieces
> > > together. We don't want a giant mis-mash site. We also don't want to
> > > write all this shit ourselves. How can we get this stuff to fit
> > > administration?
> > >
> > > (And just as a disclaimer. I've been avoiding XSM like the plague due
> > > to some early issues. I still think that we should use XSM as a
> > > _starting_ point. Once we've tried it on the new site with the other
> > > components then we can decided if it holds wind. To which, I've started
> > > poking XSM again.)
> > And you have come up with some constructive comments which will be put
> > in ASAP. Of course, registering these issues on
> > http://dev.rectang.com/projects/xsm (click "new issue") will get a more
> > "reliable" response ;)
> > > dan
> > Andy
> > -------------------------------------------------------------------------
> > Using Tomcat but need to do more? Need to support web services, security?
> > Get stuff done quickly with pre-integrated technology to make your job
> > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> > _______________________________________________
> > enlightenment-devel mailing list
> > firstname.lastname@example.org
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel