Move kdeplasma-addons to git - take 2

Albert Astals Cid aacid at
Mon Nov 8 01:26:22 CET 2010

A Diumenge, 7 de novembre de 2010, Aaron J. Seigo va escriure:
> CC'ing the release team on this, since there's a point of interest here.
> Release Team: Artur is working on migrating kdeplasma-addons to git. the
> question is now about logistical details and issues. see below.
> On Saturday, November 6, 2010, Artur de Souza wrote:
> > Any thoughts?
> a) thanks for working on this
> b) this is going to force us to define our desired workflow for plasma now
> that we have git. more on that later, and i think an irc meeting for that
> is in order, in fact.
> c) timing will be important and we need to coordinate development.
> personally i can imagine at least two approaches:
> * we make the migration ASAFP, before the first betas of 4.6 and before 4.7
> is branched off so that backporting / forwardporting changes will continue
> to happen
> * make the change shortly after the public release of 4.6, to maximize the
> easy-backporting window
> personally, i prefer the first since it will give us continuity between 4.6
> and 4.7. usually once we go into beta of a release and the next one is
> about to branch off, the older release stops getting backported fixes
> anyways. in this case that would be the 4.5 branch in svn. so this would
> be the nicest time to make the switch, imho.
> but that will require support from the release team as the release of
> kdeplasma-addons for 4.6 would have to come from instead of
> if the release team members veto that for the 4.6 release,
> then we will need to consider the second (or some other?) option.

Personally from a i18n/scripty POV and given the kdeplasma-addons size (we 
never had such a module git based in scripty yet) i'd prefer the switch to be 
done after 4.6 release (so if there are problems it does not affect 4.6 l10n) 
or tomorrow (so if there are problems they can be fixed asap).


> also, when we do the import, we'll need to notify everyone on plasma-devel@
> so that we don't get commits happening in svn on the day(s) of the actual
> import. that's easy enough to coordinate though, and perhaps sysadmin
> could help us by making that area of svn read-only on the day the git
> import is scheduled to start.

More information about the release-team mailing list