This is not working [for me]

[Albert Astals Cid]

El Dilluns, 2 de març de 2015, a les 16:57:11, Aleix Pol va escriure:
> 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.

You can build applications on the frameworks, you just need to release those 
frameworks *before* so that when the applications are out, there's tarballs 
they can use to be built. Frameworks are on a month schedule, is it really 
that hard to plan one month ahead?
 
> 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.

As said, we need tarballs to compile our tarballs, so the Frameworks releases 
needs to be already done when we release Applications-

> 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.

I'm not even going to bother to answer this, it's de-railing the topic of this 
email.

Albert

> 
> Ben, you're saying that the quality of the split isn't proper, I'd
> love to know why.
> 
> Aleix
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team