On Feb 18, 2016 9:27 AM, "Paul W. Frields" <stickster(a)gmail.com> wrote:
On Mon, Feb 08, 2016 at 09:34:35AM +1000, Jeff Fearn wrote:
> On 02/05/2016 11:34 PM, Dylan Combs wrote:
> > (2) tooling that worked like a git/pull-request model?
>
> As a developer I am really opposed to inflicting git's pull/request
> work flows on Humans. IMO docs and code have a highly divergent set
> of attributes and what makes git good for code doesn't help at all
> with docs, in fact the complexity of git work flow is just a barrier
> to entry for a lot of potential docs contributors.
Elsewhere I mentioned online editing in a git repo (which could be
made transparent to a user). The user edits in a web browser, and
doesn't worry about the pull-request mechanics. I'm not married to
that by any means. But it seems to me that someone clicking a link,
editing in a text entry form, and hitting a "Save" button without
having to do any other work is a pretty low barrier and worth aiming
for.
--
Paul W. Frields
The system I've been working on is intended to address this by periodically
querying pkgdb, which maps F$n to rawhide, prerelease, brabched, current
release, previous release, and eol iirc. The system then maps git branches
to release statii so only content from ie current and previous release are
propagated to the user. This is similar to the dist-git paradigm, except
that release branches are not automatically created in content repos; this
way, expiration of content is automatically offloaded to the CICD process
unless maintainers take explicit action to branch and update their content
for a given release.
Some of this code exists, but could use more polish. I'm currently trying
to set it up so the branch mapping can live in the content repo, and the
repo's build process (to a reasonable extent) can be defined in the same
place as the content.
And yes, pagure compliments this method nicely, especially the online
editing feature, which iirc pingou began to implement after I discussed
some of the above with him.
--Pete