On Wednesday 2019-10-30 12:23, Lubos Kocman wrote:

This survey is concerning package changelog in IBS. Example: https://build.opensuse.org/package/view_file/openSUSE:Factory/bash/bash.chan...

**We (core team*) would like to implement one of (or combination) presented solutions in order to improve current Submit Review Process. This process currently requires process exceptions in specific cases concerning changelog changes.**

Here is list of identified use cases which helped us to form our two proposals https://paste.opensuse.org/76800949

Option 1: Trimming changelog to only changes relevant to given release as there seems to be nobody (no UserStory provided) interested in older records and leave policy as it is. Option 2: Extend current policy to explicitly list cases where we can amend existing records and document consequences.

Factory allows record amending so long as the gist of "recently" made changes are preserved. Bug refs, spello fixes, whitespace trimming (goes towards story 3). The question, thus, is how much recentness people want. Rebase: Now, story 1 and 2 tell of developers wishing to essentially copypac from Factory to SLE. That is a wholly different topic from a time-based cutoff of a .changes file: For the end-user, upgrading kernel 4.12.4 to 5.3 constitues a *linear* move forward, even if the internal development history is actually {going backwards from 4.12.4 to the common ancestor 4.12.0, then forward on another branch that leads to 5.3}. This is how bugrefs get lost, and why this could be seen as undesirable. Likewise, the changes file now contains mentions of Linux 5.0, 5.1, 5.2, etc. which do not have much value to the user who was delivered a one-step change from 4.12.4 to 5.3. I have no definitive opinion on the matter. Looking at Leap:15.X:Update, some packages do get this "rebase" action, though it is generally much less of a change than what kernel-source does, so keeping the bugrefs (if any) is not too much(?) work. Second, there is generally a history loss at the start of a series, i.e. Leap:16, because that branches anew from Factory and thereby loses items from Update:15. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi, On 10/30/19 7:23 AM, Lubos Kocman wrote:

Hello all!

I'd like to ask you to participate in a following survey concerning Code Submit Reviews specifically changelog changes: https://www.surveymonkey.de/r/TVTBYTZ

This survey is concerning package changelog in IBS. Example: https://build.opensuse.org/package/view_file/openSUSE:Factory/bash/bash.chan...

**We (core team*) would like to implement one of (or combination) presented solutions in order to improve current Submit Review Process. This process currently requires process exceptions in specific cases concerning changelog changes.**

Here is list of identified use cases which helped us to form our two proposals https://paste.opensuse.org/76800949

Thanks for putting the use cases together. Reading through them shows, at least to me, clear conflicts of interest. For example parsing the changelog to see which bugs, CVEs were addressed would require a complete changelog from the beginning of time, i.e. the -Initial build entry in the changelog. This is in conflict with the "we need more space for stuff on the DVD" as well as the idea of treating a package as "new" when a new (stable) distribution stream is created. Maybe for the kernel maintainers it would make sense to have an - Initial build 5.3 bsc#.... CVE-.... entry with a collection of all bugzilla and CVE IDs that were mentioned in the changelog of the previous kernel in the new changelog. That of course in and off itself becomes a very long list if we consider the full history (20+ years for the kernel). Thus there is probably a judgement needed how far we need to go back. Does it really make sense to have the very first CVE fixed in the kernel still mentioned in the changelog for the 5.3 kernel? Anyway, back to the higher level. Overlay to the seemingly opposing interests of the use cases the different modes of package maintenance, i.e. patches for bugs vs. version updates and things get quite messy w.r.t. requirements. What I am missing is the proposed solution(s) and the reasoning behind the solution(s) as well as to how the proposed solution(s) addresses the use cases provided. Last but not least the proposed solution(s) would have to include comments as to how it addresses the discrepancy between SLE and :Factory. In :Factory packages are a continuum, i.e. everything from the beginning of time should probably be in the changelog. In short, I am not certain how "Trimming changelog to only changes relevant to given release as there seems to be nobody (no User Story provided) interested in older records and leave policy as it is." "Extending current policy to explicitly list cases where we can amend existing records and document consequences." "Combination of above" presents a solution to the challenges. Or is the idea to make the live of the reviewers easier to foster a better understanding of what to accept and what to reject? But in this case "Combination of above" might as well equate to "accept whatever the package maintainer thinks is appropriate". I think rather than providing a multiple choice option it would be great if we had a proposal that modifies the guidelines and provides wiggle room to cover the use cases. Using the example above it could read as follows. "For inclusion in a new stable distribution release the package maintainer may choose to trim the changelog to eliminate all entries prior to the date when the package is included in the new distribution. At this point the changelog begins with - Initial build - Version - List of all CVE and bug references from the dropped changelog entries " Such wording would probably cover the kernel maintainers use case, and others. Collection of CVE and bug references from previous changelogs can certainly be automated, again som etimelimit probably makes sense. The language also allows those that maintain packages in SLE essentially via copypac to continue to have a changelog of a package from the beginning of time. The later maybe unnecessary if in :Factory we can also trim the changelog following the above example. Anyway, I think the multiple choice selection presented is rather confusing as it does not provide any details as to how this would work in practice. Later, Robert -- Robert Schweikert MAY THE SOURCE BE WITH YOU Distinguished Architect LINUX Technical Team Lead Public Cloud rjschwei@suse.com IRC: robjo -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 11. 11. 19, 17:35, Lubos Kocman wrote:

Hello team,

I'd like to share results of the survey results. We've received 54 responses in total.

* Extending current policy to explicitly list cases where we can amend existing records and document consequences. 61.11% 33 votes

* Trimming changelog to only changes relevant to given release as there seems to be nobody (no User Story provided) interested in older records and leave policy as it is. 20.37% 11 votes

* Combination of above 18.52% 10votes

I've already scheduled a next steps meeting with the core team for Tomorrow 15-15:30 CEST, where we'd like to discuss the overall feedback and raised concerns and identify next steps. Please reach out to your team representative (all are in cc of the email) to make sure that your concern is being addressed.

I thought the survey was disputed by many of us. The results are irrelevant IMNSHO, sorry. thanks, -- js suse labs -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org