tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 709: Windows memory module: explicit usages proposal

[Jan N. <jan...@gm...>]

Op ma 3 feb 2025 om 13:38 schreef Harald Oehlmann <
har...@el...>:

> We may only use the memory module mechanism when explicitly requested by
> an additional parameter to the load command:
>
> load ?-memory? file ?prefix?
>
> By this mean, a package writer may explicitly test a dll and enable the
> memory module for it.
>
> Concerning the internal DLLs "registry.dll" and "dde.dll", we know, that
> memory execution would work. So, we can enable this by default.
>
> For packages, the package author may add the "-memory" flag to the
> pckIndex.tcl file if a package is compatible.
>

Two things we should consider then.
1) on macos, the loading to memory is already implemented. Should the
    option be implemented there as well? Should it be a no-op? Or
    should the switch have the same effect on macos (causing
    possible leaks on macos, which are not present now ...) ?.
2) What should happen if the dll has a TLS section? Should the
    -memory option then still load the dll in memory, knowing it
    wouldn't work?

Christian Werner proposed the -nomemory option instead. It could
be used to prevent loading to memory if if the dll cannot be loaded
in memory. Would that resolve the reservations?

Thanks!
        Jan NIjtmans

[TCLCORE] Tk telco on 2025-02-04 18:00 UTC

[Harald O. <har...@el...>]

Dear Tk team,

please allow me to remind you about the Tk telco tomorrow, 2025-02-04 at 
18:00 UTC for 1 hour at:
URL: https://meet.jit.si/TclMonthlyMeetup

Topics coming to my mind:
- communication style on TCT
- Possible changes for 9.1
- depreciation/removal of features for 9.1
- new text widget bugfixes
- ttk_chooseFolder -multiple
- sash for tkk::panedwindow

Happy to see you all,
Harald

[TCLCORE] TIP 709: Windows memory module: explicit usages proposal

[Harald O. <har...@el...>]

Dear TCL team, dear Jan,

the memory module which executes DLLs from memory on Windows has the 
following properties:
- very handy to avoid local copy (and its removal)
- may not work for all DLLs, as some features are not supported

Recently, TLS (Thread Local Storage) was identified to be incompatible 
with the current mechanism. TLS is now detected within a DLL and the 
memory module is automatically disabled.

May I do the following proposal:

We may only use the memory module mechanism when explicitly requested by 
an additional parameter to the load command:

load ?-memory? file ?prefix?

By this mean, a package writer may explicitly test a dll and enable the 
memory module for it.

Concerning the internal DLLs "registry.dll" and "dde.dll", we know, that 
memory execution would work. So, we can enable this by default.

For packages, the package author may add the "-memory" flag to the 
pckIndex.tcl file if a package is compatible.

Details: the switch "-memory" must not be granted. If memory module is 
currently not compiled in or a real dll file is sourced, it is ignored.
It may also be added to all platforms, but mostly ignored.

Thank you for your valuable opinion.

Take care,
Harald

Re: [TCLCORE] Report of biweekly Tcl/Tk telco on 2025-01-27 12:00 UTC

[Harald O. <har...@el...>]

Dear Schelte,
this is an epic message, thank you for all.
I fully agree.
I call myself the "maintainer" for two of your mentioned repositories:
- tclws and bwidget
I remarked, that I am (now) admin on tclws. But there is no admin menu 
item in the web interface. Could you create a login there and I will 
give you administrator rights (I am not "s").
On bwidget, I have no administrator rights. At least, there us no 
"users" tab for me.
Maybe, someone may fix that.
The active people I see as superusers are Andreas, Steve and Francois.

Take care,
Harald




Am 31.01.2025 um 16:19 schrieb Schelte Bron:
> On 27/01/2025 15:05, Harald Oehlmann wrote:
>> 3) fossil login
>>
>> Some fossil repositories do not allow login creation. This is seen as 
>> useful. Schelte Bron may contact repository owners to activate this 
>> feature when not enabled.
> 
> There was a remark during the meeting that we should be accommodating to 
> newcomers who want to contribute. To this I responded that it is very 
> hard for anyone to get access rights. Many repositories don't even allow 
> self-registering.
> 
> But the problems go deeper than that. After registering an account, a 
> new contributor will generally get the Reader ("u") capability. This 
> means they can edit tickets and wiki pages. To be able to contribute 
> code requires the "Developer" (v) or at least the "Check-In" (i) 
> capability. An administrator needs to be involved to assign those 
> capabilities. There is however no assured method to figure out how to 
> contact an administrator for any given repository, or even to find out 
> who they are. If self-registering is disabled, one already has to hunt 
> down an administrator to even get an account.
> 
> In my opinion the following points need to be addressed to be more 
> welcoming to new contributors:
> 
> *Email notifications*
> 
>     Email notifications are required to inform ticket originators about
>     follow-up questions. Without them, tickets may be abandoned or make
>     very slow progress because they depend on the originator taking the
>     initiative to check back for updates.
> 
>     A few of the items below also need a method to communicate
>     information to the user. Email notifications need to work for that.
>     The way to set this up on chiselapp does not work on core.tcl-lang.
>     I have contacted Roy Keene for assistance but I have not yet heard
>     back from him.
> 
> *Self registration*
> 
>     New users should be allowed to self register. To prevent too many
>     fake accounts, it would be best to enable email verification for
>     self-registration. An additional complication is that fossil changed
>     policy in 2020. When self-registering, user IDs must now be at least
>     6 characters. People who registered on some core repositories with a
>     shorter user ID in the past will now not be able to self-register
>     with the same ID on other core repositories.
> 
> *Obtain developer rights*
> 
>     There must be a better way to get developer rights than to ask on
>     the Tcl chat if anyone knows who administers a certain repository
>     and then go hunt for an email address. I can think of a few
>     possibilities:
> 
>       * Assign "Check-In" (i) privileges to all new users. This may make
>         it too easy for malicious parties to wreak havoc on the code.
>       * Assign "Announce" (A) privileges to all new users, so they can
>         send a notification to all moderators to request an upgrade of
>         their privileges. Currently the "Announce" privilege allows the
>         user to send a notification to everyone. This opens up the
>         possibility for sending spam to a possibly large number of
>         people. Maybe we should work with the fossil developers to get a
>         new privilege for only sending a message to the (active)
>         administrators. Then any spamming would be restricted to a much
>         smaller group.
>       * Have some standard page on the repository that lists the
>         administrators. This should preferably be generated, otherwise
>         it will require maintenance.
>       * Have a forum thread where such requests can be posted. Newly
>         registered users will need the "Forum-Write" (3) privilege to be
>         able to use that. This of course also requires administrators to
>         keep an eye on the forum.
>       * Define some wiki page where users can add their request to be
>         upgraded to developer. An admin can then remove that request
>         once it is processed. I don't think the ticket system should be
>         abused for this.
> 
>     Whatever method is selected, it must be documented in an easy to
>     find location.
> 
> *Download a tarball*
> 
>     On some repositories it is not possible to download a tarball or ZIP
>     archive without logging in. Newcomers have trouble enough finding
>     those links in the first place. They may get completely discouraged
>     if they go to the right place but still don't see the links because
>     they didn't log in. Being able to download sources without logging
>     in can also be useful for scripts, makefiles, and github actions.
> 
> ------------------------------------------------------------------------
> 
> List of repositories that currently don't allow self registering:
> 
>   * tcloo
>   * tclvfs
>   * expect
>   * tclws
>   * mpexpr
>   * tclquadcode
>   * sampleextension
>   * tiprender
>   * tdbcsqlite3
>   * tdbcodbc
>   * tdbcmysql
>   * tdbcpostgres
>   * iwidgets
>   * tclapps
>   * bwidget
>   * mclistbox
>   * tclbench
>   * tdom
>   * wtk
>   * tclhttpd
>   * tcludp
> 
> List of repositories that don't allow downloading a tarball without 
> logging in:
> 
>   * tclquadcode
>   * iwidgets
>   * tcllib
>   * tclapps
>   * bwidget
>   * mclistbox
>   * tclbench
>   * wtk
>   * tclhttpd
>   * tcludp
> 
> 
> Regards,
> 
> Schelte.
> 

Re: [TCLCORE] Report of biweekly Tcl/Tk telco on 2025-01-27 12:00 UTC

[Schelte B. <tc...@tc...>]

On 27/01/2025 15:05, Harald Oehlmann wrote:
> 3) fossil login
>
> Some fossil repositories do not allow login creation. This is seen as 
> useful. Schelte Bron may contact repository owners to activate this 
> feature when not enabled.

There was a remark during the meeting that we should be accommodating to 
newcomers who want to contribute. To this I responded that it is very 
hard for anyone to get access rights. Many repositories don't even allow 
self-registering.

But the problems go deeper than that. After registering an account, a 
new contributor will generally get the Reader ("u") capability. This 
means they can edit tickets and wiki pages. To be able to contribute 
code requires the "Developer" (v) or at least the "Check-In" (i) 
capability. An administrator needs to be involved to assign those 
capabilities. There is however no assured method to figure out how to 
contact an administrator for any given repository, or even to find out 
who they are. If self-registering is disabled, one already has to hunt 
down an administrator to even get an account.

In my opinion the following points need to be addressed to be more 
welcoming to new contributors:

*Email notifications*

    Email notifications are required to inform ticket originators about
    follow-up questions. Without them, tickets may be abandoned or make
    very slow progress because they depend on the originator taking the
    initiative to check back for updates.

    A few of the items below also need a method to communicate
    information to the user. Email notifications need to work for that.
    The way to set this up on chiselapp does not work on core.tcl-lang.
    I have contacted Roy Keene for assistance but I have not yet heard
    back from him.

*Self registration*

    New users should be allowed to self register. To prevent too many
    fake accounts, it would be best to enable email verification for
    self-registration. An additional complication is that fossil changed
    policy in 2020. When self-registering, user IDs must now be at least
    6 characters. People who registered on some core repositories with a
    shorter user ID in the past will now not be able to self-register
    with the same ID on other core repositories.

*Obtain developer rights*

    There must be a better way to get developer rights than to ask on
    the Tcl chat if anyone knows who administers a certain repository
    and then go hunt for an email address. I can think of a few
    possibilities:

      * Assign "Check-In" (i) privileges to all new users. This may make
        it too easy for malicious parties to wreak havoc on the code.
      * Assign "Announce" (A) privileges to all new users, so they can
        send a notification to all moderators to request an upgrade of
        their privileges. Currently the "Announce" privilege allows the
        user to send a notification to everyone. This opens up the
        possibility for sending spam to a possibly large number of
        people. Maybe we should work with the fossil developers to get a
        new privilege for only sending a message to the (active)
        administrators. Then any spamming would be restricted to a much
        smaller group.
      * Have some standard page on the repository that lists the
        administrators. This should preferably be generated, otherwise
        it will require maintenance.
      * Have a forum thread where such requests can be posted. Newly
        registered users will need the "Forum-Write" (3) privilege to be
        able to use that. This of course also requires administrators to
        keep an eye on the forum.
      * Define some wiki page where users can add their request to be
        upgraded to developer. An admin can then remove that request
        once it is processed. I don't think the ticket system should be
        abused for this.

    Whatever method is selected, it must be documented in an easy to
    find location.

*Download a tarball*

    On some repositories it is not possible to download a tarball or ZIP
    archive without logging in. Newcomers have trouble enough finding
    those links in the first place. They may get completely discouraged
    if they go to the right place but still don't see the links because
    they didn't log in. Being able to download sources without logging
    in can also be useful for scripts, makefiles, and github actions.

------------------------------------------------------------------------

List of repositories that currently don't allow self registering:

  * tcloo
  * tclvfs
  * expect
  * tclws
  * mpexpr
  * tclquadcode
  * sampleextension
  * tiprender
  * tdbcsqlite3
  * tdbcodbc
  * tdbcmysql
  * tdbcpostgres
  * iwidgets
  * tclapps
  * bwidget
  * mclistbox
  * tclbench
  * tdom
  * wtk
  * tclhttpd
  * tcludp

List of repositories that don't allow downloading a tarball without 
logging in:

  * tclquadcode
  * iwidgets
  * tcllib
  * tclapps
  * bwidget
  * mclistbox
  * tclbench
  * wtk
  * tclhttpd
  * tcludp


Regards,

Schelte.

Re: [TCLCORE] New TIP #712: Add "positive" options to the subst command

[Harald O. <har...@el...>]

