Status of PHP-GTK

[Steph-8]

> Concerning the state of the manual: What would it take to fix the build
> system? It worked at one time, but all I hear is that it needs to be
> updated to DocBook V5. Whoever broke it should just fix the damn thing
> so the old DocBook V3 sources can still be maintained.

Agreed 100%. Last build December 2007 - what happened in December 2007 that made it stop working?

After all, it is
> in a VCS where one can go back in time, right? I don't see a realistic
> chance that anybody will step up and rewrite the whole manual just for
> fun. Besides, there is still the problem with OOP support in DocBook I
> presume?

Yep. Although DocBook version 5 was supposed to address that problem, the approach hasn't been quite what we might have hoped, in that it isn't a good match for PHP-GTK's needs. (I did look at it, just my heart sank when I did.)

> I know I'm only saying what "should be done". If there was an easy way,
> I'd gladly help with the documentation. Until then, I'll just try to
> post whatever problems (and solutions) I come across to the ML and other
> public places. Unfortunately I don't have the time to work on the big
> problems, so this is my way to contribute.
>
> All developers, keep up the nice work even if it's in the shadows to the
> common subscriber :-)
>
> Regards, Andre

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

> Actually the docbook 5 stuff and php.net have implemented some pretty
> nice OOP stuff - read the php manual lately?

We're at odds over this - wonder if I'm thinking v5 but meaning v4, or if you don't know phpgtkdoc.dtd?

> As for who broke it - I'm not entirely sure.  The issue isn't the code,
> it's the server.  Docs will build manually on a local system.  They
> don't build on the site.  Something to with system administrators and
> their need to upgrade things was my last understanding of why the builds
> are broken.  I'm not a sysadmin, nor do I have any desire to be one or
> chase developers until I find one who has root...

Derick's usually a good bet.

> Steph - do you even know what box gtk.php.net is sitting on at the
> moment? There was a bunch of php website reshuffling....

y1.

- Steph

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[FGM]

Maybe this will sound like blasphemy, but wouldn't it be more reasonable to
ignore the far-fetched multiformat, docbook, php.net-integrated, approach
and go for something more lightweight that would be completely (X)HTML-based
using a CMS in massive use (you know which one I'd recommend) ?

Is it better to have a "clean", enterprise-type, XML-centric process
yielding only PDFs over 1 year old which only specialists can build anyway
when the system is broken, or to have something which is mostly web-centric,
with an easy content redaction UI, and is constantly alive, using a CMS site
technology which over 100k people know how to run/maintain, with serious
community interaction features being maintained by the CMS community instead
of the PHP-GTK devs who are already swamped in work and have more important
things to do regarding PHP-GTK than working on a web site ?

I'll gladly admit that it would obviously hit harder on the server resources
because such frameworks are inherently heavier, but is it really a problem
considering the actual frequentation ?

Of course, this doesn't come out of the blue: I've been suggesting this
approach more or less since late 2007, and its initial rejection was what
led me to create php-gtk.eu, so that the lost wiki pages and apps repository
from gtk.php.net would be available again.

And in case this isn't perfectly clear, should this turn be taken, I'd
gladly take part in the migration process, just like I did for the wiki and
apps sections. And several community members already use this same CMS for
their own sites, so I wouldn't be the only one knowing it.

Frederic

----- Original Message -----
From: "Steph" <steph.fox@...>
To: "Andre Colomb" <acolomb@...>
Cc: <php-gtk-general@...>
Sent: Thursday, April 16, 2009 11:08 AM
Subject: Re: [PHP-GTK] Status of PHP-GTK



> Concerning the state of the manual: What would it take to fix the build
> system? It worked at one time, but all I hear is that it needs to be
> updated to DocBook V5. Whoever broke it should just fix the damn thing
> so the old DocBook V3 sources can still be maintained.

Agreed 100%. Last build December 2007 - what happened in December 2007 that
made it stop working?

After all, it is
> in a VCS where one can go back in time, right? I don't see a realistic
> chance that anybody will step up and rewrite the whole manual just for
> fun. Besides, there is still the problem with OOP support in DocBook I
> presume?

Yep. Although DocBook version 5 was supposed to address that problem, the
approach hasn't been quite what we might have hoped, in that it isn't a good
match for PHP-GTK's needs. (I did look at it, just my heart sank when I
did.)

