Installation / Removal > Apple - Installation/Removal

iPod first generation install?

<< < (8/17) > >>

Llorean:
Simply put: All builds are development builds, all "users" are actually "testers." Encouraging people not to use the latest build (or track down the specific build where the problem was introduced) works against the purpose of actually getting the problem fixed.

Basically, the point can be argued both ways. Bugs are business as usual in built-from-SVN software, and hopefully the people actually interested in this build will see fit to investigate / fix the problem soon enough anyway. As always we depend on people with the hardware to work on it, in general.

A player is "supported" if "all the work necessary to make it play music and be generally usable" is done. Buggy builds don't make the build unsupported, they just mean SVN head is buggy. A warning system might be suitable, but people can always just keep their old builds backed up when updating (and should) and if a user doesn't have an old build, they can roll back.

And, *everybody* experiencing this bug should be looking in the tracker anyway (to report it if a bug report doesn't already exist), so when they encounter it, they can add to the information.

I really don't see a specific benefit to qualifying it, but can certainly see why people might have the point of view "users should be told in advance." But we have the tracker for known bugs as it is, anyone interested in existing problems can go there, search for bugs affecting iPod 1st generation (assuming that's added to the list of targets on it) and see every outstanding issue that affects that specific player. Any other form of notification will just as easily be missed by the lay user anyway. I mean look how many people click past the large bold text mentioning forum guidelines will be enforced, or how many didn't even notice the check box next to the field they entered their email address in, offering to hide it. A user is well capable of clicking past anything, but you can't really say the information isn't already available to anyone who actually cares enough to look.

Chronon:
Of course I understand those points.  And I think those who have already been exposed to Rockbox probably will appreciate this.  The demographic that seems to be under consideration seems to be those users who don't know about Rockbox and think that when they download a current build they will be getting  a working product due to it being "supported" as per the front page.  

If someone wanted to provide a note about this issue an appropriate place might be on the TargetStatus wiki page  -- which is linked from the front page.  Does that sound reasonable?

Llorean:
I believe that page would be the *perfect* place to note outstanding bugs that make the player impossible to use. I'd rather as few bugs as possible end up on this page, so restricting it to ones that prevent use of the player entirely and consistently (and hopefully by placing it there you accept responsibility for removing it when it's fixed, the page really needs to stay up to date if this is going to be done).

bidmead:
I didn't mean to start a war here.  :-)  But let me point out a couple of things:

1) The RB front page claims "It runs on a wide range of players....  Apple 1st through 5.5 generation iPod..."  The experience in this thread suggests that this at least needs qualifying in the case of 1Gen.

2) Users as "testers" is OK by me, except that without scroll-wheel function there's frankly nothing to test.

It seems to me a no-brainer that for the good of RB's rep, and in the interest of not demotivating potential RB users, the place to say "It runs, except that you can't use it" is on the front page (or at least on an easy link from the front page clearly labelled "But check this first...").

Technically this bug may be trivial, but from the POV of the 1G end-user it's a show-stopper.

 --
Chris

Llorean:
What "end-user" exactly? There's no release version for the iPod 1G. And it does run on it, it's just buggy right now. You're downloading a bleeding edge, automatically generated build from source that is being actively developed.

Do you honestly expect someone to read through every bug report, and as ports become more or less usable update the status constantly on the front page? That could nearly be a full time job, on its own. Why not just use the clearly named wiki page?

Edit: Trying to get a general disclaimer added to the current build page to reflect some of this.
Edit2: If the first generation iPod build never worked, it should clearly have never made the "supported" list and should be removed. My point only applies to if this is an introduced bug in a previously working build. Reports suggest that some 1Gs (the one our only developer with one has, for example) work fine, and the target *should* be supported, it's just "supported bug buggy." We provide support for people asking install questions, and we accept bug reports on it and attempt to resolve them.

Basically "supported" means "we expect you to be able to play music on it, and want you to tell us if something interferes with that." Basically, supported does mean *you* should have a reasonable expectation of being able to get music to work. In this case, music doesn't work, but it really is "just a bug" in an in-development software. These things crop up often, and it's somewhat unreasonable to say the front page should contain the constant status of how usable any given target is. For example, recently some (or all, I'm not sure) of the PP5002 builds all had a <50% chance of working, depending on somewhat random factors, but we had no way of knowing consistently which ones users could use without someone testing every build to verify. It's just too large of a task, and something much better suited for the wiki.

Edit, the final: Just to attempt to clarify my point. There are something like 36+ variants of hardware and/or unique install processes. To attempt to keep an up to date usability status documenting any significant bugs would be significantly difficult. This becomes more difficult because sometimes these bugs last a matter of hours, sometimes weeks, and only a few people can modify the front page. These people don't have all the players, and may not even be aware of the problems some players experience. As well, some reported problems that seem very significant only affect specific hardware variants, or even are the result of hardware faults tolerated by the OF but not accounted for by Rockbox yet. So the persons posting this have to have enough reports to verify. Then they have to remove the warnings in a very timely manner when the problems gone, so that further misinformation isn't spread. Wouldn't a better solution be more clarity for the user as to what to expect (ie: It should work, but don't *expect* it to work)? This way people will never assume "there's no warning for my build, it's surely working", nor will they mistakenly see an old warning and think it's still applicable because the person in charge of the page isn't aware it needs removal.

Note: all of this reflects personal opinion, and not project policy, just to clarify.

Navigation

[0] Message Index

[#] Next page

[*] Previous page