git migration, next steps

Modestas Vainius modax at debian.org
Tue Jun 7 18:55:24 CEST 2011


Hello,

On penktadienis 03 Birželis 2011 17:27:41 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.

Personally, I'm in favour of split tarballs. But as there seems to be so much 
opposition to this approach [1], I could take return to old ways with 
everything except kdebindings. Could you please keep that ugly beast split in 
4.7 and on onwards?

Btw, a decision (whatever it is) needs to be made quickly and some real work 
*must be put* to implement it in case you decide to go back to those 
monolithic tarballs. With so much uncertainty in the air, nobody valuing 
his/her own time will package any betas or RCs until there is no way back when 
4.7final is released.

[1] Do you really want to go back in time when Xorg/XFree86 was monolithic?  
Xorg 6.9.0 died pretty fast and there was a good reason for it.

-- 
Modestas Vainius <modax at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/release-team/attachments/20110607/f71c4477/attachment.sig 


More information about the release-team mailing list