DEVS: What Collobaration Works For You

[hammy]

* Please understand that no-one is obligated to take part in this. You don't get "black flagged" if it's not your thing.

--

IRIX enthusiasts armed with your compiler - we've asking ourselves - what environment works for you to collaborate and enjoy working together?


Today we had a little discussion on the discord server - and it's important that everyone can air their opinion, feedback and input.


Please understand - no actions or decisions have been made from this - input from you is most welcomed - and with understanding we may go a little further!

We propose two rounds to see how and with what tool.

Round One: What can work for us - to work together?

(Later we will talk about specific tools, but that's not the focus here).


The topic was: What kind of collaboration on development tools and packaging would work for you?

Here we try to focus on "what workflow and setup is ok for you" rather than "I prefer tool X" or "tool Y won't let you use MIPSPro".


All are welcome to provide their feedback - but please focus on:

1. What might be real blockers for you being part of a working group looking to maintain and port software for IRIX
2. What you consider soft "no"s - everyone has a preference - and it's OK that we express that too

Summary - (* indicates "this is a blocker for me"):


The silence of the ass (myself):

(*1) Tooling should be automated/versioned
(*2) Platform core tools should be shared and common
(3) I'm not too fussed about what existing packager we could consider, I think pkgsrc (portage or bsd ports) isn't a bad choice, for example


Raion:

(1) The choice to use any supported IRIX compiler, including markers for ports
(2) Automated packaging with full dependency control from inst or whatever installer you're using
(*3) Easy ability to toggle optional dependencies
(4) No hard dependencies on tools that lock out MIPS III users, or exclude irix versions below .30
(5) Easy to install and setup regardless if you're a dev or a user
(*later, raion perhaps on behalf of dexter1) Cutting off MIPSIII wouldn't be reasonable, prefer to target both

Unxmaal:

(*1) It exists
(*2) It is being worked on by developers
(3) It runs on and supports the final version of IRIX, 6.5.30
(4) It can bootstrap itself
(5) It produces packages in simple, non-proprietary archive format (.tgz)
(6) It is free, requiring no licensing
(7) It provides a simple, direct path for producing a set of IRIX compatible packages from a set of sources
(8) It produces a set of commonly-used packages in IRIX-compatible binary executable format
(9) It provides an easy method for a moderate to expert-level packager to port a given piece of software to IRIX

Some additional comments probably relevant:

raion: replacement of system shells is to aim for
tsota, unxmaal, lbdm: should be optional

I will append the raw log in trailing post probably in a text file attachment, it seems way too long for the forum editor.


Kr,


Dan

 

[Elf]

I like the idea of considering workflow first. This may not carry any weight since I am not really actively porting SGI software, but I guess I will give a few suggestions:

• It would be good to curate a list of what software is being considered for porting and who might be working on it (or has successfully done so already)
• The task of creating instructions / patches / forks necessary to make sure software builds and works under IRIX seems like a separate job from maintaining packages of that software
  • It's very productive for people to accumulate instructions and report success of building a piece of software even if they can't or don't want to maintain a redistributable package of it
  • People who have passion for a given package management system ( @LarBob 's, EPM, RPM, etc.) can become "port maintainers" for software that others have figured out how to build. They can, in turn, provide any needed spec files or other artifacts necessary for packaging that port under that system. This offers user choice and avoids cementing decisions too early on in the game.
• We should have the concept of versioning the build / port in addition to the main software rev, making it easier to distinguish fixes to the porting process versus fixes in the base software
• Eventually some sort of CI or build pipeline could be set up
• The ports.sgi.sh repository could be forked by package manager type to accommodate more than one

A forum thread (with standardized title) per piece of ported software per porting effort would allow for comments, user QA, and bug reports without having to establish too much tooling. There could conceivably be two or more groups trying to port the same software using different methodologies.

Professional shops obviously use ticket/bug tracking systems but that seems like a no-fun-zone for the early hobbyist stage we are in.

 

[onre]

IMO replacing anything that's part of the system is generally not a good idea, as there's surely stuff out there that depends on the system binaries being as shipped. However, as always, there are exceptions. For example, having a perl newer than the 5.004 or whatever that came on some SGI-released media kits will almost certainly never hurt.

It's also good to remember, as mentioned above by Elf, that porting and packaging are two entirely separate things. Most of the time they aren't even dependent on which toolchain you're using as the quirks are in IRIX system libraries and interfaces, which are the same for all toolchains.

The forum thread idea is a really solid one.

 

[Raion]

A forum thread (with standardized title) per piece of ported software per porting effort would allow for comments, user QA, and bug reports without having to establish too much tooling. There could conceivably be two or more groups trying to port the same software using different methodologies.

Professional shops obviously use ticket/bug tracking systems but that seems like a no-fun-zone for the early hobbyist stage we are in.

Yeah a subforum for that, like I have organized here: http://forums.irix.cc/forum-40.html for forum bug reporting servers the job.

With tags and such would make it really easy. I suggest appointing 3-4 people whose duty is to tag and update threads for various parts of the workflow. In that regard, it'd be close enough to get the workflow smooth, so long as there's sufficient coverage to tag, update and manage various forum posts

IMO replacing anything that's part of the system is generally not a good idea, as there's surely stuff out there that depends on the system binaries being as shipped. However, as always, there are exceptions. For example, having a perl newer than the 5.004 or whatever that came on some SGI-released media kits will almost certainly never hurt.

I'll probably just finalize the concept I have before we go any further with that discussion, and I'll launch a thread in both spots where I discuss how the update works, what it touches, where the original shells are backed up, and what has and has not been tested with them. I said all I needed to say on that, so tabling it until a working concept that can be replicated across a group of willing testers is probably the best way to figure out the viability.

The original motivation is that the ksh that IRIX includes sometimes messes up with makefiles, and it's fixed if you use mksh or pdksh. So I just decided to standardize how to update it. And tcsh is my login shell, so i wanted the most recent version to replace it in /bin. But I digress, I have work to do there.

 

[hammy]

Good stuff. Keep 'em coming.

Some more thoughts:

I'd like to advocate for being a little more defined about a collaborative workflow. What do I mean by this?

The mention of contributors providing build instructions for packages in forum posts is ok - but certainly for my part I'd like to challenge if replicating this approach from nekoware (or maybe earlier, I lack the history here) - is really intended and desired.

I don't know if I am alone in finding the hand made build notes and instructions rather frustrating - due to the knowledge they don't contain.

In particular I'm thinking about DEV productivity - and package / build reproduceability.

e.g. DEV #1 has issues with package A - asks for confirmation / help to DEV #2

At this point, if this is just a list of build instructions, maybe a patch - we've lost a few things between DEV #1 and DEV #2

Those boil down to non-determinism:

• No common base environment the package was built in and versions of the tools or dependencies underneath
• Notes give no assurance that the package build is reproduceable in terms of compilation flags, ability to execute package tests etc

I'd argue that our DEV productivity will take a hit from being "notes based" - and it makes life harder for new/junior contributors too.

That second one is worth reflecting on. Keeping the barrier to entry low should be near the top, IMO.

For collaborative work I'd like to see an agreed standard ports system (whatever that may be) handling base tools, dependencies and versioning -> support / official packages should be built from this platform up.

I certainly see the value in splitting ports from packaging, although ultimately our flexibility there might be determined by tools.

Edit: typo from like -> life

 

[Raion]

I'd like to advocate for being a little more defined about a collaborative workflow. What do I mean by this?

The mention of contributors providing build instructions for packages in forum posts is ok - but certainly for my part I'd like to challenge if replicating this approach from nekoware (or maybe earlier, I lack the history here) - is really intended and desired.

The Nekoware method is one I recommend we avoid. The variance in package, build/relnotes quality and communication from the maintainers has made trying to reproduce their builds a nightmare.

If a collaborative, cooperative environment is to work, we all need to agree on a singular workflow, criteria and potentially leadership, and agree to adjust our targeting and sights to fit that. Otherwise, there's no difference in the project to how Nekoware was run - and I think most of us can agree that nekoware's quality was in the pits by the time of nekochan's demise.