On Friday, June 03, 2011 04:27:41 PM Rex Dieter wrote: > On 06/03/2011 09:19 AM, Jeremy Whiting wrote: > > As you may or may not know kdeaccessibility and kdeutils are ready to > > migrate to git (when the freeze is over, don't worry). And we'd like to > > know what the feeling is about the best time to migrate to minimize > > packaging/releasing stresses. We'd also like to know what > > packagers/release-team think of the split repos already done in kde-edu, > > etc. Should we provide artificial monolithic tarballs? > > I would advocate for monolithic tarballs (again) in general (not just > kdeedu), the current quasi-arbitrary half-done hodge-podge kde-4.6.80 > tarballs are quite a mess (with both my packager and release-team hats on). > > Split tarballs *after* migrations are final and where it can be > carefully planned and executed would be more welcome, say for kde-4.8.
+1 It's answer for the question what does it mean for packagers. For the first import it means a lot of work/time/nervs ;-) and it can be done. But some stability and consistency is needed - to do it just once. As Rex and Kevin pointed out, I'm now trying to to fit the new sources to our current packaging scheme. Probably for kde edu, that seems like final split (really?) we'd like to start from scratch. But I'm not still not sure it's right time to do it - what in case of decision to roll back and release monolithic packaged for 4.7? So please - we'd like to see final word from release team ;-) We can adapt (even it won't be easy) but we have to know to what we have to adapt. R. > > -- Rex > _______________________________________________ > Kde-packager mailing list > kde-packa...@kde.org > https://mail.kde.org/mailman/listinfo/kde-packager -- Jaroslav Řezník <jrez...@redhat.com> Software Engineer - Base Operating Systems Brno Office: +420 532 294 275 Mobile: +420 602 797 774 Red Hat, Inc. http://cz.redhat.com/ _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team