Am 31.01.2025 um 15:55 schrieb Reinhard Max:
> Hi,
> 
> please notice my first TIP as a core team member and let me know what 
> you think of it.
> 
> https://core.tcl-lang.org/tips/doc/trunk/tip/712.md
> 
> cu
> Reinhard
Yes, that will make scripts much more readable.
Also abrevating the options is clearer.
And there are tests and documentation, great.
And not mixing the options is great.

I would propose to target 9.1 instead 9.0.1.
Don has not published jet the release plan to motivate this.

Thanks,
Harald

[TCLCORE] New TIP #712: Add "positive" options to the subst command

[Reinhard M. <rei...@m4...>]

Hi,

please notice my first TIP as a core team member and let me know what 
you think of it.

https://core.tcl-lang.org/tips/doc/trunk/tip/712.md

cu
Reinhard

Re: [TCLCORE] OpenACS/Tcl/Tk user meeting in Bologna/Italy the 10th and 11th of July 2025

[Colin M. <col...@ya...>]

Great News Harald!

Now I have to start thinking what I can talk about this time... 🤔

Colin.

On 31/01/2025 08:30, Harald Oehlmann wrote:
> Dear OpenACS/Tcl/Tk fans,
>
> *Bologna*, *Italy*, will welcome you
> for the OpenACS/Tcl/Tk user meeting
> happening the 10th and 11th of July 2025!
> More details in two weeks.
>
> Please save the date and feel invited !
>
> Harald
> (very excited)
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] OpenACS/Tcl/Tk user meeting in Bologna/Italy the 10th and 11th of July 2025

[Paul O. <pa...@po...>]

Great news!

Date is marked in my calender.

Paul

Am 31.01.2025 um 09:30 schrieb Harald Oehlmann:
> Dear OpenACS/Tcl/Tk fans,
>
> *Bologna*, *Italy*, will welcome you
> for the OpenACS/Tcl/Tk user meeting
> happening the 10th and 11th of July 2025!
> More details in two weeks.
>
> Please save the date and feel invited !
>
> Harald
> (very excited)
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] OpenACS/Tcl/Tk user meeting in Bologna/Italy the 10th and 11th of July 2025

[Harald O. <har...@el...>]

Dear OpenACS/Tcl/Tk fans,

*Bologna*, *Italy*, will welcome you
for the OpenACS/Tcl/Tk user meeting
happening the 10th and 11th of July 2025!
More details in two weeks.

Please save the date and feel invited !

Harald
(very excited)

Re: [TCLCORE] On type checking variables

[<apn...@ya...>]

Donal,

 

Thanks for the reply. I do think though that what you described is far more
capable and sophisticated than what I was envisioning (hence my comment in
my previous post about generalized constraints being complex).

 

But before commenting further,  I should look at your const implementation
in more detail to understand better what would be involved even for my
"simpler" goals.

 

/Ashok

 

From: Donal Fellows <don...@ma...> 
Sent: Thursday, January 30, 2025 10:06 PM
To: tcl...@li...; apn...@ya...
Subject: Re: [TCLCORE] On type checking variables

 

That's quite complicated as it stands; constant-ness is a single bit flag
right now that is tested for before analysing the variable in any depth
(i.e., before searching for traces) so it's pretty cheap. Binding a type is
more complex; the current simplest mechanism for it is what we have for
Tcl_LinkVar() and that involves traces and a way to unwind rejected writes
as traces run after the fact. A type check would probably be better done
through a pre-write authorization callback so that there's no need to unwind
failures; we don't have such a thing right now so this would be new code to
hang on the Tcl_Var ekeko. In the simplest cases we'd be able to limit that
to a "conforms to type" check but it's only easy to write such things for
basic types.

 

I'd not expect a speed boost from doing this, not without some sort of smart
compilation to remove the need to check the type in the first place (and
possibly unbox the value, for simple-enough types such as the one in your
example). Obviously, no such compiler exists at the moment as it would be
dependent on the model changes sketched in my previous paragraph.

 

In general, type constraints are complex because types are complex, as one
inevitably wants to start describing types of compound objects like lists
and dicts, which are a yawning abyss of tricky cases. It's a proper can of
worms! (As evidence, I cite the enormous complexity introduced by typing in
Python, not made easier by their different approach to mutability.)

 

Basically, we can add type constraints pretty easily (one more callback type
to run as part of a variable write prior to the variable being written) but
defining the space of type constraints that can be enforced at that point is
VERY HARD!

 

And constants don't use that mechanism. They just deny all writes.

 

Donal.

 

  _____  

From: apnmbx-public--- via Tcl-Core <tcl...@li...
<mailto:tcl...@li...> >
Sent: Thursday, January 30, 2025 16:08
To: tcl...@li... <mailto:tcl...@li...>
<tcl...@li... <mailto:tcl...@li...> >
Subject: [TCLCORE] On type checking variables 

 

(Probably a question for Donal, but sending to the list in case folks have
ideas / opinions for or against)

 

The [const] command implementation in Tcl 9 essentially bars writes to
specified variables. How hard would it be to loosen this constraint
mechanism to instead only bar certain writes, for example, writing values
that do not match a specified type? So, in Tcl 9

 

const x 42

set x 43 <- disallowed

 

Similarly,

 

Int32 x 42

Set x 43 <- allowed

Set x abc <- disallowed

 

Etc.

 

A generalized constraint mechanism will introduce many complexities but just
type check does not seem hard to implement.

 

The motivation by the way is to simplify interfaces to external API's in
other languages and data exchange by not having to carry typing tags.

 

Any comments on (a) feasibility, and (b) implications, if any, for Tcl
semantics ?

 

/Ashok

Re: [TCLCORE] On type checking variables

[Donal F. <don...@ma...>]

That's quite complicated as it stands; constant-ness is a single bit flag right now that is tested for before analysing the variable in any depth (i.e., before searching for traces) so it's pretty cheap. Binding a type is more complex; the current simplest mechanism for it is what we have for Tcl_LinkVar() and that involves traces and a way to unwind rejected writes as traces run after the fact. A type check would probably be better done through a pre-write authorization callback so that there's no need to unwind failures; we don't have such a thing right now so this would be new code to hang on the Tcl_Var ekeko. In the simplest cases we'd be able to limit that to a "conforms to type" check but it's only easy to write such things for basic types.

