Hi Waldek, I quite agree that the repo should be well maintained to attract any attention. It was my fault that the github.com/poplog one died as I was trying to do too much and didn't gather a team together.
I've had a quick glance at what the bham install script produces, and it's a little different to what's in your repo, so now I don't know which source to cohere around. The download script references your work which is great, but the readme at https://github.com/hebisch/poplog says "...currently only core part". So is that complete? What's missing? Would there be a consensus that your version is the one to start from? IMHO the tasks to tackle include: - Migrate https://www.cs.bham.ac.uk/research/projects/poplog/V16/AREADME.html to a top-level README.md (in the "master" github), remove duplication and add decent markdown formatting - Create a Dockerfile instance that works from a known base and with all the libraries, Motif etc. sorted so there's a good exemplar baseline at least - Create/add a unittest library, preferably one that produces either https://en.wikipedia.org/wiki/Test_Anything_Protocol or jUnit or some such so we can use Jenkins / circleci etc. - Fix the Motif thing - Create .deb/.rpm packages - Create/add a library/package mechanism so 3rd parties can extend the base easily (installing a library by copying files into the source is so old hat) - then the bigger projects... Ian On Sat, 2 May 2020 at 00:29, <[email protected]> wrote: > On Thu, Apr 30, 2020 at 06:29:59PM +0100, [email protected] wrote: > > It would be great if we could move everything to github - even a plain > copy > > in its current state - as the git tools would make collaboration much > > easier. > > > > I originally made the https://github.com/poplog "organisation" account, > but > > I did it under such an old email address that I simply don't have access > to > > it any more (even github has killed that user). But we/I can make > another > > (and maybe reclaim the old when we have some traction). > > > > So, to begin with, we have to tackle one of the 2 hardest things in > > computing: what name to give it? :-) Perhaps openpoplog (though it > always > > was)? Any other suggestions? > > > > When we have the repo we can discuss what should go in it... > > I slightly disagree. We clearly we need name when we want to > advertise something. But before any advertising we should > think about our message and in particular what should be in > the repo. OTOH uncoordinated/empty/stale repos send bad > message. > > Now on Github thingy. Basic development can go in "personal" > repo of any Github member, such repo may have multiple > contributors. Github allows transfering ownership of a repo, > so if needed repo can be transformed into one owned by an > organization. AFAICS main difference is that in "personal" > repo owner is the only manger. Organization can have multiple > owners and mangers. > > I created new repo because I wanted cleaned up sources: > - tabs are expanded to 4 spaces each > - Ved control chars are deleted > - changes needed for 64-bits and ARM are merged > - no longer uses symbolic links, platform specific things > live in per platform subdirectories > > The first two changes means that one can see/work with > sources using standard tools (not only Ved). > > It tried to incorporate fixes from Aaron tarball, there are > a bunch of fixes for problems that I discovered at various > times. In particular there are fixes for Poplog Common Lisp > that have nothing to do with the port, except for fact that > I discovered them running Common Lisp tests during porting. > > Thing that is my repo got at least some testing: while there > are known problems (notably one with Motif) system build from > sources and features that I use work. Skipped things fall > into few categories: > - documentation, I think it needs some cleanup > - build/support scripts, again I think that they need cleanup. > In particular it would be good to move things from shell scripts > to Pop11 files > - packages. In this case it seems that some are broken. Shipping > broken stuff sends bad message, so again I think that this > needs work before it goes into repository. > > Up to now I did not find time to do serious work on items above, > so if you folks think that it is more important to ship something > now than to clean up things I will not object. Still, I think > that is better to skip a package in case when nobody can tell > if this package is working. > > -- > Waldek Hebisch > >
