I like the proposal itself (I also believe minimal install should not contain X), but I don't think QA should be the authority that decides and dictates this condition.

I think currently it is very unclear who manages different flavors of Fedora and who gets the decision powers. Who owns the desktop flavor (or should I call it a spin?)? Who owns the minimal flavor? Who should I report bugs to? Who decides what should be there and what should be not? I don't think FESCo should be bothered every time we want to add a remove a package. It must be someone else.

I'm currently not very clear on these matters, especially wrt minimal flavor. I suspect desktop SIG would own the desktop flavor, but it's very possible that no-one manages minimal flavor at all. I tried to find some document on our wiki that would address this, but I failed. So any explanations are welcome (I guess adamw will know, he knows everything).

After this is cleared up, I think we should talk to the minimal flavor maintainer (or create one first?), whether this is the current policy or not ("no X in minimal") and whether Fedora release should be blocked if some X package happens to enter the set.

The closest document we have is probably http://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups

As a representative of the cloud sig, I have a strong vested interest in a sane minimal package set. I'm happy to be a "minimal flavor maintainer" if we need one. Bill Nottingham (release engineering) has traditionally been heavily involved here -- see https://fedoraproject.org/wiki/Features/ReworkPackageGroups.

Should I file a ticket with FESCO asking for a decision on the idea in general?

Replying to [comment:1 kparal]:

I like the proposal itself (I also believe minimal install should not contain X), but I don't think QA should be the authority that decides and dictates this condition.

Correct QA is not the authority to handle this comps maintainer(s) and arguably releng are

Okay, but, regardless of the authority, which we can figure out, a release criterion is the sensible manifestation of that decision, and ''that'' is QA.

Replying to [comment:4 mattdm]:

Okay, but, regardless of the authority, which we can figure out, a release criterion is the sensible manifestation of that decision, and ''that'' is QA.

Yes true.

Closing this ticket since we already have criteria that covers minimal install and packages and their dependency ( or lack there of ) which would automatically cover this if it's decided that the relevant packages that have been mentioned in this ticket gets removed from comps minimal group.

Replying to [comment:5 johannbg]:

Closing this ticket since we already have criteria that covers minimal install and packages and their dependency ( or lack there of ) which would automatically cover this if it's decided that the relevant packages that have been mentioned in this ticket gets removed from comps minimal group.

Wait, ''what''? Unless I'm misunderstanding you, this is backwards. The issue isn't making sure dependencies don't get removed; it is taking care not to grow (a particular set of) new ones.

If I ''am'' misunderstanding, can you point me to the existing criteria you are referring to?

We as has been stated by both Kamil and myself are not responsible on what is in particular comps group. We do not decide what's shipped in those and we already have in place criteria that handles unresolved package dependency ( see item nr 3 in the alpha criteria ) which might be the only fallout from this encase those responsible decides to make this change and we do not add criteria that apply to specific package(s).

I think you are entirely missing the point here. This is not about "unresolved package dependency", nor is it about deciding what's specifically in a particular comps group. It's about setting a basic standard.

See https://bugzilla.redhat.com/show_bug.cgi?id=874378 for background.

Again, it's fine to say "this is pending a decision by someone else on whether we want this particular requirement", but assuming general consensus on that, this

1. ''isn't'' covered by anything else
2. should be.

Alternative implementations might be:

B. More vague about the specifics: "No package in the minimal install set may have a dependency chain which includes a graphical windowing system. Packages must split functionality requiring this into subpackages, or be removed from the minimal package set."

C. Move specifics entirely to Some Other Place, as many of the existing release criteria do: "No package in the minimal install set may have a dependency chain which includes a package in the list of packages not allowed in the minimal install. Packages must split functionality requiring these dependencies into subpackages, or be removed from the minimal package set."

I'm not keen on B because it seems prone to misinterpretation. Option C would be fine, but I think the extra level of indirection is unnecessary complication in this case.

mattdm, please excuse Johann, he's known for acting in a very impolite way.

