[webdev] Re: webdev meeting

["Dale W Hodge" <dwh@xxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: webdev-bounce@xxxxxxxxx [mailto:webdev-bounce@xxxxxxxxx]On Behalf
> Of Tom Hull

> 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).

I'd really prefer anything but Friday.  I rarely get home before 7pm on
Fridays, so 8pm is pushing things a bit.

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

Definately a good idea.

> > 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.

FWIW, the things that Goerzen's computer buys us are a fast redundant
connection, full backup power,  nightly tape backups (I think), and
up-to-date security patches.

> > 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.

Debian is just much easier to manage remotely, and security patches appear
faster and are easier to install.  Debian is far from bleeding edge, it's a
rock solid distribution.  Many people prefer it for server use because of
it's stability, security, and ease of maintainance.


> >>  * 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.

I won't argue the benefits of using CVS. I do however question the wisdom
of hacking the core of PostNuke.  It's a can of worms that can cause some
serious trouble up the road. I have no objections if you are just talking
of extending things via the API.

I would say that you and I have completely different outlooks on our
website.

I want something reasonably stable and and easy to manage.  I've followed
the PostNuke discussion boards, I know what's coming, and I'm willing to
wait for the technology to mature a bit before having all the features.

You, however, seem to want the challenge of development, reguardless of the
compatability issues it may raise.  I'm having a hard time backing such an
approach.

> 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.

Sounds almost like you want to fork the code. That's something I can't
agree with.

> 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.)

Instead, you'd like to develop you own bugs. ;-)  I guess this is just one
of those places where I just don't understand.  A lot of the issues you had
when we first discussed PostNuke are being addressed in CVS.  I don't see
why you wouldn't want to work with the fixes that the development team have
made.

> >>  * 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.

I'm sorry, but your logic escapes me.  You keep refering to "bleeding edge",
yet most of the PostNuke development is currently aimed at maintainance
releases and generally cleaning up the code. Their stated goal is to provide
a stable upgrade path with as much support for legacy modules as is
reasonable. At some point, legacy support will be removed, but hopefully by
that time most of the third-party modules will have been upgraded to the
current API.

> > 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, webmaster@xxxxxxxxx mail, etc. Some
> of this we sort of do now.

There may be a need for one other development list, but otherwise things can
be handled by just adding the appropriate aliases.


> > 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?

First, tell me what you want to do.  Then I can tell you if PN can be made
to do that. There seems to be a new module every week or so, what's
impossible today, may be possible tomorrow.

> > 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).

Most of the upgrades are maintainance fixes, the problem is that some of the
third-party modules I have installed aren't yet API compliant. Hopefully
that will change soon.  A number of modules were waiting until the .8
vaporware release to upgrade. ;-)  After the development split, it became
obvious that the fabled .8 release was nowhere near ready, and wouldn't be
for some time to come. So now many of the module are being brought into API
compliance.

> If it's all futures, then it's probably not the right kit,
> and we should go back to square one.

It really depends on what you are looking for.  From my point of view, it's
a workable solution. From yours, it may not be...

--dwh

---
Dale W Hodge - dwh@xxxxxxxxxxxxxxxx
Vice Chairman & Secretary - info@xxxxxxxxx
Air Capital Linux User's Group  (ACLUG)
---