1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in

Ticket #11420 (closed: fixed)

Opened 4 years ago

Last modified 3 years ago

MinGW: project "Files" view exhibits inconsistent behaviour

Reported by: keithmarshall Owned by: hinojosa
Keywords: ENGR AT-00 Cc: mingw-dvlpr@…
Private: no

Description

The latest incarnation of the FRS "all files" view has created some serious problems for the MinGW Project, itemised in increasing order of severity from 1..4 below.

I appreciate that you are trying to generate an improved user experience. First, you gave us a FRS with an extended hierarchical organization. This was a welcome enhancement, apart from the mind numbingly slow rendition of the accompanying "View all files" page. Now, you appear to be attempting to address this issue, and the current rendition does seem to be vastly improved in this respect. However, it is not without problems, some serious for this project:

  1. Marshaling only the top level directories into the initial view does seem to provide a welcome speed boost, but do you really then need to invoke an entirely new page to expand a subdirectory view? Why not expand in place, within this initial page, as seems to be the intent within the subsequent subdirectory pages? This however, is mostly a cosmetic issue, and is the least of the problems.
  1. For the MinGW Project, on selecting one of the directory links from the initial view, the behaviour on the subsequent subdirectory pages is inconsistent; for some such pages, the hierarchy is shown much as it was in the earlier (slow) rendition, but showing only a subset of the project's entire FRS hierarchy, and orders of magnitude faster than previous performance. For subdirectories which do behave this way, subject to the critique of (1), this isn't a problem.
  1. For certain subdirectories, the behaviour described in (2) is NOT observed. For example, in the cases of our "MinGW" and "MSYS" directories, (our two PRINCIPAL top-level subdirectories), the hierarchical organization is NOT correctly depicted in the subdirectory view; all entries at the next level are depicted at the same level as the parent, as if they were its siblings rather than its children, and there are no "arrow" icons offering the ability to expand the subtree. In the cases of SOME of these degenerate subdirectory references, clicking through the link invokes a THIRD new page display, where the behaviour does seem to result in the appropriate hierarchical rendition. However...
  1. In the particular case of the "MinGW/BaseSystem" hierarchy, (and there may be others, as yet undiscovered), clicking through the "BaseSystem" link invokes a third degenerate display, in this case showing ONLY the "MinGW" top-level directory and the one "BaseSystem" child, again depicting them as if they have a sibling relationship rather than a parent-child relationship, and there then seems to be no way to expose the underlying "BaseSystem" hierarchy, (which remains clearly visible in the "Project Admin/File Manager" view). This is a VERY SERIOUS PROBLEM for the MinGW project.

Change History

  Changed 4 years ago by ctsai

  • keywords ENGR SFX-1124 SFX-1125 added
  • owner set to hinojosa
  • status changed from new to assigned

Hello,

Thank you for this report, I've confirmed your findings and I'm escalating this to our engineering team for further review.

Regards,
Chris Tsai, SourceForge.net Support

  Changed 4 years ago by keithmarshall

I don't wish to pre-empt or to prejudice your diagnosis in any way, but I'd like to add a couple of additional observations; if I type a URL directly into the browser's location bar:

  • I can directly access any level in the hierarchy, provided it has no more than one additional subdirectory level between it and the leaves of the tree, (the package files). Thus, for example, I can access sf.net/projects/mingw/files/MinGW/BaseSystem/GCC/Version4 and its children in this way, to see a tree view with expandable subdirectory levels, all the way from the "MinGW" top-level down.
  • I cannot access any higher level subdirectory in this manner; for example, if I attempt to navigate directly to sf.net/projects/mingw/files/MinGW/BaseSystem/GCC, or even to select it from the expanded tree from the preceding observation, I see the same sort of degenerate display as in my original observation (4), i.e. for this example, only the top-level "MinGW" directory and its "BaseSystem" child, shown as if it were a sibling, can be seen.

follow-up: ↓ 4   Changed 4 years ago by rubenvb

I'd like to stress that not only the mingw project is suffering this problem. Most projects still have their files accessible though, where MinGW has their most important files inaccessible for their users. The complete file view is borked for everyone.