> I know I'm only saying what "should be done". If there was an easy way,
> I'd gladly help with the documentation. Until then, I'll just try to
> post whatever problems (and solutions) I come across to the ML and other
> public places. Unfortunately I don't have the time to work on the big
> problems, so this is my way to contribute.
>
> All developers, keep up the nice work even if it's in the shadows to the
> common subscriber :-)
>
> Regards, Andre

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

FGM wrote:
> Maybe this will sound like blasphemy, but wouldn't it be more reasonable
> to ignore the far-fetched multiformat, docbook, php.net-integrated,
> approach and go for something more lightweight that would be completely
> (X)HTML-based using a CMS in massive use (you know which one I'd
> recommend) ?

Yep, that's blasphemy alright :)

The aim... yes there is an aim... is to have all php.net documentation work in the same way, using industry standard tools, so that someone who has written for the PHP-GTK Manual can easily transfer to the PHP Manual and vice versa. Outside of php.net, the skills acquired here are transferable to pretty much any major OSS project, and also to most technical authoring jobs.

Also, think 'branding'. php.net stuff should always clearly be php.net stuff.

> Is it better to have a "clean", enterprise-type, XML-centric process
> yielding only PDFs over 1 year old which only specialists can build
> anyway when the system is broken,

Ugh... you don't need special skills to build the manual.

or to have something which is mostly

> web-centric, with an easy content redaction UI, and is constantly alive,
> using a CMS site technology which over 100k people know how to
> run/maintain, with serious community interaction features being
> maintained by the CMS community instead of the PHP-GTK devs who are
> already swamped in work and have more important things to do regarding
> PHP-GTK than working on a web site ?
>
> I'll gladly admit that it would obviously hit harder on the server
> resources because such frameworks are inherently heavier, but is it
> really a problem considering the actual frequentation ?
>
> Of course, this doesn't come out of the blue: I've been suggesting this
> approach more or less since late 2007, and its initial rejection was
> what led me to create php-gtk.eu, so that the lost wiki pages and apps
> repository from gtk.php.net would be available again.

The 'lost wiki pages' were thrown out because the wiki was spammed mercilessly over a long period of time and there weren't enough hours in the day to contain it. And the apps repo is old, old, old... it never went live after PHP-GTK 2 came out, so anything in there from our servers dates from v1.

> And in case this isn't perfectly clear, should this turn be taken, I'd
> gladly take part in the migration process, just like I did for the wiki
> and apps sections. And several community members already use this same
> CMS for their own sites, so I wouldn't be the only one knowing it.

I think, given the experience we had with the wiki, it would be very unlikely that Andrei would want to take the risk again on a Yahoo! server carrying a whole bunch of php.net sites.

- Steph

>
> Frederic
>
> ----- Original Message ----- From: "Steph" <steph.fox@...>
> To: "Andre Colomb" <acolomb@...>
> Cc: <php-gtk-general@...>
> Sent: Thursday, April 16, 2009 11:08 AM
> Subject: Re: [PHP-GTK] Status of PHP-GTK
>
>
>
>> Concerning the state of the manual: What would it take to fix the build
>> system? It worked at one time, but all I hear is that it needs to be
>> updated to DocBook V5. Whoever broke it should just fix the damn thing
>> so the old DocBook V3 sources can still be maintained.
>
> Agreed 100%. Last build December 2007 - what happened in December 2007
> that made it stop working?
>
> After all, it is
>> in a VCS where one can go back in time, right? I don't see a realistic
>> chance that anybody will step up and rewrite the whole manual just for
>> fun. Besides, there is still the problem with OOP support in DocBook I
>> presume?
>
> Yep. Although DocBook version 5 was supposed to address that problem,
> the approach hasn't been quite what we might have hoped, in that it
> isn't a good match for PHP-GTK's needs. (I did look at it, just my heart
> sank when I did.)
>
>> I know I'm only saying what "should be done". If there was an easy way,
>> I'd gladly help with the documentation. Until then, I'll just try to
>> post whatever problems (and solutions) I come across to the ML and other
>> public places. Unfortunately I don't have the time to work on the big
>> problems, so this is my way to contribute.
>>
>> All developers, keep up the nice work even if it's in the shadows to the
>> common subscriber :-)
>>
>> Regards, Andre
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Christian Weiske]

Hello,


> Concerning the state of the manual: What would it take to fix the build
> system? It worked at one time, but all I hear is that it needs to be
> updated to DocBook V5. Whoever broke it should just fix the damn thing
> so the old DocBook V3 sources can still be maintained. After all, it is
It works on my machine.

--
Regards/Mit freundlichen Grüßen
Christian Weiske

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

Hey Christian,

> It works on my machine.

Yeah, confusion of terminology. It's the auto-build that's failing, not the build per se.

- Steph

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Elizabeth M Smith]

Steph wrote:
> Hey Christian,
>
>> It works on my machine.
>
> Yeah, confusion of terminology. It's the auto-build that's failing, not
> the build per se.
>
> - Steph

As I said before - it's the box not the docs code ... I think (don't
quote me) it was an xsltproc version thing but it's been (as you can see
by the Dec 2007 date) a LONG time.

You have time to kick someone with root on y1 steph?

As for the phpdoc stuff - Steph really I do prefer the OO markup for the
PHP docs - the stuff for inherited methods and such is nice, but it
won't do signals, and the properties support isn't as good so no matter
what we'll still need a .dtd just for phpgtk.  Depends on how close we
want to stick to the actual php format for those kinds of things (also
will influence how many of their tools we can use - the new online doc
editor comes to mind)

Thanks,
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

> As I said before - it's the box not the docs code ... I think (don't
> quote me) it was an xsltproc version thing but it's been (as you can see
> by the Dec 2007 date) a LONG time.

xsltproc version issues happened and were fixed before, but when is a different matter.

> You have time to kick someone with root on y1 steph?

Not without diagnosis...

> As for the phpdoc stuff - Steph really I do prefer the OO markup for the
> PHP docs - the stuff for inherited methods and such is nice, but it
> won't do signals,

Yeah...

and the properties support isn't as good so no matter
> what we'll still need a .dtd just for phpgtk.  

We always did, always will, because DocBook doesn't actually stretch to our needs. I can't believe we're the only people on the entire www with a need to describe event-driven objects, but there you go...

Depends on how close we
> want to stick to the actual php format for those kinds of things (also
> will influence how many of their tools we can use - the new online doc
> editor comes to mind)

'new' as in 'still under development' I assume, since Philip's been fairly quiet about it :)

