|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Thu Apr 29, 2010 10:43 am Post subject: |
|
|
xnappo wrote: | jimdunn wrote: |
I don't know - but it seems to beg discussion... |
Personally I think this should follow the process I outlined.
When an extender is in development, keep the RDF with the extender or in the development folder. When the RDF is mature, it should be moved into revision control.
If an update to a mature RDF is needed, the author should either check in the change themselves or contact one of the SourceForge developers to do it for them.
Otherwise we will run into issues with people winning the lottery etc. when we want to make some general improvement 8 years from now (like we are now with making sure protocols and updates are correct and making sure filenames are Linux friendly).
xnappo |
I have absolutely no problem with my exteder RDF's being included in the zip file. In fact, I prefer it that way. However to recover from an RDF mistake in my extenders, its simply a matter of doing a 981 reset and/or supplying a corrected RDF.
If an RDF error were introduced into a JP1.3 extender RDF, the recovery isn't nearly as easy, and the only person capable of guiding a user through the recovery process is unclemiltie, so I would definately respect his wishes to leave his RDF's out of the main zip as long as he's an active member of this forum! _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 862
|
Posted: Thu Apr 29, 2010 10:44 am Post subject: |
|
|
jimdunn wrote: |
So long as only "trusted" rdf developers can check in a final version that seems to work perfectly - since everyone can obviously co-operate there.
I'm certainly not trying to criticise the process - if anything, just trying to understand it.
And any well considered process is bound to be better than the lack of one - so I think what you're doing here is admirable, and essential. |
Sure - that is part of the whole revision control model.
First off, only people Greg or one of the other project leads at SourceForge give permissions to have access to 'commit' files -so there is one level of protection.
Next, the revision control tool generates nice reports that let you see any file that was modified since the last official release, who modified it and when, what comment they made as to why they modified it, and also display a graphical 'diff' of the changes made. In short - it is very powerful.
The TortoiseSVN client is more powerful, but you can get an idea of this by going here:
http://controlremote.svn.sourceforge.net/viewvc/controlremote/trunk/remotes/rdfs/10251025%20%28Atlas%205%20Day%20URC-1055_11055%20JP1.2%29.rdf?view=log
And then click 'Diff to previous 731'
Then the RDF maintainer can choose what to 'tag' as official. If something looks suspicious then they can choose to stay with the old release until it is resolved through consultation here.
It takes a while to get used to for those that don't use it at their 'real' job, but it is pretty much the way this sort of thing is done.
Please feel free to ask about the process and suggest ways to improve it!
xnappo |
|
Back to top |
|
|
jimdunn
Joined: 29 Jun 2004 Posts: 544 Location: NSW, Australia |
Posted: Thu Apr 29, 2010 11:03 am Post subject: |
|
|
xnappo wrote: |
Sure - that is part of the whole revision control model.
First off, only people Greg or one of the other project leads at SourceForge five permissions to have access to 'commit' files -so there is one level of protection.
|
I hadn't realised that - probably my error in not reading the model, sorry
Quote: |
Next, the revision control tool generates nice reports that let you see any file that was modified since the last official release, who modified it and when, what comment they made as to why they modified it, and also display a graphical 'diff' of the changes made. In short - it is very powerful.
|
I know - and that's great for analysis so long as participants can use and understand it.
Quote: |
Then the RDF maintainer can choose what to 'tag' as official. If something looks suspicious then they can choose to stay with the old release until it is resolved through consultation here.
|
That's where I'm unclear, I guess - the "maintainer" versus "project leads" and how that is tied to individual rdfs - I guess I should have a better look at how you've set that up - I confess I haven't
Quote: |
It takes a while to get used to for those that don't use it at their 'real' job, but it is pretty much the way this sort of thing is done.
|
I've been developing software for 25 years - but always we've managed revisions internally because of the small size and nature of the projects - we should turn it into a "real job" one day - you're absolutely right - and we've often discussed it - but always decided it was a great idea for later when we weren't so busy (I'm serious here, by the way - in case you read this wrong)
Quote: |
Please feel free to ask about the process and suggest ways to improve it! |
I think I felt free about that already - well, I asked anyway - you might even find a suggestion for improvement at some point, but you seem to have it pretty well covered so far... |
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 862
|
Posted: Thu Apr 29, 2010 11:20 am Post subject: |
|
|
jimdunn wrote: |
Quote: |
Then the RDF maintainer can choose what to 'tag' as official. If something looks suspicious then they can choose to stay with the old release until it is resolved through consultation here.
|
That's where I'm unclear, I guess - the "maintainer" versus "project leads" and how that is tied to individual rdfs - I guess I should have a better look at how you've set that up - I confess I haven't
|
That is an interesting point. Right now I don't think it is an issue (because the number of people wanting access is small) but long term we may want more granularity in permissions.
Greg,
Does SourceForge allow you to separate 'Commit' vs. 'Tag' permissions?
xnappo |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Thu Apr 29, 2010 12:08 pm Post subject: |
|
|
Here's another suggestion to add to the mix, how about having two separate zips of RDFs, one for the regular remotes and another for extenders?
It occurs to me that the RDFs for the regular remotes should not need to change, once they're finalized, unless a global change to IR requires a change. Whereas RDFs for the extenders may need to change as the extender evolves and new features are added.
The advantages would be (a) people who don't use extenders won't need to have the additional RDFs cluttering up their remote drop downs in RM, etc and (b) an extender developer won't risk overlaying any "in process" extender RDFs when they download the master zip. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Thu Apr 29, 2010 12:36 pm Post subject: |
|
|
The Robman wrote: | Here's another suggestion to add to the mix, how about having two separate zips of RDFs, one for the regular remotes and another for extenders?
It occurs to me that the RDFs for the regular remotes should not need to change, once they're finalized, unless a global change to IR requires a change. Whereas RDFs for the extenders may need to change as the extender evolves and new features are added. |
Not true, you need to check RDF's to make sure no variants have been identified. As more support for more protocols is added the protocols area changes. Now if this were a centralized file....
Quote: |
The advantages would be (a) people who don't use extenders won't need to have the additional RDFs cluttering up their remote drop downs in RM, etc and (b) an extender developer won't risk overlaying any "in process" extender RDFs when they download the master zip. |
I find that when I downloaded previous RDFzips that if I didn't delete the entire directory, I had problems with obsolete RDF's confusing the issue. That was much more troubling than having to keep my inprocess RDF's in a safe place to be added later.
While the clutter may be a problem, the confusion when opening an existing RDMU that were created with the extended remote as the basis outways that. And as you know there are times when an upgrade is different if the extender was used.
If you don't have a complete set of RDF's it also disuades people from looking at other peoples IR files. I learned a lot from looking at other people's IR files, but if it had been difficult, I doubt I would have bothered.
I do believe that there was some talk about adding a field to the RDF that could allow extender RDF's to be dismissed from the dropdowns. That would be worth exploring..... _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Thu Apr 29, 2010 12:49 pm Post subject: |
|
|
Maybe the remote drop down could be split into 2 drop downs, where you select the remote in the first drop down and the variant in the second (ie, 1k, 2k, 4k, extender1, extender 2, etc). _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
vickyg2003 Site Admin
Joined: 20 Mar 2004 Posts: 7073 Location: Florida |
Posted: Thu Apr 29, 2010 1:06 pm Post subject: |
|
|
Whoops when I said variants I meant new protocol variants.
I think that the idea last year of just saying show extenders or not was a good idea for the dropdowns, although since binky widened theat window in IR so that we could see a wider remote name a lot of MY issues with confusion cleared up. I was never confused as to whether to pick extender or not, I was just confused because I couldn't see the whole word extender written out.
I don't think this is as much an issue as it used to be prior to the widening of the field. _________________ Remember to provide feedback to let us know how the problem was solved and share your upgrades.
Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.
|
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 862
|
Posted: Thu Apr 29, 2010 1:49 pm Post subject: |
|
|
gfb107 wrote: | xnappo wrote: |
Greg,
Does SourceForge allow you to separate 'Commit' vs. 'Tag' permissions?
xnappo |
Write access to SVN is all or nothing. However, 'Release Technician' permission is separate from SVN access. |
Okay, I think it is still fine anyway because the links to the zip file/release area is from this site, where only site moderators could change what tag is being pointed to.
xnappo |
|
Back to top |
|
|
gfb107 Expert
Joined: 03 Aug 2003 Posts: 3411 Location: Cary, NC |
Posted: Thu Apr 29, 2010 2:14 pm Post subject: |
|
|
Making release .zip/.exe files available is a Release Technician job, which would be a much smaller set of people than developers. Probably just you and me.
So I agree, I don't see a problem.
- People have to be approved to be developers. Their developer status can be revoked at any time.
- Any version of any file can be retrieved at any time, even deleted files.
- The changes made to any file by any developer at any time can easily be identified and reverted.
- The developer responsible for any change can be easily identified.
- Release .zip/.exe files are managed by developers with the special privilege 'Release Technician'. Very few people will have this privilege.
_________________ -- Greg
Original RemoteMaster developer
JP1 How-To's and Software Tools
The #1 Code Search FAQ and it's answer (PLEASE READ FIRST) |
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 862
|
Posted: Thu Apr 29, 2010 4:54 pm Post subject: |
|
|
Final call for objections to these being merged...
xnappo
xnappo wrote: |
10181018 (URC-39860 B00-02) RDF Map and Image [mdavej]
10621062 URC-7780 map jpg rdf for IR 8.00 [mathdon]
10751075 (URC-7556 Digital 5) [czo]
11311131 URC-7781 map jpg rdf for IR 8.00 [mathdon]
113A113A (URC-7781 Extender A1) rdf for IR 8.00 [mathdon]
30043004 (URC-2050) .RDF .JPG .MAP [drussell]
30273027 (Vizio VUR8 6100 JP1.3) map jpg rdf [kmradke]
30583058 (URC-7525, next iteration) [barf]
30603060 (Radio Shack 15-100) JP1.3 [Rob - obsolete??]
30603060 (Radio Shack 15-100) with HT and Language Settings [mdavej]
30653065 (Charter OCAP C4000 URC-1060 ) [mjdave]
30853085 (Radio Shack 15-133, 15-134, 15-135) JP1.3 [mdavej]
31473147 (Insignia / Sanyo Remote 67100) RDF, Map, Image [mdavej]
CA00 (Control 4 URC-81000-B00) RDF/Image/Map files [mr_d_p_gumby]
LATLLAT0 (Mundial URC-414XXX) RDF/Image/Map Files [mr_d_p_gumby]
URC-3450 URC-3451 RDF image and map files.zip [damir]
URC-8210 Multiple maps [gertc]
|
|
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21279 Location: Chicago, IL |
Posted: Thu Apr 29, 2010 5:23 pm Post subject: |
|
|
I lay no claim to the 15-100 RDF. I assume other people have done a ton more work on it after the last time I looked at it, so you have my OK to go with Dave's version. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mdavej Expert
Joined: 08 Oct 2003 Posts: 4523
|
Posted: Thu Apr 29, 2010 7:26 pm Post subject: |
|
|
No objections, but a comment.
To head off any confusion, I just wanted to point out that there already is a 10181018 RDF in the old distribution, but this one is slightly different because it's for what I assume is a later -02 version of the original 39860. Either that or the original had errors. I don't know for sure. No harm in keeping both I suppose. |
|
Back to top |
|
|
xnappo Expert
Joined: 30 Dec 2003 Posts: 862
|
Posted: Thu Apr 29, 2010 7:42 pm Post subject: |
|
|
mdavej wrote: | No objections, but a comment.
To head off any confusion, I just wanted to point out that there already is a 10181018 RDF in the old distribution, but this one is slightly different because it's for what I assume is a later -02 version of the original 39860. Either that or the original had errors. I don't know for sure. No harm in keeping both I suppose. |
I was under the impression it was for a new physical revision of the remote - but it is hard to tell. If anyone knows for sure please let me know.
mdavej - another question though - your RS15-13x zip also contains a pause protocol. What should I do with that?
Thanks,
xnappo |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|