[geeklog-users] Much ado about nothing?

[hopfgartner]

On Sun, 5 Jan 2003 22:53:16 +0100
 "Dirk Haun" <dirk at haun-online.de> wrote:
> 
> I have to admit that, yes, too much communication has
> been going on on
> closed lists in the past. That happened just out of
> convenience, since we
> had a list for communication that wasn't intersparsed
> with requests for
> help on installation. As has been said before, we're
> going to change
> that. Feel free to start development-related discussions
> on geeklog-
> devtalk now. We're also planning to post daily digests of
> geeklog-devel
> to geeklog-devtalk (doesn't quite work yet - something's
> wrong in the
> list setup).
> 
> On the other hand, you could just pop in on IRC at any
> time and ask
> what's going on.
> 

Well, usually I work from places where I do not have a
continous Internet connection. That aside, I almost never
use IRC. I'm an asynchrouneaous kind of man.

> >2) I would need to apply some changes. First of all, I
> would like to
> >avoid to set register_globals=Off.
> 
> We have stated repeatedly in the past that we do not plan
> to make Geeklog
> 1.3 work with register_globals=off since it would require
> just too many
> changes and too much effort on retesting everything.
> We'll invest that
> time instead on further developing Geeklog 1.3 and the
> development of
> Geeklog 2 (which will be designed to work with
> register_globals=off from
> the ground up).
> 
> 
> >I submitted some patches, but there
> >has been absolutely no reactions
> 
> I sent you an answer (on 2002-12-30). Did you not get it?
> 
Unfortunaly not.

> Your patches had (almost) nothing to do with
> register_globals=off anyway,
> they just replaced some global debugging variables with
> constants. Which,
> of course, is a nicer way of doing things, but not
> something that is
> needed to get Geeklog running with register_globals=off.
> 

Basically, in a procedural language (PHP is used as a such
in most of GL 1.3.6) avoiding globals means passing stuff
as function arguments. I would like to avoid passing stuff,
that is functionally a constant, as a function argument.
Obviously, these patches are a first step toward avoiding
globals, not the whole solution.

Usually I try to submit atomic patches (if something worked
before, it should work later on). Even more if work happens
on stable releases.

> 
> >Indeed, it makes sense to allow only developers for the
> list. Only
> >people interested in the deveopment should be allowed to
> post to the
> >list. (Sigh, I've been rejected).
> 
> Subscribe to geeklog-devtalk and start posting ...
> 
> 
> >I can't really find a precise reason for this split.
> Much bigger
> >projects have only one development list, not a class A
> and a class B dev
> >list.
> 
> The problem I see is: How do you separate would-be
> developers from people
> who are actually providing input (through code or some
> other form).
> 
If somebody does not post, no problem. If he flames every
odd day, take him off from the list. If he posted
interesting (development focused) mails, keep him. I mean,
not a lot of people will subscribe, if they have to be hand
approved. And if they apply for subsrciption, let them give
some short explanation, why they they need to be in the
list.

> I like the concept that Daryll mentioned: People who
> actually do provide
> some code will be invited to join the list. We actually
> do that already -
> several of the plugin developers are already on the devel
> list.
> 
> Again, the idea is not to clutter the devel list.
> 
> 
> >These kind of things, that happen rarely, could be
> easily delt with
> >through private mail. I do not think that hiding the
> whole developent
> >discussions helps much.
> 
> Private mailing to more than one person is awkward - you
> always tend to
> forget to put someone on the list of receivers.
> 
> A security list, geeklog-security at lists.geeklog.net has
> been set up now.
> It's hidden from the list of mailing lists but will be
> listed in the
> documentation and on geeklog.net as the address to post
> to in case of
> security problems.
> 
Good choice, so the archives of the developers list can be
world readable, since sensitive data is somewhere else.
> 
> I'd say let's try the current list setup first and see if
> it works. If it
> doesn't, we can still change it at any time ...
> 
> bye, Dirk
> 
Well, there always time to change the setup, later on. So
please, go forward with your plan, I will try not to bother
you again on this topic.


Best regards,

Peter