[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Yuchen Pei
Subject: Re: [H-source-users] adapting h-client for python3/GTK3
Date: Mon, 04 Oct 2021 21:07:16 +1100
User-agent: mu4e 1.4.13; emacs 27.2

bill-auger <bill-auger@peers.community> writes:

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);

Yeah, every commit should compile unless there's some compelling reason for it not to 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

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 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

I'm not sure if we should have multiple mailing lists. h-source is not emacs, and the mailing list is pretty low volume. In the past 1.5 months it was pretty much a place for my monologues :) There are projects (e.g. emms) with similar or bigger size with only one mailing list for both help and dev. If the mailing list become noisy in the future then it will make more sense, but for now, I feel having two lists is only going to fragment and slow down the communication.

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

Let's keep things under h-source at savannah. We can use the h-source bug tracker for both h-source and h-client since both are under h-source. I think it makes sense to have all discussions on the mailing list when there is more than one person participating. When it is "single player" like the past month or so, just using the bug tracker makes sense, as it is a bit more structured and cleaner and there's not much use to raise issues when no one else is responding.

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

Sounds good to me.

- 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

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


PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]