Re: PloneSoftwareCenter DOAP



Simone Deponti wrote:
Hello,

    I'd be happier if there were some passing tests before we merge. Why is
    it a problem?


It's not a problem per se, I just need to write the tests and it'll take me time, so this means atleast another week/week and a half before merge. I don't know if wgo can wait all that much.

If I were wgo, I wouldn't deploy software with no tests. :)

If they need to, they can deploy the branch and switch later. I don't see why adding tests after merge helps anyone.

    You need to consider migrations here. If you change the value and we
    upgrade PSC on plone.org <http://plone.org>, will eveyone who had
    "All platforms" (very
    common for Plone) find that their selection is invalid?


Yeah, we'll have to migrate the content. The problem is simple: the DOAP spec says that you should put the <os> attribute only when the product/project is OS specific. In PSC however, we have no operating system associated to the project but rather, we have it associated to the release file. This is not a big deal, since I simply do a catalog search to get all the PSCFile and PSCFileLink contained in my project, extract the list of os supported from them and I'm basically done. The problem is that by doing so I end up writing in the feed something like <os>All platforms</os>. This isn't a great example of "adhering to the specs" and honestly I don't like it at all.
Thinking of the possible solutions, I came to these three solutions:
1. In DOAPView, filtering the "All platforms" keyword somewhat. Doesn't work because "All platforms" can be changed for example into "All operating systems" by the user in PSC configuration.

2. Making sure that the "All platforms" choice has always the same value and then apply solution one. That's what my proposal was about, simply enforcing a value for "All platforms" and taking that out from the user control. We can also think about keeping "All platforms" as both label and value, but enforcing them with the patch I proposed. Anyway, this solution has a drawback when it comes to internationalization: I have yet to see how we can fit this with the i18n system (there is a way, though, by directly calling translation_service.utranslate() from the vocabulary method).

3. Decide we do not need the OS attribute exported into DOAP, and skip it.

I still favor approach number 2: If instead of none we use "All platforms" we shouldn't have migration issues on plone.org <http://plone.org>, although someone else might if in his setup he changed "All platforms" to something else.

Hope I have explained myself well.


or 4, let the user select which value really means "all platforms", but that's still cumbersome. I think having it as a special value (2) makes sense, but you can't put that in trunk unless there is fallback or migration support.

Martin




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]