Re: branches_of_interest.txt
От | Tom Lane |
---|---|
Тема | Re: branches_of_interest.txt |
Дата | |
Msg-id | 63839.1530545845@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: branches_of_interest.txt (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
Andres Freund <andres@anarazel.de> writes: > On 2018-07-01 11:41:07 -0400, Tom Lane wrote: >> I can see the value of people other than you being able to change it, >> but keeping it in the core repo seems like a kluge not a proper solution. > FWIW, I've a manually maintained version of this in the scripts I use to > commit / backpatch things. I'd appreciate not having to manually > maintain it, and be afraid to forget updating it ;) Yeah, I have something similar as well, in fact a couple of them. I thought about whether I'd change those scripts to use an in-tree branches_of_interest list, and I concluded that most likely I would not, because the instant at which I decide a given branch is no longer interesting to me is not necessarily the same instant at which we shut down the buildfarm support for it. It has even less to do with the time that I next do a "git pull" after that shutdown. Contrariwise, once a new branch has been created in the repo, I need to set up a workdir for it before it can safely be added to the list of branches I auto push/pull. So giving up control of the timing just isn't gonna work well. If we were to keep this info in a separate repo requiring a separate "git pull", it might be manageable since I could control when I update that. But then you're right back to the situation of requiring a manual step you might forget. In any case, if we do put this into the tree, I want it to be named and treated as something that *only* controls the buildfarm, not any other stuff. We'll regret tying other stuff to that. regards, tom lane
В списке pgsql-hackers по дате отправления: