|Summary:||Toolchain next steps|
|Product:||[Fedora] Fedora Documentation||Reporter:||Mel Chua <mel>|
|Component:||project-tracking||Assignee:||Nobody's working on this, feel free to take it <nobody>|
|Status:||CLOSED WONTFIX||QA Contact:||Karsten Wade <kwade>|
|Version:||devel||CC:||docs, eric, stickster, wb8rcr|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-10-29 13:48:17 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Mel Chua 2009-06-04 02:05:58 UTC
Sorting out what fedora-doc-utils does, where to use Publican, etc. -- Principals to discuss status, progress, direction on IRC.
Comment 1 John J. McDonough 2009-06-04 12:22:25 UTC
I wonder a bit about that description. In the process of preparing f-r-n for F11, there were only three things I could have used from a next generation toolchain: 1) Create .omf files, 2) deal with language merge/unmerge, and 3) package. I think we know wnat f-d-u does, at least "well enough" since we are leaving it behind. If we are also leaving yelp to history, which it sounds as if we will, then almost all of f-d-u's magic is irrelevant. I think we have concluded we want to use Publican pretty much everywhere, at least, I thought that's what I heard. So, that leaves us with just a few questions, pretty much around Publican. 1) Partly because of Publican weirdness, but also because we were clinging on to Gnome help, we manually produced the RPM for f-r-n. How hard do we want to push to get upstream to produce useable RPMs? My spin is that with a single document the process is simple enough that getting it fixed in Publican is more work than just doing it. 2) If we are going to simply point to an html from the menu, how do we handle languages? I know it can be done, I just don't know how. We need to identify that and document it. 3) Is there really any issue with languages once we have the new Transifex.
Comment 2 eric 2009-06-04 17:23:31 UTC
(In reply to comment #1) > 1) Partly because of Publican weirdness, but also because we were clinging on > to Gnome help, we manually produced the RPM for f-r-n. How hard do we want to > push to get upstream to produce useable RPMs? My spin is that with a single > document the process is simple enough that getting it fixed in Publican is more > work than just doing it. I think we've pushed pretty hard to get the RPMs from Publican fixed upstream and approved by Fedora. I'm not sure what else we need to do to just spit out the RPMs as I thought all our problems had been solved. > 2) If we are going to simply point to an html from the menu, how do we handle > languages? I know it can be done, I just don't know how. We need to identify > that and document it. I didn't think we were just going to point to an html. Errr... are we talking about local html or pointing it to a website somewhere? > 3) Is there really any issue with languages once we have the new Transifex. I don't think there are any more issues... but I don't know that it's been tested so I won't say there won't be. Is there a test version of the new Transifex available?
Comment 3 John J. McDonough 2009-06-04 18:03:18 UTC
> I think we've pushed pretty hard to get the RPMs from Publican fixed > upstream and approved by Fedora. I'm not sure what else we need to > do to just spit out the RPMs as I thought all our problems had been > solved. I was under the impression that we were going after the RPM naming issue, but hadn't thought about multiple language RPMs. Based on last night's meeting I'm not sure we even know whether we will produce single-language RPMs or multiple like we do now. And then of course there is the issue of multiple docs in one RPM with different targets (as in f-r-n currently). > I didn't think we were just going to point to an html. Errr... are we > talking about local html or pointing it to a website somewhere? Ahh context. Currently, we use yelp to display the release notes and about-fedora. I gathered last night there was some concensus to move away from that toward HTML on disk and a menu item pointing to it. Publican will do that in a Publican-generated RPM, but it will do that for one language and it isn't at all clear that if multiple languages are installed it knows how to change that entry for the currently logged in language (as yelp does). Even if we decide on one RPM per language, I think we need to address the case of multiple languages installed on one PC. Perhaps Publican magically deals with all this, but I haven't seen any evidence so I'm skeptical. Should it? Absolutely! But it does seem like it may be asking a lot.
Comment 4 eric 2009-06-04 18:16:53 UTC
Maybe we can get Jeff on the phone one day soon and figure this out. I think being able to talk to him and maybe some of the packagers (Jens?) on at the same time might be a good idea.
Comment 5 eric 2009-08-05 18:52:56 UTC
With the release of Publican 1.0, I think most of these concerns have been addressed. As far as multiple languages, Publican creates SRPMs that look like <guide>-<version>-<lang> so you could install every language a guide came in if you wanted.
Comment 6 Paul W. Frields 2010-04-05 21:11:37 UTC
I'd recommend to CLOSE this as UPSTREAM, then. If we need further features in Publican we can request them as enhancements upstream and discuss there.
Comment 7 John J. McDonough 2010-10-29 11:25:41 UTC
Several things have happened over the months, and I'm not sure whether it makes sense to close this or keep it open. 1) It is quite clear that Eric's remark "you could install every language a guide came in if you wanted" is unrealistic. Publican creates a menu item per guide per language, and the titles aren't always different between language so you can't be sure what language you are getting. 2) Publican is not going to fix this because the Fedora behavior (which BTW is also the Ubuntu behavior) is different than the RHEL behavior. 3) We now have a process for dealing with this, but it needs formalization. 4) There may be compelling reasons to go back to Yelp following GNOME 3 (which has been delayed).