uuid and uuid-types need revisions

[Bodigrim]

• Allow random-1.2 (released in June 2020) in uuid. This has been initially raised in https://github.com/haskell-hvr/uuid/pull/53 (June 2020) and later in https://github.com/haskell-hvr/uuid/pull/55 (month ago). No maintainer's reaction was received.
• Allow bytestring-0.11 (released in September 2020) in uuid and uuid-types. Raised in https://github.com/haskell-hvr/uuid/pull/54 (two months ago), maintainer was reminded on several occasions publicly and privately.

CC @gbaz

[Bodigrim]

Ping @gbaz CC @mightybyte

[Bodigrim]

@gbaz @mightybyte whom should I ask to get this fixed? Are there any other Hackage Trustees active?

CC @emilypi

[emilypi]

Attempting to summon @mightybyte

[gbaz]

@Bodigrim do you want to be a trustee so you can take care of small stuff like this yourself in the future? Not all trustees have to be high-activity...

[mightybyte]

I uploaded a hackage revision to the uuid package for haskell-hvr/uuid#55. A revision has already been uploaded for uuid-types. I published a revision to both packages for haskell-hvr/uuid#54. The change in haskell-hvr/uuid#53 is not something that trustees can make (see https://hackage.haskell.org/packages/trustees/). If the maintainer is unavailable, I would suggest you initiate the procedure to take over maintenance of the package (see https://wiki.haskell.org/Taking_over_a_package).

[Bodigrim]

@Bodigrim do you want to be a trustee so you can take care of small stuff like this yourself in the future?

@gbaz yes, please, this would be most appreciated, because I have couple more revisions to ask for. Hackage account is http://hackage.haskell.org/user/Bodigrim

@mightybyte thanks!

[phadej]

If it is possible to be a Hackage Trustee and deal only with own issues, i.e. not dealing with users onboarding or packages revisions and NMUs for other people, I'd like to be Trustee again as well.

Having power of making revisions without (much) responsibility would be nice!

---

EDIT: This is sarcastic request, but I'm somewhat serious. There are once in a while threads on Twitter or Reddit with people being happy or unhappy about trustees-made revisions. For example these particular revisions to uuid are not reported back (at least publicly on issues) to the maintainer, which I consider be mandatory action; trustees cannot just make revisions silently. I'd wish trustees be trustworthy by having their processes actions as transparent as it's possible to ask from the volunteers.

[Bodigrim]

For example these particular revisions to uuid are not reported back (at least publicly on issues) to the maintainer, which I consider be mandatory action

Corresponding PRs are quoted in the opening message above. What else would you like to see?

[phadej]

@Bodigrim comments in these issues, like: https://github.com/nick8325/quickcheck/issues/326#issuecomment-777874085

[phadej]

... which is infact a good example as there was a small mistake, and it was possible to see what happened from the package's issue tracker.

[bergmark]

If it is possible to be a Hackage Trustee and deal only with own issues, i.e. not dealing with users onboarding or packages revisions and NMUs for other people, I'd like to be Trustee again as well.

This is how I acted as a trustee for a long time, I'm assuming by "own issues" you mean when you are blocked by other people's packages? @phadej since you are a power user of the eco-system i think it would be very valuable if this is "all" you did.

I haven't been active for a long time so I don't feel like my opinion should count for much, but my perception of trusteeing was that it should be purely a volunteer effort with no commitment on time spent. Ideally I would like to have a large group of people that chip in here and there when they have time.

There are once in a while threads on Twitter or Reddit with people being happy or unhappy about trustees-made revisions. For example these particular revisions to uuid are not reported back (at least publicly on issues) to the maintainer, which I consider be mandatory action;

Yes we specified this in the policy and I think this is very important as well; that we are transparent with what we are doing.

[sjakobi]

If being a Hackage Trustee doesn't require a large time commitment, I'd like to be a trustee as well! :)

[gbaz]

My view is trustworthy people can be trustees and not necessarily take on more work than they care to. I.e. some can deal with onboarding, some can do large scale work when they feel like it, some can only revise on occasion. Whatever people need to do, they need to follow procedure and be on the list (though they can set up a filter to drop onboarding messages). If people are ok with that, I'll go ahead and add sjakobi, phaej and bodigrim.

Ideally we can at some point separate revision-trusteeship from onboarding-trusteeship (and automate more of the latter) but that's future work.

[Bodigrim]

@gbaz @bergmark is there any action required from our side? AFAICT neither of us three was granted trustee rights.

[gbaz]

nope, just didn't get around to it. all three of you now should be on the trustees email alias and have permissions in the hackage group. please review the policies before taking any actions with these new permissions :-) https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md

[Bodigrim]

Thanks!

[sjakobi]

Thank you, @gbaz! :)

I haven't received any mail from the trustees list so far, but I assume there simply hasn't been any traffic yet.