SUSE/aimaas

Indicate what products are under general support

Opened this issue · 7 comments

celan commented

We have no way of clearly showing which product is under General Support. That is a very important information for most users. For now it could be a flag, but we may need other states in the future like "unreleased", "long term support", but that needs more discussion and research.

crazyscientist commented

Given the abstract nature of AIMAAS, I had proposed the current data structure, because the dates, specifying the end of each lifecycle phase, are time-independent.

Lifecycle states/phases like "General support" or "LTSS", on the other hand, are time-dependent. That means, somebody needs to invest time to change this value (manually or via automation). Therefore, I have to admit, that I do not like this idea.

but that needs more discussion and research.

TBH, given certain decisions made by certain people, I suspect that the problem is not the deduction of the current lifecycle state from a set of timestamps indicating the end of each state, but the lack of these timestamps and its implications.

I fully agree, that more discussions are required, but not to find technical workarounds for those decisions but to overturn those decisions.

Just for the record, if we were going in this direction, #100 and #7 would be requisites.

StayPirate commented

Please help me to clarify the matter. If I check Products > Basesystem Module 15 SP4 in AIMAAS I see that end_of_gs is not set. What does it means or how should I interpret that information?

At first glance it looks wrong to me, because I know that Basesystem Module 15 SP4 is under general support, so I expect to see a set date for that filed. Maybe I'm misinterpreting the meaning of the end_of_gs field?

crazyscientist commented

Maybe I'm misinterpreting the meaning of the end_of_gs field?

This is exactly the point I wanted to make with my previous comment. The information in the system should be explicit1 instead of implicit2. I tried to make this point to those responsible for managing the information, but why should somebody listen to me?

Footnotes

  1. i.e. if a product is (or will be) in state GS or LTSS, then the corresponding end_of_* should be set; at least to a rough approximation, which can be corrected later. ↩

  2. Every consumer of the data needs to be aware of the policy driving the product lifecycle and interpret the absence of a value. Any automation built on implicit information is bound to get things wrong3. ↩

  3. Sorry, I'm pretty upset by those arbitrary decisions making every data consumer's life more difficult. ↩

celan commented

I also don't like it, but I cannot overturn this. Therefore we have no other way than to work around with having an explicit field. The advantages outweigh the disadvantages here, because it blocks us from having clear information.

StayPirate commented

Can we set some filed like end_of_gs as mandatory? That would requires responsible people who input such data to make a decision and set a value.

We should consider if any active product have (and will have) a general supported phase. I think that's the case in SUSE.

Moreover, we should make data-owners to upload data their-self. IIRC product's items were added by @crazyscientist instead. I think this behavior may lead to make data-owners less involved in maintaining high-quality data in AIMAAS.

msmeissn commented

what about having "start_of_TYPE" entries perhaps to clearer define the phase?

well, some products we list are "LTSS", so they have no general support phase.

StayPirate commented

well, some products we list are "LTSS", so they have no general support phase.

Right, so my suggestion to make end_of_gs mandatory doesn't apply. Anyway, for these LTSS products I would expect at least end_of_ltss or end_of_espos to be set.

Can we say that at least one of these fields (end_of_gs, end_of_ltss, end_of_espos) should be mandatory?