Re: pending-pullups

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

On Dec 1, 12:01am, Izumi Tsutsui wrote:
} jnemeth@ wrote:
} > On Nov 29,  3:14pm, Izumi Tsutsui wrote:
} > } dholland@ wrote:
} > } > On Sun, Nov 29, 2015 at 12:58:35PM +0900, Izumi Tsutsui wrote:
} > } >  > > (the reason, besides "that's how it's been used since it was added",
} > } >  > > is that the pending-pullups state distinguishes "PRs that somebody
} > } >  > > needs to work on" from "PRs that are waiting on releng", which is an
} > } >  > > important distinction when looking for work to do.)
} > } >  > > 
} > } >  > > we ought to have a pullups-needed state; maybe we should just add it
} > } >  > > to gnats.
} > } >  > 
} > } >  > Why do you think two independent states are necessary? What's benefit?
} > } > 
} > } > So that someone searching gnats can tell if a PR they're looking at
} > } > requires action or not.
} > } > 
} > } > Releng doesn't do that, that's what the ticket queues are for. (And
} > } > that's why PRs with pending pullups are supposed to have ticket
} > } > numbers listed, to make sure we can check from the gnats end whether
} > } > things have been handled or not.)
} > } > 
} > } > However, for people looking for PRs to work on, or people maintaining
} > } > the database, or people looking at the PR counts, it's an important
} > } > distinction.
} > } 
} > } The current problem we have is there is no way to remind
} > } "commits that should be pulled up to release branches once after
} > }  it's confirmed that they won't have any bad side effect on HEAD."
} > 
} >      In FreeBSD, commits are often marked:
} > 
} > MFC: <some time period>
} > 
} > MFC stands for Merge From Current.  We could potentially do something
} > like this.  By itself, it doesn't do much other then tag the commit
} > and thus could be the target of a search.  We could also have it
} > trigger an insertion into some sort of database/queue.  This would
} > allow for reminders to the original committer and/or provide a
} > central place where somebody looking for something to do can find
} > them.
} 
} "MFC" is fine for me, though I don't see particular difference
} from "pending-pullups without ticket" which requires no system change.

     A rather large difference is that not every commit has an
associated PR.  There are quite a few commits that are suitable
for pulling up that aren't the result of a bug report.

} > } Adding a new status is still fine, though I just wonder if
} > } the additional states/tasks are appropriate for the benefit,
} > } than just adding a new similar meaning to the existing state.
} > 
} >      This would just be confusing.
} 
} Really?  Currently there are only 18 pending-pullups and

     This is a good thing since it means that releng is on top of
the pullup queue.

} the number won't be so large.

     Putting PRs in pending-pullup state without an associated req
ticket could cause the number of PRs in pending-pullup state to
balloon.

} Anyway, releng should make amake a decision, IMO.

     As has been explained earlier in this thread, releng DOES NOT
maintain gnats.  In other words, this has nothing to do with releng.
Stop trying to push extra work on them.

}-- End of excerpt from Izumi Tsutsui