tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] "In the core"

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

On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin 
<bri...@ea...>, wrote:
>
>     As a (former) consumer of Tcl, delivering a commercial product, my
>     take on "in the core" means a single download and single build step.
>     And, to address corporate due diligence, the download is subject
>     to copyright vetting and security analysis.
>
>     The number of open-source downloads that have to go through these
>     steps can be overwhelming, hence the desire to bundle stuff
>     together whenever possible.
>
>     -Brian
>
Been there, done that :-)  At Bloomberg I fudged this by putting the 
whole kbskit through the approval process as a single entity, which was 
perhaps slightly dodgy.

Colin.

Re: [TCLCORE] "In the core"

[Brian G. <bri...@ea...>]

> On Oct 30, 2024, at 18:47, Steve Landers <st...@di...> wrote:
> 
> Folks,
> 
> Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.
> 
> Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?
> 
> Does it mean “I want this package to always be available when Tcl is installed?"
> 
> Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"
> 
> Does it mean all of the above or something else?
> 
> Here’s my take ...
> 
> Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).
> 
> We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.
> 
> So what are your thoughts?   

As a (former) consumer of Tcl, delivering a commercial product, my take on "in the core" means a single download and single build step.
And, to address corporate due diligence, the download is subject to copyright vetting and security analysis.

The number of open-source downloads that have to go through these steps can be overwhelming, hence the desire to bundle stuff together whenever possible.

-Brian

> 
> -- Steve
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] "In the core"

[Torsten B. <be...@ty...>]

Hi,

I think the definition depends on the people requesting some functionality or package to be in the core.

If it is a *single command*, then the definition is clear. They want to have the command in the Tcl source tree #(.../generic, .../unix, .../win, .../macosx). This will result in TIP control and the command to be available as every other Tcl command.

Users who want *a package* "in the core" will likely just want to have it distributed and available with every Tcl release, just as the packages in tcl/pkgs ("I want this package to always be available when Tcl is installed"). They don't care if it is under TIP control as long as it works. In my view this is the case for all packages under tcl/pkgs. For example, sqlite is inside tcl/pkgs and this one is definitely not under TIP control, right? Consequently, this should apply to all packages in tcl/pkgs as we have no rule distinguishing between "controlled packages" and "uncontrolled packages".

This has consequences for the developers maintaining a package. They need to make sure the package works with every new release of Tcl. This should be the rule for all packages in tcl/pkgs: they must have a maintainer who commits to keep it running with every Tcl release. It does not mean the package is under TIP control. It does also not mean that the package needs to be developed inside the Tcl repo (but it could). It can be copied into the Tcl source code distribution when the release is prepared. This is the situation now. Reading the README in tcl/pkgs, there is no requirement there that the package must run with every Tcl release. I feel, "in the core" implies just this and it should be stated in the README. So, every package listed in tcl/pkgs/package.list.txt automatically puts itself under this additional requirement (without putting the package under TIP control). This also means the package must run under unix/win/macos and cannot be restricted to one platform (unless it is specifically designed for an individual platofrm such as dde).

If some package developer/maintainer does not want this additional constraint, the package can not be defined as being "in the core" and thus needs to go somewhere else, e.g. into tcllib or tklib. These two I would expect to be in a Batteries Included distribution. There, a user has no guarantee the package will run with every new Tcl or Tk release. It is totally up to the maintainers what they are doing.

I totally agree that putting a package under TIP control may easily lead to a maintainer abandoning the package. This is also a reason not to require TIP control for  a package in tcl/pkgs.

Bottom line:

- “I want this package to be tightly controlled via TIPs” means we have the source code in .../generic, .../unix, .../win, .../macosx and the TCT controls it using TIPS. This is "in the core".

- “I want this package to always be available when Tcl is installed?" means the package is in tcl/pkgs. This is also "in the core" but not under TIP control and not under TCT control. However, the maintainer commits to some specific rules.