I'd not expect a speed boost from doing this, not without some sort of smart compilation to remove the need to check the type in the first place (and possibly unbox the value, for simple-enough types such as the one in your example). Obviously, no such compiler exists at the moment as it would be dependent on the model changes sketched in my previous paragraph.

In general, type constraints are complex because types are complex, as one inevitably wants to start describing types of compound objects like lists and dicts, which are a yawning abyss of tricky cases. It's a proper can of worms! (As evidence, I cite the enormous complexity introduced by typing in Python, not made easier by their different approach to mutability.)

Basically, we can add type constraints pretty easily (one more callback type to run as part of a variable write prior to the variable being written) but defining the space of type constraints that can be enforced at that point is VERY HARD!

And constants don't use that mechanism. They just deny all writes.

Donal.

________________________________
From: apnmbx-public--- via Tcl-Core <tcl...@li...>
Sent: Thursday, January 30, 2025 16:08
To: tcl...@li... <tcl...@li...>
Subject: [TCLCORE] On type checking variables


(Probably a question for Donal, but sending to the list in case folks have ideas / opinions for or against)



The [const] command implementation in Tcl 9 essentially bars writes to specified variables. How hard would it be to loosen this constraint mechanism to instead only bar certain writes, for example, writing values that do not match a specified type? So, in Tcl 9



const x 42

set x 43 <- disallowed



Similarly,



Int32 x 42

Set x 43 <- allowed

Set x abc <- disallowed



Etc.



A generalized constraint mechanism will introduce many complexities but just type check does not seem hard to implement.



The motivation by the way is to simplify interfaces to external API’s in other languages and data exchange by not having to carry typing tags.



Any comments on (a) feasibility, and (b) implications, if any, for Tcl semantics ?



/Ashok

[TCLCORE] On type checking variables

[<apn...@ya...>]

(Probably a question for Donal, but sending to the list in case folks have
ideas / opinions for or against)

 

The [const] command implementation in Tcl 9 essentially bars writes to
specified variables. How hard would it be to loosen this constraint
mechanism to instead only bar certain writes, for example, writing values
that do not match a specified type? So, in Tcl 9

 

const x 42

set x 43 <- disallowed

 

Similarly, 

 

Int32 x 42

Set x 43 <- allowed

Set x abc <- disallowed

 

Etc.

 

A generalized constraint mechanism will introduce many complexities but just
type check does not seem hard to implement.

 

The motivation by the way is to simplify interfaces to external API's in
other languages and data exchange by not having to carry typing tags.

 

Any comments on (a) feasibility, and (b) implications, if any, for Tcl
semantics ?

 

/Ashok

Re: [TCLCORE] "Productive branches"

[<apn...@ya...>]

Just one more thought on the meeting topic. It feels most, not all, regular participants are much more versed in Tcl than Tk (certainly true in my case). If parallel regular meetings were scheduled, it would be good to have them in a time slot where more Tk implementers could participate.

 

/Ashok

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, January 27, 2025 10:58 PM
To: 'Marc Culler' <cul...@gm...>; 'Tcl Core List' <tcl...@li...>
Subject: Re: [TCLCORE] "Productive branches"

 

I think historically, two concurrent release trains have been maintained, for example 8.5 and 8.6. The earlier version gets updates less frequently than the later one and eventually gets EOL (8.5.19 I think was the last in 8.5 series). I would expect that to continue though personally I am all in favour of ditching older releases as soon as possible.

 

More important, to your point about the online meetings. These are very much not making decisions or setting any kind of policy. They are more akin to, say, coffee time discussions about issues and ideas in a different era. They serve the purpose of being lightweight, interactive and provide immediate feedback which is more productive in some sense than written communication. That’s all. They are a starting point for formal, wider discussions, centred around TIPs that may arise from those meetings. For example, the development workflow that Harald described reflected what was discussed, not what has been decided. The discussion will be formalized in TIP 710 and everyone will have their say and more!

 

Note the online meets are not TCT only, but open to all.

 

Your point about timings is understood. Fortunately, there are participants around the world. Unfortunately, that means it is difficult to accommodate all time zones. The current time was moved from the original to maximize participation. Rotation is certainly a possibility, but the meeting has to be driven by someone in that time zone(s). Given the difficulty of scheduling an “all-hands” meet, there is no reason at all not to have multiple discussion groups with hopefully some overlap in participants.

 

/Ashok

 

From: Marc Culler <cul...@gm... <mailto:cul...@gm...> > 
Sent: Monday, January 27, 2025 10:01 PM
To: Tcl Core List <tcl...@li... <mailto:tcl...@li...> >
Subject: Re: [TCLCORE] "Productive branches"

 

I would like to add that it does not make sense to me to even have both 9.0 and 9.1 as "productive branches".  In my opinion, when 9.1 is released 9.0 should cease to be productive.  I can't think of any reason to maintain 9.0 and 9.1 separately, much less 9.3, 9.4, 9.5, ad infinitum. While a project like Python may be able maintain 3 separate versions simultaneously, they also have a foundation with many paid employees.

 

- Marc  

 

On Mon, Jan 27, 2025 at 10:14 AM Marc Culler <cul...@gm... <mailto:cul...@gm...> > wrote:

I don't understand this, but it looks very strange to me:

First we have:

 

- there are productive branches:
core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
Missing branches are created when the first 9.1 feature is merged.

 

Then we have:

 

- if a branch is ready to merge, please ask for a merge permission it in 
the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).

 

So that makes it look like we will have "productive branches" 9.0, 9.1. 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.

 

Also, I don't understand why TCT policies are being created outside of the official communication channel of the TCT, i.e. this list, at video conferences which occur at 4AM for people on the west coast of the US, with no discussion on this list.  I thought we had agreed not to do that.

 

Also, I think it is important to provide a list of attendees at the video meeting, especially when they are claiming to set policy for the TCT.

 

- Marc

 

 

Re: [TCLCORE] "Productive branches"

[Harald O. <har...@el...>]

Thanks for pointing this out. Yes, the "chronist" have to ship around 
many obstactles ;-)

Take care,
Harald

