search

nvisionative / nvQuickSite

nvQuickSite is a desktop installation app for DNN, the world's most popular ASP.NET-based CMS. This app allows you to easily install DNN onto any environment that meets the minimum system requirements for DNN to be installed.
http://www.nvquicksite.com
47 stars 14 forks source link

Support for Release Candidates #173

Closed WillStrohl closed 5 years ago

WillStrohl commented 6 years ago

Add a setting that allows one to show/hide current release candidates so they can be tested.

david-poindexter commented 6 years ago

@hismightiness sounds great - thanks for the recommendation @iJungleboy

david-poindexter commented 6 years ago

By the way, right now there there are no "Settings", so this will require some UI/UX work.

iJungleboy commented 6 years ago

I wouldn't do it over settings - maybe more something like this:

image

WillStrohl commented 6 years ago

I think we need to do this a different way, and distributions is not on the radar right now. One of the core principles behind nvQuickSite is simplicity and speed to get DNN installed. The tabbed concept breaks the current UX paradigm, and it introduces complexity.

iJungleboy commented 6 years ago

@hismightiness I partially agree. But I could remove one complexity, maybe allowing for the tabs :)

For example, if we remove the "local installation" field (again a complexity some people don't understand) - "do I need to fill this in?" and also put that behind a tab, I think we could get it all together. The initial dialog would be even simpler (just a dropdown), and the "advanced" features would all be behind other tabs (or another kind of ui)

david-poindexter commented 6 years ago

@iJungleboy we are leaning towards a "Settings" UI. Generally speaking tabs within tabs doesn't lead to good UX.

I do agree that many people are confused by the Local Install Package section. Perhaps that too should be hidden by default since the majority of users do not use local install packages.

Several things to consider here. Thanks to all for the input and ideas!

abukres commented 6 years ago

Why not just have the release candidates in the same current list? Once the rtm release is out, remove the RC's from the list since no one is going to be interested in them anymore. Keep it simple.

@nvisionative I use the Local Install Package once I download a package. I don't want to download it again. I would like to see the full path of the package in the text box if the app knows the package exists in the downloads folder. Right now it's empty even though the zip file exists.

david-poindexter commented 6 years ago

@abukres I think you are onto something there. We will make note of that suggestion and try it out with the next Release Candidate. That would require no code changes - me likey! 😄

Great idea regarding local packages that have already been downloaded. Can you create a new issue for that one since it is unrelated to RC support? Thanks!

abukres commented 5 years ago

@nvisionative I am not seeing any movement in this area, Can you just for now add the rc candidates in your PackageManifest.xml file and put those zips on your site. The issue I am seeing here is that you're controlling the xml file and the zips have to be downloaded from your site. I suggest you enable the user to use their own local xml file and they download the rc zip themselves and they edit the xml to their liking so that they can install any rc any time they want without the tight dependency on the remote xml file. The UI can let the user switch to a local PackageManifest.xml file. The app needs to be updated so that a local rc zip can be unpacked as well on demand.

david-poindexter commented 5 years ago

@abukres we decided not to manage RCs manually (making them available in the dropdown). It is a setup for frustration when our team cannot get it available in a timely manner.

However, it is absolutely possible, and encouraged, to download the RC install packages from the DNN Platform GitHub repo and then use nvQuickSite to install (using local package).

We are not "controlling" anything. Yes, the XML file is currently hosted on our server and that indeed drives what shows up in the dropdown. However, you have always been able to download install packages from elsewhere and use them with nvQuickSite. This is a "free service" to drive a better user experience, not something we are "controlling". I am sorry you feel that way.

Furthermore, this is an open source project that others are more than welcome to propose new ways of doing things and actually create pull requests to implement them. We have always encouraged this.

abukres commented 5 years ago

@nvisionative I wasn't thinking of being able to select an rc while selecting another option from the dropdown. For some reason I thought the two are tied together. Thanks.

I didn't imply controlling as a negative thing. I meant that the user has no control in what shows up in the list and therefore is unable to install any RCs (they can but it's not very obvious). Remember that there are many non technical users who use this app to install DNN. So yeah I understand they can go to the source and make changes but not every user is a developer. In fact this app probably targets more non technical users than technical. Surely, developers know how to get an RC from Github and install them. We're trying to make the app as useful and as easy to use for non technical users and that includes an easy way to install an RC. Remember to think like a non-sophisticated non technical user instead of as a developer who has more knowledge of the nooks and crannies of the app.

The fact that it can be used to install RCs in its current state was hidden by me and I am a developer so I am pretty sure non technical people will miss this ability as well.

I am not sure what you mean by not being to get the RCs in a timely manner. Updating the xml file and putting the zip file on the server is too time consuming? So maybe host the xml and zips on a server that is managed by a few volunteers. Or let the app contact several host servers and use the server that has the most recent list. Like a distributed system.

david-poindexter commented 5 years ago

@abukres thank you for the clarifying response. My apologies for the misunderstandings. 😃

You bring up valid points about the UX. Perhaps someone can help by updating the documentation for nvQuickSite.

My point about making RCs available in the dropdown is more about availability and response time versus the actual time it takes to update. RCs are extremely timely and sometimes get pulled/updated quickly without much warning. For our team to commit to staying on top of all of that so we can be ready to react in a timely manner is not something we can commit to.

That said, we hope to move the XML file to GitHub at some point and just reference the install packages on GitHub. There was a very real and important historical reason why we initially decided to manage/host these packages ourselves, but that reasoning no longer applies and it probably much "safer" now to rely on DNN Platform releases on GitHub for this.

iJungleboy commented 5 years ago

Note that hosting on github for production data can run into problems. We used to get the default 2sxc templates from github, but after Github was attacked about 2 years ago they blocked lots of http traffic - so our setup failed. Fortunately that part of the code was running on the 2sxc.org server, so we were able to modify it to then use files on 2sxc.org. But if something like this happens to your install, it would be hard to fix on the fly.

bdukes commented 5 years ago

Retrieving releases from GitHub should be a well supported scenario, you'll just need to properly use the GitHub API to find the release to download.

iJungleboy commented 5 years ago

@bdukes you're probably right. I was using a public API, and probably I would have just needed to switch to a private one using an API key or something.

david-poindexter commented 5 years ago

Okay, so that piece just got more complicated. 😆 🚀

abukres commented 5 years ago

If someone gives me the DNN Github API url to query the latest DNN releases, I might be able to get nvQuickSite create the proper list dynamically. It gets the current PackageManifest.xml and prepends the list with whatever is the latest RC is plus its download link.

abukres commented 5 years ago

I think this is a good resource and I will check it out. https://developer.github.com/v3/repos/releases/

bdukes commented 5 years ago

Here's the NuGet package for their API wrapper: https://www.nuget.org/packages/Octokit

david-poindexter commented 5 years ago

Hey guys, there are additional things to consider here, which increases the complexity. One of the reasons we manage our own XML file and packages is due to the many GitHub "releases" that aren't actual releases, or shouldn't be surfaced in nvQuickSite. Naming conventions have been poor and inconsistent historically on the DNN Platform repo. The way it is today is not the way it has always been. Tag naming has changed over the years, etc.

Therefore, shifting to this more automated solution could ultimately lead to an even worse user experience. I realize it is not perfect now, but I wouldn't want to take a step backwards just for the sake of automating this package management.

Also, this issue is about support Release Candidates and we seem to be slipping into much more here. That is fine, but let's break the pieces out into manageable chunks (issues) to be discussed and worked on.

Thanks to everyone for your input and contributions!

iJungleboy commented 5 years ago

@nvisionative I totally agree. We must still remember, that if you need the release from 5 minutes ago, you can always download it yourself. plus if you took the automatic stream, you would also end up with some unexpected nightly build or something.

So a manual feed is probably still best. This is a bit like the auto-installed apps on 2sxc - they are not the latest, but the ones tested for that version. So if I update the news app, I only update the (manually maintaned) list of auto-install-apps for the newer versions, while the list for older versions usually don't get modified any more - simply to avoid having to test everything on older versions. it's just safer, and the automations are not meant for edge cases.

abukres commented 5 years ago

I created a solution for myself and made it available as a PR if you choose to use it. If the people who create the DNN releases keep the format of tagname and name of the releases the same, it should work for future RCs. Let me know if you find any issues.

abukres commented 5 years ago

It was interesting to notice the number of downloads for each release from the API. I don't think the UI shows these numbers.

david-poindexter commented 5 years ago

@abukres thanks - I am glad you came up with a solution that works for you. Due to several factors:

...we will not be using this approach and will continue to manually manage. This may change in the future, but for now, this generally accepted as the best option.

