Ekaitz Zarraga <[email protected]> writes:

> On 2025-11-07 14:38, Ricardo Wurmus wrote:
>> Employment doesn't factor in it.
>> Do we really want to give the impression that we don't care whether we break
>> third-party channels?
>
> One thing doesn't have anything to do with the other.
>
> I do HATE when variables are (re)moved.
>
> If breaking something is more serious on Fridays than any other day of the 
> week,
> it certainly has everything to do with employment, in an specific cultural
> context.
>
> So, should we be more careful with removals or make something that can follow
> variables from one place to another? maybe deprecation? maybe
> something else?

Yes please.  Would be nice to have a one month long window (total
guesstimate) when accessing a variable prints deprecation warning before
it gets removed.  Are there any technical blockers aside from it being
more work?

>
> Also why Fridays? Why not other days of the week which are also rest days in
> other countries?

Realistically speaking, most Guix developers are in Europe and USA, so
if single day should be picked, Friday seems to be a sensible choice.

Sure, could be considered unfair to some, but that is life. ¯\_(ツ)_/¯

>
> Idk. I see what Simon is trying to do here and I like it. But as I said in the
> past in this ML, this we might need to re-think as something more global that
> solves the root issue: (re)moved variables.
>
> WDYT?

Assuming we care about third-party channels (which seems that we do),
some deprecation window is probably preferable to assigning time-slots
for volunteering work.  IMO.

Subjective observation, although I do not contribute much lately, Friday
evenings and Saturdays are the two days when I actually have time (since
I am done with work).  Though I am not a committer, so when I send the
email with patches does not really matter much ^_^.  I imagine it could
be similar for other people as well.

Tomas

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

Reply via email to