Am 27.01.2025 um 18:44 schrieb Marc Culler:
>     The discussion will be formalized in TIP 710 and everyone will have
>     their say and more!
> 
> 
> This is very important, and was not clear from the meeting "minutes".
> 
> Is there any harm in listing TCT participants in the meeting, by 
> initials, as part of the "minutes"
> And many thanks to Harald for taking the time to write these "minutes".  
> Without them, people who don't participate, for whatever reason, would 
> really be in the dark.
> 
> - Marc
> 
> On Mon, Jan 27, 2025 at 11:28 AM <apn...@ya... 
> <mailto:apn...@ya...>> wrote:
> 
>     I think historically, two concurrent release trains have been
>     maintained, for example 8.5 and 8.6. The earlier version gets
>     updates less frequently than the later one and eventually gets EOL
>     (8.5.19 I think was the last in 8.5 series). I would expect that to
>     continue though personally I am all in favour of ditching older
>     releases as soon as possible.____
> 
>     __ __
> 
>     More important, to your point about the online meetings. *These are
>     very much not making decisions or setting any kind of policy.* They
>     are more akin to, say, coffee time discussions about issues and
>     ideas in a different era. They serve the purpose of being
>     lightweight, interactive and provide immediate feedback which is
>     more productive in some sense than written communication. That’s
>     all. They are a starting point for formal, wider discussions,
>     centred around TIPs that may arise from those meetings. For example,
>     the development workflow that Harald described reflected what was
>     discussed, not what has been decided. The discussion will be
>     formalized in TIP 710 and everyone will have their say and more!____
> 
>     __ __
> 
>     Note the online meets are not TCT only, but open to all.____
> 
>     __ __
> 
>     Your point about timings is understood. Fortunately, there are
>     participants around the world. Unfortunately, that means it is
>     difficult to accommodate all time zones. The current time was moved
>     from the original to maximize participation. Rotation is certainly a
>     possibility, but the meeting has to be driven by someone in that
>     time zone(s). Given the difficulty of scheduling an “all-hands”
>     meet, there is no reason at all not to have multiple discussion
>     groups with hopefully some overlap in participants.____
> 
>     __ __
> 
>     /Ashok____
> 
>     __ __
> 
>     *From:*Marc Culler <cul...@gm... <mailto:cul...@gm...>>
>     *Sent:* Monday, January 27, 2025 10:01 PM
>     *To:* Tcl Core List <tcl...@li... <mailto:tcl-
>     co...@li...>>
>     *Subject:* Re: [TCLCORE] "Productive branches"____
> 
>     __ __
> 
>     I would like to add that it does not make sense to me to even have
>     both 9.0 and 9.1 as "productive branches".  In my opinion, when 9.1
>     is released 9.0 should cease to be productive.  I can't think of any
>     reason to maintain 9.0 and 9.1 separately, much less 9.3, 9.4, 9.5,
>     ad infinitum. While a project like Python may be able maintain 3
>     separate versions simultaneously, they also have a foundation with
>     many paid employees.____
> 
>     __ __
> 
>     - Marc ____
> 
>     __ __
> 
>     On Mon, Jan 27, 2025 at 10:14 AM Marc Culler <cul...@gm...
>     <mailto:cul...@gm...>> wrote:____
> 
>         I don't understand this, but it looks very strange to me:____
> 
>         First we have:____
> 
>         __ __
> 
>         - there are productive branches:
>         core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
>         Missing branches are created when the first 9.1 feature is
>         merged.____
> 
>         __ __
> 
>         Then we have:____
> 
>         __ __
> 
>         - if a branch is ready to merge, please ask for a merge
>         permission it in
>         the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).____
> 
>         __ __
> 
>         So that makes it look like we will have "productive branches"
>         9.0, 9.1. 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to
>         me.____
> 
>         __ __
> 
>         Also, I don't understand why TCT policies are being created
>         outside of the official communication channel of the TCT, i.e.
>         this list, at video conferences which occur at 4AM for people on
>         the west coast of the US, with no discussion on this list.  I
>         thought we had agreed not to do that.____
> 
>         __ __
> 
>         Also, I think it is important to provide a list of attendees at
>         the video meeting, especially when they are claiming to set
>         policy for the TCT.____
> 
>         __ __
> 
>         - Marc____
> 
>         __ __
> 
>         __ __
> 

[TCLCORE] Cannot access https://tcl.tk/

[Csaba N. <csa...@t-...>]

The web server hosting the above link is down.  Can someone restart it? 
Thanks!

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] "Productive branches"

[Marc C. <cul...@gm...>]

>
> The discussion will be formalized in TIP 710 and everyone will have their
> say and more!


This is very important, and was not clear from the meeting "minutes".

Is there any harm in listing TCT participants in the meeting, by initials,
as part of the "minutes"
And many thanks to Harald for taking the time to write these "minutes".
Without them, people who don't participate, for whatever reason, would
really be in the dark.

- Marc

On Mon, Jan 27, 2025 at 11:28 AM <apn...@ya...> wrote:

> I think historically, two concurrent release trains have been maintained,
> for example 8.5 and 8.6. The earlier version gets updates less frequently
> than the later one and eventually gets EOL (8.5.19 I think was the last in
> 8.5 series). I would expect that to continue though personally I am all in
> favour of ditching older releases as soon as possible.
>
>
>
> More important, to your point about the online meetings. *These are very
> much not making decisions or setting any kind of policy.* They are more
> akin to, say, coffee time discussions about issues and ideas in a different
> era. They serve the purpose of being lightweight, interactive and provide
> immediate feedback which is more productive in some sense than written
> communication. That’s all. They are a starting point for formal, wider
> discussions, centred around TIPs that may arise from those meetings. For
> example, the development workflow that Harald described reflected what was
> discussed, not what has been decided. The discussion will be formalized in
> TIP 710 and everyone will have their say and more!
>
>
>
> Note the online meets are not TCT only, but open to all.
>
>
>
> Your point about timings is understood. Fortunately, there are
> participants around the world. Unfortunately, that means it is difficult to
> accommodate all time zones. The current time was moved from the original to
> maximize participation. Rotation is certainly a possibility, but the
> meeting has to be driven by someone in that time zone(s). Given the
> difficulty of scheduling an “all-hands” meet, there is no reason at all not
> to have multiple discussion groups with hopefully some overlap in
> participants.
>
>
>
> /Ashok
>
>
>
> *From:* Marc Culler <cul...@gm...>
> *Sent:* Monday, January 27, 2025 10:01 PM
> *To:* Tcl Core List <tcl...@li...>
> *Subject:* Re: [TCLCORE] "Productive branches"
>
>
>
> I would like to add that it does not make sense to me to even have both
> 9.0 and 9.1 as "productive branches".  In my opinion, when 9.1 is released
> 9.0 should cease to be productive.  I can't think of any reason to maintain
> 9.0 and 9.1 separately, much less 9.3, 9.4, 9.5, ad infinitum. While a
> project like Python may be able maintain 3 separate versions
> simultaneously, they also have a foundation with many paid employees.
>
>
>
> - Marc
>
>
>
> On Mon, Jan 27, 2025 at 10:14 AM Marc Culler <cul...@gm...> wrote:
>
> I don't understand this, but it looks very strange to me:
>
> First we have:
>
>
>
> - there are productive branches:
> core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
> Missing branches are created when the first 9.1 feature is merged.
>
>
>
> Then we have:
>
>
>
> - if a branch is ready to merge, please ask for a merge permission it in
> the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).
>
>
>
> So that makes it look like we will have "productive branches" 9.0, 9.1.
> 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
>
>
>
> Also, I don't understand why TCT policies are being created outside of the
> official communication channel of the TCT, i.e. this list, at video
> conferences which occur at 4AM for people on the west coast of the US, with
> no discussion on this list.  I thought we had agreed not to do that.
>
>
>
> Also, I think it is important to provide a list of attendees at the video
> meeting, especially when they are claiming to set policy for the TCT.
>
>
>
> - Marc
>
>
>
>
>
>

