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

[Yuchen Pei]

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


--
Best,
Yuchen

PGP Key: 47F9 D050 1E11 8879 9040  4941 2126 7E93 EF86 DFD0
          <https://ypei.me/assets/ypei-pubkey.txt>

signature.asc
Description: PGP signature