- “I want have confidence that this package can be built and installed in a particular Tcl version?" is NOT "in the core"

Regards, Torsten


> Am 31.10.2024 um 02:47 schrieb Steve Landers <st...@di...>:
> 
> Folks,
> 
> Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.
> 
> Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?
> 
> Does it mean “I want this package to always be available when Tcl is installed?"
> 
> Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"
> 
> Does it mean all of the above or something else?
> 
> Here’s my take ...
> 
> Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).
> 
> We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.
> 
> So what are your thoughts?
> 
> -- Steve
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] "In the core"

[Steve L. <st...@di...>]

Thanks Brian,

So if I hear you right, if the contents of tcl/pkgs are built with a Tcl build (which they are) and if they have the same (or compatible) license (which they do) then tcl/pkgs would meet your need without the need for those packages to be under TIP control.

-- Steve
On 31 Oct 2024 at 2:14 PM +0800, Brian Griffin <bri...@ea...>, wrote:
> As a (former) consumer of Tcl, delivering a commercial product, my take on "in the core" means a single download and single build step.
> And, to address corporate due diligence, the download is subject to copyright vetting and security analysis.
>
> The number of open-source downloads that have to go through these steps can be overwhelming, hence the desire to bundle stuff together whenever possible.
>
> -Brian
>

Re: [TCLCORE] "In the core"

[Steve L. <st...@di...>]

That would certainly make the package less likely to change behaviour in a minor release, but it might also stop Schelte from evolving the package. And it also commits someone to maintain it ongoing even after the original author has lost interest.  I’m not saying TIP or pkgs is better or worse in this situation, just noting considerations.

Another alternative is for a package to go into tcl/pkgs until a maintainer loses interest and and/or there is broad agreement that a package should be in the core. Again, not pushing this for debug, just observing.

Thanks

-- Steve
On 31 Oct 2024 at 11:08 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> That’s up to Schelte, but I would like it under TIP control.
>
> > On Oct 30, 2024, at 11:02 PM, Steve Landers wrote:
> >
> > Then you are asking for dbus to come under TIP control if it is part of the *nix source tree. Is that desirable or would it be better to stay maintained by Schelte as part of packages

Re: [TCLCORE] "In the core"

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

<div><img width="1" height="1" src='https://fedbdhd.r.af.d.sendibt2.com/tr/op/J3Y4YylxC_nyDXQdiFEPnYfJuShISSjuGvkqlyWWe9yxiu1ev0by-u_lwfwe_iRmyKR55-sZIePQDZfW95jeogXTjTodGYt5WeQL3VOu94wxVIU5JHmeImMUXIIwX-a5HGqpzOCt3ZPZCneRiVy4_Q_7JBABuxY388JKm-B9WHSGN6ioRM_xEVUKkq_C8f5XfjmgNJetVnPOMTwng6vw10rXXyRX0vMG' /></div>That’s up to Schelte, but I would like it under TIP control. <br/><br/>> On Oct 30, 2024, at 11:02 PM, Steve Landers <st...@di...> wrote:<br/>> <br/>> Then you are asking for dbus to come under TIP control if it is part of the *nix source tree.   Is that desirable or would it be better to stay maintained by Schelte as part of packages<br/>

Re: [TCLCORE] "In the core"

[Steve L. <st...@di...>]

Then you are asking for dbus to come under TIP control if it is part of the *nix source tree.   Is that desirable or would it be better to stay maintained by Schelte as part of packages.

This is the whole point of my original mail. When people say “in the core” what exactly do they mean?  The subsequent follow up emails haven’t shed any light on that.

-- Steve
On 31 Oct 2024 at 11:00 AM +0800, Kevin Walzer <kw...@co...>, wrote:
> tclWinDDE.c and tclWinReg.c are part of the Windows source tree, even though they are loaded like packages. That’s what I want for dbus, in the Unix source tree.
>
> > On Oct 30, 2024, at 10:53 PM, Steve Landers wrote:
> >
> > So would adding dbus to tcl/pkgs achieve you goals?

