SGUG RSE: Managing WIP

mach_kernel

Administrator
Dec 26, 2019
23
23
3
New York City
github.com
Hey all,

More hands are contributing to RSE, and I wanted to shoot around some ideas for managing our WIP packages. I think that everybody pushing to a wip branch with this many members may be reaching its ceiling. I don't know if this is just me (everyone, please chime in!), however I think the following may be things to look out for:
  • Sometimes more than one head is needed to debug a package because stuff is tedious. People will want to finish a package locally before pushing to WIP -- sending one another snippets isn't a super scalable process (as opposed to collaborating on a new branch for that package). Going back and forth with commits on WIP to debug one thing specifically may also not be the easiest workflow (plus, makes a lot of meaningless history).
  • Pushing incomplete packages to WIP may make it difficult for us to "cut" a new release once we are satisfied with what is staged: we need a second round of QA which IMO could be done making PRs on a pkg-by-pkg basis
  • Staging packages for merge into WIP would put pressure on completing them, making it easier to depend on other things in WIP with some degree of confidence
  • Committing early and making a pull request would allow us to get feedback sooner, and it's feedback that newcomers to autotools like myself very much need!
Things we've tried:
  • WIP repository (now archived)
  • A WIP branch on sgug-rse
Also -- I guess it would also be worth talking about what we do before cutting a new release? What's the strategy to move packages from WIP to a (probably protected) RC or next release branch?

What's the best way to approach these questions?
 
Last edited:

hammy

Active member
Jun 1, 2019
108
68
28
UK
Hey Mach,

For a little bit of background: (and of course we are free to change things / alter the deal as we see fit, Han).

  • Until we get a "proper" repository front end and infrastructure in place (a-la yum) - a point release (rather than rolling release) makes sense (even building and releasing the starter packs is a fair amount of effort to properly version and test - ensuring the deps are correct to be installed over the previous point release etc)
  • We need a "master" repository, that should represent the source of the most stable release
  • We need a branch under which a new release is staged - say releaseXXXXX
  • We need some quality control / standards about which packages make it into the above (mandatory review) - and to get a "release" ready, everything currently staged is built twice + verified, then pulled down to the minimal install ball for the release. (Two installs to catch latent "hidden" dependencies)
Here's the criteria that was used to get packages into 0.0.5 (criteria to go from WIP to a "released" package):


I'd be lying to say that the packages in 0.0.5 were properly reviewed by a second person -> so maybe we want to get rid of the review?

So that's the principle behind the "release" trees - WIP was created as a dumping ground for `.spec` files that didn't meet the quality bar for the above. Original as a repo, and then today as the WIP branch itself.

Because WIP project has traditionally had no barrier, that's exactly how it has been on the branch, too -> everyone takes whatever approach works for them on the WIP branch.

Sometimes more than one head is needed to debug a package because stuff is tedious. People will want to finish a package locally before pushing to WIP -- sending one another snippets isn't a super scalable process (as opposed to collaborating on a new branch for that package). Going back and forth with commits on WIP to debug one thing specifically may also not be the easiest workflow (plus, makes a lot of meaningless history).
Yep, branches work great for that - other options are personal repo + the branches there too

Pushing incomplete packages to WIP may make it difficult for us to "cut" a new release once we are satisfied with what is staged: we need a second round of QA which IMO could be done making PRs on a pkg-by-pkg basis
Define "incomplete" .-) By that I mean it's a perspective thing about what is complete or what varying levels of broken are, right?

The only place where we've historically had a minimum quality barrier is for the moving to a release. If we make it so that nothing can get into WIP without a "quality review" - IMO all that will do is push the WIP bits somewhere else.

I see your motivation - my concern is that WIP becomes a new "reviewed packages only" place - and thus we push WIP somewhere else.

Staging packages for merge into WIP would put pressure on completing them, making it easier to depend on other things in WIP with some degree of confidence
Dunno - maybe we have different expectations of what WIP is or is not. Maybe your beef here would be solved by people putting more effort into getting packages "cleaned up and pushed to release N+1" ?

