On Sun, 5 Jan 2003 22:53:16 +0100 "Dirk Haun" <[EMAIL PROTECTED]> 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, [EMAIL PROTECTED] 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