@hismightiness we are going to go ahead and close this issue due to the above decisions. Thanks for the suggestion and if you have any ideas in the future for how to make this better, please don't hesitate to share.

abukres commented 5 years ago

@nvisionative My change adds only the latest RC to YOUR list. All the existing DNN releases and future releases are still using your list. It's not getting any non RC releases from Github. If the RC naming does change in the future, it's not going to break anything. The RC entry just won't get added.

Your two factors that you mentioned are not valid in my opinion.

david-poindexter commented 5 years ago

@abukres I understand and apologize for any misunderstanding. We have decided to not support programmatic addition of Release Candidates to the dropdown in nvQuickSite.

abukres commented 5 years ago

If anyone wants the RC support, it's at my fork at https://github.com/abukres/nvQuickSite

david-poindexter commented 5 years ago

Thanks again @abukres!

WillStrohl commented 5 years ago

One of the original goals that David and I had used as our "guiding light" of sorts and the primary reason this tool is so popular and successful is the ease of use and specifically that it doesn't require any technical expertise (for the most part). I personally don't believe that making this tool support RC's continues to achieve that goal. Just my $0.02. :)

mitchelsellers commented 5 years ago

Just my $0.02 here, greater access to RC releases for ALL user types need to be s priority.

An open source project as large as DNN needs all of the help as possible during RC release cycles.

ohine commented 5 years ago

I say we take @abukres fork and rebrand it under the platform and make this the official way to download and configure packages. It's a bit sad the refusal to work with someone who is trying to make everyone's life much easier.

Also, the best testing we've gotten thus far, has come from the non-technical people who just want to help out. Us technical folks have missed quite a few major bugs in the last few rounds of RC testing.

WillStrohl commented 5 years ago

I 100% agree that surfacing RC's to people is important, but this tool is not the correct way to do that, in my opinion. It's focus is not on helping testers and developers necessarily. In most cases, those folks know everything they need to know to install and test DNN, and they tend to be far more technical.

Adding the ability to do RC's in any tool alongside normal installations is incredibly dangerous. I've run into far too many instances of (accidental) object qualifiers and installed source code versions of modules over the years to feel any other way.

In my opinion, any method of making RC's available to people needs to be specific to RC's ONLY. The average person can easily miss any kind of notice, prompt, message, etc. that tells them that something is an RC. Doing it any other way will only result in a ton of RC's in the wild that should have been a normal installation of DNN.

david-poindexter commented 5 years ago

As stated before, "it is absolutely possible, and encouraged, to download the RC install packages from the DNN Platform GitHub repo and then use nvQuickSite to install (using local package)."

This issue was about if/how to surface RCs in the UI. We have dialoged and debated options for 7 months now on this issue, and in other channels, and came to a decision. We have not refused to work with anyone on this and we have always welcomed input. The burden of a decision for nvQuickSite is on us though. Thank you for respecting that.

ohine commented 5 years ago

Closing the issue and refusing to even entertain options that quite a few people are looking for isn’t really a debate. It’s clear we need an official tool for this and it’s something I’ll work on getting added into the official release pipeline. Thanks for the initial work on this @nvisionative.

abukres commented 5 years ago

@nvisionative I encourage you to give detailed reasons when you close an issue. You mentioned two reasons and I mentioned those didn't apply to the change. You apologized for the misunderstanding and closed the issue anyway.

@hismightiness If you don't want RCs to show up in the dropdown then there are other ways to handle this situation. They can be hidden by default and a user setting in the app can enable their visibility on demand. Anyone who enables it is expected to be aware of what the setting is used for. Just like Chrome has flags to enable unreleased features. Make a feature available but hide it if you're concerned about the average user. BTW, I didn't know you're involved with this tool. This explains to me now some of your comments.

We should be encouraging more people to be using this tool and encourage them to test release candidates. It benefits the whole DNN community.

WillStrohl commented 5 years ago

The other way has already been described at least twice by David.

Get Outlook for Androidhttps://aka.ms/ghei36

