Releases in 3 months

[Aaron J. Seigo]

On Wednesday, July 10, 2013 17:16:55 Sune Vuorela wrote:
> On 2013-07-10, Àlex Fiestas <afiestas at kde.org> wrote:
> > I can't fight with distros, and I don't want to fight with them. If
> > distros
> > need .5 .6 and .200 so be it, just they will have to do them themselves
> > (and I hope we can make the process smooth so they can actually do it).
> > 
> > As has been said in this thread, almost no KDE developer is using the
> > stable branch, blindly backporting has shown to be dangerous and has
> > created many issues in the past so we are not the right people to make
> > these point releases.
> 
> Other developers has said in other contexts 'do not backport patches
> without running them thru me'. The maintainer of the code in question

these are not mutually exclusive.

a packager may identify a patch as being a candidate for backporting and even 
do the backport in the branch in git.

the maintainer may also be first notified so they can let the packager know if 
there is a reason that patch should *not* be backported.

iow, the maintainer steps into more of an advisory role for these older 
versions (allowing packagers to tap their experience and knowledge) while 
packagers are able to take on more of the actual work that is of use to their 
audience.

> So I really do think that marking patches for backporting *should* be
> done by the people behind the code, not by others.

as a maintainer, i’d much rather a workflow like this for code i maintain:

* patch is nominated for backporting
* i +1 it, or give a reason it should not be backported
* the backporting is done by the nominator

this is, btw, exactly how this often happens with code i maintain :)

> But thank you for making it clear that a large part of the reasoning for
> this proposal is that you want to drop maintenance of our product.

oh c’mon, let’s no be like that :)

to me,  it’s not about dropping maintenance but about distributing effort more. 
i think everyone would end up being better served with above workflow, btw. as 
a maintainer i wouldn’t have to guess what fixes are most important, i wouldn’t 
have to backport every change that matters to every branch just because 
someone somewhere might be using it and downstream wouldn’t be stuck waiting 
for me do the right thing and backport everything to every branch that has 
users ;)

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20130712/a089d6fa/attachment.sig>