Re: [H-source-users] adapting h-client for python3/GTK3

[bill-auger]

On Mon, 04 Oct 2021 21:07:16 +1100 Yuchen wrote:
> Yeah, every commit should compile unless there's some compelling 
> reason for it not to compile.

the compelling reason in this case, is that the alternative
would make it much more difficult to review, and that the
separations i made, make for much better documentation than a
huge non-breaking change

the breaking commits could be squashed after review; but for the
sake of clarity, i would not conflate them - TBH, while deciding
how to partition them, i imagined that someday in the future,
when porting some other python2 program, i (and any unforeseen
others) may want to refer to those categorized changes for
inspiration


On Mon, 04 Oct 2021 21:07:16 +1100 Yuchen wrote:
> Cool, let's keep it simple and have the h-client under the 
> h-source tree for now.  I'll update descriptions of the repo and 
> the mailing list.

i wold be in favor of multiple repos under the same project, as
opposed to multiple logical projects in different directories of
the same VCS - we only would need to ask the admins to create
the new repo - we should probably ask them to destroy the old
h-client project anyways, and move the h-client SVN repo over to
the h-source project, to keep for historical reasons

also, i believe that you can not update the repo description - i
think we would need to ask the admins to do that too

but, there is no urgency to do anything with the h-client code
now, other than review it, then rebase it - only after that,
would i bother the admins to reorganize things


On Mon, 04 Oct 2021 21:07:16 +1100 Yuchen wrote:
> I'm not sure if we should have multiple mailing lists.
> the mailing list is pretty low volume.
>
> I feel having two lists is only going to fragment and slow 
> down the communication.

i was not suggesting multiple mailing lists - this is clearly a
help support list for users though ('h-source-users') - people
generally expect the list name to be meaningful

you are essentially saying that this project does not need a
users mailing list - in that case, we should stop using this
list - if there is to be only one mailing list, and it is to be
used for development discussions, then it's name should reflect
that ('h-source-dev' for example)

people generally assume that development discussions would be
off-topic on a list named 'foo-users', and that user help
support questions would be off-topic on a list named 'foo-devel'


On Mon, 04 Oct 2021 21:07:16 +1100 Yuchen wrote:
> I think it makes sense to have all discussions on 
> the mailing list when there is more than one person participating. 

there is - of course if only one sane person is participating in
the discussion, well, its not actually a "discussion" anyways :)


On Mon, 04 Oct 2021 21:07:16 +1100 Yuchen wrote:
> When it is "single player" like the past month or so, just using 
> the bug tracker makes sense

id have to disagree there - an issue tracker is not a discussion
forum - it is for confirmed work items and bug reports (which
are likely to graduate directly into work items) - if arbitrary
discussions are mixed with actual work items, both become more
difficult to locate in the future

perhaps some may find it more convenient (to effectively
converse with oneself on the web); but that is essentially
conceding that only one person in the world is interested in that
project - its kinda moot as an organizational plan - that one
person may as well scribble notes on napkins

no one should think of oneself as a "single player" WRT free
software projects - you never know what may change in the future
- you never know how many people are using the software, neither
today nor 10 years from now - likewise, how many are, or will be,
interested in reading the bug reports _or_ dev discussions,
(emphasis on the _or_ - not everyone wants to read both)

in other words, bug reports, work tickets, and dev discussions
are not only relevant for the time they are written - they are
documentation for the future too - if the latter is not in mind
at the time of writing, they will be much less useful as a form
of documentation