Re: webdev meeting

Dale W Hodge wrote:
>>The meeting should occur no later than
>>two weeks from today (Oct. 6, so that means Oct. 20).
> 
> 
> I can make a meeting just about any night you schedule, as long as I have a
> couple days notice. As for where, how about a restaurant of some kind? I usually
> don't have time to eat before most meetings, and since there'll probably be only
> a few people, a restaurant shouldn't pose a problem.

Looks like the best candidate so far would be Friday, Oct. 11.
Normally I would discount Friday, but without objection ...

I'm not sure that a restaurant would be a productive meeting
place. We could have someone pick up a couple of pizzas, or
we could meet later (say, 8PM).

We might then report on our findings at the following Monday's
meeting, solicit further comments, help, etc.

>>The assumption at this point is that we will be building the
>>website using PostNuke (PHP, MySQL, Apache). Any alternative
>>proposals to this should be stated in writing to the webdev
>>list ahead of the meeting, and will only be considered if
>>there are at least 2-3 people willing and able to make a
>>credible commitment to such a project.
> 
>>I'll publish an agenda the day before the meeting. Minimally,
>>it will include:
>>
>>  * web connection and host machine
> 
> John Goerzen has offered to host the new site on the same machine as the current
> site. We would have to work out what we need in terms of access (ssh shell, etc)
> and see if he would be willing to provide such.

We previously objected to lack of access to Goerzen's machine.
Since his machine is shared with other projects, I can understand
his reluctance to give us root access. We currently have a machine,
which I provided, and which we do have root access to in John
Alexander's office. I don't know of any reason why we cannot
continue to use that machine/connection, so that's our baseline
situation. Any alternative would have to beat that deal.

>>  * system admin on host machine
> 
> That would depend on where it is hosted. However, there should be several people
> with admin rights over the web content / CMS / database.

We need to figure out who does what. Dale suggested switching
the system to Debian, so that's on the table. We can probably
break sysadmin down to several roles, of which package updates
and security is the most distro-specific. If I were to take
responsibility for that role, I would not want to use Debian.
If someone else wants to do that role (and I basically don't)
Debian might be a good choice. Backups are another role. Mail
may be a third.

>>  * revision control (cvs) on website source
> 
> Only neccessary if we do a lot of hacking ourselves. I would suggest that we
> only look at developing modules, and leave the core system alone at this time.
> Anyone who wants to make changes to the core should probably sign up as part of
> the PostNuke development team.  There are some major changes in the works, and I
> wouldn't want to find ourselves doing a lot of work needlessly.

I disagree very strongly here. I'm absolutely convinced that we
will want/have to change code in our local copy, and given that
we have to be able to identify our changes and reconcile them
with future PostNuke releases. We also need a way to identify
who made what changes when. CVS gives us these tools. It's
straightforward to set up, easy to work with, reproducible,
just plain good practice.

We need to take straight PostNuke and import it to CVS. We then
need to take each of the 3rd party modules we use, and add them
to CVS. This gives us a baseline which is reproducible on user
systems. We then need to add all of our changes (either to core
code, to 3rd party modules, or to develop our own modules). If
we don't do this, upgrading any core or 3rd party module changes
will break our own local work.

Working as part of the PostNuke development team may be a good
idea, but shouldn't be necessary, and probably would be major
overhead. I (for one) don't want to do it, although I don't
have any objection to any changes I make being kicked back to
the PostNuke development team. (One of the main reasons I don't
want to work on PostNuke releases is that I don't want to have
to follow the bleeding edge of their development bugs.)

>>  * bug tracking system
> 
> Only needed on modules we produce. Bugs in PostNuke itself should be filed at
> the development site.

No. We should track the bugs that we see/fix on our own site,
since we will necessarily be out of sync with PostNuke bleeding
edge development. Someone who wants to work on generic PostNuke
development might try to kick our reported bugs/fixes back to
PostNuke; that's cool, but it shouldn't be everyone's job.

>>  * mail lists
> 
> Do we really need more?  We will have the web forums available.

Don't know. We need to survey the mail list roles and see what
we have covered and how. This includes things like root mail
from the website machine, [email protected] mail, etc. Some
of this we sort of do now.

>>  * graphic design
> 
> Something to consider, but I wouldn't expend too much effort in customization
> until the new rendering engine is complete.  Currently, the separation of HTML
> and code is incomplete, and requires way too much hand coding to make changes.
> That should begin to change after 0.7.2.5 is released.
> 
>>  * content development plan
> 
> The old question of what kind of content?  It might be wise to poll our user
> base and see what they feel they need.

IMHO, initially we need to restrict ourselves to what the
software can do without too much extra work, and get that
working, and get people contributing along those lines.
Clearly, PostNuke is good for some kinds of content, so
what are those? and how do we use them? I've got a lot of
blue sky ideas, but they're irrelevant right now because
we can't get them working, ergo we can't get people using
them. What can we do?

>>The latter is by far the largest/most openended issue.
>>People should take a close look at what PostNuke provides
>>(news, stories, reviews?), and how easy it is to add new
>>features.
> 
> Don't base your conclusions on what you see at http://aclug.neuralmatrix.org,
> instead take a look at http://developers.postnuke.com. There are a number of
> things that are due to be changed in the next couple releases.  I'm still
> running 0.7.1.4 because of a couple issues in the current version (0.7.2.1) that
> prevented some of the installed modules from working. Hopefully things will be
> sorted by the time 0.7.2.5 is released, if not, then I'll have to take a look at
> my modules and decide if I can do without them or not.

Ugh. I'd rather bite off something that we can start with,
then face the upgrade later (like when the upgrade works).
If it's all futures, then it's probably not the right kit,
and we should go back to square one.

-- 
/*
  *  Tom Hull * thull2 at cox.net * http://www.tomhull.com/
  */