[OPEN-ILS-DEV] [OPEN-ILS-DOCUMENTATION] ***SPAM*** Re: Forming Teams by Topic

[Soulliere, Robert]

Thanks Dan,

Didn't mean to center you out. I was quoting you as the messenger. I should have copied the DEV list with my request.

The structure of the docs branch you set out below looks good to me. Would that be a good quick solution as the main repository for documentation -- at least until the DVCS tool is established? Would that work for everyone else involved - Documenters and Developers?

One other topic which may need to be discussed among the DIGers is how to handle the minor releases. For example, 1.6.1.x will add a few brand new features not in 1.6.0.1 (Booking module and password resetting self-service). I wonder if we just need to add a note under the sections dealing with these topics informing users that they are only available in version 1.6.1+ or if we need entirely different documentation sets for each for these minor release versions?


Thanks,
Robert

________________________________________
From: open-ils-dev-bounces at list.georgialibraries.org [open-ils-dev-bounces at list.georgialibraries.org] On Behalf Of Dan Scott [dan at coffeecode.net]
Sent: May 20, 2010 11:21 PM
To: Documentation discussion for Evergreen software
Cc: Evergreen Development Discussion List
Subject: Re: [OPEN-ILS-DEV] [OPEN-ILS-DOCUMENTATION] ***SPAM*** Re: Forming     Teams by Topic

On 20 May 2010 06:54, Soulliere, Robert
<robert.soulliere at mohawkcollege.ca> wrote:
> Hi All,
>
>
> I am wondering if we have come to a decision regarding the DIG repository? I brought this up last month, but did not see a definitive answer develop. Jason has brought it up again and I hope we can come up with definitive repository based home for docbook documentation files.
>
> I also asked if DIGers could be given access to the SVN repository to commit Documentation to the doc directory. Dan mentioned that we can ask for access.
>
> I followed up with this request on the list:
>
> "During the DIG meeting I volunteered to commit the documentation to the repository, so if I could be granted access that would be great. Let me know if you need more information from me such as  preferred username."
>
> I didn't hear back from anyone regarding access. Hopefully, it wasn't an issue with my trustworthiness;-) I am at least 90% sure that I will not delete the entire Evergreen repository by accident or overwrite it with My own version. However, creating a branch off of trunk for documentation as Jason suggests might be a good safety precaution.
>

Sorry if you were looking at me to do this, I've been away for most of
May and I'm not sure the request was visible to anyone else with SVN
powers on the developer list (CCing the -dev list now).

Trustworthiness isn't the issue. SVN comes with the ability to lock
down write access to particular directories and/or branches, in any
case. There is probably a silent debate about moving to a DVCS, silent
only because most of the developers are focused on a 2.0 release that
doesn't seem all that far away and changes to core development tools
probably aren't high on the priority list right now. (Purely a guess
on my part based on being away most of May, as above; not even in IRC
more than a handful of times).

Forgive me for not remembering what structure you and the rest of the
documentation team desired: do you want an empty branch that will only
contain documents, perhaps with versioning like:

/branches/
  docs/
    1.4/
    1.6/
    2.0/

... with the idea that the version-specific subdirectories will mirror the code?

This E-mail contains privileged and confidential information intended
only for the individual or entity named in the message.  If the reader
of this message is not the intended recipient, or the agent responsible
to deliver it to the intended recipient, you are hereby notified that
any review, dissemination, distribution or copying of this communication
is prohibited.  If this communication was received in error, please
notify the sender by reply E-mail immediately, and delete and destroy
the original message.