Re: branch staging updated (5aeee07 -> 104151f)

Re: branch staging updated (5aeee07 -> 104151f)

[Leo Famulari]

[-- 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 --]

Re: branch staging updated (5aeee07 -> 104151f)

[Mark H Weaver]

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

Re: branch staging updated (5aeee07 -> 104151f)

[Leo Famulari]

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.

Re: branch staging updated (5aeee07 -> 104151f)

[Jakub Kądziołka]

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

Re: branch staging updated (5aeee07 -> 104151f)

[Mark H Weaver]

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

Re: branch staging updated (5aeee07 -> 104151f)

[Hartmut Goebel]

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 |

Re: branch staging updated (5aeee07 -> 104151f)

[Efraim Flashner]

[-- 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 --]

Re: branch staging updated (5aeee07 -> 104151f)

[Mark H Weaver]

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.

Re: branch staging updated (5aeee07 -> 104151f)

[Christopher Baines]

[-- 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 --]

Re: branch staging updated (5aeee07 -> 104151f)

[Leo Famulari]

[-- 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 --]