life sign & RFC

[Andre Heinecke]

Hi,
Am Friday, 3. June 2011, 01:03:40 schrieb Patrick Spendrin:
> after some months of break, I am back online again working on KDE on
> Windows though with a lot less time.
Good to have you back even with less time :)

> There are two things that are probably most interesting in the coming
> months:
> 1) a KDE 4.6 binary release
> 2) the emerge git transition
> 
> The main question is of course in what order these should be done:
> doing the release first, and switching to git later or switching to git
> first and doing the release shortly after it.
> 
> I personally prefer to have the git transition first, and do the release
> after that, since we can benefit from the things we can change with this
> transition:
> my plan looks like this:
> - do a last emerge branch/tagging so that people can use that version if
> they want
> - do the transition
> - move/remove stuff in emerge:
> remove kde-4.X categories and only keep kde category
> rationals:
> we normally don't use the splitting between the kde-4.X release
> categories and the kde category. this also doesn't work because e.g.
> win32libs do change in between and we can't guarantee for binary
> compatibility of our 3rdparty projects anyway (examples that occurred
> until now are jpeg6/7/8, png 1.2vs.1.4 and of course Qt). So instead I
> want to have one branch per release, e.g. one 4.6 branch which will be
> split away from the master branch somewhen around the time the branches
> are set up for KDE itself.
This sounds like a practical way for me, it is actually a good reason to make 
a change to git and might even make sense to do for the e5 category as it 
would give packages of the individual categorys more freedom. What i might see 
here as problematic here is that we will have even more untested commits 
because with emerge you can not be expected to test all the portage trees you 
would merge your changes to.
We would need to see how it will work for us but I guess the workflows will 
come by themself. 
So I agree that we should do this sooner or later, might also revive the 
development a bit and will let us see how good it works for us with the 4.6 
release.

As downstream user of emerge i would like to have a decent svn readonly 
period, of around 3-5 Days before Emerge gets removed from svn. This would 
give me time to adopt my tools.
> Since Tortoisegit is not half as good as Tortoisesvn I also want to
> promote a different way to setup emerge: Beginning with a zip package
> (which might include python & emerge (& git)) you can install emerge
> somewhere, and start emerge with 'emerge --update emerge' which would
> then update itself to the most recent version. Ralf did some work on
> that already (until now only in the svn version, but I am sure we can
> easily adapt that to git) so I don't think this becomes a big problem.

Well I can not comment on this since I use cygwin on windows and mostly linux 
to work on KDE-Windows stuff. Imho most of the Linux git documentation in 
techbase applies to windows as well and if users want to use tortoise git.
To get started i do not think it is necessary to provide "another" way. I 
disagree that we should distribute python, and git. Installing git is not much 
harder then installing svn.
And if users will not do it they could just download a tarball from the webui.
So a bootstrap script for emerge would be nice but I think unecessary. 


Regards,
Andre

-- 
Andre Heinecke |  ++49-541-335083-262  |  http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner