* Re: branch staging updated (5aeee07 -> 104151f) [not found] <20210129220535.30446.38250@vcs0.savannah.gnu.org> @ 2021-01-30 23:20 ` Leo Famulari 2021-01-30 23:37 ` Mark H Weaver 0 siblings, 1 reply; 10+ messages in thread From: Leo Famulari @ 2021-01-30 23:20 UTC (permalink / raw) To: guix-devel; +Cc: kuba, mail [-- Attachment #1: Type: text/plain, Size: 882 bytes --] On Fri, Jan 29, 2021 at 05:05:35PM -0500, guix-commits@gnu.org wrote: > htgoebel pushed a change to branch staging > in repository guix. > > from 5aeee07 gnu: VLC: Remove obsolete patch. > new 9085260 guix: qt-build-system, qt-utils: Unify wrapping of qt-programs. > new 4ecc2a2 guix: qt-utils: Wrapped executables honor user's envvars. > new 094b6ac build-system: qt: Exclude useless inputs from wrapped variables. > new 104151f guix: qt-utils: Don't include useless inputs in wrapped variables. The staging branch is frozen [0] so I reverted these commits and pushed them to staging-next. I wonder what we can do to communicate the branch status. Right now it's not easy to figure out, aside from asking around. Nicolas Goaziou suggested using a Git hook. [0] https://lists.gnu.org/archive/html/guix-devel/2020-12/msg00157.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-01-30 23:20 ` branch staging updated (5aeee07 -> 104151f) Leo Famulari @ 2021-01-30 23:37 ` Mark H Weaver 2021-01-31 5:18 ` Leo Famulari 0 siblings, 1 reply; 10+ messages in thread From: Mark H Weaver @ 2021-01-30 23:37 UTC (permalink / raw) To: Leo Famulari, guix-devel; +Cc: kuba, mail Leo Famulari <leo@famulari.name> writes: > The staging branch is frozen [0] so I reverted these commits and pushed > them to staging-next. > > I wonder what we can do to communicate the branch status. Right now it's > not easy to figure out, aside from asking around. Nicolas Goaziou > suggested using a Git hook. What would the Git hook do, precisely? The reason I ask is that some bug fixes are appropriate on a frozen branch. How would a Git hook determine whether a given commit should be allowed? Regards, Mark ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-01-30 23:37 ` Mark H Weaver @ 2021-01-31 5:18 ` Leo Famulari 2021-01-31 9:59 ` Jakub Kądziołka 0 siblings, 1 reply; 10+ messages in thread From: Leo Famulari @ 2021-01-31 5:18 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel, kuba, mail On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: > What would the Git hook do, precisely? The reason I ask is that some > bug fixes are appropriate on a frozen branch. How would a Git hook > determine whether a given commit should be allowed? I haven't given much thought to how it would work but, if it ran on the client side as a pre-push hook, it could be easily disabled by the committer, when necessary. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-01-31 5:18 ` Leo Famulari @ 2021-01-31 9:59 ` Jakub Kądziołka 2021-01-31 21:09 ` Mark H Weaver 0 siblings, 1 reply; 10+ messages in thread From: Jakub Kądziołka @ 2021-01-31 9:59 UTC (permalink / raw) To: Leo Famulari, Mark H Weaver; +Cc: guix-devel, mail On Sun Jan 31, 2021 at 6:18 AM CET, Leo Famulari wrote: > On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: > > What would the Git hook do, precisely? The reason I ask is that some > > bug fixes are appropriate on a frozen branch. How would a Git hook > > determine whether a given commit should be allowed? > > I haven't given much thought to how it would work but, if it ran on the > client side as a pre-push hook, it could be easily disabled by the > committer, when necessary. Alternatively, one could include some control sequence in the commit message. For example, Allow-Frozen: staging Regards, Jakub Kądziołka ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-01-31 9:59 ` Jakub Kądziołka @ 2021-01-31 21:09 ` Mark H Weaver 2021-02-01 11:14 ` Hartmut Goebel 0 siblings, 1 reply; 10+ messages in thread From: Mark H Weaver @ 2021-01-31 21:09 UTC (permalink / raw) To: Jakub Kądziołka, Leo Famulari; +Cc: guix-devel, mail Hi, Jakub Kądziołka <kuba@kadziolka.net> writes: > On Sun Jan 31, 2021 at 6:18 AM CET, Leo Famulari wrote: >> On Sat, Jan 30, 2021 at 06:37:11PM -0500, Mark H Weaver wrote: >> > What would the Git hook do, precisely? The reason I ask is that some >> > bug fixes are appropriate on a frozen branch. How would a Git hook >> > determine whether a given commit should be allowed? >> >> I haven't given much thought to how it would work but, if it ran on the >> client side as a pre-push hook, it could be easily disabled by the >> committer, when necessary. Ah, I see now that 'git push' has the "--no-verify" option, which causes it to skip the pre-push hook. Sure, that sounds workable. > Alternatively, one could include some control sequence in the commit > message. For example, > > Allow-Frozen: staging It's an interesting idea, but it occurs to me that such annotations would have no long-term relevance, and so I'd prefer not to pollute our commit log history with them. A year from now, it's unlikely to be relevant whether a bug fix pushed today happened to be committed to the 'staging' branch when it was frozen. For our purposes, we only need a transient way to disable the pre-push hook, whereas anything included in the commit log is permanent and forever immutable. Therefore, my preference would be to use the "--no-verify" option. I could live with either approach, though. What do you think? Regards, Mark ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-01-31 21:09 ` Mark H Weaver @ 2021-02-01 11:14 ` Hartmut Goebel 2021-02-01 11:28 ` Efraim Flashner 0 siblings, 1 reply; 10+ messages in thread From: Hartmut Goebel @ 2021-02-01 11:14 UTC (permalink / raw) To: guix-devel Hi, maybe the process should be the other way round: staging -> "staging-frozen" -> master no "staging-next" This would allow committers to use the same workflow all the time. No need for any technical solution preventing to push to staging. -- Regards Hartmut Goebel | Hartmut Goebel | h.goebel@crazy-compilers.com | | www.crazy-compilers.com | compilers which you thought are impossible | ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-02-01 11:14 ` Hartmut Goebel @ 2021-02-01 11:28 ` Efraim Flashner 2021-02-01 19:39 ` Mark H Weaver 0 siblings, 1 reply; 10+ messages in thread From: Efraim Flashner @ 2021-02-01 11:28 UTC (permalink / raw) To: Hartmut Goebel; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 575 bytes --] On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: > Hi, > > maybe the process should be the other way round: > > staging -> "staging-frozen" -> master > no "staging-next" I really like this idea > This would allow committers to use the same workflow all the time. No need > for any technical solution preventing to push to staging. -- Efraim Flashner <efraim@flashner.co.il> אפרים פלשנר GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351 Confidentiality cannot be guaranteed on emails sent or received unencrypted [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-02-01 11:28 ` Efraim Flashner @ 2021-02-01 19:39 ` Mark H Weaver 2021-02-01 20:43 ` Christopher Baines 0 siblings, 1 reply; 10+ messages in thread From: Mark H Weaver @ 2021-02-01 19:39 UTC (permalink / raw) To: Efraim Flashner, Hartmut Goebel; +Cc: guix-devel Efraim Flashner <efraim@flashner.co.il> writes: > On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: >> Hi, >> >> maybe the process should be the other way round: >> >> staging -> "staging-frozen" -> master >> no "staging-next" > > I really like this idea It sounds good to me too! Mark >> This would allow committers to use the same workflow all the time. No need >> for any technical solution preventing to push to staging. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-02-01 19:39 ` Mark H Weaver @ 2021-02-01 20:43 ` Christopher Baines 2021-02-01 20:56 ` Leo Famulari 0 siblings, 1 reply; 10+ messages in thread From: Christopher Baines @ 2021-02-01 20:43 UTC (permalink / raw) To: Mark H Weaver; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 613 bytes --] Mark H Weaver <mhw@netris.org> writes: > Efraim Flashner <efraim@flashner.co.il> writes: > >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: >>> Hi, >>> >>> maybe the process should be the other way round: >>> >>> staging -> "staging-frozen" -> master >>> no "staging-next" >> >> I really like this idea > > It sounds good to me too! I've been thinking about this as well [1], although my angle is more about making it possible to separate out testing the branch vs building substitutes for users. 1: https://mail.gnu.org/archive/html/guix-devel/2020-10/msg00401.html [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 987 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: branch staging updated (5aeee07 -> 104151f) 2021-02-01 20:43 ` Christopher Baines @ 2021-02-01 20:56 ` Leo Famulari 0 siblings, 0 replies; 10+ messages in thread From: Leo Famulari @ 2021-02-01 20:56 UTC (permalink / raw) To: Christopher Baines; +Cc: guix-devel [-- Attachment #1: Type: text/plain, Size: 896 bytes --] On Mon, Feb 01, 2021 at 08:43:19PM +0000, Christopher Baines wrote: > > Efraim Flashner <efraim@flashner.co.il> writes: > > > >> On Mon, Feb 01, 2021 at 12:14:03PM +0100, Hartmut Goebel wrote: > >>> Hi, > >>> > >>> maybe the process should be the other way round: > >>> > >>> staging -> "staging-frozen" -> master > >>> no "staging-next" > >> > >> I really like this idea > > > > It sounds good to me too! > > I've been thinking about this as well [1], although my angle is more > about making it possible to separate out testing the branch vs building > substitutes for users. > > 1: https://mail.gnu.org/archive/html/guix-devel/2020-10/msg00401.html Alright, it sounds like you all have some good ideas. I've deleted the staging branch, since it has been merged to master. I'll leave it up to one of you to decide what to do about what is currently "staging-next". [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-02-01 20:57 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20210129220535.30446.38250@vcs0.savannah.gnu.org>
2021-01-30 23:20 ` branch staging updated (5aeee07 -> 104151f) Leo Famulari
2021-01-30 23:37 ` Mark H Weaver
2021-01-31 5:18 ` Leo Famulari
2021-01-31 9:59 ` Jakub Kądziołka
2021-01-31 21:09 ` Mark H Weaver
2021-02-01 11:14 ` Hartmut Goebel
2021-02-01 11:28 ` Efraim Flashner
2021-02-01 19:39 ` Mark H Weaver
2021-02-01 20:43 ` Christopher Baines
2021-02-01 20:56 ` Leo Famulari
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).