Jeremy Newman wrote:
> Molle Bestefich wrote:
> > Jeremy Newman wrote:
> > > Just wanted to make my point that it would be crazy to loose all the
> > > useful features that SGML provides.
> >
> > MoinMoin 1.3.5 supports DocBook parsing and generation.
And if that's not good enough, there's another
Jeremy Newman wrote:
> > Killer!...
> > MoinMoin 1.3.5 supports DocBook parsing and generation.
> >
> > Any reason why that wouldn't be good enough?
>
> We need to weigh all the possibilities here. Jumping from our current
> process is not something that will happen overnight. My first reaction
> i
On Tue, 2005-10-04 at 15:26 +, Molle Bestefich wrote:
> Jeremy Newman wrote:
> > Just wanted to make my point that it would be crazy to loose all the
> > useful features that SGML provides.
>
> Killer!...
> MoinMoin 1.3.5 supports DocBook parsing and generation.
>
> Any reason why that wouldn
If we are going to consider moving the wiki can we move to wiki
software that lets you use html in wiki entries? I'd imagine not
having to learn wiki tags would make it easier for people to produce
well formatted pages.
Chris
On 10/4/05, Jeremy Newman <[EMAIL PROTECTED]> wrote:
> On Tue, 2005-1
Jeremy Newman wrote:
> Just wanted to make my point that it would be crazy to loose all the
> useful features that SGML provides.
Killer!...
MoinMoin 1.3.5 supports DocBook parsing and generation.
Any reason why that wouldn't be good enough?
> It's not hard to learn to use and submit
> patches
On Tue, 2005-10-04 at 17:10 +0200, Jonathan Ernst wrote:
> That was exactly what I wanted to do:
>
> - let the sgml, wwn, press releases and so on where they are
> - move the rest to the wiki
>
> Sorry if that was not clear enough in my first message (when I said
> static I meant content that is
Le mardi 04 octobre 2005 à 09:40 -0500, Jeremy Newman a écrit :
> Also, don't forget. The WineHQ docs are in SGML which provides tools to
> convert it to any format. (html, PS, PDF, etc.) We really don't want to
> give up on those abilities.
>
> For any page that isn't SGML, sure it could be conve
Jeremy Newman wrote:
> Also, don't forget. The WineHQ docs are in SGML which provides tools to
> convert it to any format. (html, PS, PDF, etc.) We really don't want to
> give up on those abilities.
Right.
Hmm, let's see. Counting the number of items currently in use in the
SGML docs, there's:
*
Also, don't forget. The WineHQ docs are in SGML which provides tools to
convert it to any format. (html, PS, PDF, etc.) We really don't want to
give up on those abilities.
For any page that isn't SGML, sure it could be converted into a Wiki. In
fact, I'm now considering moving the entire WineHQ si
Molle Bestefich wrote:
> > This method is already available in the form of checking out lostwages
> > cvs, making changes, doing a diff, and sending in the patch to be
> > accepted. The only difference is that anyone can make changes to
> > lostwages this way (assuming they get committed).
>
> But
James Hawkins wrote:
> Molle Bestefich wrote:
> > Isn't there a compromise where Wiki's upfront editing capabilities can
> > be used to ensure up-to-date, dynamic content while you also make sure
> > that nobody wrecks the pages?
> >
> > I'm no wiki expert, but it seems like an obvious solution to
Le lundi 03 octobre 2005 à 13:23 -0700, Dan Kegel a écrit :
> On 10/3/05, James Hawkins <[EMAIL PROTECTED]> wrote:
> > This method is already available in the form of checking out lostwages
> > cvs, making changes, doing a diff, and sending in the patch to be
> > accepted. The only difference is t
On 10/3/05, James Hawkins <[EMAIL PROTECTED]> wrote:
> This method is already available in the form of checking out lostwages
> cvs, making changes, doing a diff, and sending in the patch to be
> accepted. The only difference is that anyone can make changes to
> lostwages this way (assuming they g
From: "Brian Vincent" <[EMAIL PROTECTED]>
> I'll agree for the same reasons Jeremy cited. The static pages are
> relatively static and one of the only exceptions to that was a
> Janitorial page which really required a quick way to jot down ideas.
> There are two pages that might be useful to mov
On 10/3/05, Molle Bestefich <[EMAIL PROTECTED]> wrote:
>
> Isn't there a compromise where Wiki's upfront editing capabilities can
> be used to ensure up-to-date, dynamic content while you also make sure
> that nobody wrecks the pages?
>
> I'm no wiki expert, but it seems like an obvious solution to
Jeremy White wrote:
> > I'm willing to move every simple textual (static content) page from the
> > website to the Wiki and link from the website to the corresponding
> > pages.
>
> I think this is a bad idea.
>
> The current system ensures that changes to the core parts
> of WineHQ are reviewed be
Le lundi 03 octobre 2005 à 09:25 -0700, Dan Kegel a écrit :
> On 10/3/05, Jonathan Ernst <[EMAIL PROTECTED]> wrote:
> > I'm willing to move every simple textual (static content) page from the
> > website to the Wiki
>
> Please don't do this.
I won't as nobody wants it. Let's just hope that the do
On 10/3/05, Jonathan Ernst <[EMAIL PROTECTED]> wrote:
> I'm willing to move every simple textual (static content) page from the
> website to the Wiki
Please don't do this.
On 10/3/05, Jeremy White <[EMAIL PROTECTED]> wrote:
> > I'm willing to move every simple textual (static content) page from the
> > website to the Wiki and link from the website to the corresponding
> > pages.
I'll agree for the same reasons Jeremy cited. The static pages are
relatively static an
> I'm willing to move every simple textual (static content) page from the
> website to the Wiki and link from the website to the corresponding
> pages.
I think this is a bad idea.
The current system ensures that changes to the core parts
of WineHQ are reviewed before being made, whereas a Wiki
ca
Hi everyone,
I'm willing to move every simple textual (static content) page from the
website to the Wiki and link from the website to the corresponding
pages.
The advantages are obvious:
- makes it easy to keep these pages up-to-date
- makes it easy for non-dev. contributors to keep these pages u
21 matches
Mail list logo
