search

rakudo / star

Rakudo Star (Raku distribution)
https://rakudo.org/
Artistic License 2.0
266 stars 41 forks source link

New Releaser needed for 2019.01 and following. #124

Closed stmuk closed 5 years ago

stmuk commented 5 years ago

The release process is well documented and only takes a few hours every three months (or more frequently if you want).

Having access to OS X is needed for the DMG build and access to 64bit Windows (Virtual Box fine) for the MSI build.

hankache commented 5 years ago

I volunteer. What do I need in term of accesses?

stmuk commented 5 years ago

That's Great!

You need 1. commit access to this repo 2. to the perl6.org and rakudo.org website repos and 3. ssh access to servers.

There are some details in https://github.com/rakudo/star/blob/master/tools/star/release-guide.pod

clarkema commented 5 years ago

I'd be happy to help out with this as well, if you'd like to increase the bus factor!

moritz commented 5 years ago

@hankache @clarkema I have invited you both to the perl6/perl6 and the rakudo/star teams on GitHub, which I believe gives you sufficient privileges on the GitHub side.

If you don't have SSH access for step 12 of the guide that stmuk linked to, please send me your SSH public key(s) to moritz.lenz@gmail.com, and I'll give you access.

If anything else is missing in terms of access, please don't hesitate to contact me, either in the #perl6 IRC channel, or via the email address mentioned above. I can't promise keys to every kingdom, but it's very likely that I at least know who to talk to :-)

Finally, since there are now two volunteers, who does the first release? First one to speak up wins :-)

clarkema commented 5 years ago

@moritz "wins"... ;) I'll have a go at it -- keys on the way.

moritz commented 5 years ago

For the record, I've received two SSH public keys from @clarkema and have added them to the rakudo@rakudo.org user account.

hankache commented 5 years ago

@moritz @clarkema no luck I was driving ;(

What about we do monthly releases? That way we can alternate each month and each one gets to do 6 releases per year?

@stmuk thank you for all the time you spent on rakudo/star

@moritz Will send you my keys in a bit, for the record I sent a CLA to the Perl foundation

clarkema commented 5 years ago

@hankache I guess we need to think about what kind of schedule would make sense for users and package builders. Looking at the Rakudo repo itself, it doesn't stick to an exact schedule of a release per month at the same point in the month. If we tried to do that with Star we risk running into situations when we're releasing Star with a version of Rakudo itself that only came out a few days previously.

I like the idea of making the latest goodies available for people who just want to brew install rakudo-star without having to do a full build themselves, but we also want people to feel comfortable relying on a Star release.

We could try a system along the lines of releasing every month with the previous month's Rakudo? So Rakudo 2019.01 becomes Star 2019.02, ensuring that things at least have a bit of time to settle before being fully released into the wild?

AlexDaniel commented 5 years ago

FWIW I'm +1 for more than one person working on it. There's a lot of work to do, and IMO doing it alone is not the best idea.

stmuk commented 5 years ago

The schedule I more or less used for 3 years was to release every quarter (20XX.01, 04, 07, 10) a Release Candidate (RC) a weekend after the upstream release with the final release the following weekend. I would aim to hit the Monday's Perl 6 Weekly both times. This seemed to mostly work well and allowed enough time for upstream issues to be spotted in the monthly although I never really got much feedback about the star RC itself. Usually someone would point out a typo in the release accouncement after the release :)

Very occasionally I would put a patch in star to fix a problem with upstream but this hasn't happened for a while. Sometimes MoarVM or NQP had a dot release due to a problem. But not so much recently. Upstream is taking longer for its monthly releases (probably due to the number of changes going in and increased testing) and did skip one release this year due to problems. I think having similar but different release numbering for star and upstream would be too confusing.

stmuk commented 5 years ago

@clarkema @hankache If you are both releasing you might want to consider sharing a GPG key for the release. Although I just used my own and it would be easiest to continue with personal keys to prevent private key exchange issues. I could sign keys and I think Alex signed my key.

clarkema commented 5 years ago

If that process has worked well so far, then let's stick with it. @hankache you're welcome to take the first one though; or maybe we could work through it together.

@stmuk thanks for leaving it in such a good state -- the whole process seems well documented and easy to follow. I've just worked through it without committing anything, and it seemed fairly straightfowards, at least for the .tar.gz.

stmuk commented 5 years ago

@clarkema It was set up well from the start! Most things are fairly straightforward. Making a list of module changes is always a little fiddly as is building the Windows MSI and maybe sorting the module deps when they change but otherwise it's usually plain sailing!

kawaii commented 5 years ago

Is there an ETA on the 2019.01 release yet? Will it include the latest Perl 6.d improvements? :)