Re: [TCLCORE] "In the core"

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/Rv9d1D2s_Bs_WcRRZ0bRfWODhN8jyO2q_RdUt_8iuqZclXBL84VmU4Y7SzXG1eYmGrp-xIkGoe61BosHX-NTdgmWxA6N2PjsjHKv-91ikXViuthlhQtAZqDpchO7IzOIaaffXY7iaX2ijPpJ2qw471BxjENND4lQ7BIscK8kqACwoXmTq1pdpBObaF5KiMSdbEZtsUp8Il0Au6dtKjhUGsudKRkfRJfG' /></div>tclWinDDE.c and tclWinReg.c are part of the Windows source tree, even though they are loaded like packages. That’s what I want for dbus, in the Unix source tree. <br/><br/>> On Oct 30, 2024, at 10:53 PM, Steve Landers <st...@di...> wrote:<br/>> <br/>> So would adding dbus to tcl/pkgs achieve you goals?  <br/>

Re: [TCLCORE] "In the core"

[Steve L. <st...@di...>]

So would adding dbus to tcl/pkgs achieve you goals?

I can think of others - e.g. Steve Bennet’s linenoise fork to provide a console on all platforms (much like the SQLite project has recently done.

-- Steve
On 31 Oct 2024 at 10:48 AM +0800, Kevin Walzer <kw...@co...>, wrote:
>
> On 10/30/24 9:47 PM, Steve Landers wrote:
> > Does it mean all of the above or something else?
>
>
> Depends on the package. A loosely-coupled "nice to have" package like
> todbc is not really in the core. A key platform package like registry IS
> in the core for all intents and purposes. It is distributed and built
> with the core Tcl code. I have floated the idea of adding dbus to the
> core in the latter form.
>
> --Kevin
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] "In the core"

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/3VqCj3HtcOlWrOrwoH2WaK2-cV2cUFmzolNCL7DQLgXRuhfh0OWUUjUB98f6QUwy-3wkjP1PshmP056c3VEonL4qauYSdKanTH2IIZ-EJMaxfsoymYMYnviGBklH6CU-J_f2dIuDTn5VXvCZzzFJnZdZUhXN9WECOM-H3QELZPzk_ioggtIVXXiQTExnxAynULDcDhrxFPiUcrRYIobH7BJtUcA0jTxd' /></div><br/>On 10/30/24 9:47 PM, Steve Landers wrote:<br/>> Does it mean all of the above or something else?<br/><br/><br/>Depends on the package. A loosely-coupled "nice to have" package like <br/>todbc is not really in the core. A key platform package like registry IS <br/>in the core for all intents and purposes. It is distributed and built <br/>with the core Tcl code. I have floated the idea of adding dbus to the <br/>core in the latter form.<br/><br/>--Kevin<br/><br/>

Re: [TCLCORE] "In the core"

[Steve L. <st...@di...>]

Marc,

I am most definitely not suggesting Tk be removed from TIP control, I just said (in my opinion) that packages under tcl/pkgs need not be under TIP.

Re the relationship between Tcl and Tk, now that Tk is a loadable package there is incentive in increasing its release cadence (e.g. to add themes or adapt to new OS versions more quickly). But IMO a Tcl release should always have a corresponding Tk release and hopefully with the same major.minor version numbers to avoid confusion.

Now, back to the main point of my email - what does “in the core” mean?