Also -- I guess it would also be worth talking about what we do before cutting a new release? What's the strategy to move packages from WIP to a (probably protected) RC or next release branch?
Cutting a release has previously worked like this:
  1. Packages and changes are reviewed as per the above mentioned quality criteria and pushed to "releaseN+1"
  2. A volunteer uses a machine as the staging and build mule - where the following happens
  3. Missing packages are built+installed manually to ensure the full list of packages in the release are there and complete (and available in ~/rpmbuild/SPECS, too)
  4. Any WIP packages or unfinished packages must be uninstalled and their spec files removed
  5. The "sgug_world_builder" from sgug-rpm-tools is run - and generates a "world_builder.sh" shell script that works out all the packages that need to be rebuilt
  6. A full rebuild is done with the script
  7. Errors are noted, packages are fixed
  8. A full rebuild eventually completes
  9. All packages created from the build are now installed
  10. All gen #1 output SRPMs and RPMs are removed
  11. A full rebuild is done with the script a second time
  12. Error are noted, packages are fixed
  13. A full rebuild eventually completes
  14. All packages created from the build are now installed
  15. The "sgug_minimal_computer" from sgug-rpm-tools is run - and generates the "removeexisting.sh" script
  16. The removeexisting.sh is run - which reduces the machines current sgug install down to the minimal install "selfhoster"
  17. Any personalisation under /usr/sgug must be removed, include ssh keys, hand edits, `.rpmsave` files etc
  18. The selfhoster tarball is created from this
  19. All the RPMs are re-installed to ensure that everything works as intended
  20. Testing begins
  21. Things need fixing -> depending on "severity" - might just be a patch, or might be full-rebuild
  22. SRPMs and RPMs are archived up along with the selfhoster and a release is posted
The above approach isn't going to work any more I'm afraid. Each package needs to be built "clean room" - so we'll need a new approach.

(By clean room - I mean I've noticed that you can't install all the SRPMs at the same time - some of the SRPMs have collisions in the files they place in ~/rpmbuild/SOURCES - which causes build errors).

Well that's some food for thought .-)
 
Last edited:

hammy

Active member
Jun 1, 2019
108
68
28
UK
Some thoughts on "cutting the 0.0.6 release":
  • We have a big chunk of work since 0.0.5 (the number of commits since then is more than all commits up to 0.0.5) - wowzers
  • Copying things between branches is a whole heap of work for all of us, so let's not do that
  • We could snapshot the wip branch as-is and let that become the 0.0.6 release (with work on it to make it coherent etc)
  • If we are just snapshotting the wip branch as 0.0.6, we'll need some way to indicate which packages are "in the release"
  • The 0.0.6 branch will be protected and need pull requests to it, mostly the pull requests should be about adding things to the "releasepackages.lst"
  • Bug fixes too, of course, or things that need fixing properly (like deps)
  • Let's try and keep the package list reasonable -> I'd prefer stuff that has been tested and/or is needed as deps
  • Adding 1K packages auto checked in for perl/python is doable, but someone else can be build bunny if that's where we're going .-)
So

Feedback needed on the following points from contributors (HAL, Unxy, Mach, Massive):

Q1) Are we in a state in WIP where we feel it's a good time to make that snapshot?
Q2) Off the top of my head, what's the status of:

Code:
python2, python3 (anyone had success building these other than me?)
cmake
pidgin (maybe some issues with getting it running on the native SGI X11 server?)
There may be more, feel free to chime in. It'd be nice to make a snapshot after these, but maybe we just go ahead and create the 0.0.6 branch anyway.

Feedback welcomed, including "how about doing this another way, ass" .-)
 

hammy

Active member
Jun 1, 2019
108
68
28
UK
FYI - for the automated check ins:

1) Are these automated check-ins actually of fc31 stuff? I found the version of python-decorator (auto) checked in looks like it is fc32 -> maybe there are others?

2) All these automated packages make github browsing unusable.

3) Please add a person, not a tool - Koji builder doesn't let me know _who_ I go and smack the bum of .-)

For now I've created the branch "wipnonautomated" where I'm basing my commits until we resolve the issues above.

 

Elf

Storybook / Retired, ex-staff
Feb 4, 2019
792
252
63
Mountain West (US)
@hammy: the automated checkins are mostly @mach_kernel and lately @Unxmaal I believe. I'll point them this way :)

