[wanted] thoughts on repos structure

[Sean Wheller]

Hello people,

After the meeting I have started to look at the work. One of the things I am 
thinking about is whether or not the current repos structure will continue to 
work going forward. 

Now before everyone gets a fright, this message is only to get your thoughts 
and hopefully reach consensus. Besides I would not want to do any repos 
changes until we have tagged for hoary and can hack the trunk at will.

We need to consider a few things that may or may not impact of the repos 
structure. It's hard to put them in short bullets, so bare with me.

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 
structure.

=vote here

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.

=vote here

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?

=vote here

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.

=vote here.

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.

Look forward to seeing your votes.
 
-- 
Sean Wheller
Technical Author
sean at inwords.co.za
http://www.inwords.co.za
Registered Linux User #375355
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-doc/attachments/20050313/d609f26b/attachment.pgp>