-- Steve
On 31 Oct 2024 at 10:30 AM +0800, Marc Culler <cul...@gm...>, wrote:
> I think it would be a very bad idea to not have Tk under TIP control.  Probably that is not what you intended, but you did suggest that packages in tcl/pkgs need not be under TIP control, and then suggest that Tk could become a package in tcl/pkgs.
>
> In any case I think the relationship between Tcl and Tk should stay as it is now.  And I think that has nothing to do with whether the release versions and schedules of Tcl and Tk continue to be maintained in lock step.
>
> - Marc
>
>
> > On Wed, Oct 30, 2024 at 8:48 PM Steve Landers <st...@di...> wrote:
> > > Folks,
> > >
> > > Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.
> > >
> > > Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?
> > >
> > > Does it mean “I want this package to always be available when Tcl is installed?"
> > >
> > > Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"
> > >
> > > Does it mean all of the above or something else?
> > >
> > > Here’s my take ...
> > >
> > > Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).
> > >
> > > We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.
> > >
> > > So what are your thoughts?
> > >
> > > -- Steve
> > > _______________________________________________
> > > Tcl-Core mailing list
> > > Tcl...@li...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] "In the core"

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

I think it would be a very bad idea to not have Tk under TIP control.
Probably that is not what you intended, but you did suggest that packages
in tcl/pkgs need not be under TIP control, and then suggest that Tk could
become a package in tcl/pkgs.

In any case I think the relationship between Tcl and Tk should stay as it
is now.  And I think that has nothing to do with whether the release
versions and schedules of Tcl and Tk continue to be maintained in lock step.

- Marc


On Wed, Oct 30, 2024 at 8:48 PM Steve Landers <st...@di...>
wrote:

> Folks,
>
> Over the years we often hear people ask for something to be “in the core”
> and it’s happening again recently as we start thinking about what comes
> after Tcl 9.0.   But what does “in the core” mean?  I’m interested in
> hearing people’s opinions.
>
> Does it mean “I want this package to be tightly controlled via TIPs” like
> Tcl itself?
>
> Does it mean “I want this package to always be available when Tcl is
> installed?"
>
> Does it mean “I want have confidence that this package can be built and
> installed in a particular Tcl version?"
>
> Does it mean all of the above or something else?
>
> Here’s my take ...
>
> Some packages are foundational and need to be carefully managed and always
> available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps
> others. Does that mean they need to be under TIP control?  Probably not
> albeit we should try not to break the compatibility of packages like http
> and tls.  But what I would greatly appreciate is having a set of packages
> that I could rely upon being present in any Tcl install (unless explicitly
> omitted - such as on memory constrained devices).
>
> We already have a mechanism for this in the tcl/pkgs directory. I would be
> satisfied to see more packages being included in that and perhaps a
> “batteries included” distribution added to the Tcl distribution files.  And
> since we are in parallel talking about decoupling Tk from Tcl we could add
> Tk to tcl/pkgs too.  I realise this might cause heartburn for distro
> maintainers so their input will be vital. And how would we differentiate
> Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But
> directionally I am comfortable with the notion that “in the core” means “in
> tcl/pkgs” except for features that can’t be distributed as a package.
>
> So what are your thoughts?
>
> -- Steve
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

[TCLCORE] "In the core"

[Steve L. <st...@di...>]

Folks,

Over the years we often hear people ask for something to be “in the core” and it’s happening again recently as we start thinking about what comes after Tcl 9.0.   But what does “in the core” mean?  I’m interested in hearing people’s opinions.

Does it mean “I want this package to be tightly controlled via TIPs” like Tcl itself?

Does it mean “I want this package to always be available when Tcl is installed?"

Does it mean “I want have confidence that this package can be built and installed in a particular Tcl version?"

Does it mean all of the above or something else?

Here’s my take ...

Some packages are foundational and need to be carefully managed and always available with a Tcl release: e.g. http (perhaps), tls, thread, perhaps others. Does that mean they need to be under TIP control?  Probably not albeit we should try not to break the compatibility of packages like http and tls.  But what I would greatly appreciate is having a set of packages that I could rely upon being present in any Tcl install (unless explicitly omitted - such as on memory constrained devices).

