Re: KDE 4.6.4 uploaded (try#1)
On Friday 03 June 2011, Dirk Mueller wrote: > Hi, > > just finished with a slight delay building the KDE 4.6.4 tarballs, > including kdegraphics, but not yet including kdeedu. > > I don't know yet what to do there. Other than that, most of it seems to > build for me. Please let me know if there are any urgent regressions or > build fixes missing. updated oxygen-icons: 9be84aced456e05d8cb3ba5ef8603533 oxygen-icons-4.6.4.tar.bz2 Greetings, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
oxygen-icons for KDE 4.6.4 from where?
Hi, I just got an email indicating that the setup we did so far of tagging oxygen- icons from svn trunk/KDE/kdesupport/oxygen-icons is no longer applicable. is that correct? where should I take the latest version of oxygen-icons for KDE 4.6 from? I can't find them in SVN anywhere. Please note that the current state I tagged does indeed not build - it has absolute symlinks to paths that don't exist. Thanks, Dirk (release-team release dude) ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.4 uploaded (try#1)
On Friday 03 June 2011, Stephen Kelly wrote: > > just finished with a slight delay building the KDE 4.6.4 tarballs, > > including kdegraphics, but not yet including kdeedu. > It doesn't seem to include kdepim and kdepim-runtime. Were they overlooked > or is that in a separate directory for this release? I wasn't aware that I was supposed to create kdepim tarballs of KDE 4.6.4. so far kdepim was excluded from KDE 4.6.x releases and had its own release schedule (currently at 4.6 RC2 or something like that). I was not trying to interfer with that. Lemme know what I'm missing here, I might not have read all blog posts. Thanks, Dirk ___ 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
Re: KDE 4.6.4 uploaded (try#1)
On Sat, Jun 4, 2011 at 7:07 AM, Raphael Kubo da Costa wrote: > Dirk Mueller writes: > >> Hi, >> >> just finished with a slight delay building the KDE 4.6.4 tarballs, including >> kdegraphics, but not yet including kdeedu. >> >> I don't know yet what to do there. Other than that, most of it seems to build >> for me. Please let me know if there are any urgent regressions or build fixes >> missing. > > I can't find it in ftpmaster. Was it supposed to be in stable/4.6.4? Seems that Dirk accidentally put them on KTown instead. I've transferred them to ftpmaster now. Regards, Ben Cooksley KDE Sysadmin > ___ > 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: KDE 4.6.4 uploaded (try#1)
Dirk Mueller wrote: > > Hi, > > just finished with a slight delay building the KDE 4.6.4 tarballs, > including kdegraphics, but not yet including kdeedu. > > I don't know yet what to do there. Other than that, most of it seems to > build for me. Please let me know if there are any urgent regressions or > build fixes missing. > > Thanks a lot in advance, > Dirk Hi, It doesn't seem to include kdepim and kdepim-runtime. Were they overlooked or is that in a separate directory for this release? Thanks, Steve. ___ 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: KDE 4.6.4 uploaded (try#1)
On Friday 03 June 2011 16:07:16 Raphael Kubo da Costa wrote: > I can't find it in ftpmaster. Was it supposed to be in stable/4.6.4? Right. Seems they are in ktown. -- Andrea ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.4 uploaded (try#1)
Dirk Mueller writes: > Hi, > > just finished with a slight delay building the KDE 4.6.4 tarballs, including > kdegraphics, but not yet including kdeedu. > > I don't know yet what to do there. Other than that, most of it seems to build > for me. Please let me know if there are any urgent regressions or build fixes > missing. I can't find it in ftpmaster. Was it supposed to be in stable/4.6.4? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE 4.6.4 uploaded (try#1)
Hi, just finished with a slight delay building the KDE 4.6.4 tarballs, including kdegraphics, but not yet including kdeedu. I don't know yet what to do there. Other than that, most of it seems to build for me. Please let me know if there are any urgent regressions or build fixes missing. Thanks a lot in advance, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: KDE 4.6.3 tarballs (try#1 part1) uploaded
On Friday 06 May 2011, Jeremy Whiting wrote: > You probably didn't see this, so resending directly to you. Don't try to > fix the kdeedu git stuff, it's incomplete, if you want/need to release > kdeedu 4.6.3, release it from svn branch 4.6 rev 1227326, or we can do the > 4.6.3 release of kdeedu next week once Nicolas has got the svn->git > migration issues fixed. I don't think it's worth delaying the rest of kde > for our mistake in kdeedu. Hi Jeremy, what should I do for kdeedu 4.6.4 now? Thanks, Dirk ___ 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 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
Robby Workman 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 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
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 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
Eric Hameleers 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 Fri, Jun 3, 2011 at 9:11 AM, Eric Hameleers 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 > 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 Fri, Jun 3, 2011 at 10:52, Kevin Kofler 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 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. 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 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 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, 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 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 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
git migration, next steps
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 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
On Friday 03 June 2011 4:15:36 AM Tom Albers wrote: > - Original Message - > > Tom Albers wrote: > > > > > Again, is this about the feature freeze or dependency freeze? > > > > > > Best, > > > > Both I think. > > > > In the SDO case, there was a dependency bump and a port to the > > features of > > the more recent release in kdepim, which resulted in effective source > > incompatibility being introduced. > > Right, so if we move dependency freeze one week earlier, it would be solved... > > +1 to that > no objections from kdepim ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
- Original Message - > Tom Albers wrote: > > > Again, is this about the feature freeze or dependency freeze? > > > > Best, > > Both I think. > > In the SDO case, there was a dependency bump and a port to the > features of > the more recent release in kdepim, which resulted in effective source > incompatibility being introduced. Right, so if we move dependency freeze one week earlier, it would be solved... +1 to that Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
Tom Albers wrote: > Again, is this about the feature freeze or dependency freeze? > > Best, Both I think. In the SDO case, there was a dependency bump and a port to the features of the more recent release in kdepim, which resulted in effective source incompatibility being introduced. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
- Original Message - > Albert Astals Cid wrote: > > > A Thursday, June 02, 2011, Stephen Kelly va escriure: > >> Hi, > >> > >> The ongoing mess regarding the shared desktop ontologies shows > >> that the > >> time between hard feature freeze and tagging is not long enough. > >> > >> Making destructive or potentially destructive changes on the day > >> of > >> freeze (and one week before tagging) is a very bad idea. If it > >> happens > >> anyway, then hopefully schedule changes can soften the blow in the > >> future. > >> > >> I propose a smaller 'merge window' in release branches and a > >> bigger time > >> between hard freeze and the start of the tagging cycle. Clearly > >> one week > >> is not enough to fix messes. That will give everyone more time > >> (before > >> tagging) to fix messes introduced on the day of freeze in the > >> future. > >> > >> Thoughts? > > > > Of which time are you speaking about exactly, the one between > > Dependency > > Freeze and Beta 1 Tagging? > > Sort of I guess. If a feature or dependency bump which creates a mess > is > committed on the day of feature freeze I don't think there is enough > time to > fix it and at the same time stay relaxed because there is only a > week. In > the 4.7 schedule it was between 12th May and 19th May. I was away > travelling > for part of that week. > > > > > How much time are you suggesting? > > What would you think of two weeks? Or three? Again, is this about the feature freeze or dependency freeze? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
Albert Astals Cid wrote: > A Thursday, June 02, 2011, Stephen Kelly va escriure: >> Hi, >> >> The ongoing mess regarding the shared desktop ontologies shows that the >> time between hard feature freeze and tagging is not long enough. >> >> Making destructive or potentially destructive changes on the day of >> freeze (and one week before tagging) is a very bad idea. If it happens >> anyway, then hopefully schedule changes can soften the blow in the >> future. >> >> I propose a smaller 'merge window' in release branches and a bigger time >> between hard freeze and the start of the tagging cycle. Clearly one week >> is not enough to fix messes. That will give everyone more time (before >> tagging) to fix messes introduced on the day of freeze in the future. >> >> Thoughts? > > Of which time are you speaking about exactly, the one between Dependency > Freeze and Beta 1 Tagging? Sort of I guess. If a feature or dependency bump which creates a mess is committed on the day of feature freeze I don't think there is enough time to fix it and at the same time stay relaxed because there is only a week. In the 4.7 schedule it was between 12th May and 19th May. I was away travelling for part of that week. > > How much time are you suggesting? What would you think of two weeks? Or three? > > Albert > ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
