Inclusion of simon in kde-accessibility

[grasch at simon-listens.org]

> On Tue, Jul 20, 2010 at 4:39 PM, Albert Astals Cid <aacid at kde.org>
> wrote:
>> A Dilluns, 19 de juliol de 2010, Peter Grasch va escriure:
>>> Hm. What about extragear/accessibility?
>>>
>>> I just checked and it looks like that doesn't yet exist.
>>>
>>> Seeing as there seem to be some extragear applications already on
>>> KDEs experimental git repository, would that be an option? We have
>>> been doing our own releases for years so that wouldn't be that much
>>> of a problem...
>>>
>>> Mirroring it on KDEs SVN for the review shouldn't be an issue as long
>>> as this is just a transition step anyways. Should I just checkin a
>>> copy into kdereview?
>>
>> Personally i'm not a fan of having non primary dumps of code in the
>> repo since i know several people that do roaming fixes in the KDE repo
>> and if they do that fix in code that is just a dump the fix is lost.
>>
>> AFAIR we had a rule that said that KDE repo should be the primary
>> development plaftorm for KDE software but i've been unable to find if
>> in techbase.
>>
>> I'd like others to comment on this.
>>
>> Albert
>>
>
> I think this is what you are referring to:
>
> http://techbase.kde.org/Policies/SVN_Guidelines#Stage_1:_The_start
>
> "It is not meant as a backup area, so you should not develop your
> application somewhere else and only sync the changes now and then to
> KDE's repository. "

Well I wasn't talking about doing the development outside of the KDE
repository...
If it were to be possible to create an extragear/accessibility repository
on git.kde.org where simon could move to (which is what I tried to propose
in my previous mail) then there would be basically two approaches as I see
it:

Approach A

1.) Move from SF Git to KDE SVN for the review process
2.) Move from KDE SVN to extragear Git for further development

Approach B

1.) Mirror the SF Git on KDE SVN for the review process
2.) Move from SF Git to extragear Git for further development

IMHO option B seems much easier considering that the review process -
accepted or rejected - shouldn't take longer than a couple of weeks if I
am not mistaken.

I would think that keeping these two repos in that short period of time
would work better than moving from git to svn and back.

Moving back to SVN permanently won't work for us because we might need
specific features urgently for our running research projects. We
accommodate this by creating a new Git branch to implement the missing
feature without affecting e.g. possible freezes (they are then merged back
when trunk re-opens).

This, btw, was also the reason why I have not been sure whether to apply
for extragear or not in the first place but after talking to Jeremy
Whiting in #kde-accessibility he said that these branches would be ok -
for him at least - which is why I applied to be included in the
accessibility module instead of extragear.

But as these branches would be hard to handle in SVN and the kde
accessibility module is staying on SVN for now this is not really an
option anyway.
Sorry for any confusion this might have introduced.

For the record: If we were to be accepted into a KDE Git repository, I
have absolutely no intention having another fork laying around somewhere
else. In fact the only reason why I keep talking about needing Git is
because I want to avoid that situation.

Regards,
Peter