Consolidation

[Maciej Bliziński]

Hi Stefan,

On Tue, Apr 15, 2014 at 01:28:46PM +0200, Stefan Schnyder wrote:
> Now my thoughts:
> 
>  * I think, that our website doesn't need to contain that much
>    information. It needs to get people started & provide access to
>    further information and tools (Daniel had some nice ideas there).

Yes, I agree.

>  * The current info on the website, the manual, the wiki(s) and all
>    info out there should be in one place. Preferably a tool which may
>    be edited over a browser, if we want to give all people the ability
>    to edit as well.

Two thoughts. One is that maybe not absolutely everything must be in one
place. Different documents are updated with different frequencies. For
example, we have a number of project pages on wikidot used to coordinate
collective efforts, for example the mass perl module rebuild. Others
such as the manual, are updated less frequently. Perhaps the collective
notepad case and the more static notepad case do not have to be accessed
with the same mechanism.

The second thought is access. For example, I like the checked in manual,
because it's simply part of our code base. If you can commit a build
recipe, you can commit a documentation change. The amount of friction is
a tiny bit higher compared to in-browser editing, but at the same time,
it's more inclusive: every maintainer has a text editor and subversion
access. You don't have to ask for extra permissions on wikidot, for
example. It's easy to test the changes: you edit files in
pkg/opencsw-manual/files, type "mgar clean install" and you can view
your modified manual online, e.g. for me the URL is:

http://buildfarm.opencsw.org/~maciej/opencsw-manual/

If people still think this is hard, I won't have an objection to
migrating elsewhere. But for now I want to propose that we stick with
a checked-in manual, and not require in-browser editing.

>  * I support the idea of separating information from bugtracking from
>    mailing lists from social media, etc. There should be only one place
>    for the same kind of thing, but a place for each kind of thing.
>  * The rework should be coupled with the new website that Daniel is
>    working on.
>  * It may be worth a thought if we should separate our "product" (the
>    recipes & packages) from our own tools (gar, buildfarm, ...) or
>    combine them. I'm talking about info & bugtracking & (...) for each
>    or for both in one place. Having only one place would/could reduce
>    the maintenance on the tools, but maybe lead to confusion for the users.

We've talked about this for a long time. AFAIR, Dago argued that it's
better to keep recipes and corresponding GAR versions in the same
repository, because you can check out the repository from a given point
in time and they're likely to match: you can check out an old recipe
from and old revision, get an old version of GAR and build it
successfully.

For my own workflow, I keep two separate checkouts, one for the recipes
and one for GAR (via git), so they're pretty much already separate for
me, and I think would could separate them. I also think that it doesn't
matter that much.

> I would like to propose, that we decide on a existing or new tool
> for storing & presenting information and then gradually start moving
> stuff away from the old locations. I would volunteer to do the
> moving.
> 
> What are your thoughts?

Deciding on documentation formats and places is something we've
generally been bad at. If you want to do the work, I say you get to pick
the technology. Think about how it will be maintained in the future: the
lower maintenance cost, the better. For example, please try to avoid
creating a new place where everybody has to create a new username and
password.

Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20140416/70c05dde/attachment.asc>