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

List:       kde-release-team
Subject:    Re: Fwd: Re: Fwd: KDE Frameworks Release Cycle
From:       Michael Pyne <mpyne () kde ! org>
Date:       2014-04-30 23:33:29
Message-ID: 9027999.hWYKWuOlky () midna
[Download RAW message or body]

On Wed, April 30, 2014 11:28:26 =C0lex Fiestas wrote:
> As for the backporting, you could use bugzilla (even via api) to get a li=
st
> of everything that has been fixed, get the SHA and backport it
> automatically, that will ease a lot the process.

Is there any reason we can't do this? Even if it's a good idea to have =

downstream packagers do the testing of this we can't really think it's a go=
od =

idea for every downstream to duplicate the work of automatically generating=
 a =

stable branch and coming up with slightly different KF5 x.y+z releases.

In this scenario of automated backporting we would still want to take =

responsibility for tagging at the very least so that the downstreams have a =

consistent release to tag against.

> Also ideally, we should break with this tendency of "upstream/downstream"
> and you should become upstream, I would love to see opensuse (and others)
> keeping the release you picked maintained in a branch.

I think this is wishful thinking. I mean, it would be nice to have happen a=
s =

well, but they can't all have that much extra manpower lying around with =

nothing to do. Work they do to act as a virtual upstream is work they can't=
 do =

for their downstream duties, so you're asking them to stop doing something =

they're doing now to pick up for kde.org duties.

They could just as fairly ask for us to start handing downstream packaging =

chores.

Regards,
 - Michael Pyne
_______________________________________________
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]