Livedocs took a fair amount of hacking to work with phpgtkdoc.dtd. I think phd will be the same, because it relies on pure DocBook (which is relatively new for phpdoc also). The amount of work needed just to find out whether that's so is scary, since it means rewriting the php-gtk doc scripts and dtd all over again and either search/replacing a bunch of tags throughout the manual source, or else generating from scratch. Upgrading is also likely to break Christian's nice hierarchy generation (I don't know how he even did that in the first place).

I'd be inclined to branch php-gtk-doc now and adapt the current serverside scripts to use that branch while work's in progress on upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin to hit on everything at the same time rather than pester him twice over.

>
> Thanks,
> Elizabeth
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[FGM]

Hi Steph,

Thanks for answering so fast. I beg to differ, though:

> Also, think 'branding'. php.net stuff should always clearly be php.net
> stuff.

Any halfway decent CMS should allow you to maintain the same user interface.
In the case of D., I clone the gtk.php.net theme for php-gtk.eu, although it
is not enabled to avoid such "branding" confusion, so it is clearly a
non-issue.

> Ugh... you don't need special skills to build the manual.

Anything more complicated than clicking on "edit", editing, then clicking on
"save", is "specialist" level these days, I'd say.

> The aim... yes there is an aim... is to have all php.net
> documentation work in the same way, using industry standard
> tools, so that someone who has written for the PHP-GTK Manual
> can easily transfer to the PHP Manual and vice versa.
> Outside of php.net, the skills acquired here are transferable
> to pretty much any major OSS project, and also to most
> technical authoring jobs.

This makes technical sense, of cours. However, "any major OSS project"
doesn't use PhD, or even Docbook. XHTML, for all its flaws, is pretty much
the standard when it comes to publishing for the web or for mobile. Not for
industry docs, of course, which is using Docbook or DITA anyway.

Seen from here, it feels un-community-like, more typical of a corporate
train of thought trying for openness, but refusing to take into account the
fact that the actual expectations from casual, non-professional users are
quite different and longing for a lower entry point. These can contribute
more entry-level docs than professional devs who have long forgotten what it
was like to be a newbie. We see this every day in D., where most of the
community doc and code outside core is actually done by new users on their
learning process, with help (on IRC) from the doc team, but without such a
"master plan".

> The 'lost wiki pages' were thrown out because the wiki was
> spammed mercilessly over a long period of time and there weren't
> enough hours in the day to contain it.

I cleaned up the pages from the spamming and hacking mess (the r57shell
trojan is in the php.net CVS !) it in late 2007 when I ported them D. too,
and although the site receives a few dozen attacks a day, it has never let
any come in since. Not that it couldn't happen, of course, but it seems to
resist fairly well for now.

> And the apps repo is old, old, old... it never went live after
> PHP-GTK 2 came out, so anything in there from our servers dates from v1.

Same for this: as you pobably know, I cleaned up this info too at the same
time, obtained lost pages from archive.org which weren't even in CVS, and
put them online again. New entries have been added by members over time, and
it is the most visited part of the site. So it *does* seem to work.

> I think, given the experience we had with the wiki, it would be very
> unlikely that Andrei would want to take the risk again on a Yahoo!
> server carrying a whole bunch of php.net sites.

The wiki was apparently not kept up-to-date patch-wise, which means once
intruders noticed this, they were able to install r57shell and from here
do pretty much what they wanted. More recent versions of pbWki, which you
used then, are considerably more resilient, and also would have been at the
time if updates had been applied.

But anyway, does gtk.php.net, being a fairly minor part of the PHP
universe both for Y. and Z., need to be kept on a Y. server, if this
worries Andrei ?

----- Original Message -----
From: "Steph" <steph.fox@...>
To: "fgm" <fgm@...>
Cc: <php-gtk-general@...>
Sent: Thursday, April 16, 2009 12:02 PM
Subject: Re: [PHP-GTK] Status of PHP-GTK



FGM wrote:
[...]


--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

Hey Frederic,

OK, copying reply on-list (we had a bit of a mix-up earlier).

> Any halfway decent CMS should allow you to maintain the same user interface.
> In the case of D., I clone the gtk.php.net theme for php-gtk.eu, although it
> is not enabled to avoid such "branding" confusion, so it is clearly a
> non-issue.

To you perhaps :)

>> Ugh... you don't need special skills to build the manual.
>
> Anything more complicated than clicking on "edit", editing, then clicking on
> "save", is "specialist" level these days, I'd say.

'Build' != 'edit'

> This makes technical sense, of cours. However, "any major OSS project"
> doesn't use PhD,

Again, 'build' != 'edit'... phd is a build system. I gather there are plans to evolve a phd-based editing system, but it's not there at this point in time. And even when it _is_ there, what it will be editing is pure DocBook XML.

