RDF Development and Maintenance Process

[vickyg2003]

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!

[xnappo]

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.ne ... f?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

[jimdunn]

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

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.

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

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)

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...

[xnappo]

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

[The Robman]

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.

[gfb107]

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.

[vickyg2003]

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....

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.....

[The Robman]

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).

[vickyg2003]

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.

[xnappo]

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

[gfb107]

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.

[xnappo]

Final call for objections to these being merged...
xnappo

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]

[The Robman]

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.

[mdavej]

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.

[xnappo]

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