JP1 Remotes Forum Index JP1 Remotes


FAQFAQ SearchSearch 7 days of topics7 Days MemberlistMemberlist UsergroupsUsergroups RegisterRegister
ProfileProfile Log in to check your private messagesLog in to check your private messages Log inLog in

RDF Development and Maintenance Process
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
 
Post new topic   Reply to topic    JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs
View previous topic :: View next topic  
Author Message
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 10:43 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 10:44 am    Post subject: Reply with quote

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
View user's profile Send private message
jimdunn



Joined: 29 Jun 2004
Posts: 544
Location: NSW, Australia

                    
PostPosted: Thu Apr 29, 2010 11:03 am    Post subject: Reply with quote

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 Embarassed

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 Embarassed

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
View user's profile Send private message Visit poster's website
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 11:20 am    Post subject: Reply with quote

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 Embarassed


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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Apr 29, 2010 12:08 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Thu Apr 29, 2010 12:28 pm    Post subject: Reply with quote

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.
_________________
-- 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
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 12:36 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Apr 29, 2010 12:49 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
vickyg2003
Site Admin


Joined: 20 Mar 2004
Posts: 7073
Location: Florida

                    
PostPosted: Thu Apr 29, 2010 1:06 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 1:49 pm    Post subject: Reply with quote

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
View user's profile Send private message
gfb107
Expert


Joined: 03 Aug 2003
Posts: 3411
Location: Cary, NC

                    
PostPosted: Thu Apr 29, 2010 2:14 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 4:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
The Robman
Site Owner


Joined: 01 Aug 2003
Posts: 21210
Location: Chicago, IL

                    
PostPosted: Thu Apr 29, 2010 5:23 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
mdavej
Expert


Joined: 08 Oct 2003
Posts: 4500

                    
PostPosted: Thu Apr 29, 2010 7:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
xnappo
Expert


Joined: 30 Dec 2003
Posts: 861

                    
PostPosted: Thu Apr 29, 2010 7:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic       JP1 Remotes Forum Index -> JP1 - New Remotes & RDFs All times are GMT - 5 Hours
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 4 of 7

 
Jump to:  
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
Top 7 Advantages of Playing Online Slots The Evolution of Remote Control