We already have a mechanism for this in the tcl/pkgs directory. I would be satisfied to see more packages being included in that and perhaps a “batteries included” distribution added to the Tcl distribution files.  And since we are in parallel talking about decoupling Tk from Tcl we could add Tk to tcl/pkgs too.  I realise this might cause heartburn for distro maintainers so their input will be vital. And how would we differentiate Tcl pkgs from Tk pkgs if Tk itself was a pkg (maybe we don’t need to).  But directionally I am comfortable with the notion that “in the core” means “in tcl/pkgs” except for features that can’t be distributed as a package.

So what are your thoughts?

-- Steve

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

Am 29.10.2024 um 11:46 schrieb Jan Nijtmans:
> Advantage: no merge-mark's any more (which were
> always difficult to explain anyway)
To my understanding, a merge mark will still be necessary, if something 
is not ported to 8.7/8.6/8.5.

But fixing something in 9.0 and then pushing it to 8.6 is currently 
difficult and will be easier with reversed merge order.

Thank you,
Harald

[TCLCORE] TIP 701 accepted and merged

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

Vote-Summary:             Accepted 9/0/0

Votes-For:          AK, AN, HO, JD, JN, KW, MC, RA, SL

Votes-Against:  none

Votes-Present: none

 

One caveat. The TIP stated 9.1 as its target pending resolution of whether
the next version would be 9.0.1 or 9.1. Further, there continues to be
confusion in my mind (if no one else's) about 8.7 status and the
implications of its API compatibility with Tcl 9. The code has therefore
been merged into both core-8-branch and trunk.

 

Thanks to those who reviewed and voted.

 

/Ashok 

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

I would definitely prefer prioritizing fixes for 9.0 first. Moreover, at some point in the future backporting should not be mandated for bugs that have a low severity level (leaving aside the question of who determines the severity of a bug!)

 

I am ok with not requiring a TIP but having one would forestall objections.

 

/Ashok

 

From: Jan Nijtmans <jan...@gm...> 
Sent: Tuesday, October 29, 2024 4:16 PM
To: Harald Oehlmann <har...@el...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

 

Op za 26 okt 2024 om 14:54 schreef Harald Oehlmann:

Possible points:
...
- what is the new merge strategy core-8-6branch->core-8-branch-main or 
may we revert this?

 

We didn't discuss this in the meeting, but ... I think we should reverse

the merge-order. Since 8.6 and 8.7 have less attention, it's not logical

to be forced to implement Tcl 9.0 bug-fixes on 8.6 (or 8.7) first.

 

Example: Ticket 7677029cd9

    Tk Source Code: View Ticket <https://core.tcl-lang.org/tk/tktview/7677029cd9> 

The fix is initially created for 9.0, but should (eventually) be

backported to 8.7, or not. Reversing the merge order allows

us to focus on the fix, and worry about an eventual

backport later.

 

Should I write a TIP on this? Or can we simply agree on it,

write out a message and continue?

 

Advantage: no merge-mark's any more (which were

always difficult to explain anyway)

 

Regards,

   Jan Nijtmans

 

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

Op di 29 okt 2024 om 12:14 schreef Harald Oehlmann:

> Am 29.10.2024 um 11:46 schrieb Jan Nijtmans:
> > We didn't discuss this in the meeting, but ... I think we should reverse
> > the merge-order. Since 8.6 and 8.7 have less attention, it's not logical
> > to be forced to implement Tcl 9.0 bug-fixes on 8.6 (or 8.7) first.
> I would agree on it and document it on the TCL/Tk fossil wiki
>

And as TIP #386 addendum.
    Tcl Improvement Proposals: Check-in [1ee88e8ff7]
<https://core.tcl-lang.org/tips/info/1ee88e8ff7980292>
I think TIP #386 is the only place the current
merge-order is documented.

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

