[sage-devel] Re: Trac #34152 needs you (to vote)!

[François Bissey]

The vote is now closed.
Hybrid:  8 top votes
pseudo-package: 2 top votes
copy: 0 top votes

Thanks to all voters.

François
On Wednesday, August 24, 2022 at 11:38:40 AM UTC+12 François Bissey wrote:

> Hi all,
>
> https://trac.sagemath.org/ticket/34152 needs help to decide what solution 
> we implement going forward.
>
> The ticket is concerned with updating the bootstrap process by removing 
> the current need for gettext and replacing it with gnulib (
> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
> library but a collection of bits and pieces to help portability across 
> platforms.
>
> The issue at hand is how do we include and use gnulib in sagemath.
> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and 
> across most of the ~250 comments of the ticket about the way to proceed. At 
> some point it became clear that they would not agree and would need 
> arbitration. This is what this post is about, I am inviting the sagemath 
> community to weigh in and decide the issue.
>
> The ticket summary has been updated with summaries of the problem and of 
> both options along with links to branches implementing them. I would not 
> recommend diving in the comment section.
>
> There are 3 (three) options to choose from, one from Matthias, one from 
> Dima and a hybrid approach they tried to create.
>
> -- copy files --
>
>- Follows approach 3 of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>.
>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>using `gnulib-tool import iconv` 
> 
> and 
>committed to the branch.
>- Matches our practice with imported files `m4/ax_*.m4` 
> from 
>autoconf-archive 
>. 
>Different from our practice with SPKGs because the files are needed to 
>generate the configure script.
>- Introduces no new dependency.
>- Burden on a developer who authors an update ticket for these files: 
>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>remove unneeded files (that's where #29549 
> went wrong), commit the 
>changes. (Updates are expected to be necessary only very rarely.)
>- Burden on users and other developers: None.
>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>code, it has no place in Sage git tree; this way, updating the imported 
>gnulib files is tricky and error-prone by design".
>
> -- sage pseudo package --
>
>- Follows approach 2(C) of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>, 
>but instead of using Gnulib's Programs for developing in Git checkouts 
>
> , 
>implements its own script (making checkout much faster, as full gnulib 
> checkout 
>is 250 MB).
>- Introduces a new (although one can't really do Sage development 
>without git installed) dependency on git and on availability of 
>internet connection at the first run of ./bootstrap in a tree, to pull 
>83 MB (fair to say that internet is needed for Sage development a lot, 
>anyway).
>- Burden on a developer who authors an update ticket for these files: 
>Edit the bootstrap file to change the commit hash, verify that the 
>list of files removed by make bootstrap-clean is still correct, commit 
>this change
>- Burden on other users: a pseudo-package needs to be installed once 
>(and updated, automatically)
>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>multi-megabyte git clone (on the 1st install and when there's a change of 
>the gnulib commit hash) in the upstream/ directory increases 
>complexity for no benefit."
>
> -- hybrid --
>
>- Resolves the criticism on the "copy files" approach: "updating the 
>imported gnulib files" is now assisted by the spkg-src script (adapted 
>from dimpase's branch)
>- Resolves the criticism on the "Sage pseudo-package" approach: 
>"operate a multi-megabyte git clone (on the 1st install and when there's a 
>change of the gnulib commit hash)" is only done by authors of tickets that 
>update gnulib, not by general users of bootstrap.
>
> Vote is open now and will close - tentatively - on the 29th of August at 
> 12pm New Zealand time [my time zone] when I will do the tally. If no option 
> gets a majority, the voting period may be extended by a few days.
> Please vote!
> [ ] copy files
> [ ] sage pseudo package
> [ ] hybrid
>
>
>

-- 
You received this message because 

[sage-devel] Re: Trac #34152 needs you (to vote)!

[Marc Culler]

If I am allowed to vote, my vote is hybrid > copy files > pseudo package.

- Marc

On Tuesday, August 23, 2022 at 6:38:40 PM UTC-5 François Bissey wrote:

> Hi all,
>
> https://trac.sagemath.org/ticket/34152 needs help to decide what solution 
> we implement going forward.
>
> The ticket is concerned with updating the bootstrap process by removing 
> the current need for gettext and replacing it with gnulib (
> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
> library but a collection of bits and pieces to help portability across 
> platforms.
>
> The issue at hand is how do we include and use gnulib in sagemath.
> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and 
> across most of the ~250 comments of the ticket about the way to proceed. At 
> some point it became clear that they would not agree and would need 
> arbitration. This is what this post is about, I am inviting the sagemath 
> community to weigh in and decide the issue.
>
> The ticket summary has been updated with summaries of the problem and of 
> both options along with links to branches implementing them. I would not 
> recommend diving in the comment section.
>
> There are 3 (three) options to choose from, one from Matthias, one from 
> Dima and a hybrid approach they tried to create.
>
> -- copy files --
>
>- Follows approach 3 of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>.
>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>using `gnulib-tool import iconv` 
> 
> and 
>committed to the branch.
>- Matches our practice with imported files `m4/ax_*.m4` 
> from 
>autoconf-archive 
>. 
>Different from our practice with SPKGs because the files are needed to 
>generate the configure script.
>- Introduces no new dependency.
>- Burden on a developer who authors an update ticket for these files: 
>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>remove unneeded files (that's where #29549 
> went wrong), commit the 
>changes. (Updates are expected to be necessary only very rarely.)
>- Burden on users and other developers: None.
>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>code, it has no place in Sage git tree; this way, updating the imported 
>gnulib files is tricky and error-prone by design".
>
> -- sage pseudo package --
>
>- Follows approach 2(C) of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>, 
>but instead of using Gnulib's Programs for developing in Git checkouts 
>
> , 
>implements its own script (making checkout much faster, as full gnulib 
> checkout 
>is 250 MB).
>- Introduces a new (although one can't really do Sage development 
>without git installed) dependency on git and on availability of 
>internet connection at the first run of ./bootstrap in a tree, to pull 
>83 MB (fair to say that internet is needed for Sage development a lot, 
>anyway).
>- Burden on a developer who authors an update ticket for these files: 
>Edit the bootstrap file to change the commit hash, verify that the 
>list of files removed by make bootstrap-clean is still correct, commit 
>this change
>- Burden on other users: a pseudo-package needs to be installed once 
>(and updated, automatically)
>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>multi-megabyte git clone (on the 1st install and when there's a change of 
>the gnulib commit hash) in the upstream/ directory increases 
>complexity for no benefit."
>
> -- hybrid --
>
>- Resolves the criticism on the "copy files" approach: "updating the 
>imported gnulib files" is now assisted by the spkg-src script (adapted 
>from dimpase's branch)
>- Resolves the criticism on the "Sage pseudo-package" approach: 
>"operate a multi-megabyte git clone (on the 1st install and when there's a 
>change of the gnulib commit hash)" is only done by authors of tickets that 
>update gnulib, not by general users of bootstrap.
>
> Vote is open now and will close - tentatively - on the 29th of August at 
> 12pm New Zealand time [my time zone] when I will do the tally. If no option 
> gets a majority, the voting period may be extended by a few days.
> Please vote!
> [ ] copy files
> [ ] sage pseudo package
> [ ] hybrid
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[Dima Pasechnik]

On Wed, 24 Aug 2022, 03:49 Nils Bruin,  wrote:

