Re: No more release schedules.
On Friday, June 10, 2011 17:24:57 Jos Poortvliet wrote: In the end, you will be perceived for what you release - and here we get back to this list. KDE lives from being a consistent whole. Eric Hameleers already made some very valid points there. Breaking KDE up does not help, and the coordinated releases were/are a great thing. No matter your or anyone else's opinion on this, I think Toma is saying: let the release team discuss and come up with a proposal, THEN comment on it on kde-devel, kde-packager etcetera. A very valid request from him and I think you should follow it. Well no, we need feedback, especially from our downstreams (e.g. through kde- packagers) to take a sensible decision for a way forward, so feedback which helps us with that is pretty essential :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
On Thursday 09 June 2011 19:28:13 Tom Albers wrote: Hi, Since it seems some modules are going to have their own numbers and some modules will have a different (git) workflow, which will inevitably result in different release schedules, I propose we stop producing the central release schedule as we have now. So http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule is the last one we provide. From here on, I think it would be best if the module maintainer or the particular git maintainer sets up a release schedule for their own module / repo. He can use the sofware in playground/utils/releaseschedule for their convenience. I see 2 different things here: the release schedule and the release itself. The release schedule was put up by Tom (with agreement from the Release Team which I somehow do not really know what this is in reality) and the release process (making tarballs and sending them to packagers + including patches and sorting mess) is done by Dirk. A third task is the announcement itself made by Sebas and the promo team, the future being here that the promo team is more involved. I am not sure how Tom's proposal would work in real world. For example I am the coordinator for KDE Edu (but not really the git maintainer which would be Jeremy maybe) and I don't see how I would manage to set up a release schedule in case of conflict. If we all agree to follow the frameworks release schedule, we can set up the release page with your tool. But whose responsability will it be to make the tarballs? Same if KDE Edu agrees on a release date independently from the rest of KDE, does it mean we'll have to release and test the tarballs? and make the announcement? And what if the module apps want to have different release dates? To what extend is the power of the module coordinator? Of course this list can be used to coordinate a combined release between modules and what not. Even if this plan is vetoed away, I personally will not make a new schedule, as I have no idea how to do that in the new setup and I've little interest in studying the new setup. Is http://techbase.kde.org/Projects/Release_Team#Module_Coordinators still up-to-date? Maybe we should put up a wiki page and list all modules and propose a schedule, see if they want to follow it. Some modules did not switch to git yet and should probably do it before 4.8. They need to make use of existing problems. For example I don't see why kdesdk would stay as a module, considering it's a collection of apps. Should it still be built in git as such? For packagers sake, can we then define KDE SC (= KDE apps = offical apps released apart from frameworks) as whole git building modules for 4.8? Anne-Marie Best, ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
On Thursday, June 9, 2011 18:07:33 Tom Albers wrote: - Original Message - Weren't you the one proposing that subprojects should adopt their own git workflows? I'm quite puzzled about how problematic this would be. Since KDE is the community, how can we do a KDE 4.8? as we always have: we do a coordinated SC release. And then Platform will call itself 5 if I understood correctly. completely undecided, and almost certainly not by 4.8. 4.8 will likely be the current kdelibs + critical fixes .. we'll be working on Frameworks to make it a timely release with Qt5 and because we have limited manpower to make all that happen, but 4.x releases will continue, from master kdelibs and kde- runtime, until we are ready to make that jump. when we make that jump is yet in the future. and one easy way to do this _when we get to that point_ is probably something like: * the Frameworks branch merges into master * any further 4.x releases are made from the last stable 4.x branch in kdelibs/kde-runtime * apps can start porting as needed, either in branches or in master, something we can determine as a community when that time comes. but that time isn't going to be here until next year, so we can decide this probably post-4.8. So how do we call a new release schedule then? good question. let's discuss this at the Desktop Summit where the bandwidth is high enough to do so productively. we have a git workflow that is a result of doing such in-person discussions, let's take this as the next logical set of answers we need. let's also keep in mind that we'll probably enact them sometime between 12-18 months from now. Then there will be a new workflow for kdelibs, with new policies about what to release from which branch. I just don't think one release schedule will fit all modules. actually, with the new workflow, this is a moot point. in fact, it's designed so that this doesn't matter. if master is always releasable then we can simply branch x.y when feature + string freeze happens and do the releases from there instead of from master. development can continue in master as always, improvements and fixes become the responsibility of the projects just as it is now. iow, our release engineering should need to change very little and projects will only need to adjust according to their own needs (e.g. do they need an integration branch? do they wish to just follow the SC releases, and move to the stable branch immediately when it is made, only returning to master when the freeze is up? etc.) we need to document the possibilities, of course. we're not even finished documenting the git workflow itself yet, though, so one step at a time :) Just like kdepim could not follow the release schedule the last releases, kdebindings have troubles following it now and then, kdevelop followed it now and then and koffice wants to follow it again, I think it's time for more 'freedom' in this area... i agree; i'd love to talk about this more in berlin... hopefully release team people will be there? :) and thanks, btw, for caring enough about these issues to speak up on them. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks 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
kdegraphics 4.6.4 tarball contains the wrong okular
Not sure about the other kdegraphics programs but at least for okular it is containing something that seems to be okular from 4.6.1 era. Dirk any idea how that happened? Albert ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdegraphics 4.6.4 tarball contains the wrong okular
On Tuesday 14 of June 2011 19:53:39 Albert Astals Cid wrote: Not sure about the other kdegraphics programs but at least for okular it is containing something that seems to be okular from 4.6.1 era. Dirk any idea how that happened? /me guesses it's because of okular git branch names being inconsistent with the rest of kdegraphics (the rest uses KDE/4.x whle Okular goes with 4.x) or because the newest Okular tag is v4.6.1 in git repo.. Out of curiosity, whose task is to tag versions after split now? Application provider (or particular repository admin) or release team (for all apps within KDE module being tagged) ? -- regards MM 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