Am 29.10.2024 um 11:46 schrieb Jan Nijtmans:
> Op za 26 okt 2024 om 14:54 schreef Harald Oehlmann:
> 
>     Possible points:
>     ...
>     - what is the new merge strategy core-8-6branch->core-8-branch-main or
>     may we revert this?
> 
> 
> We didn't discuss this in the meeting, but ... I think we should reverse
> the merge-order. Since 8.6 and 8.7 have less attention, it's not logical
> to be forced to implement Tcl 9.0 bug-fixes on 8.6 (or 8.7) first.
> 
> Example: Ticket 7677029cd9
> Tk Source Code: View Ticket <https://core.tcl-lang.org/tk/ 
> tktview/7677029cd9>
> The fix is initially created for 9.0, but should (eventually) be
> backported to 8.7, or not. Reversing the merge order allows
> us to focus on the fix, and worry about an eventual
> backport later.
> 
> Should I write a TIP on this? Or can we simply agree on it,
> write out a message and continue?
> 
> Advantage: no merge-mark's any more (which were
> always difficult to explain anyway)
> 
> Regards,
>     Jan Nijtmans
I would agree on it and document it on the TCL/Tk fossil wiki

Great proposal, thanks,
Harald

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

Op za 26 okt 2024 om 14:54 schreef Harald Oehlmann:

> Possible points:
> ...
> - what is the new merge strategy core-8-6branch->core-8-branch-main or
> may we revert this?
>

We didn't discuss this in the meeting, but ... I think we should reverse
the merge-order. Since 8.6 and 8.7 have less attention, it's not logical
to be forced to implement Tcl 9.0 bug-fixes on 8.6 (or 8.7) first.

Example: Ticket 7677029cd9
    Tk Source Code: View Ticket
<https://core.tcl-lang.org/tk/tktview/7677029cd9>
The fix is initially created for 9.0, but should (eventually) be
backported to 8.7, or not. Reversing the merge order allows
us to focus on the fix, and worry about an eventual
backport later.

Should I write a TIP on this? Or can we simply agree on it,
write out a message and continue?

Advantage: no merge-mark's any more (which were
always difficult to explain anyway)

Regards,
   Jan Nijtmans

Re: [TCLCORE] Monday noon TCL/Tk meeting report

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

Dear Kevin,
thank you, I appreciate! This is really a long wanted and very useful 
feature and a big load of work. You are always taking the difficult 
ones, like the printing support in the past...

Thanks for Tk. Don wants to pass the message, that if Tk feels ready, it 
may do interim releases at any time.
Specially the Mac platform is subject of heavy changes. If Mark and team 
feels time for an additional release, please give a sign.
Also the other highly appreciated Tk developers - Francois, Csaba, are 
invited.
Thank you for all the great work,
Harald

Am 28.10.2024 um 18:09 schrieb Kevin Walzer:
> I will help as I am able, but my limited time for the foreseeable future
> is going to be invested in implementing a long-requested missing feature
> in Tk: accessibility/screen reader support across all three platforms
> (using Accessibility on the Mac, MSAA on Windows, and ATK on Linux).
> It's in the very early stages now, but the goal is to add basic
> accessibility support "for free" and with an API for more
> detailed/customized support if a developer wants - or, for instance, if
> a developer wants to add this to widgets outside the core.
> 
> There's very little sample code out there that can be adapted for this
> project, so I will mostly be doing it from scratch. Once a rough version
> is available across all three platforms, I'll invite testing and submit
> a TIP, but that is many months away.
> 
> --Kevin
> 
> On 10/28/24 9:33 AM, Harald Oehlmann wrote:
>  > R6) Decoupling of TCL and Tk release
>  >   - There is a strong support to decouple TCL and Tk (minor) releases
>  >   - Don is ready to release Tk separately at any time
>  >   - Major Tk people were missing in the call
>  >   - Eventually own infra-structure: TIP, Team
>  >   It would be great to build-up a Tk team and a working way.
>  >   Any people for a task force?

Re: [TCLCORE] Monday noon TCL/Tk meeting report

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

