On Saturday 06 November 2010 21:21:18 Ivan Čukić wrote:
> It would seam ok for me. The only problem is how we will handle
> backporting fixes, but that would be an issue no matter when we do the
> switch.
git-svn?
Bye,
-Riccardo
___
Plasma-devel mailing
Quoting Chani :
> uhm... wouldn't git-svn be easier? :)
I'm not understanding the issue here: when we do the migration and
want to backport something we would only need to commit to the right
branch (in git itself), wouldn't we?
Cheers,
---
_
> uhm... wouldn't git-svn be easier? :)
It's a matter of personal preference :)
--
There's so many different worlds, so many different suns
We have just one world, but we live in different ones
~ Mark Knopfler
___
Plasma-devel mailing list
Plasma-dev
> * make the change shortly after the public release of 4.6, to maximize the
> easy-backporting window
Well, theoretically, we could do the backporting in a bit dirty way if we are
careful - having the code in bot git repo and
svn (in local) - where svn would be on a branch we want to backport
Quoting Artur de Souza :
> PS: as soon as I finish the conversion that is running right now I'll
> push the code to my "scratch area" so you can take a look at the repo,
> check the history and then point if you find any errors/mismatches
> (the last try was 100% successful, just changing the name
Hi!
Quoting "Aaron J. Seigo" :
> a) thanks for working on this
:D
> 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.
+1. I think that we can come up with an easy and st
Hi,
- Original Message -
> but that will require support from the release team as the release of
> kdeplasma-addons for 4.6 would have to come from git.kde.org instead
> of
> svn.kde.org. if the release team members veto that for the 4.6
> release, then
> we will need to consider the secon
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 wo
Hi Artu(r) :)
> Good question. Maybe we could switch as soon as we have the 4.6 tag? Some
> other teams are planning like this. What do you think about this?
It would seam ok for me. The only /problem/ is how we will handle
backporting fixes, but that would be an issue no matter when we do the
sw
Hi Ivan!
Quoting Ivan Cukic :
How are we going to handle this release-wise - switching when the
regular trunk opens for features or what?
Good question. Maybe we could switch as soon as we have the 4.6 tag?
Some other teams are planning like this. What do you think about this?
Some update
How are we going to handle this release-wise - switching when the regular trunk
opens for features or what?
Ch
--
So remember when you're feeling very small and insecure
How amazingly unlikely is your birth
And pray that there's intelligent life somewhere up in space
Because there's bugger all
Quoting Chani :
> On November 6, 2010 16:48:28 Artur de Souza wrote:
> it'd be nice-to-have, yes.
> I think we could live without it if it's a big hassle to convert, though.
I'm getting the history of those that Marco listed...
> kdereview won't be a module in git, it'll be a state of.. being. :)
Hello :)
I'm almost back from vacations and today I found some minutes to work
on this again. So, I'm getting the history of the items that Marco
selected (above) from whatever they came. Question: should I get the
history from kdereview too, or that is going to be treated as a
different
On Monday, October 11, 2010, Artur de Souza wrote:
> Ideas, suggestions ?
while it would be nice to have the full "to the start of time" history for
each component, i don't think we'd actually find use for it down the road, so
it would be extra work for no real world benefit. being able to track
Quoting Marco Martin :
> to me the problem is mostly those that came in in 4.5 - 4.6 but i don't
> remember at the moment if there is any.
> the other ones i think have enough history to track potential recently
> inserted bugs.
> as ivan said, the changes done in ancient history still have somewh
Quoting Ivan Cukic :
> IIRC, there was a big move from playground to kdeplasma-addons in
> the beginning and it was all done by a single commit by Aaron. But
> it is ancient history - it
> happened before 4.1 (maybe even before 4.0?).
True. I can see this commit in the log.
> As a maintainer
Quoting Marco Martin :
> it would just be a bit more difficult to track eventual bugs on those recent
> things: what would be the most recent/problematic ones?
I didn't try one by one to track if there is any recent/problematic :)
But most of the stuff in this module came from playground and we
> I had some spare time and started to play with the Git migration.
> Regarding the Plasma stuff, I thought that kdeplasma-addons would be
> an easier repo to start :).
IIRC, there was a big move from playground to kdeplasma-addons in the beginning
and it was all done by a single commit by Aa
Hello :)
I had some spare time and started to play with the Git migration.
Regarding the Plasma stuff, I thought that kdeplasma-addons would be
an easier repo to start :).
So, while looking at it's log I saw that there are some modules that
were imported from playground at beginning as well
19 matches
Mail list logo
