Re: Reminder: Use Gerrit to submit patches/translation fixes, not flyspray
On 1 March 2012 23:10, Dominik Riebeling dominik.riebel...@gmail.com wrote: On Fri, Mar 2, 2012 at 12:03 AM, Paul Louden paulthen...@gmail.com wrote: Shouldn't we remove the patches category on Flyspray then, much like we did Feature Requests? Maybe, but more importantly the Patches link in the website menu should point to Gerrit instead of Flyspray. It might be better for it to point to UsingGit instead, since patches in Gerrit are not particularly discoverable and there is no way to actually upload a patch there. :) -- Torne Wuff to...@wolfpuppy.org.uk
Reminder: Use Gerrit to submit patches/translation fixes, not flyspray
Hi all, Please remember we have mostly switched to gerrit for patch tracking and would like to only use flyspray for bugs. If your patches (translations especially) are submitted to gerrit it is much more likely they will be merged quickly (they can be done wih a single click from the website instead of requiring a checkout, download and apply the patch and push.) Useful links: http://gerrit.rockbox.org/ http://www.rockbox.org/wiki/UsingGit http://www.rockbox.org/wiki/UsingGit#Setting_up_Gerrit Finally, please add your full name to docs/CREDITS on the first patch you submit. Thanks Jonathan
Re: Reminder: Use Gerrit to submit patches/translation fixes, not flyspray
Shouldn't we remove the patches category on Flyspray then, much like we did Feature Requests?
Re: Reminder: Use Gerrit to submit patches/translation fixes, not flyspray
On 2 March 2012 09:56, Jonathan Gordon jdgo...@gmail.com wrote: Hi all, Please remember we have mostly switched to gerrit for patch tracking and would like to only use flyspray for bugs. If your patches (translations especially) are submitted to gerrit it is much more likely they will be merged quickly (they can be done wih a single click from the website instead of requiring a checkout, download and apply the patch and push.) Useful links: http://gerrit.rockbox.org/ http://www.rockbox.org/wiki/UsingGit http://www.rockbox.org/wiki/UsingGit#Setting_up_Gerrit Finally, please add your full name to docs/CREDITS on the first patch you submit. Thanks Jonathan I evidently forgot how translate.rockbox.org is used. Ignore this email (though still if you can, pushing through gerrit is easier/faster)/ Jonathan
Re: Reminder: Use Gerrit to submit patches/translation fixes, not flyspray
On Fri, Mar 2, 2012 at 12:03 AM, Paul Louden paulthen...@gmail.com wrote: Shouldn't we remove the patches category on Flyspray then, much like we did Feature Requests? Maybe, but more importantly the Patches link in the website menu should point to Gerrit instead of Flyspray. - Dominik
Re: RFC: Rockbox Flyspray policy
It has been a while but I still want to post my thoughts. For easier distinction I haven't trimmed the text but only added my extensions. Comments are marked with square brackets. On 9/30/06, Jonas H [EMAIL PROTECTED] wrote: I suggest everyone pick this suggestion to bits, and when some sort of consensus is found, it should be put in the wiki and linked somewhere prominent on the Flyspray page. I think we should divide this into subpages, similar to the bugs page of the Gimp project (http://www.gimp.net/bugs/ which has already mentioned on IRC some time ago). I suggest having a UsingFlyspray (or rework ReportingBugs?) page which is the only page that is linked from the side menu for all types. From there we have separate pages for reporters and for developers. *** * ROCKBOX FLYSPRAY POLICY * *** FOR REPORTERS = Flyspray is *not* a support channel. Our support channels are the mailing lists, the forums and IRC. For support questions don't go to Flyspray as you'll get way better responses there -- the tracker is a completely different thing and used in a completely different way. You won't get any support from the tracker, it is used to keep track of tasks *only*. Note that support questions in the tracker will get closed without any comment! It is *really* important that you follow the rules for our tracker: by following these rules you make it easier for the devs to keep up with bugs, feature requests and patches which in turn means you can expect the development (and fixing of bugs) getting faster. Ignoring these rules only adds extra work for the devs and wastes precious time that could be used better for coding. When signing up please make sure you provided a correct and *working* mail address. Tasks you are involved with (as reporter or commenter) get automatically notified to you when something changes. This is a *really* important thing as it's useless to have a task which reporter can't get reached anymore, especially on bug reports. Your mail address won't get used for anything else than these notification. When submitting a task, please include as much information as you can think of. Be honest when you set the severity level, see explanation in the section below. If you are unsure about a task you want to submit please ask in the aforementioned support channels first. This helps saving work for the devs and can also avoid you quite some amount of frustration. A really annoying issue are duplicates. Please make sure the task you are about to submit isn't already present. If there is a similar task please take into consideration if it would be sufficient to comment on that existing task. Again, if you are unsure feel free to ask in our support channels. Duplicates require quite some work, and that work is precious developer time. You'll agree that wasting deveoper time isn't a good think, don't you? If you're submitting a bug, please explain: - What behavior you are seeing - What behavior you expected - How to reproduce the bug Please make sure you can reproduce the bug -- if it's not reproducable it's unlikely to get fixed. Also, make sure you have tried the latest cvs build and reset your settings (see the FAQ pages on how to do this). If you still can reproduce the bug it's worth filing. You may want to ask on IRC before filing, maybe some dev is already working on it. If you're submitting a feature request, please include: - A detailed description of the feature you want added - If you want current behavior changed, an explanation of why your suggestion is better Please also consider the following before filing a feature request: - is the requested feature possible? Music players aren't PCs, so there are quite some hardware limitations. If you are unsure please ask in the support channels. You'll most probably get an answer quicker and can help the tracker staying useable. - is the requested feature compatible with the open source nature of Rockbox? Rockbox is distributed as GPL which requires all work included to be GPL. We can't add features that are incompatible, regardless if it's from a source code point of view or any other. - Don't file requests for new ports. They are completely pointless. New ports will only happen if some dev is interested and owns the actual device. Of course you are welcomed to start working on a new port. See the NewPort wiki page if you are interested. If you're submitting a patch: - Explain in as much detail as possible what the patch does - Mention any related existing Flyspray tasks - if your patch has issues that need to get adressed don't forget to note them. Perhaps someone else is interested in your work and wants to help you out. - submitting a patch implies the assumption you want to get it included into Rockbox. For that to happen your patch needs to work on all players suppported by Rockbox (if it's specific to some series of players make sure it doesn't
RE: RFC: Rockbox Flyspray policy
While we're at it, I suggest some changes to categories: - rename categories using a two-level hierarchy, e.g., Plugins-general, Plugins-video, Plugins-games, Env-building, Env-simulator, HW-LCD, HW-remote, HW-fm tuner, Audio-general, Audio-codecs, UI-fonts, UI-language, OS-playlists, OS-bootloader, OS-ID3, - operating system/drivers and drivers should be united into HW-general - user interface should be split to UI-button assignment and UI-general - settings and configuration should be united - HW-connectivity should be added (suitable for all USB-related tasks as well as ipod accessories, etc.) And some little bits: - Which category is suitable for tasks related to file-system issues? - Is the wps category intended for themes or for code patches that change WPS functionality? Why not call it UI-wps enhancement or something like that? R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominik Riebeling Sent: Tuesday, October 17, 2006 9:49 PM To: Rockbox development Subject: Re: RFC: Rockbox Flyspray policy It has been a while but I still want to post my thoughts. For easier distinction I haven't trimmed the text but only added my extensions. Comments are marked with square brackets. On 9/30/06, Jonas H [EMAIL PROTECTED] wrote: I suggest everyone pick this suggestion to bits, and when some sort of consensus is found, it should be put in the wiki and linked somewhere prominent on the Flyspray page. I think we should divide this into subpages, similar to the bugs page of the Gimp project (http://www.gimp.net/bugs/ which has already mentioned on IRC some time ago). I suggest having a UsingFlyspray (or rework ReportingBugs?) page which is the only page that is linked from the side menu for all types. From there we have separate pages for reporters and for developers. *** * ROCKBOX FLYSPRAY POLICY * *** FOR REPORTERS = Flyspray is *not* a support channel. Our support channels are the mailing lists, the forums and IRC. For support questions don't go to Flyspray as you'll get way better responses there -- the tracker is a completely different thing and used in a completely different way. You won't get any support from the tracker, it is used to keep track of tasks *only*. Note that support questions in the tracker will get closed without any comment! It is *really* important that you follow the rules for our tracker: by following these rules you make it easier for the devs to keep up with bugs, feature requests and patches which in turn means you can expect the development (and fixing of bugs) getting faster. Ignoring these rules only adds extra work for the devs and wastes precious time that could be used better for coding. When signing up please make sure you provided a correct and *working* mail address. Tasks you are involved with (as reporter or commenter) get automatically notified to you when something changes. This is a *really* important thing as it's useless to have a task which reporter can't get reached anymore, especially on bug reports. Your mail address won't get used for anything else than these notification. When submitting a task, please include as much information as you can think of. Be honest when you set the severity level, see explanation in the section below. If you are unsure about a task you want to submit please ask in the aforementioned support channels first. This helps saving work for the devs and can also avoid you quite some amount of frustration. A really annoying issue are duplicates. Please make sure the task you are about to submit isn't already present. If there is a similar task please take into consideration if it would be sufficient to comment on that existing task. Again, if you are unsure feel free to ask in our support channels. Duplicates require quite some work, and that work is precious developer time. You'll agree that wasting deveoper time isn't a good think, don't you? If you're submitting a bug, please explain: - What behavior you are seeing - What behavior you expected - How to reproduce the bug Please make sure you can reproduce the bug -- if it's not reproducable it's unlikely to get fixed. Also, make sure you have tried the latest cvs build and reset your settings (see the FAQ pages on how to do this). If you still can reproduce the bug it's worth filing. You may want to ask on IRC before filing, maybe some dev is already working on it. If you're submitting a feature request, please include: - A detailed description of the feature you want added - If you want current behavior changed, an explanation of why your suggestion is better Please also consider the following before filing a feature request: - is the requested feature possible? Music players aren't PCs, so there are quite some hardware limitations. If you are unsure please ask in the support channels. You'll most probably get an answer quicker and can
Re: RFC: Rockbox Flyspray policy
Another issue with Flyspray at the moment is that it is not possible to select an entire group of targets when you create your task. There could be something wrong with the clickwheel on the Ipods for instance. In that case you would want to file a bug report to Ipod, not Ipod nano. Martin On 10/17/06, RaeNye [EMAIL PROTECTED] wrote: While we're at it, I suggest some changes to categories: - rename categories using a two-level hierarchy, e.g., Plugins-general, Plugins-video, Plugins-games, Env-building, Env-simulator, HW-LCD, HW-remote, HW-fm tuner, Audio-general, Audio-codecs, UI-fonts, UI-language, OS-playlists, OS-bootloader, OS-ID3, - operating system/drivers and drivers should be united into HW-general - user interface should be split to UI-button assignment and UI-general - settings and configuration should be united - HW-connectivity should be added (suitable for all USB-related tasks as well as ipod accessories, etc.) And some little bits: - Which category is suitable for tasks related to file-system issues? - Is the wps category intended for themes or for code patches that change WPS functionality? Why not call it UI-wps enhancement or something like that? R. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dominik Riebeling Sent: Tuesday, October 17, 2006 9:49 PM To: Rockbox development Subject: Re: RFC: Rockbox Flyspray policy It has been a while but I still want to post my thoughts. For easier distinction I haven't trimmed the text but only added my extensions. Comments are marked with square brackets. On 9/30/06, Jonas H [EMAIL PROTECTED] wrote: I suggest everyone pick this suggestion to bits, and when some sort of consensus is found, it should be put in the wiki and linked somewhere prominent on the Flyspray page. I think we should divide this into subpages, similar to the bugs page of the Gimp project (http://www.gimp.net/bugs/ which has already mentioned on IRC some time ago). I suggest having a UsingFlyspray (or rework ReportingBugs?) page which is the only page that is linked from the side menu for all types. From there we have separate pages for reporters and for developers. *** * ROCKBOX FLYSPRAY POLICY * *** FOR REPORTERS = Flyspray is *not* a support channel. Our support channels are the mailing lists, the forums and IRC. For support questions don't go to Flyspray as you'll get way better responses there -- the tracker is a completely different thing and used in a completely different way. You won't get any support from the tracker, it is used to keep track of tasks *only*. Note that support questions in the tracker will get closed without any comment! It is *really* important that you follow the rules for our tracker: by following these rules you make it easier for the devs to keep up with bugs, feature requests and patches which in turn means you can expect the development (and fixing of bugs) getting faster. Ignoring these rules only adds extra work for the devs and wastes precious time that could be used better for coding. When signing up please make sure you provided a correct and *working* mail address. Tasks you are involved with (as reporter or commenter) get automatically notified to you when something changes. This is a *really* important thing as it's useless to have a task which reporter can't get reached anymore, especially on bug reports. Your mail address won't get used for anything else than these notification. When submitting a task, please include as much information as you can think of. Be honest when you set the severity level, see explanation in the section below. If you are unsure about a task you want to submit please ask in the aforementioned support channels first. This helps saving work for the devs and can also avoid you quite some amount of frustration. A really annoying issue are duplicates. Please make sure the task you are about to submit isn't already present. If there is a similar task please take into consideration if it would be sufficient to comment on that existing task. Again, if you are unsure feel free to ask in our support channels. Duplicates require quite some work, and that work is precious developer time. You'll agree that wasting deveoper time isn't a good think, don't you? If you're submitting a bug, please explain: - What behavior you are seeing - What behavior you expected - How to reproduce the bug Please make sure you can reproduce the bug -- if it's not reproducable it's unlikely to get fixed. Also, make sure you have tried the latest cvs build and reset your settings (see the FAQ pages on how to do this). If you still can reproduce the bug it's worth filing. You may want to ask on IRC before filing, maybe some dev is already working on it. If you're submitting a feature request, please include: - A detailed description of the feature you want added - If you want current behavior changed
RE: Rockbox Flyspray policy
My scattered thoughts: For reporters Bug - If the bug doesn't appear when using the default settings, please specify the non-default settings you're using. (maybe add the .cfg?) Feature, mostly for plugins - Note that providing a link to an open-source implementation for the requested application elevates the chances of fulfilling your request. Severity levels High - add 'possible damage to data (e.g., filesystem)', 'crash due to a non-predictable yet avoidable (e.g., by using some setting) action' Medium - add 'crash due to a predictable action' We need to define more carefully what constitutes a majority/minority of RB users. Are ipod users a majority? A minority? What about ondio sp users? Moreover, most RB users wouldn't notice changes in codecs/plugins they don't use. For admins I link duplicate tasks (via related tasks) mostly because some useful comments exist on either task, so that's my way of saving relevant discussion while closing the redundant task. Status - I usually change verified bug reports status to Researching and outdated bug reports with a 'please check whether the problem persists' comment to Waiting on Costumer. Closing reports Maybe we should consider using the Later status for rather large yet obviously needed feature reqs, e.g., implement USB-OTG for supported HW or optimize AAC codec. R.
Flyspray severity setting
I think we need some kind of guidelines for these. First of all, is there any reason for feature requests and patches to have severity other than normal? Then, for bugs I suggest the following key: (please add more bullets here) * Critical o A (previously working) target cannot be used for audio playback at all o Possible damage to hardware * High o A core feature (e.g., some codec) doesn't work o A nonpredictable action freezes/segfaults but can be avoided (e.g., by using some setting) o Possible damage to data (e.g., filesystem) * Medium o A predictable action freezes/segfaults * Low o Non-core related annoyances o Button assignments * Very Low o Visual glitches My 2 cents, R. P.S. When we're done with these we could deal with priority values and other flyspray settings; IMHO, severity is the least intuitive property.
Re: Flyspray severity setting
I agree with you most completely. Some more thoughts: On 9/18/06, RaeNye [EMAIL PROTECTED] wrote: First of all, is there any reason for feature requests and patches to have severity other than normal? I think feature requests should get a severity of normal or low as default. If someone starts working on a specific request, the severity could be increased, making it easier to find them. Also, how should we deal with a patch to a feature request? IMO if a patch to an already existing request gets committed (to FS, not cvs) it would be the cleanest to close the original feature request as duplicate, noting the patch in the close comment. This way we won't have that type of duplicates. It also would solve the issue of patches that get accepted but the original feature requests for that specific patch getting missed and staying open (until someone goes through FS and closes them). If someone starts working on a feature request, that request could be modified to a patch and its severity set accordingly. That would keep patch and request together. - Dominik
Re: Flyspray severity setting
On 9/18/06, RaeNye [EMAIL PROTECTED] wrote: Dominik said: If someone starts working on a specific request, the severity could be increased, making it easier to find them. Shouldn't you assign it to yourself instead/as well? good point, missed that ;-) The important thing IMHO is to connect them via 'related tasks'. Then we could have a script that finds closed patches related to open feature reqs I just looked a bit deeper into that, agreed. It only needs the person who closes a task to give a bit attention to the related tasks field (which I didn't do up to now -- IMO this field is a bit too hidden). Maybe FS could display the number of related tasks in the overview at the top? Or, even better, the task IDs? If someone starts working on a feature request, that request could be modified to a patch and its severity set accordingly. That would keep patch and request together. But what happens when you only partially implement the req? same point is relevant for closing the feature request... Close the remaining request and open a new one yourself, indicating that this was part of a different request possibly? Using two tasks for request and patch and connecting them is also an option, but I'm a bit unsure which is better. - Dominik
Re: Flyspray and forgotten patches.
I'd like CVS commit access, but I don't know that I'd be much more proactive than the current devs -- a patch /should/ a certain amount of time on the tracker, to ensure it's beta tested. That said, tooting my own horn, I think a couple of my patches are pretty much no-brainers and if I had commit access I'd likely add them (after the feature freeze). Daniel Stenberg wrote: On Wed, 12 Jul 2006, Liberman Shachar (Lamed) wrote: I don't know if this is some feeling many contributors share, but I for once feel that many of my work, which I always make sure is worthy gets left out of the main cvs branch, and not for a good reason but for the reason nobody takes the time having a look at it. This is how it is and yours are not the only good patches that are still pending due to us committers focusing too little on patches or simply just not having enough time in our lifes. But it is also a matter of us focusing on getting a 3.0 out the door so there should be a focus on fixing the relevant bugs (only). Personally, I just haven't had much time for Rockbox for months. For anyone without CVS commit access who think you have what it takes to get it, please speak up and we'll take everyone into consideration. We need more committers.
Re: Flyspray and forgotten patches.
I know the feeling that lamed just described. Many times in the past some of my patches (not something extremely major) would sit idle on the tracker for a lot of time. Sometimes I would pester some of the devs to look at them but after a while I feel a little weird to annoy or disturb some of you with my work. In my case I was lucky and Bger has committed most of my big patches. (Thanks Bger! (and of course all the devs)) On the other hand I can truly understand the developers. They have their own life, problems and code to work with. Add to that the low CVS activity due to summer, or the feature freeze (which I am not on the side of ending it) and it only gets worse. I, for myself, would certainly like to have CVS access but I am not sure if I got what it takes to, or if I really deserve it. Having access you can avoid asking or disturbing devs repeatedly but on the other side it is a major responsibility as to what you are going to commit in the end. That's why I believe that you, (main developers) should give CVS access to those that you think they can handle the responsibility and that they will be able to help on the process of committing bug fixes, patches and eventually new features. Having more active developers is surely an asset on moving Rockbox forward, though choosing who is able to do it, may be a difficult call.. On 12/07/06, Daniel Stenberg [EMAIL PROTECTED] wrote: On Wed, 12 Jul 2006, Liberman Shachar (Lamed) wrote: I don't know if this is some feeling many contributors share, but I for once feel that many of my work, which I always make sure is worthy gets left out of the main cvs branch, and not for a good reason but for the reason nobody takes the time having a look at it.This is how it is and yours are not the only good patches that are stillpending due to us committers focusing too little on patches or simply just not having enough time in our lifes. But it is also a matter of us focusing ongetting a 3.0 out the door so there should be a focus on fixing the relevantbugs (only).Personally, I just haven't had much time for Rockbox for months. For anyone without CVS commit access who think you have what it takes to getit, please speak up and we'll take everyone into consideration. We need morecommitters.--Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Flyspray and forgotten patches.
Hey guys. I don't know if this is some feeling many contributors share, but I for once feel that many of my work, which I always make sure is worthy gets left out of the main cvs branch, and not for a good reason but for the reason nobody takes the time having a look at it. I think it will only be dignified if at least someone will say 'sorry, I took a look and it doesn't looks like a good thing to have', or ask a bunch of question regarding the patch so I could clarify things about what was done. The only patch I had gotten to be committed was the screen scroll patch, and actually nobody reviewed that one to it's full depth either, it was just a long time talking about it over and over again by the IRC channel until someone ran it on a bunch of simulators and decided it's good enough. my patches are far from being low-level. they are usually just improvements to stuff I thought I could benefit to everyone else with, and sometimes I even go the long way of having some dev to agree that some patch is a good idea, but unless I talk about it day and night, nobody actually does anything about including it. I _really_ hope this will get nicely answered. hebrew translation major update http://www.rockbox.org/tracker/task/5587 one button hold for vertical screen scroll patch http://www.rockbox.org/tracker/task/5182 holdswitch pause games http://www.rockbox.org/tracker/task/4761 (could be a tad out of date) I have a star game fix for h-100 series but we are all about porting to color screen now... (it's still a very good patchfile, I guess I lost hope it'll get in.) have a good day everyone! I'm way to tired to go on with it.
Re: Flyspray
Actually, if you look at my New Forum Proposal sticky in the general discussion forum, I do believe one of the changes I would like to make is to have two forums specifically for the purpose of discussing patches (as an alternative to the comments on the patches at Flyspray, which seem a little out of the way for the general public, and a better place for specific questions from devs, and patch update postings). The idea would be to still have the patches on the tracker, but also to have the author post a link in the patch entry to the forum thread, and a link in the first post on the thread to the tracker entry. The two forums would be for Plugins and Non-plugin Patches. Of course, these will only go into effect if I'm reasonably certain I won't get chewed out for doing it, and there's still a large weakness in the new forum proposal (lack of hardware specific forums entirely, which resolves some issues, but introduces new ones since there are *some* hardware specific questions). On 6/28/06, Björn Stenberg [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: Actually, I learned there is a drop-down (if you're logged in to Flyspray) to show tasks reported by me, which allows me to see my patches.Ah, lookie there! You learn something new everyday. :-)Also, I noticed the Reports function allows date searching of the kind you initially requested. Such as list tasks with attachments added on 2006-04-17. --Björn
Re: Flyspray
Paul Louden said: Actually, if you look at my New Forum Proposal sticky in the general discussion forum, I do believe one of the changes I would like to make is to have two forums specifically for the purpose of discussing patches (as an alternative to the comments on the patches at Flyspray, which seem a little out of the way for the general public, and a better place for specific questions from devs, and patch update postings). The idea would be to still have the patches on the tracker, but also to have the author post a link in the patch entry to the forum thread, and a link in the first post on the thread to the tracker entry. The two forums would be for Plugins and Non-plugin Patches. Of course, these will only go into effect if I'm reasonably certain I won't get chewed out for doing it, and there's still a large weakness in the new forum proposal (lack of hardware specific forums entirely, which resolves some issues, but introduces new ones since there are *some* hardware specific questions). Since all patches are announced via an email if you are subscribed, I don't really see the point of this. If you want to follow up via email rather than flyspray, then simply post to the rockbox-dev list instead. THere's a lot to be said for followups to be kept within the thread on flyspray though, so they are all kept together. -- Mike Holden
Re: Flyspray
What do you mean by all patches are announced via an email?Not everyone announces their patches on the list, and there's also great benefit in putting patches in front of the eyes of the general public for discussion. That way more users know of its existence, and can comment on bugs it causes etc, more easily. On 6/28/06, Mike Holden [EMAIL PROTECTED] wrote: Paul Louden said: Actually, if you look at my New Forum Proposal sticky in the general discussion forum, I do believe one of the changes I would like to make is to have two forums specifically for the purpose of discussing patches (as an alternative to the comments on the patches at Flyspray, which seem a little out of the way for the general public, and a better place for specific questions from devs, and patch update postings). The idea would be to still have the patches on the tracker, but also to have the author post a link in the patch entry to the forum thread, and a link in the first post on the thread to the tracker entry. The two forums would be for Plugins and Non-plugin Patches. Of course, these will only go into effect if I'm reasonably certain I won't get chewed out for doing it, and there's still a large weakness in the new forum proposal (lack of hardware specific forums entirely, which resolves some issues, but introduces new ones since there are *some* hardware specific questions).Since all patches are announced via an email if you are subscribed, I don't really see the point of this. If you want to follow up via emailrather than flyspray, then simply post to the rockbox-dev list instead.THere's a lot to be said for followups to be kept within the thread on flyspray though, so they are all kept together.--Mike Holden
Re: Flyspray
On Wed, 28 Jun 2006, Paul Louden wrote: What do you mean by all patches are announced via an email? I think he refers to the rockbox-sf mailing list: http://cool.haxx.se/cgi-bin/mailman/listinfo/rockbox-sf -- Daniel Stenberg -- http://www.rockbox.org/ -- http://daniel.haxx.se/
Re: Flyspray
I think a patch-forum would be a good idea too, because on Flyspray patches can easily get out of sight if you don't subscribe to them. In a patch forum you could follow updates to patches and general discussion on a patch more easily (for instance you can see which patches are still activly developed) and you get definatly more feedback from users. I got most of my ideas for improving my patch through a form thread.
Flyspray patches, mime type
The patch tracker seems to give (or Firefox assumes) the mime type of the link to a patch (e.g., http://www.rockbox.org/tracker/?getfile=11546) is application/octet-stream. This means that Firefox insists that the file be downloaded or a handler program be specified, and worse, refuses to allow a particular handler to set as the default handler for the type. I want to be able to browse the patches without (explicitly) downloading them. Is there a way to make the mime type text/plain? Thanks.
Flyspray abuse..?
Please could somebody with the ability consider closing bug #5471 - http://www.rockbox.org/tracker/task/5471 IMHO this is a support query, not a bug report and should be redirected to the forum, user mailing list or IRC. There are already plenty of support channels (too many?) and there is no advantage to tolerating the use of Flyspray for this. Steve Bavin