in reply to: ↑ 3   Changed 4 years ago by keithmarshall

Replying to rubenvb:

I'd like to stress that not only the mingw project is suffering this problem. Most projects still have their files accessible though, where MinGW has their most important files inaccessible for their users. The complete file view is borked for everyone.

Certainly, all projects will be similarly affected; there was never any intent, on my part, to imply otherwise. Ticket #11473 explicitly identifies another project which is similarly affected.

As noted in my previous comment, the determinant appears to be related to the depth of the files hierarchy. Any project with a hierarchy no deeper than the old Package/Release/files model will likely not have noticed the issue; any deeper, and the problem becomes severe. Reverting to the old Package/Release/files model simply isn't a viable option, for MinGW; (I cannot speak for any other project, but I'm sure there are others).

Since my original report, there clearly has been some attention given to this. We no longer see the degenerate sibling vs. child conflict when attempting to access an intermediate directory; instead we see nothing at all. So apparently, SF staff are following up, but have yet to identify a fully effective solution.

As a workaround, for the time being, we are advising our users to browse https://sourceforge.net/downloads/mingw instead of https://sourceforge.net/projects/mingw/files, for downloading; the full hierarchy does seem to be visible there.

  Changed 4 years ago by ctsai

  • keywords DIST-768 DIST-769 added; SFX-1124 SFX-1125 removed

  Changed 4 years ago by ctsai

  • keywords DIST-768 removed

Hello,

The engineering team has reverted the changes to the files page that caused the issues with the page. The entire tree is available now. However, this is only a temporary solution, the engineering team is still working on speeding up the load times on that page. I'm going to leave this ticket open while they work on those speed enhancements, and we'll continue to provide updates via this ticket.

Regards,
Chris Tsai, SourceForge.net Support

  Changed 4 years ago by hinojosa

  • keywords PEND added

Hello Keith,

I'd like to introduce myself. I am Daniel Hinojosa, the Sr. Manager of Support here at SourceForge.net. I have been in discussion with the engineering team on this issue.

We are working a solution to address the larger view of the directory structure. The team believes they will have a solve for this in about two to three weeks time.

Before that goes live, I'd like to invite you and the other !MinGW project administrators to a phone conference and WebEx session so that we can demo the proposed solution.

Please let me know if you all are interested in that review. If so, I'll contact you direct to get an event in our calendar on this side.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

  Changed 4 years ago by hinojosa

Hello again Keith,

I'm following up on this to see if you and the team would be willing to have the conversation I suggested. The team here would like your direct feedback on the proposed change.

If you would please get back to me by the end of business tomorrow, I'd appreciate that.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

  Changed 4 years ago by keithmarshall

Hello Daniel,

Yes, I am interested, but will be unavailable to discuss details until next week. One of my most proactive developers, cwilso11, is also interested but has very limited availability at present. I have yet to receive any reply from earnie, (one of my co-administrators), and infidel, (the third current administrator), has just informed me that is no longer interested in the project.

Regards,
Keith.

  Changed 4 years ago by hinojosa

  • keywords OMB added

Keith,

Okay, please let me know what opportunities exist as you get replies.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

  Changed 4 years ago by keithmarshall

Daniel,

Both Earnie (earnie) and Chuck (cwilso11) have expressed an interest, but finding a mutually convenient time may be difficult. Chuck has excluded business hours EDT, all of the weekend past, and Tues/Wed/Thur evenings of this week; I'll need to check with him, if his availability improves next week. Earnie has similar constraints on morning business hours EDT, but might manage afternoons or evenings. I'm in a different time zone (BST); business hours 8:30..16:30 might be possible, subject to proxy rules not barring access to whatever services you have in mind, but evenings would be better.

Can you provide more detail on what you have in mind, and suggest times?

  Changed 4 years ago by hinojosa

Hi Keith,

Well, as I'm in the Pacific Time zone, We can easily do this between 2:00 PM and 4:00PM (5:00 PM if needed) during the week. We can certainly push this to next week.

