[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: git migration, next steps
From:       Modestas Vainius <modax () debian ! org>
Date:       2011-06-07 16:55:24
Message-ID: 201106071955.29571.modax () debian ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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@debian.org>

["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]