Delay LTS baseline selection by 2 weeks or 4 weeks?

[Mark Waite]

There are several regressions in the current weekly releases that make me concerned.  The LTS baseline selection is scheduled to be made next Wednesday, April 20, 2022.  I don't think that we're ready to choose the LTS baseline.

I propose that we delay LTS baseline selection by either 2 weeks or 4 weeks to allow time to correct those regressions and assure that the next LTS will be a great experience for users.

I'll add an item to the UX SIG agenda for today so that we can discuss it.

Regressions that worry me include:

• JENKINS-67849    Organization folder not displayed if --prefix used
• JENKINS-68251    Missing images on old plugins
• JENKINS-68250    Missing images on old plugins
• JENKINS-68022    Missing images on old plugins
• JENKINS-68129    Credentials plugin domains and agent labels presented badly
• JENKINS-68097    Credentials plugin domains and agent labels presented badly
• JENKINS-67902    Matrix auth plugin missing tooltips
• JENKINS-68103    Build progress bar clicks to different location
• JENKINS-67933    Plugin search field moved too far right

Regressions that are less worrisome to me include:

• JENKINS-67966    Labels of parallel sections of build log overlap colored region of build log
• JENKINS-68205    Strange line break pattern in Firefox
• JENKINS-68042    Help button wrong
• JENKINS-68031    Bottom border is cut off
  

Thanks,

Mark Waite

[Alexander Brandes]

Heyo Mark,

I've rearranged your blocker list a bit, based on a different impact:

Blocker:

• JENKINS-67849  Organization folder not displayed if --prefix used
  

• Definitely something that should be addressed in a weekly before, launching Jenkins in that way or using folder icons is a common practice.

Major:

• JENKINS-68129, JENKINS-68097
  Other plugins are impacted by it as well, which are working with dropdowns here, e.g. the maven integration if it lists fingerprints for maven modules.

Minor:

• JENKINS-67902
  I agree, losing tooltips here is annoying, but I wouldn't postpone a LTS release for it, this can easily be shipped as a point release if it is fixed later on.

Trivial:

• JENKINS-68251, JENKINS-68250, JENKINS-68022
  I wouldn't label broken icons as blocker. Plugins affected by it didn't use the API in the first place to access the icon and relied on the icon path, which is not a great way to start with.
  In the meantime, I've migrated and released over 70 plugins, since Jan started the initial PR last year. This is more of an ongoing task (which should be tracked as Epic on Jira) which can be addressed in a "spotted on sight" way, considering the ease of migration.
  In case the plugin is abandoned, the author went MIA or other circumstances prevent a release of a plugin, I went ahead and adopted several ones to perform a release, which is no show stopper either.

These are only my two cents, but I guess it makes my aspect a bit more clear.

~ Alex

[Basil Crow]

Regarding the SVG icon transition, we have a responsibility to our users to perform due diligence when making breaking changes to the ecosystem. When making such changes, it is incumbent on us to enumerate the affected plugins and, for each one:

• If the plugin is actively maintained, ensure a pull request has been created and ensure the pull request is merged and released prior to shipping the LTS.
• If the plugin is not actively maintained, make a conscious decision to leave it behind, ideally also filing an update-center2 PR to formally mark the plugin as deprecated in the Update Center.

This process has been followed for many other transitions, including JEP-227 and JEP-233.

Tables-to-divs did not follow this process, and it resulted in a slow trickle of complaints from users as broken plugins were discovered, one by one, during upgrades. This was an unpleasant and avoidable burden on end users, who discovered that their system was broken after upgrading. This was an unpleasant and avoidable burden on those who support end users, including myself.

We need to enumerate the list of affected plugins and make a conscious decision about each one prior to shipping the LTS, and I consider the lack of such an enumeration a blocker. I have filed JENKINS-68251 to track this issue.

[Mark Waite]

On Wednesday, April 13, 2022 at 8:01:07 AM UTC-6 Mark Waite wrote:

I propose that we delay LTS baseline selection by either 2 weeks or 4 weeks to allow time to correct those regressions and assure that the next LTS will be a great experience for users.

I should have been more precise in my description.

My proposal is that the delay we take in order to correct the regressions will be added to all upcoming dates in the release calendar for 2022.  If we delay 2 weeks, then the LTS that would have been released June 1, 2022 would instead be released June 15, 2022.  All releases after that follow the 4 weeks per cycle cadence.  The next release after the June 2.3xx.1 would be July 13, 2022 rather than June 29, 2022.

Mark Waite

[Tim Jacomb]

I've created a dashboard to show the current open UX regressions:

https://issues.jenkins.io/secure/Dashboard.jspa?selectPageId=21754#Filter-Results/22297

Currently I think we have plenty of time till LTS and we can backport bug fixes after selection.

Thanks

Tim

--
You received this message because you are subscribed to the Google Groups "Jenkins User Experience" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-ux...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-ux/4d458c46-88e0-447c-a37b-6dd509269a67n%40googlegroups.com.

[Basil Crow]

We delivered eight (8) UX regression fixes, in 2.344, with more to
come in 2.345. I would like to personally thank everyone who
contributed to this concerted effort, including

- Alexander Brandes
- Feng-Yi Xue
- Jan Faracik
- Tim Jacomb
- Yu-Xun Chen
- Zbynek Konecny

Your contributions are highly appreciated, and they put us firmly on
the path toward delivering a stable LTS release.

On Thu, Apr 14, 2022 at 2:29 PM Tim Jacomb <timja...@gmail.com> wrote:
> I've created a dashboard to show the current open UX regressions:
> https://issues.jenkins.io/secure/Dashboard.jspa?selectPageId=21754#Filter-Results/22297

This dashboard is very helpful. My understanding is that for a ticket
to appear on this dashboard, it must first be triaged. Over the past
few weeks, I (along with Adrien Lecharpentier) have spent a
significant amount of time triaging incoming UX issues. Roughly
speaking, my process is as follows:

- Reproduce the issue on my local machine.
- Find a recent release where the problem cannot be reproduced.
- Run "git bisect" to find the commit that introduced the regression.
- Update the issue with a "Caused By" link and notify the author on GitHub.
- Add the "(regression in 2.xyz)" text to the title of the issue.
- Add the "ux" and "regression" labels to the issue.

While I have found a few ways to optimize the process, the process is
still very laborious and can take hours or even days if round-trip
communication with the issue reporter is required. While I am willing
to keep helping out as we get closer to the LTS release, I do not
think I can sustain this level of involvement indefinitely, especially
after the LTS release is shipped. Yet untriaged UX tickets continue to
come in every week, and past experience predicts that the volume of
tickets will only increase after the LTS release is shipped. Therefore
I think we should create a process that allows others to work on issue
triage.

Allow me to propose that we define a label, say "ux-untriaged", that
indicates a need for someone to take the steps I described above. This
could be added to the dashboard mentioned above in a separate panel
alongside the confirmed regressions. As issues are triaged, they would
either move to the confirmed regressions panel or disappear from the
dashboard entirely if deemed invalid.

I would be happy to conduct a session where I demonstrate the process
I have been using and explain how to do a "git bisect" efficiently if
anyone is interested. What do you all think?

Basil

[Tim Jacomb]

Thanks, sounds good

I've updated the dashboard:

https://issues.jenkins.io/secure/Dashboard.jspa?selectPageId=21754

--
You received this message because you are subscribed to the Google Groups "Jenkins User Experience" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-ux...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-ux/CAFwNDjonP2OD73Ec34xT14dar0sWWF6L41rYH5-YbHZ6nJpNng%40mail.gmail.com.