or even Docbook. XHTML, for all its flaws, is pretty much
> the standard when it comes to publishing for the web or for mobile.

DocBook generates HTML, XHTML, PHP, CHM, PDF... whatever you like really. Why tie yourself to a single possible output when you could have the full range at your fingertips?

Not for
> industry docs, of course, which is using Docbook or DITA anyway.
>
> Seen from here, it feels un-community-like, more typical of a corporate
> train of thought trying for openness, but refusing to take into account the
> fact that the actual expectations from casual, non-professional users are
> quite different and longing for a lower entry point.


It's not as simple as corporate vs community, it's more that the sheer size of the PHP project means we have big-project issues even for a relatively small php.net project. We simply don't have the freedom that a community site has.

These can contribute
> more entry-level docs than professional devs who have long forgotten what it
> was like to be a newbie. We see this every day in D., where most of the
> community doc and code outside core is actually done by new users on their
> learning process, with help (on IRC) from the doc team, but without such a
> "master plan".

Yes, this is where user notes play a strong part in PHP documentation. The idea is that users contribute and doc team members take the 'golden nuggets' and incorporate them into the manual. This worked well when PHP was a relatively small project with a keen hobbyist userbase. Now PHP is used in a much different context, we're seeing a lot of users who don't want to get involved but who do like to complain when they aren't spoon-fed, and the result is less useful manual notes and very few people willing to sift through them looking for the nuggets and/or deleting the irrelevant bits. Community efforts like yours are great, but how do you oversee quality?

PHP-GTK hasn't quite reached those dizzy heights, but suffers from the same userbase as PHP even though it's a relatively hobbyist project. We need people to invest something in the project for it to work, and yes often that means learning a new skill. Would you open up your own repository to people who refuse to learn a new skill?

> I cleaned up the pages from the spamming and hacking mess (the r57shell
> trojan is in the php.net CVS !)

Let's point out here that the only way the trojan could've got there in the first place is via the wiki...

it in late 2007 when I ported them D. too,
> and although the site receives a few dozen attacks a day, it has never let
> any come in since. Not that it couldn't happen, of course, but it seems to
> resist fairly well for now.

You ported them to your own server; if you crash it or break something it's not a big problem, you can sort it out yourself. Ours is a server that belongs to someone else; for that reason we have very few people with root access. A number of us - myself included - have write access to the system scripts repository, but nobody without root can apply the changes made there. Ergo, any breakage of any kind is more problematic for php.net than it would be for an independent operator. As Liz wrote earlier, when we find a problem in any php.net site it means tracking down and harrassing one of the handful of people with root access to the affected server. If we do that it might be days or weeks before our sysadmin gets around to looking into the problem. If we can't be bothered to track down/harrass that person in the first place, there's never going to be a fix.

> Same for this: as you pobably know, I cleaned up this info too at the same
> time, obtained lost pages from archive.org which weren't even in CVS,

Not possible. That's what CVS attic is for.

> put them online again. New entries have been added by members over time, and
> it is the most visited part of the site. So it *does* seem to work.

Adding new entries works - I assumed you'd simply taken the apps (!)

>> I think, given the experience we had with the wiki, it would be very
>> unlikely that Andrei would want to take the risk again on a Yahoo!
>> server carrying a whole bunch of php.net sites.
>
> The wiki was apparently not kept up-to-date patch-wise, which means once
> intruders noticed this, they were able to install r57shell and from here
> do pretty much what they wanted. More recent versions of pbWki, which you
> used then, are considerably more resilient, and also would have been at the
> time if updates had been applied.

I can't even remember who the wiki admin was. But I do know they won't have had root access. We're back to the problems I outlined earlier.

> But anyway, does gtk.php.net, being a fairly minor part of the PHP
> universe both for Y. and Z., need to be kept on a Y. server, if this
> worries Andrei ?

