I have to say, I'm a bit fuzzy on the policy here, too.
Things I know:
* We don't want to be in the business of listing every single application
that claims Subversion support.
* We don't want to appear to endorse one IDE/3rd-party-client over
another -- users can form their own opinions.
Had I to construct this policy right now, I'd say that (especially on a
'links' page) the primary deliverable is useful links, not a list of
software. We should be focused on providing links to Subversion-centric
third-party tools, IDEs, and IDE add-ons that are of obvious benefit to
users. If a standard installation of some IDE includes Subversion, we don't
need to list it. If, however, the Subversion support in some IDE or tool is
an add-on not included in a standard installation, then there is value to
users of that IDE in us providing a link to the place where they can get
that add-on. Notice that the distinction here isn't about whether the
Subversion support comes via a plug-in or add-on (modular development isn't
exactly a new concept). The distinction is about whether that plug-in is
something folks might find themselves having to locate on the Web themselves
because it isn't part of the standard installation of their tool of choice.
Andrés G. Aragoneses wrote:
> Julian Foad wrote:
>> On Thu, 2008-06-12 at 10:40 +0200, "Andrés G. Aragoneses" wrote:
>>> Karl Fogel wrote:
>> [...]
>>>> I'm not sure it makes sense for us to link to every IDE that has
>>>> Subversion support, since huge numbers of them do these days. Instead,
>> [...]
>>
>>> I am not going to argue about this: you have the policies that you
>>> want. But the only thing I would say is: if you don't include
>>> MonoDevelop, please drop also NetBeans, JDeveloper, etc. (just for
>>> consistency).
>>
>> You are right, of course, Andrés. Thank you for saying it politely. This
>> decision was bound to come up sooner or later as support for Subversion
>> becomes more widespread, and it just happened to come up now.
>>
>> I have removed those, and one called "Eric", in r31710. The JDeveloper
>> entry did contain a link named "Subversion plugin" but the linked page
>> didn't mention it, so it's not clear what its status is. If there still
>> is a separate plug-in it would be perfectly fine for somebody to
>> reinstate a link to it. (The entry was worded too much like an advert
>> for me to have much sympathy with it :-) .)
>>
>> I have also split up the section (in r31711) into four smaller
>> categories to make it easier to find the links one is interested in.
>
> Thanks for your answer Julian
>
> One last thing to discuss: it seems not clear yet for me, upon your and
> Karl's statements, the policy about the inclusion, given that they are a
> bit contradictory: Karl argues about not accepting programs that have
> SVN support (we could define them as anyone who calls svn client API,
> right?) but you seem more focused on having just a "module" for a
> program which is a client.
>
> Regarding your opinion, and not Karl's, MonoDevelop could also be
> included because:
> - It's based on add-ins (more or less the same as plugins).
> - It has a VersionControl add-in [1].
> - It has a Subversion add-in [2], which depends on the former.
>
> Regards,
>
> Andrés
>
> [1]
> http://anonsvn.mono-project.com/source/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl/
>
> [2]
> http://anonsvn.mono-project.com/source/trunk/monodevelop/main/src/addins/VersionControl/MonoDevelop.VersionControl.Subversion/
>
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-06-12 16:18:15 CEST