[webdev] Re: webdev meeting

[Tom Hull <thull2@xxxxxxx>]

The misunderstanding below is extreme enough that I don't think
it can be fixed by responding inline. My goals here are simple:

  1) I want to get http://www.aclug.org/ up and running ASAP.

  2) I think the minimum requirements for this are:

      a) The website needs to be maintainable by a team of ACLUG
         people; minimally I think this is 3-4 people. (This is
         the main problem we identified with the old website.)

      b) The ACLUG community needs to be able to contribute to
         the content on the website.

      c) Some things this has to include are: a calendar, access
         to mail lists, a repository for presentations. Anything
         else is gravy (although a lot more things would be nice).

  3) The website has to be maintainable and reproducible. In
     particular, this means:

      a) We have to know where all of the source code comes from,
         and who has added or changed what. (This is what CVS is
         for.)

      b) We need to be able to keep track of problems with the
         website, and encourage people to fix them. (This is what
         Bugzilla is for.)

My openacs-based prototype has thus far failed at 2(a) -- not
enough people have come forward to work on it. Dale's PostNuke
prototype seemed more likely to satisfy 2(a), but currently
lacks 3(a) and 3(b). IMO, this is not a serious problem, in
that it is relatively easy to implement CVS and Bugzilla, just
as we did with the openacs-based prototype.

If we agree that CVS and Bugzilla will be added, I have no
problem starting with the PostNuke 7.1.4 code that Dale's
prototype was based on, since I think it satisfies our bare
requirements. I do have a problem waiting for some hopefully
better future release, because that fails my point 1. If
there's something more recent than 7.1.4 that can be used
immediately, that's OK too.

If we don't agree on using CVS and Bugzilla (or some suitable
substitute) then IMHO this project is doomed, and I think it
would be a waste of my time to participate. Please note that
this is *NOT* because I want to hack on PostNuke, fork the
code, etc.

Dale W Hodge wrote:
>>-----Original Message-----

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

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