On Mon, Mar 2, 2015 at 11:00 AM, Albert Astals Cid <aa...@kde.org> wrote: > I don't know how to fix it, I am not even sure what's wrong, but this was
Hi Albert, > supposed to be a release team, and to me it seems that it's me being the bad > guy and everyone else just pushing in for their own agenda. You're not the bad guy here. We've got a few things going in now which seem to be awfully rushed. > > Of course this may be my own perception of the thing, but it's affecting my > mood and willigness to work on stuff so I decided it made sense to bring it > up. Thanks for doing so, it certainly needs to be done. Having repositories split without proper time for review, new releases of dependencies needing to be rushed out and other outstanding issues unresolved right before the freeze kicks in is unacceptable. > > Some days this week i really wanted to step down for 15.04 but at the end i > convinced myself it's too close and I don't want to leave anyone with no floor > to stand on. > > But we need to make this work better for my sanity for 15.08 otherwise I'm > out. > > Does anyone have any magic solution? I'd suggest stronger dependency controls - ie. explicitly saying that KDE Applications releases can only depend on released versions of Frameworks/Qt itself. Having a deadline of two weeks prior to freeze for new applicants to join might help as well. Miss the deadline, and you miss out on this cycle. And that doesn't mean rushing the Framework through review on that side either... Frameworks should be properly released - and have to meet the criteria, including depending only on other Frameworks (as permitted by their place in the tier structure). We could enforce this if necessary by forcing CI builds to hard-fail if the specified dependencies violate the guidelines. The new iteration of the dependency metadata might not even permit certain dependency structures - such as Frameworks depending on something which is not a Framework/Qt. For the record, i'm unhappy about the Dolphin split situation (the repository split is of questionable quality and I suspect will have to be redone once a proper review is conducted) as well as how Baloo/KPeople has been handled as a Framework for Telepathy (being optional is irrelevant, it's a dependency and doesn't meet the guidelines). Both were rushed, and regardless of the code quality, rushing things leads to quality and review being compromised and places pressure on the people who look after other aspects of the system. > > Cheers, > Albert Thanks, Ben > > _______________________________________________ > release-team mailing list > release-team@kde.org > https://mail.kde.org/mailman/listinfo/release-team _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