hankache commented 5 years ago

@kawaii Rakudo 2019.01 will have to be released first. Usually a couple of days afterwards you'll find a Rakudo Star release. Yes it will include the latest 6.d improvements.

AlexDaniel commented 5 years ago

Also, while Rakudo 2019.01 is scheduled for 2019-01-19, it will likely take more time. There are many blockers right now.

AlexDaniel commented 5 years ago

In case anybody is following this in anticipation, Rakudo 2019.01 was skipped. So the next rakudo star will have to be based on 2019.02 (which will come in ≈2-3 weeks).

AlexDaniel commented 5 years ago

Rakudo 2019.03 was released.

Ping @hankache, @clarkema.

AlexDaniel commented 5 years ago

@hankache @clarkema, so what's the situation? I see new commits but no person or team assigned here: https://github.com/rakudo/star/blob/master/tools/star/release-guide.pod#star-releases

hankache commented 5 years ago

@AlexDaniel I made the necessary changes to the repo. I also packaged a .tar.gz and a .msi release candidate for 2019.03 both of them are available on https://hankache.com/rakudostar

Once tested I'll release a new version of Star and scp the files with their keys to rakudo.org

Meanwhile if you can test any of those RCs it would be great.

@clarkema Would you be able to package the .dmg?

AlexDaniel commented 5 years ago

@clarkema Also, I can't find your pgp key, can you fix that? (checked github and https://pgp.mit.edu/).

EDIT: OK, actually, I did find it! But can you add it to github also? I see some expired and some revoked, so it'd be nice to know that the one I'm looking at is correct.

clarkema commented 5 years ago

@hankache I can test on the *BSDs later on today, and build / test a DMG for OS X.

@AlexDaniel Anything you've managed to find will be super old. I'll probably end up making a new keypair.

clarkema commented 5 years ago

I'm seeing failures in make rakudo-spectest on macOS 10.14.1:

Test Summary Report
-------------------
t/spec/S17-supply/watch-path.t                                  (Wstat: 512 Tests: 4 Failed: 2)
  Failed tests:  2, 4
  Non-zero exit status: 2
t/spec/integration/error-reporting.rakudo.moar                  (Wstat: 0 Tests: 33 Failed: 0)
  TODO passed:   11
t/spec/S32-str/utf8-c8.t                                        (Wstat: 256 Tests: 54 Failed: 1)
  Failed test:  31
  Non-zero exit status: 1
  Parse errors: Bad plan.  You planned 66 tests but ran 54.
Files=1234, Tests=76212, 451 wallclock secs (18.15 usr  5.83 sys + 2953.11 cusr 232.86 csys = 3209.95 CPU)
Result: FAIL
make[1]: *** [m-spectest5] Error 1
make: *** [rakudo-spectest] Error 2

I'll do some more digging and see if I can pin down a cause and test case.

AlexDaniel commented 5 years ago

@clarkema try roast checked out at https://github.com/perl6/roast/commit/a3b365fcda33b58815f4c57569d3a32d380f611e instead of master.

clarkema commented 5 years ago

@AlexDaniel Will give that a try, thanks. I was running the spectest on a Star build generated from @hankache's 2019.03-RC tarball -- I've already done a bit of digging and I suspect that the issue is some macOS-specific tests are out of date.

lizmat commented 5 years ago

On 11 Mar 2019, at 15:52, Mike Clarke notifications@github.com wrote:

I'm seeing failures in make rakudo-spectest on macOS 10.14.1:

Test Summary Report

t/spec/S17-supply/watch-path.t (Wstat: 512 Tests: 4 Failed: 2) Failed tests: 2, 4 Non-zero exit status: 2

I see this one flap all the time. Sometimes MacOS takes its time to deliver file system events, causing these.

t/spec/integration/error-reporting.rakudo.moar (Wstat: 0 Tests: 33 Failed: 0) TODO passed: 11

Don’t know about that one.

t/spec/S32-str/utf8-c8.t (Wstat: 256 Tests: 54 Failed: 1) Failed test: 31 Non-zero exit status: 1 Parse errors: Bad plan. You planned 66 tests but ran 54.

