unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
* 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).