Re: [Gnu-arch-users] NEW POLICIES (draft)

[Thomas Lord]

    > From: Andrew Suffield <address@hidden>
    > > Ideally, 3rd parties should be able to construct at least casual
    > > contributions and ideally long-term contributions as described in the
    > > standard, yet have those processed by the voting system.   It's the
    > > path from entry to the voting system to inclusion in mainline that
    > > needs some attention.

    > Entry point is (has to be) a completely formed merge request in the
    > bug goo database; anything else is far too much work, and it's not a
    > particularly onerous requirement; by design you can stuff any
    > arbitrary thing produced by a front-end process in here with minimal
    > effort.

    > Exit path is not my problem; you can pure-merge from the managed
    > branch (rubber-stamping the group's work), ignore it completely
    > (discarding the group's work), or any point in between.

    > I can't think of anything else that matters here.

The issues that concern me about the relationship between voting
system and mainline are more or less summed up by two parts of 
stds--rel-src-mgt--1.0:

First, the section "Quality Standards for Development Branches"
should give you some idea what the output of the voting system
has to provide: I'm at the moment disinclined towards the idea of
batching many otherwise unrelated changes in the voting system and
then merging them, en masse, to the mainline --- I'd much prefer
preserving the independence of changes in spite of their being vetted
by co-maintainers, for the reaasons stated in "Quality Standards" (and
we can probably think up some more to go with those).

Second, consider the subsection "The Problem with Long Term Branches",
combined with the role of the voting system in conflict resolution (by
filtering out changes that conflict).  Although the voting system
itself simply punts on conflict resolution, its deployment implies a
strategy for conflict resolution --- namely that submitters to the
queue take steps to try to ensure that when their sumbission is
processed, it happens to apply cleanly against the voting system
target version.

If we assume, as I do for the moment, that the GNU mainline and 
target version of the voting system are distinct, then merges to one
are asynchronous to the other, there's a need to syncronize them,
those syncronizations, done naively, can lead to conflicts --- thus
undermining half the useful functionality of the voting system.

A solution that would certainly work, although it implies some changes
to the voting rules, would be for the output of the voting system to
be a cascade and to establish a policy about the frequency of
bidirectional merging between that cascade and the mainline.  The
voting-approved queue of merges could, upon a merge from mainline to
cascade, have to backtrack --- but that is simply realistic and the
voting system could and probably should afford an opportunity for the
work of recovering from such backtracks to be distributed rather than
entirely foisted on a single maintainer.


-t