From: Abdu notifications@github.com Sent: Thursday, April 4, 2019 12:20:48 PM To: nvisionative/nvQuickSite Cc: Will Strohl; Mention Subject: Re: [nvisionative/nvQuickSite] Support for Release Candidates (#173)

@nvisionativehttps://github.com/nvisionative I encourage you to give detailed reasons when you close an issue. You mentioned two reasons and I mentioned those didn't apply to the change. You apologized for the misunderstanding and closed the issue anyway.

@hismightinesshttps://github.com/hismightiness If you don't want RCs to show up in the dropdown then there are other ways to handle this situation. They can be hidden by default and a user setting in the app can enable their visibility on demand. Anyone who enables it is expected to be aware of what the setting is used for. Just like Chrome has flags to enable unreleased features. Make a feature available but hide it if you're concerned about the average user. BTW, I didn't you're involved with this tool. This explains to me now some of your comments.

We should be encouraging more people to be using this tool and encourage them to test release candidates. It benefits the whole DNN community.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/nvisionative/nvQuickSite/issues/173#issuecomment-480029353, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA5QJ-0hR0KkNFWi-k96gz0WwzptAK9oks5vdlCQgaJpZM4WZnhM.

ohine commented 5 years ago

While yes, there are other ways of installing things. The point is we CAN make it easier. We will make it easier under the official version we will start to promote with the v9.4 round of RCs.

ohine commented 5 years ago

It’s really a shame that the a couple leaders of the ecosystem advisor groups are this much against making the platform better and making it easier for all users to get set up with a test site or a local site to start helping us continue improving the platform.

It makes no sense how you’re both all for RC, then the feature shows up and your public stance changes 180 degrees.

WillStrohl commented 5 years ago

Have fun, Oliver. I hope it works out well for you. :)

ohine commented 5 years ago

We will. The build team takes these issues seriously. Improving the platform is our primary goal

WillStrohl commented 5 years ago

That sounds amazing! Good luck!

ohine commented 5 years ago

It is amazing. It’s an insult to the entire community that you guys cannot get even continue the discussion to come up with a solution together. Luckily there is a group of people who do want to continue this great work and make it even better and easier to use for our entire community.

WillStrohl commented 5 years ago

You are a rock star, Oliver. I can't wait to see what you do with your fork. :)

ohine commented 5 years ago

Thanks Will.

WillStrohl commented 5 years ago

You are welcome.

ohine commented 5 years ago

Anytime

WillStrohl commented 5 years ago

Sweet.

iJungleboy commented 5 years ago

@ohine @hismightiness - this is not the right platform for this...

david-poindexter commented 5 years ago

After a healthy cool-down period, we are re-opening this issue. With objective re-consideration of all points made during the past 7 months, and even after this issue was closed, we have decided on a way of doing this that aligns with the guiding principles of this project, yet makes Release Candidates more accessible to those wishing to participate in the RC test cycle.

Thank you all for your input. Moving forward, please be advised that we will be implementing a CODE OF CONDUCT via #193. We take this very seriously and want to do our part to facilitate a healthy and productive open source community.

@abukres we would like to work with you on the PR you submitted, as it contains some key pieces in making this possible. Are you good with this? If so, there are just a few house-keeping things we'll want to do in order to clean up the PR. If this is agreeable to you, then we will continue that endeavor within PR #185.

This will be one of several things that will need to be put into place in order to ready nvQuickSite for the next release. Additional steps will be taken to solidify the solution.

  1. Implement a Preferences, Settings or Configuration user experience to allow opt-in for seeing Release Candidates show up in the Package Install Info screen dropdown list.
  2. By default, users will not see Release Candidates in the dropdown list. They would need to opt-in via the new Preferences/Settings/Configuration experience.
  3. For opt-in users, only the most recent Release Candidate should show.
  4. For opt-in users, the most recent Release Candidate should show only if an official release has not been subsequently posted.
  5. Prior to advancing beyond the Package Install Info screen, a check should be implemented to determine if a user has selected a Release Candidate, and if so, present a friendly warning. This warning should make it clear that they are selecting a Release Candidate and that it should not be used in a production environment.

Please review the above plan and let us know if we have missed or misrepresented anything. We will be moving forward with this plan immediately and we expect multiple PRs to accomplish this solution. Each PR leading up to the final one should reference this issue, but not close this issue. The final PR should auto-close this issue.

Thanks again for the dialog on this and we look forward to moving ahead in a healthy and productive manner! 😃🎉

WillStrohl commented 5 years ago

@nvisionative Should we plan this from a UX perspective first? Maybe it's worth our time to do some bullet points and wireframes to make sure we both (1) keep the prominent ease-of-use aspect, and (2) make RC's both accessible and wildly obvious what they are and whether or not they should be opted in-to, used, etc. What do you think?