Johann, please don't close this ticket after every comment, it's annoying and rude. Let's give other QA members (and anyone else) chance to express their opinion as well. Thanks.

I'll read the links mattdm posted and reply today or tomorrow, as time permits.

Dependency explosion is a serious issue, and probably will require a refactoring of several packaging approaches into either a: non-X and full pair, or a base and -GUI pair. But there are other useful axes for partition: Sound, and no-sound, Display and no-display, Server and non-server, all come to mind

The need is clear as the first comment mentions, and the tactics to get there have to start somewhere. I saw pkgconfig pulled in, as I tried to get a minimal X install up yesterday, and that is just wrong ;)

If QA only means 'lights up and does not crash', it may well be out of scope here ... but until an alternative venue is found, it seems a fair topic for discussion here

It's not our decisions to decide what is and what is not supposed to be in various comps group and adding a criteria that specifically checks for what is or what no supposed to be in those groups will be near impossible to maintained and in general does not scale.

You might want to check with releng or autoqa who could automatically check for "only those dependency" and first and foremost before all of the above points I just mentioned can be made those changes will need to be approved first by the comps maintainers.

Matthew, I read the document you linked, I saw that you created http://fedoraproject.org/wiki/SIGs/Minimal_Core and I saw you started discussion in devel list. Great job!

I think you should create some high-level goals of your SIG (e.g. "No X libraries in the minimal system", maybe with some generic exceptions) and FESCo should bless it. The concrete issues would be then decided by the SIG according to this high-level goals, without bothering FESCo. This way QA have no say in what should and what should not be included, and that is the correct way, we don't want to have any decision powers here.

Currently we often have too much power - we create release criteria (even though we try to get feedback from other teams), we find bugs in Fedora, and we decide whether the bug violates the criteria. It's similar to having a single entity to be a parliament, police and judge, all at once. And we all know that's not a good idea.

So I'm very glad that you started the SIG. FESCo (and users of Fedora) will decide the high level goals (the parliament), we will be the police, and you will be the judges.

Now, the core question still remains - should we have a release criteria matching your goals? I think we should first wait to see what requirements you come up with and then decide whether the requirements are hard blockers. Because we are trying to include only the important criteria that are critical to making a Fedora release. And I'm not fully sure whether a package that got included in the minimal install and brings 10 more X libraries as dependencies is a blocker or not. I guess cloud/rhev/similar people often use netinst/pxeboot installations and therefore some hiccups can be fixed even after release by editing comps.xml (comps are downloaded before installation, aren't they?). Therefore it might not be critical to stop the release. That doesn't mean we can't accept it as NTH and push the fix during freeze periods or something.

I think this should get discussed when we have some tangible outputs from your new SIG. What do you think?

Thanks Kamil. That sounds reasonable. (Too bad trac doesn't have a "deferred" state.)

It's my opinion that a few key things like this need to go in the release criteria because otherwise they have no teeth. There are plenty of other release criterion which could technically be fixed after the fact (like "no fuzzy menu items"). But I'm happy for FESCO to make the call.

matt, just in case you wonder why I haven't said anything - I think kparal is entirely on point in everything, and have nothing to add. comment #15 covers the situation perfectly for me.

Matt is it ok to close this ticket and you can just reopen it once the minimal sig comes to be or fesco decision has been made if need be or are you wondering or waiting for someone else to comment on the ticket?

I would resolve it but none of the resolutions seem appropriate -- it's not fixed, worksforme, invalid, wontfix, or duplicate. I guess it's up to your workflow, but my preference (absent a "deferred" state) would be to leave it open and then we'll come back to it shortly.

mattdm: current thoughts? :)

The Base Design Working Group is really the logical successor to the Minimal Core SIG that I proposed -- so, that's good. Additionally, with the cloud/server/workstation split, it probably makes more sense to talk about this specific criterion in terms of what goes on the cloud image (even if I do hope base design continues to care about it).