Regarding copying things between branches, this may be a naive question, but are they not mergeable? (merge WIP branch into mainline branch and cut release branch)
 

hammy

Active member
Jun 1, 2019
108
68
28
UK
@Elf yeah, it's no biggie, I understand the joy of wanting to get more stuff included. We'll work something out. Let's give the guys a chance to see if I'm talking crap about the fc32 versions .-)

Far as I can tell at a minimum we might need to re-org our github layout a bit to not have quite so many packages all at one level.

e.g. structure things into "first two letters" directories to split em up a little bit (just a suggestion, probably there's better approaches).
 

Unxmaal

Administrator
Feb 8, 2019
98
60
18
We very much need acceptance criteria for 'stable' specs. Here's some:
  • the spec builds a rpm that installs on IRIX
  • the spec builds with tests enabled (eh? or not?)
  • the spec directory includes both the updated spec and the original
  • the spec does not have items commented out. they're removed instead
  • the spec has correct datestamps in the changelog
  • the changelog is updated to reflect our work
  • every effort has been made to retain listed dependencies, rather than deleting them
  • the minor version has been incremented (so for foobar-2.1.1-0.2, we'd increment to foobar-2.1.1-0.3)

If we can agree on some of these criteria, we next need a script to scan potential packages for meeting criteria.
 

hammy

Active member
Jun 1, 2019
108
68
28
UK
Regarding copying things between branches, this may be a naive question, but are they not mergeable? (merge WIP branch into mainline branch and cut release branch)
@Elf - sorry I did mean to respond to this, but got distracted with trying to work out how to cherry pick stuff in git.

Indeed they _are_ mergeable, and that's exactly how I propose we do the "merge to master" when 0.0.6 is ready.

But to _create_ the 0.0.6 branch, we just create that branch from the point in the WIP branch we want to (or, as I'm feeling right now, from the wipnonautomated branch).

Mainline branch doesn't get updated until 0.0.6 is ready + released - until then, it represents "last stable".


We very much need acceptance criteria for 'stable' specs. Here's some:
Are these intended to replace / supplement or other the criteria I linked we used for 0.0.5?

(And I'm not certain I agree with "the spec does not have items commented out. they're removed instead").

0.0.5 criteria again copied here:
  • Package must not depend on something in sgug-rse-wip (unless that's getting merged too)
  • Package should have package.spec.origfedora if available too
  • Package should compile and install without any use of --force or --nodeps
  • Package spec must not contain AutoReqProv: 0 or disable dependency computations/constraints
  • Package changelog should be updated
  • Binaries (program/library) should have appropriate RPATH (see existing with objdump -p THING |grep RPATH)
  • Package should in almost all cases only touch files under /usr/sgug - check the files list of the RPMs and any pre/post sections of the spec
  • Evidence of testing (make check or some tool that uses it) - justifications about failures not being blockers are fine too
  • Where possible, package naming should match fedora style package naming
  • Patches associated with packages should try and use packagename.sgifixdescription.patch for hygiene reasons
  • Patches referenced in a spec should start at Patch100 (or later)
  • If possible, package is checked to see if "optimised linker flags" can be used
  • Do a review, see/check if the Requires, BuildRequires make sense / are up to date
 

Unxmaal

Administrator
Feb 8, 2019
98
60
18
FYI - for the automated check ins:

1) Are these automated check-ins actually of fc31 stuff? I found the version of python-decorator (auto) checked in looks like it is fc32 -> maybe there are others?

2) All these automated packages make github browsing unusable.

3) Please add a person, not a tool - Koji builder doesn't let me know _who_ I go and smack the bum of .-)

For now I've created the branch "wipnonautomated" where I'm basing my commits until we resolve the issues above.

We've rolled back the automated commits and have parked that effort for now.

I feel having multiple WIP branches can be confusing.

What's the effort needed to merge wipnonautomated back into wip? Are further changes to wip required?
 

About us

  • Silicon Graphics User Group (SGUG) is a community for users, developers, and admirers of Silicon Graphics (SGI) products. We aim to be a friendly hobbyist community for discussing all aspects of SGIs, including use, software development, the IRIX Operating System, and troubleshooting, as well as facilitating hardware exchange.

User Menu