> hybrid.
>
> [it provides an immediate solution to an urgent problem *and* it provides
> a reasonably automated path for updating. It does indeed put some files
> under sage git control that shouldn't be, but compared to the urgency of
> the problem at the moment, that's minor.
>
> It looks to me that avoiding the git control problem requires there to be
> a tarball to point at if we don't want to insist on git as a prereq for
> building from source.
>
Since that tarball does not exist, we'd need to make it. We did that in the
> past for nearly all the spkgs. We'd basically need to have a separate repo
> somewhere "gnulib-for-sagemath" that maintains a tool to extract and
> package the required files for sagemath in an appropriate package and then
> host that resulting package (a tarball, I presume) somewhere. We'd just
> make a derivative of gnulib that DOES have tarball releases. On itself,
> that sounds like it could have merit, but one would weigh that against the
> cost. On the plus side: once the tarball is up, it would likely not change
> for *many* years. Only when we run into trouble would one have to pull the
> lever to generate a new release.
>

we can of course do this, in sagemath org on github. We don't need to do
anything to gnulib source.
It is very little work - just put a gnulib clone there and make a (GitHub)
release.

Updating it is just refreshing the GitHub fork, and making a new Github
release.



>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/d571b46b-d973-4453-ae97-aa76c36cd676n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq195xG%3DoSt%2BfydeYoJX2MnTPnhBBZUzjrZKo6CNSwV%3D0g%40mail.gmail.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[Dima Pasechnik]

On Wed, 24 Aug 2022, 01:43 Matthias Koeppe, 
wrote:

> On Tuesday, August 23, 2022 at 5:34:01 PM UTC-7 Travis Scrimshaw wrote:
>
>> I also fully agree with Dima that gnulib has no business being in Sage's
>> git tree
>>
>
> This is a mischaracterization. None of the approaches puts "gnulib in the
> Sage git tree". I recommend to read the discussion on the ticket.
>
Not the whole gnulib, yet
only sage pseudo package solution does not inject parts of gnulib into Sage
git tree (the other two do inject about 100K of gnulib)



>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/CAAWYfq35-gRM88_gE%2BTPM%2BObdDocPtuv6x8cORyzgEHJR_u-Kg%40mail.gmail.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[Nils Bruin]

hybrid.

[it provides an immediate solution to an urgent problem *and* it provides a 
reasonably automated path for updating. It does indeed put some files under 
sage git control that shouldn't be, but compared to the urgency of the 
problem at the moment, that's minor.

It looks to me that avoiding the git control problem requires there to be a 
tarball to point at if we don't want to insist on git as a prereq for 
building from source. Since that tarball does not exist, we'd need to make 
it. We did that in the past for nearly all the spkgs. We'd basically need 
to have a separate repo somewhere "gnulib-for-sagemath" that maintains a 
tool to extract and package the required files for sagemath in an 
appropriate package and then host that resulting package (a tarball, I 
presume) somewhere. We'd just make a derivative of gnulib that DOES have 
tarball releases. On itself, that sounds like it could have merit, but one 
would weigh that against the cost. On the plus side: once the tarball is 
up, it would likely not change for *many* years. Only when we run into 
trouble would one have to pull the lever to generate a new release.


-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/d571b46b-d973-4453-ae97-aa76c36cd676n%40googlegroups.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[John H Palmieri]

hybrid > copy files > pseudo package


On Tuesday, August 23, 2022 at 5:56:01 PM UTC-7 Kwankyu Lee wrote:

> hybrid
>
> Hearty thanks for setting up the vote.
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/f7aa23f9-634b-4158-92ee-826166c4227fn%40googlegroups.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[Kwankyu Lee]

hybrid

Hearty thanks for setting up the vote.

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8f405fcb-3af7-4947-8395-fcc98d943e01n%40googlegroups.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[Matthias Koeppe]

On Tuesday, August 23, 2022 at 5:47:04 PM UTC-7 François Bissey wrote:

> In the interest of clarity and ease of counting for me, can we keep the 
> thread onto votes and possibly voting issues. 
>
> Arguments should go back to the ticket or a separate thread please.
>
 
+1

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/c89842d8-ef20-4f3e-b629-35e51c8fb48dn%40googlegroups.com.

Re: [sage-devel] Re: Trac #34152 needs you (to vote)!

[François Bissey]

In the interest of clarity and ease of counting for me, can we keep the 
thread onto votes and possibly voting issues.


Arguments should go back to the ticket or a separate thread please.

François

On 24/08/22 12:43, Matthias Koeppe wrote:

On Tuesday, August 23, 2022 at 5:34:01 PM UTC-7 Travis Scrimshaw wrote:

I also fully agree with Dima that gnulib has no business being in
Sage's git tree


This is a mischaracterization. None of the approaches puts "gnulib in 
the Sage git tree". I recommend to read the discussion on the ticket.


--
You received this message because you are subscribed to the Google 
Groups "sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to sage-devel+unsubscr...@googlegroups.com 
.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com 
.


--
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/08667017-53fa-a087-307e-d3672e9d842f%40gmail.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

[Matthias Koeppe]

On Tuesday, August 23, 2022 at 5:34:01 PM UTC-7 Travis Scrimshaw wrote:

> I also fully agree with Dima that gnulib has no business being in Sage's 
> git tree
>

This is a mischaracterization. None of the approaches puts "gnulib in the 
Sage git tree". I recommend to read the discussion on the ticket.

 

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/dc9d3f46-389e-48f5-9110-1e782dd1bfb9n%40googlegroups.com.

[sage-devel] Re: Trac #34152 needs you (to vote)!

['Travis Scrimshaw' via sage-devel]

hybrid > sage psuedo > copy files package

I think we should be mindful that there can be people who build from source 
who are not developers. So not having a dependency on git is a small bonus, 
but I think almost everyone who has a non-Windows machine has git installed 
on their computer by default. I also fully agree with Dima that gnulib has 
no business being in Sage's git tree, and if I understand the hybrid 
approach, it remains separate as a separate (cloned) git repo.

Best,
Travis


On Wednesday, August 24, 2022 at 9:04:58 AM UTC+9 Matthias Koeppe wrote:

> Thanks for sending out the poll, Francois.
>
> I endorse the "hybrid" variant.
>
> On Tuesday, August 23, 2022 at 4:38:40 PM UTC-7 François Bissey wrote:
>
>> Hi all,
>>
>> https://trac.sagemath.org/ticket/34152 needs help to decide what 
>> solution we implement going forward.
>>
>> The ticket is concerned with updating the bootstrap process by removing 
>> the current need for gettext and replacing it with gnulib (
>> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
>> library but a collection of bits and pieces to help portability across 
>> platforms.
>>
>> The issue at hand is how do we include and use gnulib in sagemath.
>> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks 
>> and across most of the ~250 comments of the ticket about the way to 
>> proceed. At some point it became clear that they would not agree and would 
>> need arbitration. This is what this post is about, I am inviting the 
>> sagemath community to weigh in and decide the issue.
>>
>> The ticket summary has been updated with summaries of the problem and of 
>> both options along with links to branches implementing them. I would not 
>> recommend diving in the comment section.
>>
>> There are 3 (three) options to choose from, one from Matthias, one from 
>> Dima and a hybrid approach they tried to create.
>>
>> -- copy files --
>>
>>- Follows approach 3 of the Gnulib manual section 'Integration with 
>>Version Control Systems' 
>>
>>.
>>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>>using `gnulib-tool import iconv` 
>>
>>  
>> and 
>>committed to the branch.
>>- Matches our practice with imported files `m4/ax_*.m4` 
>> from 
>>autoconf-archive 
>>. 
>>Different from our practice with SPKGs because the files are needed to 
>>generate the configure script.
>>- Introduces no new dependency.
>>- Burden on a developer who authors an update ticket for these files: 
>>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>>remove unneeded files (that's where #29549 
>> went wrong), commit the 
>>changes. (Updates are expected to be necessary only very rarely.)
>>- Burden on users and other developers: None.
>>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>>code, it has no place in Sage git tree; this way, updating the imported 
>>gnulib files is tricky and error-prone by design".
>>
>> -- sage pseudo package --
>>
>>- Follows approach 2(C) of the Gnulib manual section 'Integration 
>>with Version Control Systems' 
>>, 
>>but instead of using Gnulib's Programs for developing in Git checkouts 
>>
>> , 
>>implements its own script (making checkout much faster, as full gnulib 
>> checkout 
>>is 250 MB).
>>- Introduces a new (although one can't really do Sage development 
>>without git installed) dependency on git and on availability of 
>>internet connection at the first run of ./bootstrap in a tree, to 
>>pull 83 MB (fair to say that internet is needed for Sage development a 
>> lot, 
>>anyway).
>>- Burden on a developer who authors an update ticket for these files: 
>>Edit the bootstrap file to change the commit hash, verify that the 
>>list of files removed by make bootstrap-clean is still correct, 
>>commit this change
>>- Burden on other users: a pseudo-package needs to be installed once 
>>(and updated, automatically)
>>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>>multi-megabyte git clone (on the 1st install and when there's a change of 
>>the gnulib commit hash) in the upstream/ directory increases 
>>complexity for no benefit."
>>
>> -- hybrid --
>>
>>- Resolves the criticism on the "copy files" approach: "updating the 
>>imported gnulib files" is now assisted by the spkg-src script 
>>(adapted from dimpase's 

[sage-devel] Re: Trac #34152 needs you (to vote)!

[Matthias Koeppe]

Thanks for sending out the poll, Francois.

I endorse the "hybrid" variant.

On Tuesday, August 23, 2022 at 4:38:40 PM UTC-7 François Bissey wrote:

> Hi all,
>
> https://trac.sagemath.org/ticket/34152 needs help to decide what solution 
> we implement going forward.
>
> The ticket is concerned with updating the bootstrap process by removing 
> the current need for gettext and replacing it with gnulib (
> https://www.gnu.org/software/gnulib). gnulib is not a regular software 
> library but a collection of bits and pieces to help portability across 
> platforms.
>
> The issue at hand is how do we include and use gnulib in sagemath.
> Matthias Koeppe and Dima Pasechnik have been arguing for several weeks and 
> across most of the ~250 comments of the ticket about the way to proceed. At 
> some point it became clear that they would not agree and would need 
> arbitration. This is what this post is about, I am inviting the sagemath 
> community to weigh in and decide the issue.
>
> The ticket summary has been updated with summaries of the problem and of 
> both options along with links to branches implementing them. I would not 
> recommend diving in the comment section.
>
> There are 3 (three) options to choose from, one from Matthias, one from 
> Dima and a hybrid approach they tried to create.
>
> -- copy files --
>
>- Follows approach 3 of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>.
>- 5 files, in config/ and m4/, total 112 KB, have been imported by 
>using `gnulib-tool import iconv` 
> 
> and 
>committed to the branch.
>- Matches our practice with imported files `m4/ax_*.m4` 
> from 
>autoconf-archive 
>. 
>Different from our practice with SPKGs because the files are needed to 
>generate the configure script.
>- Introduces no new dependency.
>- Burden on a developer who authors an update ticket for these files: 
>Obtain gnulib by cloning the repo, then re-run gnulib-tool import, 
>remove unneeded files (that's where #29549 
> went wrong), commit the 
>changes. (Updates are expected to be necessary only very rarely.)
>- Burden on users and other developers: None.
>- dimpase's criticism of this approach: "gnulib's code is not Sage's 
>code, it has no place in Sage git tree; this way, updating the imported 
>gnulib files is tricky and error-prone by design".
>
> -- sage pseudo package --
>
>- Follows approach 2(C) of the Gnulib manual section 'Integration with 
>Version Control Systems' 
>, 
>but instead of using Gnulib's Programs for developing in Git checkouts 
>
> , 
>implements its own script (making checkout much faster, as full gnulib 
> checkout 
>is 250 MB).
>- Introduces a new (although one can't really do Sage development 
>without git installed) dependency on git and on availability of 
>internet connection at the first run of ./bootstrap in a tree, to pull 
>83 MB (fair to say that internet is needed for Sage development a lot, 
>anyway).
>- Burden on a developer who authors an update ticket for these files: 
>Edit the bootstrap file to change the commit hash, verify that the 
>list of files removed by make bootstrap-clean is still correct, commit 
>this change
>- Burden on other users: a pseudo-package needs to be installed once 
>(and updated, automatically)
>- mkoeppe's criticism of this approach: "Having bootstrap operate a 
>multi-megabyte git clone (on the 1st install and when there's a change of 
>the gnulib commit hash) in the upstream/ directory increases 
>complexity for no benefit."
>
> -- hybrid --
>
>- Resolves the criticism on the "copy files" approach: "updating the 
>imported gnulib files" is now assisted by the spkg-src script (adapted 
>from dimpase's branch)
>- Resolves the criticism on the "Sage pseudo-package" approach: 
>"operate a multi-megabyte git clone (on the 1st install and when there's a 
>change of the gnulib commit hash)" is only done by authors of tickets that 
>update gnulib, not by general users of bootstrap.
>
> Vote is open now and will close - tentatively - on the 29th of August at 
> 12pm New Zealand time [my time zone] when I will do the tally. If no option 
> gets a majority, the voting period may be extended by a few days.
> Please vote!
> [ ] copy files
> [ ] sage pseudo package
> [ ] hybrid
>
>
>

-- 
You received this message because you are subscribed to the Google Groups