[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: toolchain rock-up



On Wed, 2008-05-21 at 17:29 +1000, Jeff Fearn wrote:
> Hi, here is some feedback for people to chew on before the meeting.
> 
> Hopefully it will minimize time spent on points that are already know,
> get people to think of some other questions to ask, and help people
> gather relevant information where required.

Thanks.

> Karsten 'quaid' Wade wrote:
> > We've been talking about rocking up our toolchain by integrating
> > Publican[1].  We need to set up some tests to be able to confirm if
> the
> > tool does what we need, technically, socially, and communally.
> > 
> > Please add yours to the list below, then we can throw it in a wiki
> page
> > to start working against.
> > 
> > = Technical =
> > 
> > * Does it fulfill all the current tool's capabilities?
> >   - These need to be defined and listed as specific tests
> 
> You need to know which of those capabilities are must haves and which
> are niceties.

I'll be surprised if we've baked any niceties in; it's a fairly sparse
toolchain.

The 'docs-common' tools mainly build output from input XML.  However,
there are a few bits that are Fedora-specific, such as how we generate
an RPM and SRPM for the release builds, desktop files, etc.  In many
cases, I expect we'll just call Publican's make instead.

> > * Is it built on sound technology with a future?
> 
> The current system is tightly bound to CVS ... please, let CVS die
> quietly, it has earned its rest.

There are separate issues here.  We cannot separate the need to maintain
packages such as fedora-release-notes in CVS.  However, last week we
agreed to stop pushing new books in to CVS and to let them form
one-project-per-book on fedorahosted.org.  Once we give the toolchain
it's own fh.o project space, we can retire most of our CVS usage. 

> Publican uses standard Linux technologies and FOP. If anyone makes a
> better PDF generator than FOP it will get assessed by the publican
> team _immediately_!!111!

+1 ... you know you don't have to convince me here. :)

Anyway, yes, that is a good answer to that checklist item.

> > * ...
> > 
> > = Social =
> > 
> > * Is there an active upstream?
> 
> Bugs against Publican have already being lodged and fixed in the
> Fedora Bugzilla.
> 
> > * Is upstream responsive to Fedora Docs?
> 
> See above.

+1 on both from what I've seen so far.

> > * Is the upstream work in the open?
> 
> Publican development is hosted on fedorahosted.org.
> 
> > * Can anyone (theoretically) join the upstream work?
> 
> Theoretically anyone with a FAS account can join the Publican team.
> 
> > * Is there a role Fedora Docs should take in the upstream?
> 
> What role does Fedora docs take in other upstream packages?

* We contributed the original patch to xmlto to support FOP
* We've been highly active with the Fedora Java folks to get FOP
packaged and supported in Fedora
* Worked with MoinMoin on Google Summer of Code dev project
* Other small bugfixes, iirc
...

Like other parts of Fedora, we see the value in remaining active with
the upstream, no matter the outcome.

> > * ...
> > 
> > = Communal =
> > 
> > * Is there a Fedora packager?
> 
> There is no packager for the current system.
> 
> Since publican is packaged in Fedora (8, 9 & devel) this question
> would seem to have an answer.
> 
> > * Is it maintained for EPEL as well?
> 
> You mean packaged. The current system is not packaged for EPEL.

"Maintain a package," yes.

> Publican has been built in plague for EPEL 4 & 5, the packages are
> waiting to be pushed to the repos.

Sweet.

> > * Do other parts of Fedora want to use this tool?
> 
> Which other parts of Fedora use the current tool?
> 
> Several Fedora projects, e.g. Fedora Directory Server & Fedora IPA
> etc, either already use publican or are having their documentation
> migrated to publican.

That's good news, thanks.

- Karsten
-- 
Karsten Wade, Sr. 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]