Re: [TCLCORE] "Productive branches"

[<apn...@ya...>]

I think historically, two concurrent release trains have been maintained, for example 8.5 and 8.6. The earlier version gets updates less frequently than the later one and eventually gets EOL (8.5.19 I think was the last in 8.5 series). I would expect that to continue though personally I am all in favour of ditching older releases as soon as possible.

 

More important, to your point about the online meetings. These are very much not making decisions or setting any kind of policy. They are more akin to, say, coffee time discussions about issues and ideas in a different era. They serve the purpose of being lightweight, interactive and provide immediate feedback which is more productive in some sense than written communication. That’s all. They are a starting point for formal, wider discussions, centred around TIPs that may arise from those meetings. For example, the development workflow that Harald described reflected what was discussed, not what has been decided. The discussion will be formalized in TIP 710 and everyone will have their say and more!

 

Note the online meets are not TCT only, but open to all.

 

Your point about timings is understood. Fortunately, there are participants around the world. Unfortunately, that means it is difficult to accommodate all time zones. The current time was moved from the original to maximize participation. Rotation is certainly a possibility, but the meeting has to be driven by someone in that time zone(s). Given the difficulty of scheduling an “all-hands” meet, there is no reason at all not to have multiple discussion groups with hopefully some overlap in participants.

 

/Ashok

 

From: Marc Culler <cul...@gm...> 
Sent: Monday, January 27, 2025 10:01 PM
To: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] "Productive branches"

 

I would like to add that it does not make sense to me to even have both 9.0 and 9.1 as "productive branches".  In my opinion, when 9.1 is released 9.0 should cease to be productive.  I can't think of any reason to maintain 9.0 and 9.1 separately, much less 9.3, 9.4, 9.5, ad infinitum. While a project like Python may be able maintain 3 separate versions simultaneously, they also have a foundation with many paid employees.

 

- Marc  

 

On Mon, Jan 27, 2025 at 10:14 AM Marc Culler <cul...@gm... <mailto:cul...@gm...> > wrote:

I don't understand this, but it looks very strange to me:

First we have:

 

- there are productive branches:
core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
Missing branches are created when the first 9.1 feature is merged.

 

Then we have:

 

- if a branch is ready to merge, please ask for a merge permission it in 
the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).

 

So that makes it look like we will have "productive branches" 9.0, 9.1. 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.

 

Also, I don't understand why TCT policies are being created outside of the official communication channel of the TCT, i.e. this list, at video conferences which occur at 4AM for people on the west coast of the US, with no discussion on this list.  I thought we had agreed not to do that.

 

Also, I think it is important to provide a list of attendees at the video meeting, especially when they are claiming to set policy for the TCT.

 

- Marc

 

 

Re: [TCLCORE] "Productive branches"

[Harald O. <har...@el...>]

No problem, just go there.
Thanks for all,
Harald

Am 27.01.2025 um 18:14 schrieb Marc Culler:
> Why not discuss it here, using the " primary mechanism for communicating 
> with the Tcl Core Team" (as it is described in TIP #0)?
> 
> - Marc
> 
> On Mon, Jan 27, 2025 at 11:03 AM Harald Oehlmann 
> <har...@el... <mailto:har...@el...>> wrote:
> 
>     Hi Marc,
> 
>     thanks for your contribution. I propose to discuss this point at the
>     next meeting, which is the Tk meeting.
> 
>     Thanks for all,
>     Harald
> 
>     Am 27.01.2025 um 17:58 schrieb Marc Culler:
>      >
>      >
>      > On Mon, Jan 27, 2025 at 10:45 AM Harald Oehlmann
>      > <har...@el... <mailto:har...@el...>
>     <mailto:har...@el...
>     <mailto:har...@el...>>> wrote:
>      >
>      >     We, in Germany, are very strict in personal data protection.
>      >     That is the reason why there are only sparse names on
>     informal meetings.
>      >     And on some participants, I don't know the identity.
>      >
>      >
>      > Hi Harald,
>      >
>      > This is not an issue related to personal data protection.  While
>      > protecting privacy is admirable, albeit often used to mask other
>      > motives, some data is public and needs to be public. The list of
>     names
>      > of TCT members is public, and easily available on the web.  When
>     a TIP
>      > is voted on we publish the votes of the TCT, using initials.  I
>     would
>      > propose the same thing for the reports of the video conferences. 
>     List
>      > the TCT members present at the meeting by their initials.  That
>     would
>      > allow other TCT members to have a clear idea of how our decisions
>     are
>      > being made and how our interests are being represented by fellow
>      > members.  There is no need to publish any personal information about
>      > other people who happen to drop in on the meeting.
>      >
>      > - Marc
>      >
>      >
>      >
>      >     Take care,
>      >     Harald
>      >
>      >     Am 27.01.2025 um 17:14 schrieb Marc Culler:
>      >      > I don't understand this, but it looks very strange to me:
>      >      > First we have:
>      >      >
>      >      > - there are productive branches:
>      >      > core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
>      >      > Missing branches are created when the first 9.1 feature is
>     merged.
>      >      >
>      >      > Then we have:
>      >      >
>      >      > - if a branch is ready to merge, please ask for a merge
>      >     permission it in
>      >      > the ticket including the proposed branches (e.g. 8.6, 9.0,
>     9.1).
>      >      >
>      >      > So that makes it look like we will have "productive branches"
>      >     9.0, 9.1.
>      >      > 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
>      >      >
>      >      > Also, I don't understand why TCT policies are being created
>      >     outside of
>      >      > the official communication channel of the TCT, i.e. this
>     list, at
>      >     video
>      >      > conferences which occur at 4AM for people on the west coast of
>      >     the US,
>      >      > with no discussion on this list.  I thought we had agreed
>     not to
>      >     do that.
>      >      >
>      >      > Also, I think it is important to provide a list of
>     attendees at the
>      >      > video meeting, especially when they are claiming to set policy
>      >     for the TCT.
>      >      >
>      >      > - Marc
> 