<div><img width="1" height="1" src='https://fedbdhd.r.bh.d.sendibt3.com/tr/op/BGjjY2lprZB-W2M8DjEN38Nw8HrQLrwcejImxzCSJ59pov1d_VSRm51hTBf7cBYE0D6wOXAbV5zL2Qzd5iScbHxMX8BP-xhxSuTOvRCKEjhNW0sYztAmTdO_seEdj7Mm3ymLVyMsG5NJkclLR90d08BhJRCvhPWi-kblqTcgceAa24RMPZUG6-HypbZRTPRuaPl3lVfaN9YQp8ZB_Tp2P0tmu8HrpcBM' /></div>I will help as I am able, but my limited time for the foreseeable future <br/>is going to be invested in implementing a long-requested missing feature <br/>in Tk: accessibility/screen reader support across all three platforms <br/>(using Accessibility on the Mac, MSAA on Windows, and ATK on Linux). <br/>It's in the very early stages now, but the goal is to add basic <br/>accessibility support "for free" and with an API for more <br/>detailed/customized support if a developer wants - or, for instance, if <br/>a developer wants to add this to widgets outside the core.<br/><br/>There's very little sample code out there that can be adapted for this <br/>project, so I will mostly be doing it from scratch. Once a rough version <br/>is available across all three platforms, I'll invite testing and submit <br/>a TIP, but that is many months away.<br/><br/>--Kevin<br/><br/>On 10/28/24 9:33 AM, Harald Oehlmann wrote:<br/>> R6) Decoupling of TCL and Tk release<br/>>   - There is a strong support to decouple TCL and Tk (minor) releases<br/>>   - Don is ready to release Tk separately at any time<br/>>   - Major Tk people were missing in the call<br/>>   - Eventually own infra-structure: TIP, Team<br/>>   It would be great to build-up a Tk team and a working way.<br/>>   Any people for a task force? <br/>

[TCLCORE] Monday noon TCL/Tk meeting report

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

Dear TCL/Tk/OpenACS/Naviserver team,

we had a great meeting today with: Don, Jan, Rolf, Paul, Brian, Massimo, 
Ashok, Andreas Kupries, Andreas Leitgreb, Mark, Steve, Harald.

The results are:

R1) TCL/Tk 9.0.0 release is great ! Thanks for all contributors !

R2) TCL/Tk 9.0.1 is the next step
   - release process starts in December 2024
   - developed in main branches
   - address double-distribution of 8.6 and 9.0 by Linux maintainers
   - TIP 701 (tilde API) included
   - TIP 700 (MD documentation) eventually started

R3) TCL 8.6 support
   - proposed support time: until end 2025
   - all major packages and distributions should be ported to 9.0
   - but some will only switch, if 8.6 declared as unsupported
   - specially Tk 9 offers so much practical value, that Tk8.6 is seen 
as obsolete (scaled interface, updated themes)
   - no new features for 8.6, sorry, only bug back-porting

R4) TCL 8.7 release
   - discussion point
   - most just want to focus on 9.0
   - 8.6 is easy for migration for 8.6 packages:
     - TCL_CHAR size with 16 bit interface is available
     - TCL_CHAR size with 32 bit interface (like 9.0) is also available
     - No surrogates (like 8.6.11+)
   - 8.7 is better than 8.6 as compatible 9.0 extensions are included 
(full Unicode)
   - major player like AndroWish are supposed to directly go to 9.0
   - if released, 8.6 should be taken out of maintenance to avoid 
double-burden
   - first possible release in 1 year. All bugfixes of 9.0 are 
back-ported, so 8.7. is getting better
   - Debian co-maintainer pointed out, that distributions do not have 
resources for multiple versions. So, only one version is best, max 2, not 3.

R5) TCL 9.1 release
   - will be started when 9.0 is stable (not now)
   - TIP 626 (long number of command arguments) is binary incompatible 
