On Thu, 2007-10-11 at 01:20 +0000, Paul W. Frields wrote:
On Tue, 2007-10-09 at 12:20 -0600, Jonathan Steffan wrote:
> * Replace Makefiles with config files and then use the FDP to do
all
> building, allowing a user to specify they want to use the local cpu to
> do the building, or if they want to use the buildd.
>
> + We get to use python :-D
> + IMHO we would get much more flexibility and a tighter integration
> with our translators and translation systems (read: translators would be
> able to easily render for their language to check their results before
> pushing the build to zope
> + AFAIK, we have more combined skills with python, over Makefiles
I afraid of being a naysayer, but this sounds a bit like the cart
driving the horse.
This is the essence of my concern, that tools needs are driving the
situation. DocBook XML in an SCM is a well known, stable way to write
content.
Does this mean that two people can't work on a guide at the same
time,
or only that two people can't publish the same guide at the same time?
Because currently, Karsten and I can do something like hit the Release
Notes "beats" in tandem to get the content put together faster. Can you
explain this in a way that shows me how we gain by using this kind of
scheme?
In fact, that is an essence of source control. You can work on the same
file at the same time.
I think I may be able to hazily glimpse a little of why these config
files are important, but it's still eluding me. Could these config
files, then, be generated from Makefile rules and a bit of other content
unseen by mortals? That would retain some sort of compatibility for
people who just want to do work via the $SCM command line.
+1
If we have to have a parallel system, it would help to have them tie
together via Makefiles somehow. Plone administration could be a
separate function from CVS/Makefile admin.
Basically, we're already stretched thin on resources to handle a
relatively simple Makefile system. Building a more complex beast to
replace it is a bit scary. Perhaps if we got Fedora Infrastructure
involved? But really, it's not their job to maintain sub-project
toolchains. I'm nervous about creating a need for a *more* experienced
resource to replace what we have now.
- Karsten
--
Karsten Wade, Developer Community Mgr.
Dev Fu :
http://developer.redhatmagazine.com
Fedora :
http://quaid.fedorapeople.org
gpg key : AD0E0C41