Re: [TCLCORE] "Productive branches"

[Marc C. <cul...@gm...>]

Why not discuss it here, using the " primary mechanism for communicating
with the Tcl Core Team" (as it is described in TIP #0)?

- Marc

On Mon, Jan 27, 2025 at 11:03 AM Harald Oehlmann <
har...@el...> wrote:

> Hi Marc,
>
> thanks for your contribution. I propose to discuss this point at the
> next meeting, which is the Tk meeting.
>
> Thanks for all,
> Harald
>
> Am 27.01.2025 um 17:58 schrieb Marc Culler:
> >
> >
> > On Mon, Jan 27, 2025 at 10:45 AM Harald Oehlmann
> > <har...@el... <mailto:har...@el...>>
> wrote:
> >
> >     We, in Germany, are very strict in personal data protection.
> >     That is the reason why there are only sparse names on informal
> meetings.
> >     And on some participants, I don't know the identity.
> >
> >
> > Hi Harald,
> >
> > This is not an issue related to personal data protection.  While
> > protecting privacy is admirable, albeit often used to mask other
> > motives, some data is public and needs to be public. The list of names
> > of TCT members is public, and easily available on the web.  When a TIP
> > is voted on we publish the votes of the TCT, using initials.  I would
> > propose the same thing for the reports of the video conferences.  List
> > the TCT members present at the meeting by their initials.  That would
> > allow other TCT members to have a clear idea of how our decisions are
> > being made and how our interests are being represented by fellow
> > members.  There is no need to publish any personal information about
> > other people who happen to drop in on the meeting.
> >
> > - Marc
> >
> >
> >
> >     Take care,
> >     Harald
> >
> >     Am 27.01.2025 um 17:14 schrieb Marc Culler:
> >      > I don't understand this, but it looks very strange to me:
> >      > First we have:
> >      >
> >      > - there are productive branches:
> >      > core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
> >      > Missing branches are created when the first 9.1 feature is merged.
> >      >
> >      > Then we have:
> >      >
> >      > - if a branch is ready to merge, please ask for a merge
> >     permission it in
> >      > the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).
> >      >
> >      > So that makes it look like we will have "productive branches"
> >     9.0, 9.1.
> >      > 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
> >      >
> >      > Also, I don't understand why TCT policies are being created
> >     outside of
> >      > the official communication channel of the TCT, i.e. this list, at
> >     video
> >      > conferences which occur at 4AM for people on the west coast of
> >     the US,
> >      > with no discussion on this list.  I thought we had agreed not to
> >     do that.
> >      >
> >      > Also, I think it is important to provide a list of attendees at
> the
> >      > video meeting, especially when they are claiming to set policy
> >     for the TCT.
> >      >
> >      > - Marc
>

Re: [TCLCORE] "Productive branches"

[Harald O. <har...@el...>]

Hi Marc,

thanks for your contribution. I propose to discuss this point at the 
next meeting, which is the Tk meeting.

Thanks for all,
Harald

Am 27.01.2025 um 17:58 schrieb Marc Culler:
> 
> 
> On Mon, Jan 27, 2025 at 10:45 AM Harald Oehlmann 
> <har...@el... <mailto:har...@el...>> wrote:
> 
>     We, in Germany, are very strict in personal data protection.
>     That is the reason why there are only sparse names on informal meetings.
>     And on some participants, I don't know the identity.
> 
> 
> Hi Harald,
> 
> This is not an issue related to personal data protection.  While 
> protecting privacy is admirable, albeit often used to mask other 
> motives, some data is public and needs to be public. The list of names 
> of TCT members is public, and easily available on the web.  When a TIP 
> is voted on we publish the votes of the TCT, using initials.  I would 
> propose the same thing for the reports of the video conferences.  List 
> the TCT members present at the meeting by their initials.  That would 
> allow other TCT members to have a clear idea of how our decisions are 
> being made and how our interests are being represented by fellow 
> members.  There is no need to publish any personal information about 
> other people who happen to drop in on the meeting.
> 
> - Marc
> 
> 
> 
>     Take care,
>     Harald
> 
>     Am 27.01.2025 um 17:14 schrieb Marc Culler:
>      > I don't understand this, but it looks very strange to me:
>      > First we have:
>      >
>      > - there are productive branches:
>      > core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
>      > Missing branches are created when the first 9.1 feature is merged.
>      >
>      > Then we have:
>      >
>      > - if a branch is ready to merge, please ask for a merge
>     permission it in
>      > the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).
>      >
>      > So that makes it look like we will have "productive branches"
>     9.0, 9.1.
>      > 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
>      >
>      > Also, I don't understand why TCT policies are being created
>     outside of
>      > the official communication channel of the TCT, i.e. this list, at
>     video
>      > conferences which occur at 4AM for people on the west coast of
>     the US,
>      > with no discussion on this list.  I thought we had agreed not to
>     do that.
>      >
>      > Also, I think it is important to provide a list of attendees at the
>      > video meeting, especially when they are claiming to set policy
>     for the TCT.
>      >
>      > - Marc

Re: [TCLCORE] "Productive branches"

[Marc C. <cul...@gm...>]

On Mon, Jan 27, 2025 at 10:45 AM Harald Oehlmann <
har...@el...> wrote:

