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 _______________________________________________ gnome-web-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gnome-web-list
