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
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-docs-list mailing list fedora-docs-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-docs-list
