This is not working [for me]
aleixpol at kde.org
Mon Mar 2 15:57:11 UTC 2015
On Mon, Mar 2, 2015 at 12:49 AM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Mon, Mar 2, 2015 at 11:00 AM, Albert Astals Cid <aacid at 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
> 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
>> 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
> 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.
On the other hand, we need to have mechanisms so that the releasing
process is not just a facade. Releasing a framework without any
application using it doesn't make sense either (sense as in common
sense), it can be useful because it matches how we've been releasing,
but it isn't practical.
What I understand is that we need to find how we want the different
schedules to work together if at all. I'm unsure it makes sense to
treat our internal dependencies (KDE Applications to KF5) as 3rd party
With regards to Dolphin, I do agree that the splitting was rushed, but
I also understand that the KF5 port has been ongoing for months and
tested by many (in fact it is much more tested than many other
applications that will be released in 15.04). For some people having
the correct thing pointing to the correct repository can be the
definition of stability, but my impression is that it's actually
admirable how well it was handled. My experience with splitting is
that it's a stressful bit of work that people tend to despise for some
reason beyond my understanding and nobody is happy to help with.
I'd like to note that if he had done the splitting first thing and
then worked on stabilization, maybe it would be less stable now but
nobody would have a problem with releasing it.
Ben, you're saying that the quality of the split isn't proper, I'd
love to know why.
More information about the release-team