This one has been failing for me on MacOS like forever. I’m running on APFS, so I fear that’s got something to do with it. Never got the courage to dig deeper :-(

clarkema commented 5 years ago

Everything passes on FreeBSD 11.2, and the remaining failures on macOS are all accounted for (either test suite issues or long-standing UTF-8 FS issues)

I've uploaded an RC DMG based on @hankache's source tarball to

http://clarkema.org/scratch/rakudo/rakudo-star-2019.03-RC.dmg http://clarkema.org/scratch/rakudo/rakudo-star-2019.03-RC.dmg.sig

The PGP key used for the signature is new -- I've added it to Github, but it's taking a while to propagate through the keyservers.

AlexDaniel commented 5 years ago

There's a weird issue here, please take a look: https://github.com/Tux/CSV/issues/13

Edit: here's the ticket: https://github.com/rakudo/rakudo/issues/2763

hankache commented 5 years ago

@AlexDaniel regarding rakudo/rakudo#2763 it turns out it was a false positive

hankache commented 5 years ago

So the status so far is as following:

I curently have three options:

@stmuk In the past how did you cater for such occurrences?

lizmat commented 5 years ago

I think in the past, a .1 release has been done in such cases.

hankache commented 5 years ago

Perfect then. Moar and nqp are fine it's just rakudo that needs a .1 release that includes the following 2 commits:

@ugexe can you kindly confirm that those two commits are the only thing needed to fix https://github.com/rakudo/rakudo/issues/2756 ?

AlexDaniel commented 5 years ago

@lizmat @hankache also let me know if there's any other commit worth having in 2019.03.1.

lizmat commented 5 years ago

Glanced over the log so far, but nothing urgent spotted my eye

stmuk commented 5 years ago

So the status so far is as following:

I curently have three options:

@stmuk In the past how did you cater for such occurrences?

Windows is often a PITA 😄 One of the pluses of Star is that at least one person builds on Windows and does basic tests every few months and catches issues exactly like this! I got a surprising number of complaints when I didn't release Windows binaries so people do use them.

Generally its best if upstream releases a .1 as I see will happen.

But there are mechanisms possible in star to patch upstream like the "lastmin-fixes" (which I think I only used once or maybe twice in very extreme cases when upstream wasn't patched).

In this situation had there no upstream fix I would have probably used the "patch" system which I probably should have doc'd better and used more frequently than "lastmin-fixes".

This is the same mechanism used to patch the binary to return "Rakudo Star" rather than "Rakudo" see the "patches" top level directory. You can see past examples by

git log -p -S patch

Usually these are small, simple fixes which are platform specific and discovered by testing star like changing OpenBSD to use clang and not gcc. I'd commit upstream and cherry pick the patch out and (hopefully!) doc the change.

AlexDaniel commented 5 years ago

OK, I'll release 2019.03.1, no prob. Should be ready tomorrow, although maybe you'll see it today.

AlexDaniel commented 5 years ago

Done.

hankache commented 5 years ago

@AlexDaniel thanks. I'll start the process now.

AlexDaniel commented 5 years ago

Please do test that it was indeed fixed on windows :)

hankache commented 5 years ago

@AlexDaniel Indeed the regression of $*KERNEL was fixed on Windows. RC2 for both Windows and Linux are available at https://hankache.com/rakudostar

clarkema commented 5 years ago

I've just built the DMG for RC2 and uploaded to

http://clarkema.org/scratch/rakudo-star-2019.03-RC2.dmg http://clarkema.org/scratch/rakudo-star-2019.03-RC2.dmg.sig

AlexDaniel commented 5 years ago

Does anybody know something about https://github.com/niner/Inline-Python/issues/33 ?

https://colabti.org/irclogger/irclogger_log/perl6?date=2019-03-30#l429

hankache commented 5 years ago

@clarkema I just released both tar.gz and .msi Whenever you're done with the .dmg please merge https://github.com/perl6/rakudo.org/pull/24 Thanks.

clarkema commented 5 years ago

@hankache Just uploaded the .dmg. It looks like the linked ticket was closed, so I just cherry picked your commit from it back onto master. I think that means we're officially done!

AlexDaniel commented 5 years ago

What's up with having a sha256.txt for msi but not for a dmg?

hankache commented 5 years ago

@clarkema well done!

clarkema commented 5 years ago

@AlexDaniel I've added instructions and hash / gpg sig for the dmg as well.

hankache commented 5 years ago

Thank you everyone for your support. I will close this issue now that the release is behind us.

hankache commented 5 years ago

@clarkema do you by any chance still have a local copy of the dmg?

moritz commented 5 years ago

@hankache the dmg should be available from https://perlgeek.de/static/p6/star/ (which has the recovered files from the old WWW server)