On Fri, May 17, 2024 at 9:59 AM Robert Haas wrote:
>
> On Fri, May 17, 2024 at 11:05 AM Tom Lane wrote:
> > > We already have gone back to that model. We just haven't admitted it
> > > yet. And we're never going to get out of it until we find a way to get
> > > the contents of the CommitFest
On Thu, May 16, 2024 at 4:00 PM Joe Conway wrote:
>
> On 5/16/24 17:36, Jacob Champion wrote:
> > On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
> >> If no one, including the author (new or otherwise) is interested in
> >> shepherding a particular patch, what chance does it have of ever
Tomas Vondra writes:
> I personally don't think the FOSDEM triage is a very productive use of
> our time - we go through patches top to bottom, often with little idea
> what the current state of the patch is. We always ran out of time after
> looking at maybe 1/10 of the list.
> Having an
On 5/24/24 22:44, Tom Lane wrote:
> Joe Conway writes:
>> On 5/24/24 15:45, Tom Lane wrote:
>>> I was *not* proposing doing a regular review, unless of course
>>> somebody really wants to do that. What I am thinking about is
>>> suggesting how to make progress on patches that are stuck, or in
Joe Conway writes:
> On 5/24/24 15:45, Tom Lane wrote:
>> I was *not* proposing doing a regular review, unless of course
>> somebody really wants to do that. What I am thinking about is
>> suggesting how to make progress on patches that are stuck, or in some
>> cases delivering the bad news that
On 5/24/24 15:45, Tom Lane wrote:
I was *not* proposing doing a regular review, unless of course
somebody really wants to do that. What I am thinking about is
suggesting how to make progress on patches that are stuck, or in some
cases delivering the bad news that this patch seems unlikely to
Tomas Vondra writes:
> On 5/24/24 19:09, Tom Lane wrote:
... Maybe we could divide and conquer: get a
dozen-or-so senior contributors to split up the list of pending
patches and then look at each one with an eye to what needs to
happen to move it along (*not* to commit it
On 5/24/24 19:09, Tom Lane wrote:
> Tomas Vondra writes:
>> On 5/20/24 16:16, Robert Haas wrote:
>>> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
* Before starting this thread, Robert did a lot of very valuable
review of some individual patches. I think what prompted him to
Tomas Vondra writes:
> On 5/20/24 16:16, Robert Haas wrote:
>> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
>>> * Before starting this thread, Robert did a lot of very valuable
>>> review of some individual patches. I think what prompted him to
>>> start the thread was the realization that
On 5/20/24 16:16, Robert Haas wrote:
> On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
>
>...
>
>> * Another reason for things sitting a long time is that they're too
>> big to review without an unreasonable amount of effort. We should
>> encourage authors to break large patches into smaller
On Sun, May 19, 2024 at 10:50 PM Thomas Munro wrote:
> Sometimes I question the sanity of the whole thing. Considering
> cfbot's original "zero-effort CI" goal (or I guess "zero-extra-effort"
> would be better), I was curious about what other projects had the same
> idea, or whether we're really
Hi everyone!
I would like to share another perspective on this as a relatively new user
of the commitfest app. I really like the concept behind the commitfest app
but while using it, sometimes I feel that we can do a better job at having
some sort of a 'metainfo' for the patch.
Although in some
On Fri, 17 May 2024 at 15:02, Peter Eisentraut wrote:
>
> On 17.05.24 09:32, Heikki Linnakangas wrote:
> > Dunno about having to click a link or sparkly gold borders, but +1 on
> > having a free-form text box for notes like that. Things like "cfbot says
> > this has bitrotted" or "Will review
On Mon, May 20, 2024 at 7:49 AM Alvaro Herrera wrote:
> On 2024-May-19, Tom Lane wrote:
> > (The cfbot tends to discourage this, since as soon as one of the
> > patches is committed it no longer knows how to apply the rest.
> > Can we improve on that tooling somehow?)
>
> I think a necessary next
On Sun, May 19, 2024 at 3:18 PM Tom Lane wrote:
> Dmitry Dolgov <9erthali...@gmail.com> writes:
> > How do we make sure this time it will be different?
>
> Things *have* changed, if you take the long view.
That's true, but I think Dmitry's point is well-taken all the same: we
haven't really made
On 2024-May-19, Tom Lane wrote:
> (The cfbot tends to discourage this, since as soon as one of the
> patches is committed it no longer knows how to apply the rest.
> Can we improve on that tooling somehow?)
I think a necessary next step to further improve the cfbot is to get it
integrated in
On 20/05/2024 06:56, Mark Cave-Ayland wrote:
In general you find that a series consists of 2 parts: 1) a set of refactorings to
enable a new feature and 2) the new feature itself. Even if the details of 2) are
still under discussion, often it is possible to merge 1) fairly quickly which also
On 20/05/2024 02:09, Tom Lane wrote:
Bruce Momjian writes:
On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
* Another reason for things sitting a long time is that they're too
big to review without an unreasonable amount of effort. We should
encourage authors to break large patches
> On 20 May 2024, at 07:49, Thomas Munro wrote:
> We're actually
> halfway to Gitlab et al already, with a web account and interaction
> required to start the process of submitting a patch for consideration.
Another Web<->Mailinglist extreme is Git themselves who have a Github bridge
for
On Mon, May 20, 2024 at 1:09 PM Tom Lane wrote:
> (The cfbot tends to discourage this, since as soon as one of the
> patches is committed it no longer knows how to apply the rest.
> Can we improve on that tooling somehow?)
Cfbot currently applies patches with (GNU) patch
--no-backup-if-mismatch
Bruce Momjian writes:
> On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
>> * Another reason for things sitting a long time is that they're too
>> big to review without an unreasonable amount of effort. We should
>> encourage authors to break large patches into smaller stepwise
>>
On Sun, May 19, 2024 at 03:18:11PM -0400, Tom Lane wrote:
> * Another reason for things sitting a long time is that they're too
> big to review without an unreasonable amount of effort. We should
> encourage authors to break large patches into smaller stepwise
> refinements. It may seem like
Dmitry Dolgov <9erthali...@gmail.com> writes:
> There are lots of good takes on this in the thread. It also makes clear what's
> at stake -- as Melanie pointed out with the patch about EXPLAIN for parallel
> bitmap heap scan, we're loosing potential contributors for no reasons. But I'm
> a bit
On 5/19/24 05:37, Dmitry Dolgov wrote:
* How to deal with review scalability bottleneck.
An evergreen question. PostgreSQL is getting more popular and, as stated in
diverse research whitepapers, the amount of contribution grows as a power
law, where the number of reviewers grows at
> On Thu, May 16, 2024 at 02:30:03PM -0400, Robert Haas wrote:
>
> I wonder what ideas people have for improving this situation. I doubt
> that there's any easy answer that just makes the problem go away --
> keeping large groups of people organized is a tremendously difficult
> task under pretty
On Fri, May 17, 2024 at 11:44:40AM -0400, Melanie Plageman wrote:
> So, anyway, I'd argue that we need a parking lot for patches which we
> all agree are important and have a path forward but need someone to do
> the last 20-80% of the work. To avoid this being a dumping ground,
> patches should
Robert Haas writes:
> On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
>> I think it is a good rule. I don't think that it shouldn't lead to putting
>> people on the pillory or kicking their patches, but I imagine that a
>> committer
>> looking for somebody else's patch to work on could
On 5/17/24 21:59, Robert Haas wrote:
> On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
>> On Fri, 2024-05-17 at 13:12 -0400, Greg Sabino Mullane wrote:
Long time ago there was a "rule" that people submitting patches are
expected
to do reviews. Perhaps we should be more
On Fri, May 17, 2024 at 3:51 PM Laurenz Albe wrote:
> On Fri, 2024-05-17 at 13:12 -0400, Greg Sabino Mullane wrote:
> > > Long time ago there was a "rule" that people submitting patches are
> > > expected
> > > to do reviews. Perhaps we should be more strict this.
> >
> > Big -1. How would we
On Fri, 2024-05-17 at 13:12 -0400, Greg Sabino Mullane wrote:
> > Long time ago there was a "rule" that people submitting patches are expected
> > to do reviews. Perhaps we should be more strict this.
>
> Big -1. How would we even be more strict about this? Public shaming?
> Withholding a
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
> It does seem to me a part of the solution needs to be helping to get
> those patches reviewed. I don't know how to do that, but perhaps there's
> a way to encourage people to review more stuff, or review stuff from a
> wider range of
"David G. Johnston" writes:
> On Friday, May 17, 2024, Joe Conway wrote:
>> A solution to both of these issues (yours and mine) would be to allow
>> things to be added *during* the CF month. What is the point of having a
>> "freeze" before every CF anyway? Especially if they start out clean. If
On Fri, 17 May 2024 at 17:59, Robert Haas wrote:
> If they
> get attention, it's much more likely to be because somebody saw their
> email and wrote back than it is to be because somebody went through
> the CommitFest and found their entry and was like "oh, I should review
> this".
I think this
On 5/17/24 11:58, Robert Haas wrote:
I realize that many people here are (rightly!) concerned with
burdening patch authors with more steps that they have to follow. But
the current system is serving new patch authors very poorly. If they
get attention, it's much more likely to be because
On Fri, May 17, 2024 at 11:57 AM Tom Lane wrote:
> Melanie Plageman writes:
> > So, anyway, I'd argue that we need a parking lot for patches which we
> > all agree are important and have a path forward but need someone to do
> > the last 20-80% of the work. To avoid this being a dumping ground,
On Fri, May 17, 2024 at 11:05 AM Tom Lane wrote:
> > We already have gone back to that model. We just haven't admitted it
> > yet. And we're never going to get out of it until we find a way to get
> > the contents of the CommitFest application down to a more reasonable
> > size and level of
Melanie Plageman writes:
> So, anyway, I'd argue that we need a parking lot for patches which we
> all agree are important and have a path forward but need someone to do
> the last 20-80% of the work. To avoid this being a dumping ground,
> patches should _only_ be allowed in the parking lot if
On Fri, May 17, 2024 at 7:40 AM Robert Haas wrote:
>
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
> > To my mind, the point of the time-boxed commitfests is to provide
> > a structure wherein people will (hopefully) pay some actual attention
> > to other peoples' patches. Conversely, the
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
>
> On 5/16/24 23:43, Peter Eisentraut wrote:
> > On 16.05.24 23:06, Joe Conway wrote:
> >> On 5/16/24 16:57, Jacob Champion wrote:
> >>> On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
> Maybe we should just make it a policy that
Robert Haas writes:
> On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
>> If we go back to the old its-development-mode-all-the-time approach,
>> what is likely to happen is that the commit rate for not-your-own-
>> patches goes to zero, because it's always possible to rationalize
>> your own
On Fri, May 17, 2024 at 10:31 AM Tom Lane wrote:
> To my mind, the point of the time-boxed commitfests is to provide
> a structure wherein people will (hopefully) pay some actual attention
> to other peoples' patches. Conversely, the fact that we don't have
> one running all the time gives
Robert Haas writes:
> On Fri, May 17, 2024 at 9:54 AM Joe Conway wrote:
>> I agree with you. Before commitfests were a thing, we had no structure
>> at all as I recall. The dates for the dev cycle were more fluid as I
>> recall, and we had no CF app to track things. Maybe retaining the
>>
On Fri, May 17, 2024 at 9:09 AM Peter Eisentraut wrote:
> How would the development process look like if we
> just had one commitfest per dev cycle that runs from July 1st to March 31st?
Exactly the same?
--
Peter Geoghegan
On Fri, May 17, 2024 at 9:54 AM Joe Conway wrote:
> I agree with you. Before commitfests were a thing, we had no structure
> at all as I recall. The dates for the dev cycle were more fluid as I
> recall, and we had no CF app to track things. Maybe retaining the
> structure but going back to the
On 5/17/24 09:08, Peter Eisentraut wrote:
On 17.05.24 14:42, Joe Conway wrote:
Namely, the week before commitfest I don't actually know if I will
have the time during that month, but I will make sure my patch is in
the commitfest just in case I get a few clear days to work on it.
Because if
> On 17 May 2024, at 15:05, Robert Haas wrote:
>
> On Fri, May 17, 2024 at 9:02 AM Peter Eisentraut wrote:
>> We already have the annotations feature, which is kind of this.
>
> I didn't realize we had that feature. When was it added, and how is it
> supposed to be used?
A while back.
commit
On 5/17/24 14:51, Andrey M. Borodin wrote:
>
>
>> On 17 May 2024, at 16:39, Robert Haas wrote:
>>
>> I think Andrey Borodin's nearby suggestion of having a separate CfM
>> for each section of the CommitFest does a good job revealing just how
>> bad the current situation is. I agree with him:
On 17.05.24 14:42, Joe Conway wrote:
Namely, the week before commitfest I don't actually know if I will
have the time during that month, but I will make sure my patch is in
the commitfest just in case I get a few clear days to work on it.
Because if it isn't there, I can't take advantage of
On Fri, May 17, 2024 at 9:02 AM Peter Eisentraut wrote:
> We already have the annotations feature, which is kind of this.
I didn't realize we had that feature. When was it added, and how is it
supposed to be used?
--
Robert Haas
EDB: http://www.enterprisedb.com
On Fri, May 17, 2024 at 8:31 AM Jelte Fennema-Nio wrote:
> Such a proposal would basically mean that no-one that cares about
> their patches getting reviews can go on holiday and leave work behind
> during the week before a commit fest. That seems quite undesirable to
> me.
Well, then we make it
On 17.05.24 09:32, Heikki Linnakangas wrote:
Dunno about having to click a link or sparkly gold borders, but +1 on
having a free-form text box for notes like that. Things like "cfbot says
this has bitrotted" or "Will review this after other patch this depends
on". On the mailing list, notes
On Friday, May 17, 2024, Joe Conway wrote:
>
> I wrote:
>
>> Namely, the week before commitfest I don't actually know if I will have
>> the time during that month, but I will make sure my patch is in the
>> commitfest just in case I get a few clear days to work on it. Because if it
>> isn't
> On 17 May 2024, at 16:39, Robert Haas wrote:
>
> I think Andrey Borodin's nearby suggestion of having a separate CfM
> for each section of the CommitFest does a good job revealing just how
> bad the current situation is. I agree with him: that would actually
> work. Asking somebody, for a
On 17.05.24 13:36, Daniel Gustafsson wrote:
On 17 May 2024, at 13:13, Robert Haas wrote:
But if we are to guess what those reasons might be, Tom has already
admitted he does that for CI, and I do the same, so probably other
people also do it. I also suspect that some people are essentially
On 5/17/24 08:31, Jelte Fennema-Nio wrote:
On Fri, 17 May 2024 at 14:19, Joe Conway wrote:
On 5/16/24 22:26, Robert Haas wrote:
> For example, imagine that the CommitFest is FORCIBLY empty
> until a week before it starts. You can still register patches in the
> system generally, but that just
On Fri, 17 May 2024 at 14:19, Joe Conway wrote:
>
> On 5/16/24 22:26, Robert Haas wrote:
> > For example, imagine that the CommitFest is FORCIBLY empty
> > until a week before it starts. You can still register patches in the
> > system generally, but that just means they get CI runs, not that
> >
On Fri, 17 May 2024 at 13:39, Robert Haas wrote:
>
> On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
> wrote:
> > Yeah, I 100% agree with this. If a patch bitrots and no one cares enough
> > to rebase it once in a while, then sure - it's probably fine to mark it
> > RwF. But forcing all
On 5/16/24 22:26, Robert Haas wrote:
For example, imagine that the CommitFest is FORCIBLY empty
until a week before it starts. You can still register patches in the
system generally, but that just means they get CI runs, not that
they're scheduled to be reviewed. A week before the CommitFest,
On Fri, May 17, 2024 at 7:11 AM Tomas Vondra
wrote:
> Yeah, I 100% agree with this. If a patch bitrots and no one cares enough
> to rebase it once in a while, then sure - it's probably fine to mark it
> RwF. But forcing all contributors to do a dance every 2 months just to
> have a chance someone
> On 17 May 2024, at 13:13, Robert Haas wrote:
> But if we are to guess what those reasons might be, Tom has already
> admitted he does that for CI, and I do the same, so probably other
> people also do it. I also suspect that some people are essentially
> using the CF app as a personal todo
On Fri, May 17, 2024 at 1:05 AM Peter Eisentraut wrote:
> On 17.05.24 04:26, Robert Haas wrote:
> > I do*emphatically* think we need a parking lot.
>
> People seem to like this idea; I'm not quite sure I follow it. If you
> just want the automated patch testing, you can do that on your own by
>
On 5/16/24 23:43, Peter Eisentraut wrote:
> On 16.05.24 23:06, Joe Conway wrote:
>> On 5/16/24 16:57, Jacob Champion wrote:
>>> On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and
I think there are actually a number of factors that make this much harder.
On Fri, May 17, 2024 at 2:33 PM Heikki Linnakangas wrote:
>
> On 17/05/2024 05:26, Robert Haas wrote:
> > For bonus points, suppose we make it so that when you click the link,
> > it takes you to a box where you can type
> On 16 May 2024, at 23:30, Robert Haas wrote:
>
I think we just need 10x CFMs. Let’s have a CFM for each CF section. I’d
happily take "Replication and Recovery” or “System Administration” for July.
“Miscellaneous” or “Performance” look monstrous.
I feel I can easily track ~20 threads
On Fri, 17 May 2024 at 11:02, Jelte Fennema-Nio wrote:
>
> On Fri, 17 May 2024 at 10:47, Daniel Gustafsson wrote:
> > One way to ensure we capture detail could be if the system would send an
> > automated email to the thread summarizing the entry when it's marked as
> > "committed"?
>
> This
On Fri, 17 May 2024 at 10:47, Daniel Gustafsson wrote:
> One way to ensure we capture detail could be if the system would send an
> automated email to the thread summarizing the entry when it's marked as
> "committed"?
This sounds great! Especially if Going back from an archived thread
to the
> On 17 May 2024, at 00:03, Peter Eisentraut wrote:
> I think, if we consider the core mission of the commitfest app, we need to be
> more protective of the Needs Review state.
IMHO this is a very very good summary of what we should focus on with this
work.
--
Daniel Gustafsson
> On 17 May 2024, at 09:32, Heikki Linnakangas wrote:
> On the mailing list, notes like that are both noisy and easily lost in the
> threads. But as a little free-form text box on the commitfest, it would be
> handy.
On a similar note, I have in the past suggested adding a free-form textfield
On Fri, 17 May 2024 at 06:58, Peter Eisentraut wrote:
> Yeah, some fine-tuning might be required. But I would be wary of
> over-designing too many new states at this point. I think the key idea
> is that there ought to be a state that communicates "needs attention
> from someone other than
On 17/05/2024 05:26, Robert Haas wrote:
For bonus points, suppose we make it so that when you click the link,
it takes you to a box where you can type in a text comment that will
display in the app, explaining why your patch needs review: "Robert
says the wire protocol changes in this patch are
On Fri, May 17, 2024 at 12:25 AM Maciek Sakrejda
wrote:
> Thanks for raising this. As someone who is only modestly familiar with
> Postgres internals or even C, but would still like to contribute through
> review, I find the current process of finding a suitable patch both tedious
> and
On 17/05/2024 08:05, Peter Eisentraut wrote:
On 17.05.24 04:26, Robert Haas wrote:
I do*emphatically* think we need a parking lot.
People seem to like this idea; I'm not quite sure I follow it. If you
just want the automated patch testing, you can do that on your own by
setting up
On 17.05.24 04:26, Robert Haas wrote:
I do*emphatically* think we need a parking lot.
People seem to like this idea; I'm not quite sure I follow it. If you
just want the automated patch testing, you can do that on your own by
setting up github/cirrus for your own account. If you keep
On 17.05.24 00:13, Tom Lane wrote:
So a third status that encompasses the various other situations like
maybe forgotten by author, disagreements between author and reviewer,
process difficulties, needs some senior developer intervention, etc.
could be helpful.
Hmm, "forgotten by author" seems
On Thu, May 16, 2024 at 5:46 PM Tom Lane wrote:
> Right, so what can we do about that? Does Needs Review state need to
> be subdivided, and if so how?
It doesn't really matter how many states we have if they're not set accurately.
> At this point it seems like there's consensus to have a
On Thu, May 16, 2024 at 5:04 PM Tom Lane wrote:
>
> Jacob Champion writes:
> > ... Similar to how people currently use the
> > Reviewer field as a personal TODO list... it might be nice to
> > officially separate the ideas a bit.
>
> Oh, that's an independent pet peeve of mine. Usually, if I'm
Peter Eisentraut writes:
> On 16.05.24 23:46, Tom Lane wrote:
>> Right, so what can we do about that? Does Needs Review state need to
>> be subdivided, and if so how?
> Maybe a new state "Unclear". ...
> I think, if we consider the core mission of the commitfest app, we need
> to be more
On 16.05.24 23:46, Tom Lane wrote:
Peter Eisentraut writes:
The problem is if we have 180 patches in Needs Review, and only 20 are
really actually ready to be reviewed. And a second-order problem is
that if you already know that this will be the case, you give up before
even looking.
Right,
Daniel Gustafsson writes:
> Pulling in the information from the CFBot regarding test failures and whether
> the patch applies at all, and automatically altering the state to WOA for at
> least the latter category would be nice.
+1. There are enough intermittent test failures that I don't think
On 5/16/24 17:36, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
If no one, including the author (new or otherwise) is interested in
shepherding a particular patch, what chance does it have of ever getting
committed?
That's a very different thing from what I think
> On 16 May 2024, at 23:46, Tom Lane wrote:
> At this point it seems like there's consensus to have a "parking"
> section of the CF app, separate from the time-boxed CFs, and I hope
> somebody will go make that happen. But I don't think that's our only
> issue, so we need to keep thinking about
Peter Eisentraut writes:
> The problem is if we have 180 patches in Needs Review, and only 20 are
> really actually ready to be reviewed. And a second-order problem is
> that if you already know that this will be the case, you give up before
> even looking.
Right, so what can we do about
On Thu, May 16, 2024 at 2:04 PM Tom Lane wrote:
> Oh, that's an independent pet peeve of mine. Usually, if I'm
> looking over the CF list for a patch to review, I skip over ones
> that already show an assigned reviewer, because I don't want to
> step on that person's toes. But it seems very
On 16.05.24 23:06, Joe Conway wrote:
On 5/16/24 16:57, Jacob Champion wrote:
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for
On 16.05.24 23:04, Tom Lane wrote:
I think it'd be great if we could separate "I'm actively reviewing
this" from "I'm interested in this". As a bonus, adding yourself
to the "interested" list would be a fine proxy for the thumbs-up
or star markers mentioned upthread.
If those were separate
On Thu, May 16, 2024 at 2:29 PM Joe Conway wrote:
> If no one, including the author (new or otherwise) is interested in
> shepherding a particular patch, what chance does it have of ever getting
> committed?
That's a very different thing from what I think will actually happen, which is
- new
On 16.05.24 22:46, Melanie Plageman wrote:
I was reflecting on why a general purpose patch tracker sounded
appealing to me, and I realized that, at least at this time of year, I
have a few patches that really count as "waiting on author" that I
know I need to do additional work on before they
On 5/16/24 17:24, Jacob Champion wrote:
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
Maybe the word "care" was a poor choice, but forcing authors to think
about and decide if they have the "time to shepherd a patch" for the
*next CF* is exactly the point. If they don't, why clutter the CF
On Thu, May 16, 2024 at 2:06 PM Joe Conway wrote:
> Maybe the word "care" was a poor choice, but forcing authors to think
> about and decide if they have the "time to shepherd a patch" for the
> *next CF* is exactly the point. If they don't, why clutter the CF with it.
Because the community
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman
wrote:
>
> I should probably simply
> withdraw and re-register them. My justification was that I'll lose
> them if I don't keep them in the commitfest app. But, I could just,
> you know, save them somewhere myself instead of polluting the
>
On 5/16/24 16:48, Magnus Hagander wrote:
On Thu, May 16, 2024 at 10:46 PM Melanie Plageman
I was reflecting on why a general purpose patch tracker sounded
appealing to me, and I realized that, at least at this time of year, I
have a few patches that really count as "waiting on
Jacob Champion writes:
> On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
>> Maybe we should just make it a policy that *nothing* gets moved forward
>> from commitfest-to-commitfest and therefore the author needs to care
>> enough to register for the next one?
> I think that's going to
On 5/16/24 16:57, Jacob Champion wrote:
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
Maybe we should just make it a policy that *nothing* gets moved forward
from commitfest-to-commitfest and therefore the author needs to care
enough to register for the next one?
I think that's going to
Jacob Champion writes:
> ... Similar to how people currently use the
> Reviewer field as a personal TODO list... it might be nice to
> officially separate the ideas a bit.
Oh, that's an independent pet peeve of mine. Usually, if I'm
looking over the CF list for a patch to review, I skip over
Hi,
On 5/16/24 4:31 PM, Joe Conway wrote:
Yeah. I think that Robert put his finger on a big part of the
problem, which is that punting a patch to the next CF is a lot
easier than rejecting it, particularly for less-senior CFMs
who may not feel they have the authority to say no (or at
least
On Thu, May 16, 2024 at 1:31 PM Joe Conway wrote:
> Maybe we should just make it a policy that *nothing* gets moved forward
> from commitfest-to-commitfest and therefore the author needs to care
> enough to register for the next one?
I think that's going to severely disadvantage anyone who
On Thu, May 16, 2024 at 1:46 PM Melanie Plageman
wrote:
> I should probably simply
> withdraw and re-register them. My justification was that I'll lose
> them if I don't keep them in the commitfest app. But, I could just,
> you know, save them somewhere myself instead of polluting the
>
Melanie Plageman writes:
> I was reflecting on why a general purpose patch tracker sounded
> appealing to me, and I realized that, at least at this time of year, I
> have a few patches that really count as "waiting on author" that I
> know I need to do additional work on before they need more
On Thu, May 16, 2024 at 12:14 PM David G. Johnston
wrote:
> Those likely never get out of the new WIP slot discussed above. Your patch
> tracker basically. And there should be less angst in moving something in the
> bimonthly into WIP rather than dropping it outright. There is discussion to
On Thu, May 16, 2024 at 10:46 PM Melanie Plageman
wrote:
> On Thu, May 16, 2024 at 2:30 PM Robert Haas wrote:
> >
> > Hi,
> >
> > The original intent of CommitFests, and of commitfest.postgresql.org
> > by extension, was to provide a place where patches could be registered
> > to indicate that
1 - 100 of 109 matches
Mail list logo
