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

[bill-auger]

On Thu, 05 Aug 2021 15:13:12 +1000 Yuchen wrote:
> Can you mail the patches for review?

i could do that; but then again, so could anyone - the
problem is, these are not like a minor change which would be
easily grokked in an email though - it is a numerous and tightly
couple patch-set - its 30+ commits now, probably 20 after
squashing; so youre asking for at least 20 patch files - the
changes are sorted (essentially arbitrary) by category (all print
statements), meaning that none of them are meaningful alone; and
the program may not even compile at some of the change points -
it would be _much_ easier to review them on the pagure website

o/c some people would recommend to never do that (every commit
should compile); but the only alternative for such massive
breaking changes like this, is one massive patch (which is cruel
to reviewers) - once reviewed, i may even add warnings to each
intermediate "WIP" commit message like:

 "this is a broken WIP - working toward tag v0.0.0pre1"


> Damien Zammit writes:
> > h-source repo contains:
> >    h-client  h-source  scripts
> >
> > Why don't we commit the latest version of h-client under 
> > h-source/h-client on savannah?
> >
> > Or if we are going to maintain two repos, should we delete the 
> > old h-source/h-client folder and push the commits for h-client
> > to the h-client savannah repo?  

either is fine by me - there is no technical reason to merge
them - they share no code, for example - any benefit would be
purely workflow/maintenance related - the client repo could
actually remain separate _and_ grafted onto the server tree as a
sub-tree - alternatively, bob told us that savannah projects
support multiple repo per-project - that seems like the ideal
plan: a single project with two repos and shared mailing lists -
we would only need to create a new dev list and start using it

i would put that decision at a very low priority today - i
suggest deferring it entirely, to accommodate the more important
decision of where is the bug tracker and mailing lists will be -
this ('h-source-users') is very clearly a 'help' list
for user support - there should be a separate 'dev' list -
h-client has one - i suppose we could simply re-use that one,
even if we are going to abandon the savannah project

being a small team, it does make sense to have only one dev list
- as for the bug tracker, probably the server code does not need
one - if we merge the two repos, that would also suggest
destroying the 'h-client' savannah project where the client
bug tracker is now - again i have no problem with that (the
split actually confused us at first); but where will the code
and bug tracker live? - is everyone content with savannah? -
any forge would do - i have no preference, as long as i can
reply to tickets via email

it would be good to get some eyeballs on the changes and
hopefully everyone can at least get it to build; but there is no
urgency to release, or establish the permanent repo - i would
consider the client to be a secondary concern, before the server
is up-to-date - it could also wait until the FSF decides (or not)
to host a new forge (probably pagure or sourcehut) and use that
one - a more "modern" git-centric forge (pull-requests, etc) may
be more inviting to new contributors, for example


On Thu, 05 Aug 2021 15:13:12 +1000 Yuchen wrote:
> I have the same question: Which repo / branch shall we use to push 
> these changes?

i think we should discuss and settle on an over-all organization
plan first - savannah is much more strict than other hosts about
adding/deleting/rebasing repos - i put it on pagure.io instead
of savannah intentionally; so as to avoid deciding how to manage
the repo yet

as you noticed, the old code is nearly useless on most distros;
and the new version is not ready for release - so for all intents
and purposes, the client does not even exist today - it can not
be tested thoroughly until the server is ready to experiment
with; so there is no reason for any of it to be on savannah yet
(assuming that savvannah will indeed remain as the primary host)

also, if it is decided to merge the two projects, whichever bug
tracker would be used today, may be abandoned soon anyways - in
that case, there would be some administration to do - we would
probably want to request that the 'h-client' savannah project be
destroyed at the same time, so that it will not appear to be
abandoned, then add the h-source bug tracker to the website, and
so on - those are the more important and more urgent concerns to
iron-out

i think it is prudent at this time, to keep the client code where
it is now, until after the upgraded server code has taken shape,
or at least until we have an over-all plan in place - for the
short term, i could add everyone as a maintainer on pagure.io