Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rename iso_graphical to iso_plasma5 #25

Merged
merged 1 commit into from Jan 30, 2020

Conversation

worldofpeace
Copy link
Contributor

Coordinate with NixOS/nixpkgs#66640

Copy link
Member

@grahamc grahamc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

contingent on NixOS/nixpkgs#66640

@samueldr
Copy link
Member

How will it work with "mixed channels", e.g. the span up to the EOL of 19.03? We'll have updates for both 19.03 and 19.09/unstable going on, with a different sent of images being generated.

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Aug 14, 2019

Perhaps we backport all of the renames?
Or maybe use $releaseName to differentiate which ones, though I don't know perl.

@grahamc
Copy link
Member

grahamc commented Aug 14, 2019

We should probably not backport renames, as that is a pretty big change which somebody might have built against.

I propose we put a blocking 19.09 issue in nixpkgs saying merge these two PRs at release time.

@grahamc
Copy link
Member

grahamc commented Aug 14, 2019

Hrm. Using $releaseName is for sure the right thing to do, as otherwise channel updates will fail for all prior branches.

@worldofpeace
Copy link
Contributor Author

worldofpeace commented Aug 14, 2019

Yep, and I think the script will need this in the future if the gnome3 iso gets added.
As 19.09 and unstable will have this new iso but all prior releases won't.

Copy link
Member

@grahamc grahamc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(great points raised)

@samueldr
Copy link
Member

(light bikeshedding warning) It would be great if the release could define artifacts, and that definition be used to generate the page, instead of making it in the script. This would ensure future additions (hint: aarch64 releases?) to be done without having to hack around in the publishing script.

@worldofpeace
Copy link
Contributor Author

e72e5c7 maybe does the things?
(insert nonbinary shrug emoji)

@samueldr
Copy link
Member

samueldr commented Aug 15, 2019

Here's my 1:1 replica of the bikeshed, with the colour applied to it

The main idea being that there's a job added to the channels, listing job names that will be published by the release script. (Except for pre-19.09 releases, where it uses the fixed manifest equivalent.)

Here are things I don't like from my first draft:

  • Jobs are listed in an unordered manner
  • Jobs are mapped in a hash, the key being the hydra job name, the value being either null (ugh) or the expected filename

And the things I think might ruffle some feathers:

  • Special job
  • Job name starting with _

I am not attached to the implementation, though I think the concept is sound. Let's make each released channels describe their own "publishables".


@edolstra your input would be appreciated. I think this is generally the right direction, but it would be nice to have some advice, and your opinion, about the best way to handle the concept. Thanks!

@worldofpeace worldofpeace changed the title rename iso_graphical to iso_graphical_plasma5 rename iso_graphical to iso_plasma5 Jan 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants