This is not working [for me]

[Ben Cooksley]

On Tue, Mar 3, 2015 at 4:57 AM, Aleix Pol <aleixpol at kde.org> wrote:
> 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
>>> 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.
>
> 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
> dependencies.
>
> 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.

The branches and tags should have commits in common. By all accounts,
this is not the case.
At least that is what i've been told.

>
> Aleix

Cheers,
Ben

> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team