MY intent was to show the solve we are working towards and wanted to make sure it met your needs. I was looking to do a brief phone conference and WebEx session if that would be helpful.

My intent was to demo for you what we're planning. We generally don't do voice communication with users; I was feeling like changing things up a little, so was looking to do that.

Simply, if you look at the way the Beta file manager behaves, this is what we'd be doing in this case. If you look over the Beta download manager for opening folders and that makes sense as a solve for this, then you can just let me know.

Let me know about times if you are still interested.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

  Changed 4 years ago by keithmarshall

Hi Daniel,

So basically, your proposed solution is an adaptation of what we can already see at https://sourceforge.net/downloads/mingw, if I understand you correctly? I think that would be a move in the right direction. Indeed, when this issue first arose, we made that the preferred download link from http://mingw.org, since it continued to work correctly, even when https://sourceforge.net/projects/mingw/files was completely broken; but for SourceForge continuing to direct users to the broken URI by default, this would have been pretty much a non-issue.

There are, however, still some rough edges to https://sourceforge.net/downloads which need to be ironed out. For example, a topic raised independently by two of our users, on our mailing lists, concerns the disposition of release notes. In the days of the old package->release->files FRS structure, we pasted release notes into a web form, and they were stored away somewhere which was completely transparent to end users; they accessed them by clicking on a specific icon on the downloads page, and the notes were displayed immediately in the browser; simple and unambiguous.

With the move to the hierarchical FRS structure, (which I consider, in general, to be a vast improvement over the old structure, BTW), we now have to upload a release notes file, assign it a "release note" attribute, and associate it with other files or folders to which it relates. Once we've done that, then in the projects/mingw/files view there are two mechanisms whereby users may access the notes: an icon, which when clicked causes the notes to be displayed in the browser, as before, but also the notes file itself is offered for download, usually (but not always, and rarely consistently) with the choice of saving the file, or opening it with some default application, (which will likely be notepad on MS-Windows, and is really bad news if the file happens to have unix style line endings). This is confusing for end users, and a complete nightmare for us, as package maintainers, to administer.

Now, with downloads/mingw, the release notes file simply appears as any other file; there appears to be no mechanism to specifically identify release notes, and no way for end users to access them, other than by electing to download the file and either save it, or open it with some (probably entirely inappropriate) application. While downloads/mingw is, in general, a vastly improved UI, this aspect in particular, is a huge retrograde step. You need to address it, IMO, as a matter of some urgency.

Another aspect, which you need to address, is the stability of the UI, (in terms of maintaining a consistent presentation over time). To be frank, your track record in this respect, over the past two or three years, has been dismal. As project administrators we have been forced, too many times, to reorganise our FRS package structure because you have unilaterally imposed a change in presentation style, which hasn't suited us. While I do think that downloads/mingw is moving in the right direction, if we can't have an assurance from you, that once the rough edges have been ironed out, the presentational style will remain available to us, as a hosted project, not just for six months, or a year, or whenever you have some other bright idea, but for ten or even fifteen-plus years, then, without such an assurance, we will have to seriously consider whether SourceForge can continue to host our project.

--
Regards,
Keith.

  Changed 4 years ago by hinojosa

  • keywords ENGR DIST-769 removed

Hi Keith,

By way of update, I am connecting again with the engineering team on this issue. I had been on vacation this past week, so I'm tying up loose ends.

I expect to get you an update on this probably early next week.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

  Changed 4 years ago by hinojosa

Hi Keith,

I was able to close the loop with engineering. In the end, Downloads is the future. The solve I had suggested sounds like it will work for you, so I think we are on a good track here.

As for the release notes, I had replied to the ticket you had for that. The team is going to be making a change in that regard soon, so I expect this will be moot.

Finally, on the UI changes, I passed your input directly to the product team. This issue has been raised by many projects. To the extent we are able, we look to minimize such changes, though as you note, we have made many over time. In the end, change is the one constant we all face. We continue to do our best to minimize impact on project teams in this regard, with of course, varying results.

Please let me know if there are any other questions on this.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

  Changed 4 years ago by keithmarshall

Hello Daniel,

