Thread: Re: Huge commitfest app update upcoming: Tags, Draft CF, Help page, and automated commitfest creat/open/close

On 16.06.25 14:47, Jelte Fennema-Nio wrote:
> # Draft CF
> 
> There's now an additional Draft CF. People can move patches there as a
> way of not forgetting about them. CFBot will rerun these patches less
> frequently (exact behaviour TBD). Draft CFs are never "In Progress"
> and are open until the final CF of the release cycle becomes "In
> Progress". So PG19-Drafts will close on February 28th 2026, and at the
> same moment PG20-Drafts will be opened.

Can we clarify the expectations around this?

In some early discussions, I had heard this being talked about as a 
"parking lot".  You can put patches there so that they get CI runs, but 
no one else is really expected to pay attention to them.  Makes sense.

But many patches that are routinely submitted to normal commit fests are 
really drafts, in that they are in an early phase of development but 
still need feedback.

I sense there could be some confusion whether such draft patches should 
go into the regular commit fest or the draft commit fest, and then also 
when they should move between them.

On 16.06.25 14:47, Jelte Fennema-Nio wrote:

# Draft CF

There's now an additional Draft CF. People can move patches there as a
way of not forgetting about them. CFBot will rerun these patches less
frequently (exact behaviour TBD). Draft CFs are never "In Progress"
and are open until the final CF of the release cycle becomes "In
Progress". So PG19-Drafts will close on February 28th 2026, and at the
same moment PG20-Drafts will be opened.

Can we clarify the expectations around this?

In some early discussions, I had heard this being talked about as a "parking lot".  You can put patches there so that they get CI runs, but no one else is really expected to pay attention to them.  Makes sense.

But many patches that are routinely submitted to normal commit fests are really drafts, in that they are in an early phase of development but still need feedback.

I sense there could be some confusion whether such draft patches should go into the regular commit fest or the draft commit fest, and then also when they should move between them.

On 20.06.25 16:41, David G. Johnston wrote:

    I sense there could be some confusion whether such draft patches
    should go into the regular commit fest or the draft commit fest, and
    then also when they should move between them.

Draft CF patches with “Needs Review” are looking for feedback from others or otherwise aid in development for a patch that isn’t ready to be committed even if said review turns up nothing or is otherwise fully resolved.  Patches in Drafts are never marked Ready to Commit, they get moved to Open first.

It will be nice if people spend time providing reviews/feedback to patches in Drafts when requested.

It’s purely the author’s judgement on the readiness of the patch, whether absent our policy they would mark it ready to commit or not.  If they believe it is it should be moved to open, if no, it should remain in drafts.  This is mostly like what happens today but with a clear delineation between reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without having to be bumped to the next cf every other month and where an author patch can be ignored by everyone else not authoring it.

I don't know about this.  This could become an ongoing source of confusion, without any clear benefit.  Either the draft and the "real" commitfest are going to be indistinguishable, because they are just two places to look for stuff to review in various phases of maturity.  Or the draft commitfest is just not going to get any attention, which will be annoying for those who put things there hoping to get attention.

On Sunday, June 22, 2025, Peter Eisentraut <peter@eisentraut.org> wrote:

On 20.06.25 16:41, David G. Johnston wrote:

    I sense there could be some confusion whether such draft patches
    should go into the regular commit fest or the draft commit fest, and
    then also when they should move between them.

Draft CF patches with “Needs Review” are looking for feedback from others or otherwise aid in development for a patch that isn’t ready to be committed even if said review turns up nothing or is otherwise fully resolved.  Patches in Drafts are never marked Ready to Commit, they get moved to Open first.

It will be nice if people spend time providing reviews/feedback to patches in Drafts when requested.

It’s purely the author’s judgement on the readiness of the patch, whether absent our policy they would mark it ready to commit or not.  If they believe it is it should be moved to open, if no, it should remain in drafts.  This is mostly like what happens today but with a clear delineation between reviews to help and reviews to approve commit-ability.

Otherwise, it’s a place where author patches can sit without having to be bumped to the next cf every other month and where an author patch can be ignored by everyone else not authoring it.

I don't know about this.  This could become an ongoing source of confusion, without any clear benefit.  Either the draft and the "real" commitfest are going to be indistinguishable, because they are just two places to look for stuff to review in various phases of maturity.  Or the draft commitfest is just not going to get any attention, which will be annoying for those who put things there hoping to get attention.

Yes, more experienced people have to want to help people who can’t just get a patch ready to commit on their own.  As opposed to only reviewing things they expect to perform the formality of the review to make it ready to commit.  The tooling help distinguish those cases if used properly.  But people have to choose to do the things it encourages/enables.

If one performs a review of a non-draft and it isn’t close to ready, encourage the author to move it into drafts as part of a teaching moment of how their expectations of done-ness and yours differ.

We aren’t going to get 100% accuracy here but it’s is better information that intends to address the complaint that what we had was not fit for purpose because the information it provided was insufficient.  Tags get even more granular while this provides high-level draft/non-draft delineation where drafts don’t have to keep being shuffled around.  Review Need still needs review no matter where it is.  That doesn’t change.

+1

--

Vik Fearing