[Kde-pim] Re: KDEPIM Git Move

[Torgny Nyblom]

On Thursday 04 November 2010 11.20.43 Allen Winter wrote:
> Howdy,
> 
> As negotiated today between me, Volker and Torgny we have decided
> to make the KDEPIM move to the new KDE Git repo after the 4.6 branching.
> 
> The release schedule says this should on 21 Dec, approx.

This means that some time before the actual move any merging will be 
disallowed to allow the final rules to be written and verified. Also there 
will be a period when the KDEPIM repositories will be read-only.

Proposed workflow:
Events happen from top to bottom and the proposed times are a guess not to be 
taken as descided. Also if the schedule is to be accepted then the Christmas 
holiday might delay (or speedup?) certain parts.

Day 0: KDE 4.6 is branched:
Day 0: No merges/moves/copies allowed in KDEPIM.
Day 2: Rules and generated gits availabe for review.
Day 4: KDEPIM is made read-only.
Day 4-5: KDEPIM is converted.
Day 6: KDEPIM is pushed to git.kde.org
Day 6: KDEPIM git acceptance check.
Day 7: KDEPIM is open for buissness as usual but hosted in git.

Rollback plan: (Re)Open the SVN repository and do another try when whatever 
blocker is fixed.

As the schedule is above that would mean that KDEPIM will be read only for 3-4 
days and a sort of feature freeze will be in affect for 7 days beyond the 4.6 
freeze.

One open issue:
The grand plan is to keep SVN open in a read only mode after the migration, 
however the parts that have already moved to git has been deleted from SVN.
This is (in my view) a mistake as it makes browsing old history a pain as one 
would need to know at what revision the part one is interested in was deleted. 

As I see it there are three ways of doing it: (current way is #1)
1) Move to git, replace SVN copy with a file telling people where it went and 
after X days remove the directory.
2) Same as above but do not delete the directory.
3) Move to git and make the SVN copy read only with a file telling people 
where it went.

#1 Has the benifit of clearly marking what is left in SVN as other parts are 
gone, but the downside of making browsing harder.

#2 Has the same downside as #1 but it willl be easier to find the correct 
revision (as the readme file was added at that point). The upside is also 
close to that of #1 but not as big as the directories will still be in SVN.

#3 Has the upside of easy history access. It has the downside of not making it 
clear that SVN is not to be used.

Personally I prefer option #3 but I'm not the one making the descision, so 
opinions?

/Regards
Torgny
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/