The fact that Y! are the benefactor in this case is irrelevant, since php.net as a group don't actually own any servers outright. Everyone donating a server and bandwidth deserves the same respect; we'd always try not to do anything that would mean using up unwarranted bandwidth or opening up the system to viral infection. The wiki idea has been tried and found wanting in that respect; the only wikis used by php.net these days are on private servers (Pierre's and Lukas').

- Steph


--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Elizabeth M Smith]

Steph wrote:

> We always did, always will, because DocBook doesn't actually stretch to
> our needs. I can't believe we're the only people on the entire www with
> a need to describe event-driven objects, but there you go...

Seems odd, I swear gtk uses docbook don't they?  But yes... why no
support...

> 'new' as in 'still under development' I assume, since Philip's been
> fairly quiet about it :)
Ah, it's likely to be a gsoc project this year as well (wahoo), but it
is in CVS and he's been quiet because it's not "ready" yet.

> Livedocs took a fair amount of hacking to work with phpgtkdoc.dtd. I
> think phd will be the same, because it relies on pure DocBook (which is
> relatively new for phpdoc also).
Agreed - however the guys volunteering and working on the new stuff also
 worked on PhD/phpdoc stuff - this is a big plus ;)  And it also means
finding out what PhD doesn't do and needs to do is easier (and we have
people to annoy about it)

 The amount of work needed just to find
> out whether that's so is scary, since it means rewriting the php-gtk doc
> scripts and dtd all over again and either search/replacing a bunch of
> tags throughout the manual source, or else generating from scratch.
> Upgrading is also likely to break Christian's nice hierarchy generation
> (I don't know how he even did that in the first place).
Sadly enough, this is true.

> I'd be inclined to branch php-gtk-doc now and adapt the current
> serverside scripts to use that branch while work's in progress on
> upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin
> to hit on everything at the same time rather than pester him twice over.
Sounds good.


Thanks,
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Christian Weiske]

Hi all,



> > Livedocs took a fair amount of hacking to work with phpgtkdoc.dtd. I
> > think phd will be the same, because it relies on pure DocBook (which is
> > relatively new for phpdoc also).
> Agreed - however the guys volunteering and working on the new stuff also
>  worked on PhD/phpdoc stuff - this is a big plus ;)  And it also means
> finding out what PhD doesn't do and needs to do is easier (and we have
> people to annoy about it)

PhD does not do all the custom XSLT stuff we built in over the years. (e.g. class hierarchies). That would have to be re-programmed in php.

--
Regards/Mit freundlichen Grüßen
Christian Weiske

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Elizabeth M Smith]

Christian Weiske wrote:

> Hi all,
>
>
>
>>> Livedocs took a fair amount of hacking to work with phpgtkdoc.dtd. I
>>> think phd will be the same, because it relies on pure DocBook (which is
>>> relatively new for phpdoc also).
>> Agreed - however the guys volunteering and working on the new stuff also
>>  worked on PhD/phpdoc stuff - this is a big plus ;)  And it also means
>> finding out what PhD doesn't do and needs to do is easier (and we have
>> people to annoy about it)
>
> PhD does not do all the custom XSLT stuff we built in over the years. (e.g. class hierarchies). That would have to be re-programmed in php.
>

Would probably be worth it - I KNOW that the spl guys were whining for
this anyway ;)  Kill two birds with one stone?

Thanks
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

> Would probably be worth it - I KNOW that the spl guys were whining for
> this anyway ;)  Kill two birds with one stone?

Heh, we could just adopt the SPL approach - doxygen and disgruntlement all round ;)

- Steph

>
> Thanks
> Elizabeth
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Steph-8]

D'oh. That'll teach me to hit 'reply-all'...

Steph wrote:

>> Would probably be worth it - I KNOW that the spl guys were whining for
>> this anyway ;)  Kill two birds with one stone?
>
> Heh, we could just adopt the SPL approach - doxygen and disgruntlement
> all round ;)
>
> - Steph
>
>>
>> Thanks
>> Elizabeth
>>
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Andrei Zmievski]