Indeed, we are enthusiastic about the prospect of "downloads"; we believe it will suit our project files organisation very well, and with the exception of its current lack of any mechanism for presenting release notes, for direct viewing in the browser, we already consider it to offer a superior interface to the old files view. It is a pity it is not more accessible to general users, via site navigation, than it is at present.

With regard to the UI changes, sure, we accept that change is inevitable -- it's called progress! What we find so distasteful is the manner in which past changes have been foisted on us, with little or no prior warning, or consultation on likely impact on hosted projects. Yes, the new(ish) hierarchical FRS organisation is a vast improvement over the older package->release->fileset organisation; long may it remain thus. We found the older organisation severely limiting, and we put considerable effort into making it work, for us and our users; every UI change you imposed on us had the overnight effect of wrecking everything we'd striven for, leaving us with several weeks of heartache, as we took on the challenge of adapting to your latest-and-greatest idea, only to have you kick us in the teeth again, with yet another incompatible change. This rapidly became frustrating for both us and our users; for us because of the continuous effort chasing a moving target, and for our users because the ensuing chaos made it very difficult for them to find packages.

So yes, while change may be inevitable, and often for the better, it still needs to be pursued with more consideration for your clients, and with a view to retaining backward compatibility, at least in the medium term. Yes, that may seem like a harsh criticism, but frankly, your past performance in this respect has been disappointing.

--
Regards,
Keith.

  Changed 4 years ago by hinojosa

Keith,

I re-opened #11244 as engineering has taken this issue back up. I had advocated strongly on your specific behalf for this issue and we made a difference here.

In the past, we have been less than smooth in our transitions. The team has heard from projects and developers like yourself. To that end, we have taken to using a Beta model, like we have now with the Downloads Beta.

I expect that any new changes to the larger site will be along these lines as well.

With that, are we ready to close out this item?

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

follow-up: ↓ 19   Changed 4 years ago by hinojosa

Hi Keith,

Please let me know your status on this issue.

Best regards,

Daniel Hinojosa - Sr. Manager, SourceForge.net Support

P.S., Be sure to monitor our Site Status.

in reply to: ↑ 18   Changed 4 years ago by keithmarshall

Replying to hinojosa:

Please let me know your status on this issue.

Hello Daniel,

Sorry, I don't understand your eagerness to simply close an issue which is not yet completely resolved; (unless, of course, your primary interest is in meaningless and misleading statistics, to the detriment of technical performance). I thought I had made our project position clear:--

1) Existing behaviour, since you reverted the change which broke it, is satisfactory, but can this step backwards be considered a resolution? (I guess it is, in a way, if you now freeze this manifestation of "files", until "downloads" is ready to supersede it).

2) We are looking forward to the eventual progression to "downloads"; it appears that it will satisfy our project requirements, subject to:--

2.1) Better accessibility for regular site users is needed, perhaps even while still in beta, via normal site navigation links.

2.2) Provision of a mechanism for presentation of release notes, for direct viewing in the browser, which is at least as good as the existing feature of "files", without requiring separate download of an arbitrarily named file, for external viewing in some (possibly unsuitable) text editor.

--
Regards,
Keith.

  Changed 4 years ago by hinojosa

  • keywords ENGR AT-00 added; PEND OMB removed

Keith,

Okay, that's what I was after, clarification on your expectations. Thank you.

As ticket #11244 is about the Release note issue, which is with engineering at this time via "AT-63", as noted on that other ticket, I hear you noting that you'd like this item to remain open until such time as the fix for the "files" space on the current forge, functioning as is the newer "Downloads" space.

This issue is expected to be resolved soon. I am assigning accordingly to the engineering item.

Daniel.

  Changed 3 years ago by ctsai

  • status changed from assigned to closed
  • resolution set to fixed

Okay, the new File Manager has superseded the old one for quite some time now, along with improved readme functionality. I suspect that most if not all your expectations have been met now.

As such, I'm closing this ticket, if you require further assistance, please log a new ticket.

Best Regards,
Chris Tsai, SourceForge.net Support

Note: See TracTickets for help on using tickets.