infrastructure
/
blender-projects-platform
5
1
Issues 20 Projects Activity

Triaging Wizard #78

New Issue
Open
opened 2024-03-15 10:39:40 +01:00 by Iliya Katushenock · 17 comments
Iliya Katushenock commented 2024-03-15 10:39:40 +01:00
Copy Link

This document is a design proposal of Wizard interface for users to improve bug report submitting.

This document mostly based on discussion on Triaging Module Meeting, notes can be seen there: https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580

Everyday around 20 new reports are submitted to Blender. A lot of new reports are the first one for the sender. There are too many things that can be missed in the report, and it is part of the job of the triaging team to spend its time and time of the user to collect all required info.
The Wizard should be the best interface for users to ensure that all necessary info will be added into the report. Each field of the report needs to be checked to be filled by correct and most informative info. Also, wizards are proposed to make it most user-friendly and simple (affordable) for any beginners.

Examples of Wizard

  • Stackoverflow interface to submit questions.

Currently there are 4 available way to have Triaging Wizard

  1. Gitea page to submit reports can be changed to be easily customizable and to support dialog-like report filing. Triaging can be responsible for writing all dialogs and simple scripting if this will be required. Some additional requirements:
    1.1. This should be customizable as just a new Gitea repository with pull requests.
    1.2. Changes in dialogs need to be reflected to user pages without 1-2 days delay. Is there a way to update part of Gitea/projects.blender everyday? Locate this on a separate domain?
    1.3. Changes to bug reporting infrastructure are available to all users/versions of Blender without having to update/download additional tools.
    1.4. It's possible to automate system information collecting in case the Wizard is runned on a user pc, is there a way to automatically attach stack-trace files, system info, messages from blender terminal, and other useful things without asking them from the user?
    1.5. After Mano’s check: Can Gitia template page for bug submitting support dynamic page form and some kind of scripting? How long should we wait for that?
  2. Python addon for blender.
    2.1. Is this bundled with Blender? If so, is it enabled by default?
    2.2. Is there a way to update config (question tree) afterward? Can this addon be built-in and require an internet connection?
    2.3. How do new users know to use this tool instead of the existing “Report a Bug” button?
    2.4. Such addon should not lock current blender instance, is it possible to have such Addon with separate window or with dialog system which will be unrelated with undo ando etc?
    2.5. Sometimes users can not run blender at all, so such Wizard come to be locked to help in bug report submission.
  3. Separate additional application.
    3.1. Is it bundled with Blender or a separate download?
    3.2. Can this tool be updated from the internet after it has been downloaded?
    3.3. How do new users know to use this tool over the standard “Report a bug” button? Add to “Help” menu? Create a pop-up upon Blender crash informing the user of this tool?
    3.5. In the case of maintaining such a tool by Blender, which license should it have? Is it possible to use external libraries..?
  4. Replace the function of the “Help -> Report a bug” button with a Triaging Wizard built into Blender.
    4.1. Is the Foundation ready to add such things in Blender itself? Separate editor?
    4.2. This kind of Wizard can not be used in case Blender can not run.
    4.3. There is no way to update question-tree after blender has been downloaded? Maybe kind of extensions?

Questions for Blender Foundation

  1. Is the Blender Foundation ready to accept such a project?
  2. Which approach does the Foundation prefer from a design and maintenance standpoint?
  3. How many resources could the Foundation spend on this?
    How many resources can such a project take?
    How can the triaging team help here?

Initial plans to start

  1. Figure out if some approaches are even possible (E.G. Can we easily modify the Gitea bug reporting page?)
    We already can edit the bug-report template page to add more info for users in the page of bug submitting.
  2. Create a proposal/basic plan and share it with the Blender foundation, asking the relevant questions from the section above.
  3. Decide upon a design and create a mockup to get feedback on.

Additional features

These features are available for a case of local executable application for bug submitting / Wizard. All of these features are preferable to have and can make bug submitting as efficient as it even possible. But just to start the Triaging Wizard project, it's okay to just know that all of these functions are possible to be added in future, this is not locked things:

  1. Local blender bisecting with downloading blender on the fly.
  2. Handling of memory leaks messages on blender closing, and submitting bug proposing for the user.
  3. Auto bug submitting for blender crash.
  4. Bisecting of blender file (deleting random things in file and asking user if bug still reproducible to reduce size of file or even delete all NDA content and replace all meshes by cubes, all textures by noise, ...).
## This document is a design proposal of Wizard interface for users to improve bug report submitting. This document mostly based on discussion on Triaging Module Meeting, notes can be seen there: https://devtalk.blender.org/t/2024-02-29-triaging-module-meeting/33580 Everyday around 20 new reports are submitted to Blender. A lot of new reports are the first one for the sender. There are too many things that can be missed in the report, and it is part of the job of the triaging team to spend its time and time of the user to collect all required info. The Wizard should be the best interface for users to ensure that all necessary info will be added into the report. Each field of the report needs to be checked to be filled by correct and most informative info. Also, wizards are proposed to make it most user-friendly and simple (affordable) for any beginners. ### Examples of Wizard - Stackoverflow interface to submit questions. ## Currently there are 4 available way to have Triaging Wizard 1. Gitea page to submit reports can be changed to be easily customizable and to support dialog-like report filing. Triaging can be responsible for writing all dialogs and simple scripting if this will be required. Some additional requirements: 1.1. This should be customizable as just a new Gitea repository with pull requests. 1.2. Changes in dialogs need to be reflected to user pages without 1-2 days delay. Is there a way to update part of Gitea/projects.blender everyday? Locate this on a separate domain? 1.3. Changes to bug reporting infrastructure are available to all users/versions of Blender without having to update/download additional tools. 1.4. It's possible to automate system information collecting in case the Wizard is runned on a user pc, is there a way to automatically attach stack-trace files, system info, messages from blender terminal, and other useful things without asking them from the user? 1.5. After Mano’s check: Can Gitia template page for bug submitting support dynamic page form and some kind of scripting? How long should we wait for that? 2. Python addon for blender. 2.1. Is this bundled with Blender? If so, is it enabled by default? 2.2. Is there a way to update config (question tree) afterward? Can this addon be built-in and require an internet connection? 2.3. How do new users know to use this tool instead of the existing “Report a Bug” button? 2.4. Such addon should not lock current blender instance, is it possible to have such Addon with separate window or with dialog system which will be unrelated with undo ando etc? 2.5. Sometimes users can not run blender at all, so such Wizard come to be locked to help in bug report submission. 3. Separate additional application. 3.1. Is it bundled with Blender or a separate download? 3.2. Can this tool be updated from the internet after it has been downloaded? 3.3. How do new users know to use this tool over the standard “Report a bug” button? Add to “Help” menu? Create a pop-up upon Blender crash informing the user of this tool? 3.5. In the case of maintaining such a tool by Blender, which license should it have? Is it possible to use external libraries..? 4. Replace the function of the “Help -> Report a bug” button with a Triaging Wizard built into Blender. 4.1. Is the Foundation ready to add such things in Blender itself? Separate editor? 4.2. This kind of Wizard can not be used in case Blender can not run. 4.3. There is no way to update question-tree after blender has been downloaded? Maybe kind of extensions? ## Questions for Blender Foundation 1. Is the Blender Foundation ready to accept such a project? 2. Which approach does the Foundation prefer from a design and maintenance standpoint? 3. How many resources could the Foundation spend on this? How many resources can such a project take? How can the triaging team help here? ## Initial plans to start 1. Figure out if some approaches are even possible (E.G. Can we easily modify the Gitea bug reporting page?) We already can edit the bug-report template page to add more info for users in the page of bug submitting. 3. Create a proposal/basic plan and share it with the Blender foundation, asking the relevant questions from the section above. 4. Decide upon a design and create a mockup to get feedback on. ## Additional features These features are available for a case of local executable application for bug submitting / Wizard. All of these features are preferable to have and can make bug submitting as efficient as it even possible. But just to start the Triaging Wizard project, it's okay to just know that all of these functions are possible to be added in future, this is not locked things: 1. Local blender bisecting with downloading blender on the fly. 2. Handling of memory leaks messages on blender closing, and submitting bug proposing for the user. 3. Auto bug submitting for blender crash. 4. Bisecting of blender file (deleting random things in file and asking user if bug still reproducible to reduce size of file or even delete all NDA content and replace all meshes by cubes, all textures by noise, ...).
Brecht Van Lommel added the
blender customization
 label 2024-03-15 14:34:07 +01:00
Brecht Van Lommel commented 2024-03-15 16:19:46 +01:00
Owner
Copy Link

I think this type of wizard should be on a website, not built into Blender. Otherwise we'll get users running outdated versions. Some improvements on the Blender side to collect logs and submit them would be good though.

Integrating a wizard into Gitea is probably the best solution, using Javascript to dynamically alter the web page. Some part could also use Go templates. Though I think there is some benefit to not coupling this implementation too tightly to Gitea, for easy testing and in case want to make it a dedicated website later.

It would go into this repo. Updating Gitea with changes to that repo is done manually at the moment, but it's simple and non-disruptive. I think it could be automated to run every hour.
https://projects.blender.org/infrastructure/gitea-custom

I think this would be worthwhile to do. About resources, it would be simplest if someone in the triaging team could implement and maintain this. We don't currently have anyone whose job it's obviously to do this, but I think many developers are capable of doing this. So if needed we could figure something out.

I think this type of wizard should be on a website, not built into Blender. Otherwise we'll get users running outdated versions. Some improvements on the Blender side to collect logs and submit them would be good though. Integrating a wizard into Gitea is probably the best solution, using Javascript to dynamically alter the web page. Some part could also use Go templates. Though I think there is some benefit to not coupling this implementation too tightly to Gitea, for easy testing and in case want to make it a dedicated website later. It would go into this repo. Updating Gitea with changes to that repo is done manually at the moment, but it's simple and non-disruptive. I think it could be automated to run every hour. https://projects.blender.org/infrastructure/gitea-custom I think this would be worthwhile to do. About resources, it would be simplest if someone in the triaging team could implement and maintain this. We don't currently have anyone whose job it's obviously to do this, but I think many developers are capable of doing this. So if needed we could figure something out.
Alaska commented 2024-04-15 09:36:08 +02:00
Copy Link

During the triaging module meeting roughly two weeks ago, a discussion was had about potentially splitting the triaging wizard work into two parts:

  1. Update the Gitea issue template in the Blender repository to be more informative and easier for users to follow in hope it results in higher quality reports.
  2. Then work on something more custom if necessary.

For the "updating the issue template" task, some people were hoping we could make use of the visible option available in Gitea 1.22 (currently in development) to adjust the visibility of certain input fields. It is documented as part of the issue template documenation here: https://docs.gitea.com/next/usage/issue-pull-request-templates

Just to get a general idea of the time line of things, once Gitea 1.22 officially releases, what is the expected time line for the Blender foundation to update to this version of Gitea, assuming no show stopping bugs?

During the triaging module meeting roughly two weeks ago, a discussion was had about potentially splitting the triaging wizard work into two parts: 1. Update the Gitea issue template in the Blender repository to be more informative and easier for users to follow in hope it results in higher quality reports. 2. Then work on something more custom if necessary. For the "updating the issue template" task, some people were hoping we could make use of the `visible` option available in Gitea 1.22 (currently in development) to adjust the visibility of certain input fields. It is documented as part of the issue template documenation here: https://docs.gitea.com/next/usage/issue-pull-request-templates Just to get a general idea of the time line of things, once Gitea 1.22 officially releases, what is the expected time line for the Blender foundation to update to this version of Gitea, assuming no show stopping bugs?
Brecht Van Lommel commented 2024-04-15 10:54:56 +02:00
Owner
Copy Link

We'll probably update within a month after the release? Not really in a rush and might wait for a a bugfix release or two before doing it.

I don't understand why this template should depend on that specific feature. I would expect you'd use javascript and CSS to manipulate what is visible quite heavily anyway, and if you can do that this Gitea feature doesn't seem important.

We'll probably update within a month after the release? Not really in a rush and might wait for a a bugfix release or two before doing it. I don't understand why this template should depend on that specific feature. I would expect you'd use javascript and CSS to manipulate what is visible quite heavily anyway, and if you can do that this Gitea feature doesn't seem important.
Alaska commented 2024-04-15 11:29:55 +02:00
Copy Link

The goal of the triaging wizard project is to improve the bug reporting process to get higher quality bug reports. One area that could be improved upon is the bug reporting page. This can be done via two methods:

  1. Update the issue template that Gitea uses (the issue template file is found here)
  2. Enhance/replace the issue reporting form with Javascript, CSS, etc.

Option 2 is much more flexible, but requires more work from the parities involved. And so far I don't think anyone has volunteered to do it. I'm not sure if this is just because we're still in a planning phase, or if there's issues with avaliable time and/or knowledge.
So as a intermediate step, we were exploring the idea of updating the issue template now (which is very simple to do), then replace/expand upon it with the more flexible custom Javascript and CSS work later on.

To update the issue template, we don't need the visible option from Gitea 1.22. But if we had access to it, we could do a little bit more in this intermediate step.

I was just checking on the timeline of events for the update to get an understanding on if we should just progress with updating the issue template now with the current limitations, or wait until Gitea 1.22 comes out then update then. Or do two updates. One now, then another for Gitea 1.22. That is assuming we do progress with updating the issue template (It was just a proposed idea in the last meeting, and I wanted to gather more information to make a more informed decision in the next meeting).

If you have opinions about the triaging module just skipping the issue template work and going straight to javascript and/or CSS work, then let us know.

The goal of the triaging wizard project is to improve the bug reporting process to get higher quality bug reports. One area that could be improved upon is the [bug reporting page](https://projects.blender.org/blender/blender/issues/new?template=.gitea%2fissue_template%2fbug.yaml). This can be done via two methods: 1. Update the issue template that Gitea uses (the issue template file is found [here](https://projects.blender.org/blender/blender/src/branch/main/.gitea/issue_template/bug.yaml)) 2. Enhance/replace the issue reporting form with Javascript, CSS, etc. Option 2 is much more flexible, but requires more work from the parities involved. And so far I don't think anyone has volunteered to do it. I'm not sure if this is just because we're still in a planning phase, or if there's issues with avaliable time and/or knowledge. So as a intermediate step, we were exploring the idea of updating the issue template now (which is very simple to do), then replace/expand upon it with the more flexible custom Javascript and CSS work later on. To update the issue template, we don't need the `visible` option from Gitea 1.22. But if we had access to it, we could do a little bit more in this intermediate step. I was just checking on the timeline of events for the update to get an understanding on if we should just progress with updating the issue template now with the current limitations, or wait until Gitea 1.22 comes out then update then. Or do two updates. One now, then another for Gitea 1.22. That is assuming we do progress with updating the issue template (It was just a proposed idea in the last meeting, and I wanted to gather more information to make a more informed decision in the next meeting). --- If you have opinions about the triaging module just skipping the issue template work and going straight to javascript and/or CSS work, then let us know.
👍 1
Brecht Van Lommel commented 2024-04-15 15:03:14 +02:00
Owner
Copy Link

Ok, thanks for the details.

I'll keep an eye on the Gitea releases, we can probably updated within a few weeks of the release if needed. But I can't predict when they will release.

I don't really mind one way or the other if the triaging team wants to use just the template or go immediately to more advanced Javascript. I don't have good insight into how much template changes would help, if it seems useful to the triaging team they should feel free to make the changes.

Ok, thanks for the details. I'll keep an eye on the Gitea releases, we can probably updated within a few weeks of the release if needed. But I can't predict when they will release. I don't really mind one way or the other if the triaging team wants to use just the template or go immediately to more advanced Javascript. I don't have good insight into how much template changes would help, if it seems useful to the triaging team they should feel free to make the changes.
👍 1
Alaska commented 2024-04-23 05:17:17 +02:00
Copy Link

Based on feedback from members of the triaging team, it seems likely that we will be going forward with updating the Gitea issue template as an intermediate step.

I have a question for the Blender admins:

  • Should we update the existing bug reporting template, or add a secondary "Bug reporting v2" (Named can be decided later) template?
    • I bring this up becase it seems that when you select Help -> Report a bug in Blender, you are taken to a developer.blender.org page that parses your system information and redirects you to Gitea.
      • If we update the existing bug reporting template, then we will need to adjust this redirecting system at the exact same time. If this is the prefered option, then knowledge about this redirect system would be helpful to obtain so we can update it.
      • If we add a secondary "Bug reporting v2" template, then we can update the Help -> Report a bug button to go straight to our new template without passing information through developer.blender.org. However all old versions of Blender will continue to use the old template resulting in a transition period.

Assuming this is fine, then the triaging module will progress with working on updating the issue template.

I am willing to volunteer some time to update the issue template, but if someone else wanted to do it, just say so.

We did have a discussion about the usefulness of the Visible feature avaliable in Gitea 1.22+ for this intermediate step. There was a general agreement that it can be useful in some situations, but probably isn't neccesary for this first stage.

So we will progress under the assumption that it won't be avaliable.

Based on feedback from members of the triaging team, it seems likely that we will be going forward with updating the Gitea issue template as an intermediate step. I have a question for the Blender admins: - Should we update the existing bug reporting template, or add a secondary "Bug reporting v2" (Named can be decided later) template? - I bring this up becase it seems that when you select `Help -> Report a bug` in Blender, you are taken to a `developer.blender.org` page that parses your system information and redirects you to Gitea. - If we update the existing bug reporting template, then we will need to adjust this redirecting system at the exact same time. If this is the prefered option, then knowledge about this redirect system would be helpful to obtain so we can update it. - If we add a secondary "Bug reporting v2" template, then we can update the `Help -> Report a bug` button to go straight to our new template without passing information through `developer.blender.org`. However all old versions of Blender will continue to use the old template resulting in a transition period. Assuming this is fine, then the triaging module will progress with working on updating the issue template. I am willing to volunteer some time to update the issue template, but if someone else wanted to do it, just say so. --- We did have a discussion about the usefulness of the `Visible` feature avaliable in Gitea 1.22+ for this intermediate step. There was a general agreement that it can be useful in some situations, but probably isn't neccesary for this first stage. So we will progress under the assumption that it won't be avaliable.
🎉 1
Brecht Van Lommel commented 2024-04-23 17:48:18 +02:00
Owner
Copy Link

It would be helpful to see what the new template will look like, to figure out the best way to hook that up to Blender. It might be possible to make the redirect smart enough to reformat the text for a new template, or maybe it's impractical.

I don't know where exactly this redirect is configured, @Sergey set this up. I think it's just a one line regular expression in nginx or Apache.

It would be helpful to see what the new template will look like, to figure out the best way to hook that up to Blender. It might be possible to make the redirect smart enough to reformat the text for a new template, or maybe it's impractical. I don't know where exactly this redirect is configured, @Sergey set this up. I think it's just a one line regular expression in nginx or Apache.
Alaska commented 2024-04-23 23:41:16 +02:00
Copy Link

It would be helpful to see what the new template will look like, to figure out the best way to hook that up to Blender.

The main idea proposed for improving the report form with this intermediate step is to break the report form up into seperate steps. So instead of having 1 text box, we would have multiple. Here is a quick mockup Germano made a while ago. We do plan to make alterations to this, but I don't expect the layout to deviate much.

Germano Mockup.jpg

The new link to prefill information will look something like this:

{link_to_issue_template}&field:os={OSINFO}&field:gpu={GPUINFO}&field:v_broken={BLENDERINFO}

For example:
https://projects.blender.org/mano-wii/testes/issues/new?template=.gitea%2fissue_template%2fbug.yaml&field:os=MYOPERATINGSYSTEM&field:gpu=NVIDIAGPU&field:v_broken=402

Hopefully it should be simple enough to use regular expression to extract this information and redirect it to the relevant fields.

> It would be helpful to see what the new template will look like, to figure out the best way to hook that up to Blender. The main idea proposed for improving the report form with this intermediate step is to break the report form up into seperate steps. So instead of having 1 text box, we would have multiple. Here is a quick mockup Germano made a while ago. We do plan to make alterations to this, but I don't expect the layout to deviate much. <details> ![Germano Mockup.jpg](/attachments/51710dd7-664a-40d3-9db7-0940bda7281b) </details> The new link to prefill information will look something like this: ``` {link_to_issue_template}&field:os={OSINFO}&field:gpu={GPUINFO}&field:v_broken={BLENDERINFO} ``` For example: https://projects.blender.org/mano-wii/testes/issues/new?template=.gitea%2fissue_template%2fbug.yaml&field:os=MYOPERATINGSYSTEM&field:gpu=NVIDIAGPU&field:v_broken=402 Hopefully it should be simple enough to use regular expression to extract this information and redirect it to the relevant fields.
Germano Mockup.jpg
183 KiB
Sergey Sharybin commented 2024-04-24 09:45:03 +02:00
Owner
Copy Link

@brecht The redirect is handled by the developer.b.o site. We could move the logic from regex-based to a script, to ease its development and maintainability.

For moving forward I would really strongly advocate against adding any formatting or web-application specific logic on Blender side. The way how it was done is a mistake. The way it should be done is to have an intermediate URL, to which Blender says it wants to submit an artifact of specific type, with specific fields. For example, https://redirect.blender.org/?type=bug&action=submit&os=macOS&gpu=Apple M2. It would not take long time to set it up, and it will solve a lot of problem w.r.t template, fields, issue tracking system, etc, in a way that keeps all Blender versions work without spreading the redirect/adjust/versioning code all over the webservers.

@brecht The redirect is handled by the developer.b.o site. We could move the logic from regex-based to a script, to ease its development and maintainability. For moving forward I would really strongly advocate against adding any formatting or web-application specific logic on Blender side. The way how it was done is a mistake. The way it should be done is to have an intermediate URL, to which Blender says it wants to submit an artifact of specific type, with specific fields. For example, `https://redirect.blender.org/?type=bug&action=submit&os=macOS&gpu=Apple M2`. It would not take long time to set it up, and it will solve a lot of problem w.r.t template, fields, issue tracking system, etc, in a way that keeps all Blender versions work without spreading the redirect/adjust/versioning code all over the webservers.
🎉 1
Brecht Van Lommel commented 2024-04-24 20:48:04 +02:00
Owner
Copy Link

I guess extracting the OS, GPU and Blender version from the old redirect is not that difficult, to keep compatibility with older Blender versions. Even just with regex if needed, it doesn't have to be very smart.

I'm not sure what the next step would be though. If this is moved to a script, which language would that be in? Can someone from the triaging team implement that, or do you prefer to handle it?

I guess extracting the OS, GPU and Blender version from the old redirect is not that difficult, to keep compatibility with older Blender versions. Even just with regex if needed, it doesn't have to be very smart. I'm not sure what the next step would be though. If this is moved to a script, which language would that be in? Can someone from the triaging team implement that, or do you prefer to handle it?
Alaska commented 2024-04-25 06:22:19 +02:00
Copy Link

Just so I'm understanding correctly, this is generally what would be prefered:

  1. The existing bug reporting template is updated.
  2. At the same time developer.b.o is updated to properly fill out the new template.
  3. At some point in the future, new versions of Blender will transistion to sending information to redirect.blender.org in a clean format, allowing it to be easy adapted to lots of different websites and bug report templates should things change in the future.

There's still an issue. At this point we're maintaining two redirect systems. developer.b.o for old versions of Blender and redirect.blender.org for new versions of Blender.
And if the issue template under goes another major adjustment (which may happen if we implement some custom stuff), then both redirects would need to be updated again. Which just adds extra work.

Maybe we update the existing template, developer.b.o, and setup new versions of Blender to use redirect.blender.org. Then if the bug reporting template under goes another major change in the future, we set it up as a "new template", reconfigure redirect.blender.org to point to the new template and leave developer.b.o pointing to the old template?

Another possibility is that by the time this "future major change" happens, the the versions of Blender using developer.b.o may be really old, and if we don't want to have two bug reporting templates, then developer.b.o could just show you a simple HTML page with your system information, Blender version, etc, and a link to the new bug reporting page.

Just so I'm understanding correctly, this is generally what would be prefered: 1. The existing bug reporting template is updated. 2. At the same time `developer.b.o` is updated to properly fill out the new template. 3. At some point in the future, new versions of Blender will transistion to sending information to `redirect.blender.org` in a clean format, allowing it to be easy adapted to lots of different websites and bug report templates should things change in the future. There's still an issue. At this point we're maintaining two redirect systems. `developer.b.o` for old versions of Blender and `redirect.blender.org` for new versions of Blender. And if the issue template under goes another major adjustment (which may happen if we implement some custom stuff), then both redirects would need to be updated again. Which just adds extra work. --- Maybe we update the existing template, `developer.b.o`, and setup new versions of Blender to use `redirect.blender.org`. Then if the bug reporting template under goes another major change in the future, we set it up as a "new template", reconfigure `redirect.blender.org` to point to the new template and leave `developer.b.o` pointing to the old template? Another possibility is that by the time this "future major change" happens, the the versions of Blender using `developer.b.o` may be really old, and if we don't want to have two bug reporting templates, then `developer.b.o` could just show you a simple HTML page with your system information, Blender version, etc, and a link to the new bug reporting page.
Sergey Sharybin commented 2024-04-25 14:54:42 +02:00
Owner
Copy Link

@brecht I think the easiest would be to use PHP, as that system is already equipped with everything needed for it (and is already used for task redirection). And also think easiest would be if I put some things in-place, before someone else can pick the code up. As this will also be a nice opportunity to consolidate the task redirector in a more clean manner.

I would stay away from the Web-server level regex, as it is very hard to debug, and we do not have any staging environment for it. And there are also complications coming form the fact that some other sites are on that config.

@Alaska Depends on priority. If it is something really UNBREAK-NOW, then sure, we can go deeper in technical debt with the developer.b.o URL. Otherwise I'd advocate for not going deeper in debt, put redirector in-place, and then update Blender to the new reditector. If I can focus on it, it should not take that much time to implement.

@brecht I think the easiest would be to use PHP, as that system is already equipped with everything needed for it (and is already used for task redirection). And also think easiest would be if I put some things in-place, before someone else can pick the code up. As this will also be a nice opportunity to consolidate the task redirector in a more clean manner. I would stay away from the Web-server level regex, as it is very hard to debug, and we do not have any staging environment for it. And there are also complications coming form the fact that some other sites are on that config. @Alaska Depends on priority. If it is something really UNBREAK-NOW, then sure, we can go deeper in technical debt with the `developer.b.o` URL. Otherwise I'd advocate for not going deeper in debt, put redirector in-place, and then update Blender to the new reditector. If I can focus on it, it should not take that much time to implement.
Sergey Sharybin commented 2024-04-25 18:48:14 +02:00
Owner
Copy Link

I've committed an initial state of the redirector: https://projects.blender.org/infrastructure/redirect-website
It probably still need love and such, but is a beginning.

For moving forward I think something like this:

  • Deploy the website on our servers
  • Take over the current developer.b.o redirects
  • Agree on the URL query parameters, and implement them
  • Synchronize changes in the issue template for Gitea, and the redirector, and deploy them
  • Switch Blender to use redirector instead of developer.b.o

The last two could happen in any order.

I've committed an initial state of the redirector: https://projects.blender.org/infrastructure/redirect-website It probably still need love and such, but is a beginning. For moving forward I think something like this: - Deploy the website on our servers - Take over the current `developer.b.o` redirects - Agree on the URL query parameters, and implement them - Synchronize changes in the issue template for Gitea, and the redirector, and deploy them - Switch Blender to use redirector instead of developer.b.o The last two could happen in any order.
❤️ 2 🎉 1
Sergey Sharybin commented 2024-04-29 16:40:12 +02:00
Owner
Copy Link

The site has been deployed. It is ready to handle direct requests to it. I did not make it so the old developer.b.o type of URLs are routed via it just yet.

I've made a PR against Blender to use the new style of URL: blender/blender#121215

The site has been deployed. It is ready to handle direct requests to it. I did not make it so the old developer.b.o type of URLs are routed via it just yet. I've made a PR against Blender to use the new style of URL: blender/blender#121215
👍 2
Philipp Oeser commented 2024-04-30 10:52:06 +02:00
Copy Link

Great to see progress, thx everyone involved 🥇

Great to see progress, thx everyone involved 🥇
👍 1
Alaska commented 2024-05-03 03:21:23 +02:00
Copy Link

During discussion around the issue template design, there was a request to limit the size of files that users can upload.

Upon investigation, it appears this can be done by editing the app.ini Gitea uses with something like this:

[attachment]
ENABLE = true
PATH = data/attachments
MAX_SIZE = 50
MAX_FILES = 20

How do the Blender admins feel about this?

We may want to have a disucssion on what the limit should be before making any changes if you want to do them.

During discussion around the issue template design, there was a request to limit the size of files that users can upload. Upon investigation, it appears this can be done by editing the `app.ini` Gitea uses with something like this: ``` [attachment] ENABLE = true PATH = data/attachments MAX_SIZE = 50 MAX_FILES = 20 ``` How do the Blender admins feel about this? --- We may want to have a disucssion on what the limit should be before making any changes if you want to do them.
Philipp Oeser commented 2024-05-03 08:59:06 +02:00
Copy Link

I dont think limiting the max size will help us much.

There are enough (somewhat legit) cases that need space

  • a single 4k fullfloat Multilayer EXR with all enabled passes is already above 50MB
  • 3d scans
  • alembic containing animation
  • ...

I am not against the emphasis on simplification, just dont think it is possible in every case to push it below 50MB (in some cases - e.g. when users get an exported file from another software that they dont even have access to - it might be impossible to squeeze it down in blender alone).

In practice, this will probably end up with the user just uploading the file somewhere else. We could just refuse to accept external storage as well (because links can end up being dead after a while), but as mentioned, I do believe there are cases that just (rightfully) demand some space.

Imo, time is probably better spent making some good guides/tutorials on the process of simplification rather than putting a hard barrier on upload sizes (and then dealing with the "secondary" issue of external storage).

I dont think limiting the max size will help us much. There are enough (somewhat legit) cases that need space - a single 4k fullfloat Multilayer EXR with all enabled passes is already above 50MB - 3d scans - alembic containing animation - ... I am not against the emphasis on simplification, just dont think it is possible in every case to push it below 50MB (in some cases - e.g. when users get an exported file from another software that they dont even have access to - it might be impossible to squeeze it down in blender alone). In practice, this will probably end up with the user just uploading the file somewhere else. We could just refuse to accept external storage as well (because links can end up being dead after a while), but as mentioned, I do believe there are cases that just (rightfully) demand some space. Imo, time is probably better spent making some good guides/tutorials on the process of simplification rather than putting a hard barrier on upload sizes (and then dealing with the "secondary" issue of external storage).
👍 1
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
Labels
Clear labels   
blender customization

   
bug

Something is not working

  
buildbot

   
deployment

   
gitea feature request

   
help wanted

Need some help

  
policy
No Label
blender customization
bug
buildbot
deployment
gitea feature request
help wanted
policy
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
5 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: infrastructure/blender-projects-platform#78
No description provided.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?