[bug#59513] [PATCH v2] doc: contributing: Tweak the Commit Policy.

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 1809 bytes --]


Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

>> > > +Changes should be posted to @email{guix-patches@@gnu.org}.  This
>> > > mailing
>> > > +list fills the patch-tracking database (@pxref{Tracking Bugs and
>> > > +Patches}).  It also allows patches to be picked up and tested by
>> > > the
>> > > +quality assurance tooling; the result of that testing eventually
>> > > shows
>> > > +up on the dashboard at
>> > > +@indicateurl{https://qa.guix.gnu.org/issue/@var{number}}, where
>> > > +@var{number} is the number assigned by the issue tracker.  Leave
>> > > time
>> > > +for a review, without committing anything (@pxref{Submitting
>> > > Patches}).
>> > > +If you didn’t receive any reply after one week (two weeks for
>> > > more
>> > > +significant changes), and if you're confident, it's OK to
>> > > commit.
>> >
>> > I would reword that so
>> >   (not significant ∧ confident ∧ qa_green) → good after 1 week
>> > whereas
>> >   (not significant ∧ confident ∧ qa_unknown) → good after 2 weeks
>> > and significant changes should anyway take 2 weeks.
>>
>> While I like the intent here, for the moment I prefer a simpler
>> policy. Maybe we can move in this direction when the QA tooling is
>> more usable and reliable.
>
> I wrote this partly with the intent of resolving an ambiguity, but I
> agree on the principle of having a simple policy.  I take it that QA
> status is not that important at the moment – more that QA knows about
> the patch and has already started building packages?

I don't think the QA stuff happening is important enough make some
requirements of it in the policy (yet), but, as you say, there are still
benefits right now with submitting patches to guix-patches, and that's
what I'm going for here.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]