[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: Fwd: KDE Frameworks Release Cycle
From:       Scott Kitterman <kde () kitterman ! com>
Date:       2014-05-20 12:52:39
Message-ID: bf405ffc-e767-4e61-8d92-23eb47f478d6 () email ! android ! com
[Download RAW message or body]

On May 20, 2014 8:27:39 AM EDT, Kevin Ottens <ervin@kde.org> wrote:
> On Tuesday 20 May 2014 08:00:43 Scott Kitterman wrote:
> > On Tuesday, May 20, 2014 08:04:59 Kevin Ottens wrote:
> > > On Monday 19 May 2014 22:28:27 Scott Kitterman wrote:
> > > > Speaking as a packager for a distro that's in group #2, I don't
> see this
> > > > as
> > > > any change from your initial proposal.
> > > 
> > > That's correct...
> > > 
> > > > You're proposal moves us into group #1
> > > 
> > > ... which is what I stated I think.
> > > 
> > > Chosen extracts:
> > > > > Going forward I see four options for addressing those
> packagers:
> > > > > 1) Don't care, which means we're pushing them toward the case
> 1,
> > > > > they'll
> > > > > release outdated versions with hand picked patches on top;
> > > > > 2) Gain the necessary trust of our downstream to show that our
> new
> > > > > releases are not less stable than our former bug fix releases;
> > > > > 3) Provide a yearly LTS branch as I've seen proposed;
> > > > > 4) Provide release branches for which we commit backports.
> > > > > 
> > > > > [...]
> > > > > So, even though I understand why it wouldn't please packagers,
> I don't
> > > > > think we should change course overall. So the tactic we'll
> follow is
> > > > > (1)
> > > > > hoping to get to (2).
> > > > > Indeed, if we don't change course, I expect the distributions
> will all
> > > > > move to a scheme of backporting. That's unfortunate, but
> hopefully,
> > > > > we'll
> > > > > manage to gain the required trust to prove that the releases
> are not
> > > > > less
> > > > > stable than the former bug fix releases
> > > 
> > > So it's not that I don't understand, I completely see what will
> happen at
> > > first.
> > > 
> > > Now, I think we'll have to agree to disagree on something. You
> believe
> > > there's some rule written in stone somewhere which will make the
> "everyone
> > > will pile up backports only" the new status quo forever, I say
> let's try
> > > and find out.
> > 
> > I make no prediction about other distros, only mine.  You started
> this go at
> > the topic by saying that packagers don't understand what developers
> deal
> > with and developers don't understand what packagers deal with and we
> had to
> > try and cross that bridge.  Given that you're on the developer end of
> that
> > divide, why do you keep insisting you know better what will happen in
> my
> > distro that I do?
> 
> I never said I knew better, actually I'm pretty sure I don't. OTOH I'm
> sure 
> that polarizing the situation as much isn't going to help figure out
> the real 
> outcome.

That's how it comes across to me.  There was a lot of negative feedback the first \
time and the reaction to that comes across to me as a patronizing repetition of the \
initial proposal wrapped up in IMO unfounded assurances that it would be fine. 

Sorry if it comes across as harsh. I actually waited half a day to calm down before I \
replied. 

> Also, I happen to have discussed with other packagers[*] before sending
> the 
> email of yesterday who have a different opinion than you do, so it
> can't be 
> labeled as our fate yet. Especially since we generally tend to do a bad
> job at 
> predictions.
> 
> Regards.
> 
> [*] Some of them working on the same distribution than you.

None of them are the one that did the work to get our current approval to ship KDE \
point releases post-release.   

If they feel differently though they should say so publicly. I'm not going to argue \
with anonymous theories channeled through you (or through anyone).

Scott K

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


[prev in list] [next in list] [prev in thread] [next in thread]