and will wait for 9.1
   - now we have long strings and lists, we should work on its performance.
   - decodings currently also have performance issues and are sometimes 
issued multiple times
   - drop support for ITCL

R6) Decoupling of TCL and Tk release
   - There is a strong support to decouple TCL and Tk (minor) releases
   - Don is ready to release Tk separately at any time
   - Major Tk people were missing in the call
   - Eventually own infra-structure: TIP, Team
   It would be great to build-up a Tk team and a working way.
   Any people for a task force?

R7) Documentation
   - The new documentation project is seen as important to get wider 
audience
   - Help is proposed to advance - Torsten must not do all the work

R8) Extensions
   - Porting all extensions to 9 is a main step to put energy in
   - Get tests for larger strings/lists
   - make valgrind cleaner for extensions
   - Massimo is the Debian maintainer for TDBC. He proposed (before) to 
be the tdbc packages maintainer. I would say: yes, just do it, great, 
applause!

It is proposed to repeat those meetings each two weeks on Mondays at 
12:00 UTC. The next meeting will take place 11th of November 2025.

Thank you all, you guys rock !
Harald

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

[Steve L. <st...@di...>]

I’m in

-- Steve
On 27 Oct 2024 at 1:44 AM +0800, Paul Obermeier <pa...@po...>, wrote:
> I plan to attend.
> Paul
>
> Am 26.10.2024 um 14:53 schrieb Harald Oehlmann:
> > Dear TCL/Tk team,
> >
> > a friendly reminder about the upcoming TCL/Tk planning meeting next Monday 28th at 12:00 UTC for 1 hour.
> > Only Ashok confirmed his presence.
> >
> > The agenda is to answer the question "what is next in Tcl/Tk"?
> > Possible points:
> > - what is the next version for bugfixes and features?
> > - what is the new merge strategy core-8-6branch->core-8-branch-main or may we revert this?
> > - current open issues?
> >   - zip file system?
> > - next changes?
> > The agenda is generally open, others may propose items.
> >
> > It is on the TCL meetup jitsi:
> > https://meet.jit.si/TclMonthlyMeetup
> >
> > THank you for all,
> > Harald
> >
> >
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

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

I plan to attend.
Paul

Am 26.10.2024 um 14:53 schrieb Harald Oehlmann:
> Dear TCL/Tk team,
>
> a friendly reminder about the upcoming TCL/Tk planning meeting next Monday 28th at 12:00 UTC for 1 hour.
> Only Ashok confirmed his presence.
>
> The agenda is to answer the question "what is next in Tcl/Tk"?
> Possible points:
> - what is the next version for bugfixes and features?
> - what is the new merge strategy core-8-6branch->core-8-branch-main or may we revert this?
> - current open issues?
>   - zip file system?
> - next changes?
> The agenda is generally open, others may propose items.
>
> It is on the TCL meetup jitsi:
> https://meet.jit.si/TclMonthlyMeetup
>
> THank you for all,
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TCL/Tk planning meeting on Monday 28th at 12:00 UTC

[Brian G. <bri...@ea...>]

I plan on attending. 

-Brian
(from mobile device)

> On Oct 26, 2024, at 05:54, Harald Oehlmann <har...@el...> wrote:
> 
> Dear TCL/Tk team,
> 
> a friendly reminder about the upcoming TCL/Tk planning meeting next Monday 28th at 12:00 UTC for 1 hour.
> Only Ashok confirmed his presence.
> 
> The agenda is to answer the question "what is next in Tcl/Tk"?
> Possible points:
> - what is the next version for bugfixes and features?
> - what is the new merge strategy core-8-6branch->core-8-branch-main or may we revert this?
> - current open issues?
>  - zip file system?
> - next changes?
> The agenda is generally open, others may propose items.
> 
> It is on the TCL meetup jitsi:
> https://meet.jit.si/TclMonthlyMeetup
> 
> THank you for all,
> Harald
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
> <OpenPGP_signature.asc>