[wanted] thoughts on repos structure
ubuntu at trickie.org
Sun Mar 13 23:18:59 UTC 2005
Sean Wheller wrote:
> The most immediate problem is to facilitate translations. We currently do not
> use the convention of placing documents into folders intended for specific
> languages. For example, the C/ is used for English documents. I think we may
> need to cater for this convention if we are to maintain some order to the
> repos going forward. Do you feel we should use this method? I will tally
> votes and if required spawn a new thread so we can discuss proposals on
> =vote here
This is like a ballot card :)
+1+1+1 for using the gettext inspired layout. I don't have time to do
this for the next few days, but then i was hoping to work on this (as
well as the .pot and .po files for rosetta)
> The next problem is how to manage GNOME and KDE Documents effectively? We
> agree to do documents for Kubuntu. I would like to start with the K Quick
> Guide. Now, as I see it, we have a few options on how to manage this.
> 1. We document in the current quickguide.xml and use profiling.
> I don't think we can do this due to the fact that we have not decided whether
> or not ubuntu-docs will be dynamic under yelp or static html under any
> browser. Yelp does not currently support profiling, a method we would have to
> use if we wanted to manage in this way.
> 2. We document in the same folder in a file called kquickguide.xml
> This would be straight forward as we did with the gnome document. Screen capts
> continue to be places in images/
> 3. We make a more intrusive change by creating a trunk/gnome/ and trunk/kde/
> where we create and maintain the two desktop docs seperately. In this case
> each would have an image/ folder so trunk/gnome/images/ and trunk/kde/images/
> I the top level libs/, common/, etc. will remain. However, the make system
> will need splitting into two objects, one for kde and one for gnome. The root
> makefile can still hook these make subsystems.
> Do you think we should consider using one of these methods? Please vote and I
> will spawn a thread for this topic if required.
+1 option 2 or 3. Option 1 does not look like it is doable at this point
> We are often get requests to edit documents external to our primary domain,
> but which I mean documents that are not wiki or part of ubuntu-docs. For
> example, the Synaptic Manual. There are a number of problems with this:
> 1. Moving out to do external docs detracts from our focus and therefore
> diminishes productivity in ubuntu-doc. Naturally, we cannot stop people doing
> external docs and don't want to stop them. We also want to help on other
> things and do ubuntu-docs. We want to do everything :-)
> 2. Where is the repos? It is time consuming to determine where the repository
> for a given document is. Is there a snapshot in some server within the ubuntu
> community, or must we go all the way upstream to get a copy against which we
> can patch. Getting and installing sources from the software repository just
> consumes disk space.
> I wonder how we can manage this. Perhaps we can have a list of where to get
> certain docs and grow that over time. A single place to find this info would
> be a blessing. Do you want to discuss this problem?
+ 1 on point 1.
+1+1 on point 2. I don't know how authoritive we will be on this topic
without maybe discussing the issue (and what to do) with someone like
jdub or mdz.
> Sometimes we will have documents that are not strictly in the ubuntu docteam
> project list. For example, I am writing a document on how to install kde for
> ubuntu (kubuntu). It is an article type document. In the future it may become
> part of a greater document by for now it is aimed at sufficing a simple need
> to know how. So it can be called a HOWTO. Where would we put such documents
> in the repos. Take into consideration your thoughts on the above repos
> problems and vote here if you want to discuss your ideas.
+1 the earlier we get docs into the repos (even if they are one page
howtos), then the earlier the will start getting worked on, reviewed,
evolved etc etc
> Each of these topics will be spawned into sperate threads so that we can:
> a. focus on those thread in which we are interested.
> b. make it easier to follow and respond on topics.
Excellent Ideas Sean!
More information about the ubuntu-doc