monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] Re: ikiwiki and monotone


From: Brian May
Subject: Re: [Monotone-devel] Re: ikiwiki and monotone
Date: Fri, 13 Oct 2006 15:50:58 +1000
User-agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux)

>>>>> "Daniel" == Daniel Carosone <address@hidden> writes:

    Daniel> Sure, it's the same thing with a different certificate
    Daniel> name.

Of course. Message to self: wakeup!

    Daniel> Sure. The X/Y/Z requirement amounts to setting the update
    Daniel> trust hooks for the build workspace when recompiling the
    Daniel> pages.

I read a prior thread on this mailing list where it was felt it would
be a good idea to separate the update code from the hook:

http://lists.gnu.org/archive/html/monotone-devel/2006-07/msg00144.html

Is that still the case? Would it apply here? Did anybody come up with
a good solution?

Is running "mtn update" from within the note_* triggers Ok?

    Daniel> Either way, add some simple UI to tell the user "your
    Daniel> submission has been accepted for review and approval" so
    Daniel> they don't get confused, and perhaps links to search
    Daniel> viewmtn for other edits pending approval.

Yes, I think this would be important. I suspect the current API plugin
for ikiwiki doesn't support it though (that doesn't mean it can't be
added).

    Daniel> The thing is that certs are whole-revision, whatever cert
    Daniel> you use.  In the sample scenario, you want to allow
    Daniel> arbitrary web submissions to most pages, but moderate
    Daniel> some. So you need a way to flag these pages for special
    Daniel> handling. This could be an attr, or maybe a PageSpec.

I suspect this is currently a weak area of ikiwiki - either you allow
web modifications to all pages or no pages (I might be mistaken).

    Daniel> Then one of two things happens: - web commits for pages
    Daniel> with this flag tell the cgi to commit to the for-review
    Daniel> branch, while others go to the main branch - all web
    Daniel> commits go to the review branch, and the TrustBot then
    Daniel> auto merges/approves revs on that branch that *don't*
    Daniel> involve a file with this attr, leaving the others to be
    Daniel> merged by people.

    Daniel> They're pretty similar, one just puts the bot within the
    Daniel> cgi and closer to the wiki, the other works with netsync
    Daniel> submissions too.

So, if I got this correct, we have a "moderation required" flag for
certain pages. The first method:

if (moderation) {
   commit to review branch;
} else {
   commit to main branch;
}

The second method is:

commit to review branch;

With the trustbot automatically merging in all non-conflicting changes
that don't require moderation.

If conflicts occur, then ???



I think you may have to define moderation as "if at least one of the
files in this changeset modifies a moderated file...".

I tend to like the 2nd version, because it will work with netsync. I
guess the 1st one would too, but presumably all netsync requests from
untrusted sources would have to go through the review branch.
-- 
Brian May <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]