Elizabeth M Smith wrote:
>> I'd be inclined to branch php-gtk-doc now and adapt the current
>> serverside scripts to use that branch while work's in progress on
>> upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin
>> to hit on everything at the same time rather than pester him twice over.
> Sounds good.

It sounds to me like the current doc system is a big barrier to entry for those who want
to contribute to the documentation. To summarize my feelings on this subject: I'd rather
have a non-php.net-standard doc system that works and allows easy contributions that be
stuck in the current rut.

-Andrei

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Bob Majdak Jr-2]

> those who want to contribute to the documentation. To summarize my feelings
> on this subject: I'd rather have a non-php.net-standard doc system that

Is this actually possible? I mean... I been told stories... about how
things will never change... because its too much work... or because
the internals will explode instead of fixing them... or because an old
person does not want to change...

Because of all of that I quit trying to change it and just became
callused to the world and nod my head in unison...

But is this actually possible? That is not a light at the end of the
tunnel is it?

- bob



On Thu, Apr 16, 2009 at 2:26 PM, Andrei Zmievski <andrei@...> wrote:

> It sounds to me like the current doc system is a big barrier to entry for
> those who want to contribute to the documentation. To summarize my feelings
> on this subject: I'd rather have a non-php.net-standard doc system that
> works and allows easy contributions that be stuck in the current rut.
>
> -Andrei
>
> --
> PHP-GTK General Mailing List (http://gtk.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Elizabeth M Smith]

Andrei Zmievski wrote:

> Elizabeth M Smith wrote:
>>> I'd be inclined to branch php-gtk-doc now and adapt the current
>>> serverside scripts to use that branch while work's in progress on
>>> upgrading to v5 in HEAD. In that case, it'd be best to get the sysadmin
>>> to hit on everything at the same time rather than pester him twice over.
>> Sounds good.
>
> It sounds to me like the current doc system is a big barrier to entry
> for those who want to contribute to the documentation. To summarize my
> feelings on this subject: I'd rather have a non-php.net-standard doc
> system that works and allows easy contributions that be stuck in the
> current rut.
>
> -Andrei

We have guys offering to do the work to migrate to docbook5, fix the
reflection doc updater, and make PhD do php-gtk builds with a new shiny
theme... - they've started on it already in fact... personally if they
want to give their free time to do the migration I'm not going to tell
them no.

Work is in an outside svn right now... we can either wait and see if
something comes of it, then branch the current docs and let them push
the new stuff... or branch it now and let them work in php-cvs - I don't
really care.

For now - someone troubleshooting the issues with builds on Y1 would be
great, so we can at least have a little bit more recent docs.  People
can continue to work on the current docs... not that anyone is... but
they can - we just can't build them for the live site.

Thanks,
Elizabeth

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Benjamin Smith-6]

On Thursday 16 April 2009 11:26:59 Andrei Zmievski wrote:
> It sounds to me like the current doc system is a big barrier to entry for
> those who want to contribute to the documentation. To summarize my feelings
> on this subject: I'd rather have a non-php.net-standard doc system that
> works and allows easy contributions that be stuck in the current rut.

A heavy PHP-GTK1 developer and long-time list-lurker dances in the street,
hands overhead, smiling with glee. Yippee!

-Ben

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Madeleine D.-3]

Make that two of us.  I think my godzillion lines of code are even cheering.


Madeleine D.



Benjamin Smith wrote:

> On Thursday 16 April 2009 11:26:59 Andrei Zmievski wrote:
>  
>> It sounds to me like the current doc system is a big barrier to entry for
>> those who want to contribute to the documentation. To summarize my feelings
>> on this subject: I'd rather have a non-php.net-standard doc system that
>> works and allows easy contributions that be stuck in the current rut.
>>    
>
> A heavy PHP-GTK1 developer and long-time list-lurker dances in the street,
> hands overhead, smiling with glee. Yippee!
>
> -Ben
>
>  

--
PHP-GTK General Mailing List (http://gtk.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php