> We, in Germany, are very strict in personal data protection.
> That is the reason why there are only sparse names on informal meetings.
> And on some participants, I don't know the identity.
>

Hi Harald,

This is not an issue related to personal data protection.  While protecting
privacy is admirable, albeit often used to mask other motives, some data is
public and needs to be public. The list of names of TCT members is public,
and easily available on the web.  When a TIP is voted on we publish the
votes of the TCT, using initials.  I would propose the same thing for the
reports of the video conferences.  List the TCT members present at the
meeting by their initials.  That would allow other TCT members to have a
clear idea of how our decisions are being made and how our interests are
being represented by fellow members.  There is no need to publish any
personal information about other people who happen to drop in on the
meeting.

- Marc



>
> Take care,
> Harald
>
> Am 27.01.2025 um 17:14 schrieb Marc Culler:
> > I don't understand this, but it looks very strange to me:
> > First we have:
> >
> > - there are productive branches:
> > core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
> > Missing branches are created when the first 9.1 feature is merged.
> >
> > Then we have:
> >
> > - if a branch is ready to merge, please ask for a merge permission it in
> > the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).
> >
> > So that makes it look like we will have "productive branches" 9.0, 9.1.
> > 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
> >
> > Also, I don't understand why TCT policies are being created outside of
> > the official communication channel of the TCT, i.e. this list, at video
> > conferences which occur at 4AM for people on the west coast of the US,
> > with no discussion on this list.  I thought we had agreed not to do that.
> >
> > Also, I think it is important to provide a list of attendees at the
> > video meeting, especially when they are claiming to set policy for the
> TCT.
> >
> > - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] "Productive branches"

[Kevin W. <kw...@co...>]

<div><img width="1" height="1" src='https://fedbdhd.r.tsp1-brevo.net/tr/op/ZYw1UCek1YLtbzvN0ardJ7V4h0ubMTV5spHwyB2OcliIq_wOXwf4cet9S7AVkIPevkB1FpGBc259nuMs1vXdpS6a2GAGANncVJBagmZh_3II077L1LFenCIJ9djbLDkctbATHMHVfSMg_8oAV_x4yArQfGAhDP2VC3psnRc3mrLd1ZGohFwNrTo_QPv1OgrkLV8ApwR-0qLnMtE0k0wwMWOyFom1' /></div>I’ll add that I am rarely able to attend these meetings (I have enough zoom calls on my day job) and certainly nothing that is discussed at such meetings should be viewed as final / the formal decision of the TCT. If it’s just a check-in to see what folks are working on, fine. <br/><br/>> On Jan 27, 2025, at 11:46 AM, Harald Oehlmann <har...@el...> wrote:<br/>> <br/>> Hi Marc,<br/>> thank you for your valuable contribution.<br/>> the report is a proposal.<br/>> The relevant TIP 710 is in creation.<br/>> <br/>> We, in Germany, are very strict in personal data protection.<br/>> That is the reason why there are only sparse names on informal meetings.<br/>> And on some participants, I don't know the identity.<br/>> <br/>> Take care,<br/>> Harald<br/>> <br/>>> Am 27.01.2025 um 17:14 schrieb Marc Culler:<br/>>> I don't understand this, but it looks very strange to me:<br/>>> First we have:<br/>>> - there are productive branches:<br/>>> core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch<br/>>> Missing branches are created when the first 9.1 feature is merged.<br/>>> Then we have:<br/>>> - if a branch is ready to merge, please ask for a merge permission it in<br/>>> the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).<br/>>> So that makes it look like we will have "productive branches" 9.0, 9.1. 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.<br/>>> Also, I don't understand why TCT policies are being created outside of the official communication channel of the TCT, i.e. this list, at video conferences which occur at 4AM for people on the west coast of the US, with no discussion on this list.  I thought we had agreed not to do that.<br/>>> Also, I think it is important to provide a list of attendees at the video meeting, especially when they are claiming to set policy for the TCT.<br/>>> - Marc<br/>> _______________________________________________<br/>> Tcl-Core mailing list<br/>> Tcl...@li...<br/>> https://lists.sourceforge.net/lists/listinfo/tcl-core<br/>> <OpenPGP_signature.asc><br/>

Re: [TCLCORE] "Productive branches"

[Harald O. <har...@el...>]

Hi Marc,
thank you for your valuable contribution.
the report is a proposal.
The relevant TIP 710 is in creation.

We, in Germany, are very strict in personal data protection.
That is the reason why there are only sparse names on informal meetings.
And on some participants, I don't know the identity.

Take care,
Harald

Am 27.01.2025 um 17:14 schrieb Marc Culler:
> I don't understand this, but it looks very strange to me:
> First we have:
> 
> - there are productive branches:
> core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
> Missing branches are created when the first 9.1 feature is merged.
> 
> Then we have:
> 
> - if a branch is ready to merge, please ask for a merge permission it in
> the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).
> 
> So that makes it look like we will have "productive branches" 9.0, 9.1. 
> 9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.
> 
> Also, I don't understand why TCT policies are being created outside of 
> the official communication channel of the TCT, i.e. this list, at video 
> conferences which occur at 4AM for people on the west coast of the US, 
> with no discussion on this list.  I thought we had agreed not to do that.
> 
> Also, I think it is important to provide a list of attendees at the 
> video meeting, especially when they are claiming to set policy for the TCT.
> 
> - Marc

[TCLCORE] "Productive branches"

[Marc C. <cul...@gm...>]

I don't understand this, but it looks very strange to me:
First we have:

- there are productive branches:
core-8-6-branch, core-8-branch, core-9-0-branch, core-9-branch
Missing branches are created when the first 9.1 feature is merged.

Then we have:

- if a branch is ready to merge, please ask for a merge permission it in
the ticket including the proposed branches (e.g. 8.6, 9.0, 9.1).

So that makes it look like we will have "productive branches" 9.0, 9.1.
9.2, 9,.3, 9.4, ....  which seems like a crazy idea to me.

Also, I don't understand why TCT policies are being created outside of the
official communication channel of the TCT, i.e. this list, at video
conferences which occur at 4AM for people on the west coast of the US, with
no discussion on this list.  I thought we had agreed not to do that.

Also, I think it is important to provide a list of attendees at the video
meeting, especially when they are claiming to set policy for the TCT.

- Marc