Re: git migration, next steps
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
Re: git migration, next steps
Le Tuesday 7 June 2011 11:01:37, Jaroslav Reznik a écrit : 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. I lost track of what is the issue so I'll bear with the KDE Edu situation. For kdeedu we have 4.6.4 non split (apologies for 4.6.3) and next 4.7 and further on are split as in master KDE git. For KDE 4.7 and current master, Kalzium, Kanagram, KHangMan, KWordQuizz and Parley require libkdeedu to be buit and installed first. The rest of KDE Edu builds as single tarballs/git repos. As the KDE Edu team coordinator, I did not expect packagers wanting to package kdeedu as a whole. I'd like to know what's the reason is for monolithic tarballs for KDE Edu, the scope of KDE Edu applications for users being so diverse that no user will need to install and use all the KDE Edu applications. So please enlight me about a monolithic kdeedu. Anne-Marie PS: We did not communicate as we should have. Be aware that KDE devels have no idea what you're doing when you package. I assumed it's a script and would be easily changed, probably I assumed wrong. Be also aware that most KDE devels have to follow the KDE decisions (in kdeedu we knew we had to move to git and some devels wanted it quickly as they already built only their app code with patching svn), we did it the best we can and I'd like to thanks the people who did it even if there was a mess. The mess would have been greater if the KDE Edu team was left alone without experts assistance! PS2: Qt 4.8: Another note as I am at it: KDE 4.7 git repos do not support Qt 4.8 as for now so issuing bug reports is not the thing to do. Talk directly with Qt people if you have an issue building master with Qt 4.8, thanks. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
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 mo...@debian.org signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps: proposal
On 06/07/2011 12:49 PM, Arkadiusz Miskiewicz wrote: Now if I have big kde tarball and I want to split into smaller pieces I have to figure out which file is used by what and then put that file into proper separate subpackage. With split tarballs I don't have to do such guessing. It's already done. Right. While there are some advocating against any and all tarball splits (Kevin, Erik, others?), I think there are a good number (including Scott, myself and other fedora packagers minus Kevin) that are asking for only well-planned split tarballs. With that in mind, I'd propose: * for any module (in the classic svn sense) not-yet fully migrated to git (ie, that is currently in the frankenstein half-split state), continue to distribute it as a single monolithic tarball. I'm assuming this is technically feasible. If not, the point is moot (and why are we having this conversation? :) ). -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Tuesday, June 07, 2011 19:55:24 Modestas Vainius wrote: Hello, On penktadienis 03 Birželis 2011 17:27:41 Rex Dieter wrote: 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? I don't think anyone (even Slackware packagers) are opposed to split tarballs being available, or even the default. From what I can tell the Slackware packagers would have significantly less packaging burden if monolithic tarballs are available. For what it's worth as kdesrc-build author trying to maintain a sample configuration, I agree completely, and I make it a business to keep dependency handling as simple as possible! Actually having to key in dependency data as the packagers would have to do is more work and while the consensus from most packagers seems to be that they were doing that work /anyways/ (and therefore split tarballs are fine), that's not the case for all of them. A separate objection had come about from the process of creating split tarballs (e.g. kdeedu migration as annma already mentioned), not the idea of having split tarballs itself. I think most of us would agree that a smooth migration to split tarballs is the much preferred mode of operation if we're going to be migrating at all, so I don't see that as controversial either. So in other words: Split tarballs are still the answer, but taking a little bit of extra work on our end to get a decent monolithic compilation can help some of packagers save a significant amount of maintenance burden, and as we transition over we just need to take advantage of past experience to try and ensure everything moves as smoothly as possible. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
Dne 3. června 2011 16:19 Jeremy Whiting jpwhit...@kde.org napsal(a): Dirk, all, 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? Hi, I'm porting KDE to Solaris. We often face difficulties compiling either due to compiler (Sun Studio) or OS differences. The split will actually make it easier to make most of KDE available in time for the users - e.g. as of KDE 4.6 we're not delivering pim, plasma-addons and bindings due to build issues in some parts. I'm a bit afraid of having to resolve intercomponent dependencies if they are not set-up properly. best P. thanks, Jeremy Whiting ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Fri, 3 Jun 2011, Raphael Kubo da Costa wrote: Eric Hameleers al...@slackware.com writes: If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. I'd appreciate it if people interested in the monolithic tarballs could summarize their concerns so that it is easier to understand their reasons. So far, I can see these: * Adding new packages (SRPMs or whatever) is slow in some distros; * Fear that new tarballs will be released without proper instructions or not following any criteria, so that creating packages and following the dependencies gets harder. One of them has already (sorta) happened, though I don't recall the part involved. Suppose several components depend on a particular library, e.g. libsomething, and the libsomething dev team releases a new version with some cool new feature and an API change. Some of the components see that cool new feature and start depending on the new API, while others don't. KDE SC -next includes some of each of those components. Now, which one should packagers ship? As I wrote this, my memory jogged a bit, and I seem to recall that shared-desktop-ontologies was the involved bit mentioned earlier... -RW ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Friday, June 03, 2011 10:56:12 Ian Monroe wrote: If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. I agree with you there. It's still release-team@kde.org not release-team-ark, release-team-marble etc etc. Why would split tarballs for 4.7 be an uncoordinated shambles? Ian, Having a million difference source tarballs required is a pain even for kdesrc-build, and that's even with the fact that individuals are graciously fixing the kdesrc-buildrc-sample as necessary to keep up with changes to Git module layout. Exposing the KDE project infrastructure over kde_projects.xml was/is supposed to be the fix for the explosion of source modules in kdesrc-build, but what has /actually/ happened for many modules in the kdesrc-buildrc-sample is that every single individual subproject for a given virtual module like kdegraphics has to still be spelled out by hand. And if you want to simply build individual projects, there's no clean way working straight from source tarballs to know beforehand which KDE deps you actually need. For instance I can no longer build Digikam because it required libkface, libkmap, and more which are documented in their CMakeLists.txt, but require Fortran to work for some face recognition algorithm. The point is not to complain about the fact that Fortran is required, but that I had to dig under quite a bit of separate subprojects, always trying to install separately, until I figured out that I would not be able to build Digikam for that reason. Even other projects that are more straightforward are difficult to deal with dependencies sanely. There is no information in the kde_projects.xml to relate what git projects depend on which other ones, so every single individual package from a packager's point of view represents some non-trivial amount of work to handle, as it is not as if it's a flat dependency tree where a given git module depends only on e.g. Qt and kdelibs. Areas where we might have, back in the day, included dependencies all in the same module and made sure they built in the proper order in CMakeLists.txt now get punted to the packagers. Now many packagers have taken this task on board /anyways/ and so splitting things up on our part makes it easier on these packagers. But it's not uniformly easier across the board for all packagers, and it's not like our current migrations have been exceptionally-well coordinated on this mailing list. Just look at the troubles that have occurred doing nothing more than trying to tag 4.6 follow-on releases. So you see, it's not as simple as just doing some copy/paste on a bunch of RPM spec files or whatever. Every individual package that gets created represents actual work to do. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
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. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 3 Jun 2011, Jeremy Whiting wrote: Dirk, all, 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? thanks, Jeremy Whiting Hi Jeremy Thanks for asking this, really appreciated. I would feel very relieved if the old monolithic tarballs would stay as a download option. Even if the release team maintains a series of scripts that makes a controlled checkout of monolithic tarballs possible for packagers, that would be an acceptible solution. I expressed my thoughts on the split of kdeedu in an earlier post and coincidentally I fired up this discussion on my blog and the SLackware forum a few hours ago... Slackware will have to consider dropping KDE if we are confronted with source fragmentation. We are a small team and can not accept the added burden of maintaining a fragmented KDE based desktop environment. Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3o+cAACgkQXlaqr6dcvaC6dgCfeQLtEetvS4t/MEZmIFkrgsEg naIAn12z4bp/1EjO00dKiL/HkVizoRVR =3XmU -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Friday 03 June 2011, Eric Hameleers wrote: I would feel very relieved if the old monolithic tarballs would stay as a download option. +1 Even if the release team maintains a series of scripts that makes a controlled checkout of monolithic tarballs possible for packagers, that would be an acceptible solution. Well, I'd really prefer something which leads to perfectly reproducible output, ideally with the same checksum each time it is run. So IMHO starting from the split release tarballs (which could be automatically downloaded with e.g. wget) would be a better idea than starting directly from git. I expressed my thoughts on the split of kdeedu in an earlier post and coincidentally I fired up this discussion on my blog and the SLackware forum a few hours ago... Slackware will have to consider dropping KDE if we are confronted with source fragmentation. We are a small team and can not accept the added burden of maintaining a fragmented KDE based desktop environment. In Fedora, we're currently kludging multiple tarballs into single SRPMs to get 4.6.80 built for Rawhide. Proceeding with the splits in Fedora would imply getting several new packages through review, which is going to take quite a while. But even the multi-tarball SRPM hack is a waste of time. :-( I personally think we have better things to do with our time. Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. Please leave Red Hat out of this! Red Hat has absolutely nothing to do with these splits! In fact, the main Red Hat KDE packager (Than Ngo) has also expressed his unhappiness about the split tarballs in the Fedora KDE SIG discussions. Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 3 Jun 2011, Kevin Kofler wrote: On Friday 03 June 2011, Eric Hameleers wrote: Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. Please leave Red Hat out of this! Red Hat has absolutely nothing to do with these splits! In fact, the main Red Hat KDE packager (Than Ngo) has also expressed his unhappiness about the split tarballs in the Fedora KDE SIG discussions. Kevin, it was not meant as a stab at you and your KDE team. My apologies if it came across like that. I do like Redhat's Linux, use it on a daily basis on my laptop even. I also respect Fedora as a testing ground and a distro in itself. No more bad words about your employer. I want to rephrase then: I would like to see KDE keep its independent position and easy build process. Please don't let it grow more GNOME-like in maintenance effort and limitation of the target audience. If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3pAg8ACgkQXlaqr6dcvaBaJQCfQQkEn/+NYbrf5le7WRMPRRRM 2JcAnjP4Gjqgyt8L8FzBpB+4elVozvRp =czYD -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Fri, Jun 3, 2011 at 10:52, Kevin Kofler kevin.kof...@chello.at wrote: On Friday 03 June 2011, Eric Hameleers wrote: Kevin, it was not meant as a stab at you and your KDE team. My apologies if it came across like that. I do like Redhat's Linux, use it on a daily basis on my laptop even. I also respect Fedora as a testing ground and a distro in itself. No more bad words about your employer. FYI, I do not work for Red Hat, I'm one of the community Fedora packagers (currently doing a GSoC 2011 project with Fedora, otherwise unpaid). It just rubs me the wrong way when our project's main sponsor gets attacked for no reason. That said, your apologies are accepted. :-) If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. I agree with you there. It's still release-team@kde.org not release-team-ark, release-team-marble etc etc. Why would split tarballs for 4.7 be an uncoordinated shambles? So far the main reason against it seems to be that it would be kind of a pain in dealing with your internal bureaucracy of adding new SRPMs. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Fri, Jun 3, 2011 at 9:11 AM, Eric Hameleers al...@slackware.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Fri, 3 Jun 2011, Jeremy Whiting wrote: Dirk, all, 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? thanks, Jeremy Whiting Hi Jeremy Thanks for asking this, really appreciated. It needs discussing, so I brought it up. I would feel very relieved if the old monolithic tarballs would stay as a download option. Even if the release team maintains a series of scripts that makes a controlled checkout of monolithic tarballs possible for packagers, that would be an acceptible solution. As a developer preferring split git repos I'm not against this solution, assuming dirk wants to go for this. My plan for kdeaccessibility is to make one simple CMakeLists.txt that can be used with a tarball of each application beneath it to simply create what exists in svn now. I expressed my thoughts on the split of kdeedu in an earlier post and coincidentally I fired up this discussion on my blog and the SLackware forum a few hours ago... Slackware will have to consider dropping KDE if we are confronted with source fragmentation. We are a small team and can not accept the added burden of maintaining a fragmented KDE based desktop environment. Fragmenting the source tarballs may be only one step but seeing what happens in GNOME land, with Redhat employees forcibly pushing people into directions they do not want to be taken, I would welcome it if KDE would remain the sane, independent desktop enviroment, or even Software Collection, that I have come to love. I was involved with the kdeedu split and I agree it wasn't very well done. Part of that was bad assumptions on my part, but I think we've learned from the mistakes made there. I also don't see how smaller tarballs == more burden, but I've never been a packager. I don't see how it creates something different than the sane, independent desktop environment either, could you explain that a bit? thanks, Jeremy Cheers, Eric - -- Eric Hameleers al...@slackware.com Jabber: al...@jabber.xs4all.nl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: For info see http://quantumlab.net/pine_privacy_guard/ iEYEARECAAYFAk3o+cAACgkQXlaqr6dcvaC6dgCfeQLtEetvS4t/MEZmIFkrgsEg naIAn12z4bp/1EjO00dKiL/HkVizoRVR =3XmU -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
Eric Hameleers al...@slackware.com writes: If you want to give people a feeling of unity (pun intended) when running KDE it should not be given to packagers as a shambles of small un-coordinated source tarballs. I'd appreciate it if people interested in the monolithic tarballs could summarize their concerns so that it is easier to understand their reasons. So far, I can see these: * Adding new packages (SRPMs or whatever) is slow in some distros; * Fear that new tarballs will be released without proper instructions or not following any criteria, so that creating packages and following the dependencies gets harder. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On 06/03/2011 10:56 AM, Ian Monroe wrote: It's still release-team@kde.org not release-team-ark, release-team-marble etc etc. Why would split tarballs for 4.7 be an uncoordinated shambles? So far the main reason against it seems to be that it would be kind of a pain in dealing with your internal bureaucracy of adding new SRPMs. It's that, and a lot more. Fact is, the current source tarballs situation with 4.6.80 is inconsistent and (at least feels) unplanned. Seems to me, git repo splits were done only for convenience of developers (and rightly so), but without any forethought to the implications that had on source distribution and packagers. The latter ought to be well-planned and discussed ahead-of-time, not rushed in as an afterthought. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On 06/03/2011 10:56 AM, Ian Monroe wrote: It's still release-team@kde.org not release-team-ark, release-team-marble etc etc. Why would split tarballs for 4.7 be an uncoordinated shambles? So far the main reason against it seems to be that it would be kind of a pain in dealing with your internal bureaucracy of adding new SRPMs. (cc'ing -packagers) It's that, and a lot more. Fact is, the current source tarballs situation with 4.6.80 is inconsistent and (at least feels) unplanned. Seems to me, git repo splits were done only for convenience of developers (and rightly so), but without any forethought to the implications that had on source distribution and packagers. The latter ought to be well-planned and discussed ahead-of-time, not rushed in as an afterthought. -- Rex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Friday 03 June 2011, Jeremy Whiting wrote: I also don't see how smaller tarballs == more burden, but I've never been a packager. It's actually quite simple: smaller tarballs = more source packages (unless you jam multiple tarballs into the same source package, which is generally frowned upon in the RPM world and might not even be technically possible in some other packaging systems) = more burden: more initial package reviews to go through, more specfiles to update with every release, more builds to issue with every release, more build-time dependencies to keep track of etc. Most of this work is per source package and not per binary package, so even doing split packages from unsplit source tarballs would be significantly less work. But since it is only possible to build multiple binary subpackages from one source package and not the other way round, having split tarballs effectively also forces us to do split binary packages (unless we go with the multi-tarball SRPM hack), removing flexibility from us. Doing split binary packages in turn has other problems, e.g. huge update metadata when we push a new version (e.g. a bugfix point release) as an update. Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
Robby Workman rwork...@slackware.com writes: One of them has already (sorta) happened, though I don't recall the part involved. Suppose several components depend on a particular library, e.g. libsomething, and the libsomething dev team releases a new version with some cool new feature and an API change. Some of the components see that cool new feature and start depending on the new API, while others don't. KDE SC -next includes some of each of those components. Now, which one should packagers ship? Supposing component A which depends on libsomething 0.1 is in KDE module `kdefoo' and component B which depends on libsomething 0.2 is in KDE Module `kdebar', how would it be any different if A and B were released as A-4.7.0.tar.bz2/B-4.7.0.tar.bz2 or kdefoo-4.7.0.tar.bz2 and kdebar-4.7.0.tar.bz2? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Fri, Jun 3, 2011 at 11:18, Kevin Kofler kevin.kof...@chello.at wrote: On Friday 03 June 2011, Jeremy Whiting wrote: I also don't see how smaller tarballs == more burden, but I've never been a packager. It's actually quite simple: smaller tarballs = more source packages (unless you jam multiple tarballs into the same source package, which is generally frowned upon in the RPM world and might not even be technically possible in some other packaging systems) = more burden: more initial package reviews to go through, more specfiles to update with every release, more builds to issue with every release, more build-time dependencies to keep track of etc. Most of this work is per source package and not per binary package, so even doing split packages from unsplit source tarballs would be significantly less work. But since it is only possible to build multiple binary subpackages from one source package and not the other way round, having split tarballs effectively also forces us to do split binary packages (unless we go with the multi-tarball SRPM hack), removing flexibility from us. Doing split binary packages in turn has other problems, e.g. huge update metadata when we push a new version (e.g. a bugfix point release) as an update. Yea honestly since Slackware is the only distro in the world probably to not split stuff up, I would've thought everyone else would be thankful for splitting since it shifts responsibility for documenting intra-modules dependencies upstream to us. All the KDE distro maintainers are probably just trained to deal with meta-project tarballs, but that doesn't really mean it makes the most sense. Also lets try to split up (haha!) the issue between what we want to do longterm and what we need to do in the short term. Ian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
On Friday 03 June 2011, Ian Monroe wrote: Yea honestly since Slackware is the only distro in the world probably to not split stuff up, Fedora is doing only very limited splitting, e.g. kdegraphics is not split beyond kdegraphics, kdegraphics-libs, kdegraphics-devel and kio_msits (split out because kchmviewer also uses it and didn't want to depend on kdegraphics(-libs)). Our policy so far has been to only split where there is a concrete need for it. Kevin Kofler ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: git migration, next steps
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03-06-2011 14:19, Jeremy Whiting wrote: Dirk, all, 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? In general, for Gentoo we're very happy to see the move towards split tarballs. We had some issues with the 4.6.80 tarballs. The most significant issue is that we're still waiting for the krosspython tarball, no reply after 3 emails, which is preventing us from working on superkaramba. Then we still need to update our kdebindings split, but thanks to the note about the README.MODULARIZATION we should get that worked out soon. Finally, we need to review our changes in the ebuilds for 4.6.80 and double check dependencies are correct and packages don't have regressions. thanks, Jeremy Whiting ___ Kde-packager mailing list kde-packa...@kde.org https://mail.kde.org/mailman/listinfo/kde-packager - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJN6Vq/AAoJEC8ZTXQF1qEPPtcP/3JsV+vgwfHs5zxGx02zEXKF FVivsvc/m9mlREwP1WXHoZH55q2iSvEJBDxO/fRYER/Kz5LmawU9nJLvmHqlUetT dynJTPvjwXsKl3j3Jb5qaaeFG/6Lzg2jKB1//JlScuDKf3KdIraIxTjYdta6iz52 4ajl5QXUZn0Ntx/hEWI6rIFyCTtsgJLxUQ7e82JNIuiJHpzmVT0fkk3MaB7njsKn JvZe8l2ImSnh2TVgxwZN9LZWwsj36cPt2Sk3dw0VnXELEwMZlUfDUYgxKntx/WH5 hvCDD8w9aVndbyZuczt+wFN7+xarYYYpQoNnTQKRZGtiwjK8h/QNwl7OT+8xmKEE yfeu1aC2RFOJSuaD/WHoKLv0Jl2YSyqLb9aW/tk1uCZB1nXCyjwDTc6uwahxahcT UOhmw8DIwyyxJIFueStQniQnyX4RO+5K8sJyd2NnVVFyl/YfpM6DEQoTld4dD+S9 MCI7AohfliW5C4KupUCCLFM/dG0b95oJCHz8Vc47VwMkGtW9f0yD5Bc4r5ILi0Al Bjt29SOGa8NGXjYnNXveLuwe/eIwD8v3L+qeIDz+wCVjzQiWeABLJE4Wiepq6bk/ soc7IzK3cmMJmRkPvxcqqhsHYfiqPFWJ2JGuRfzLZRK+ajNBkkcZaN7o/ayFSmN4 CQe3IBP08/eXfhCJ6nHp =zVlr -END PGP SIGNATURE- ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
