Releases in 3 months

Luigi Toscano luigi.toscano at tiscali.it
Mon Jul 8 17:25:30 BST 2013


On Monday 08 of July 2013 18:09:44 Àlex Fiestas wrote:
> On Monday 08 July 2013 17:45:10 Philip Muskovac wrote:
> > I understand that we can have additional point releases if people still
> > find issues that need to be fixed, but with so many short release cycles
> > I expect that the attention for the previous release (even worse: the one
> > before that) will die quickly leaving the distributions with having to do
> > the bugfix backporting.
> > That's ofc. already the case for older releases, but shorter release
> > cycles
> > only amplify the issue as no distribution will change their release cycle
> > to match the new KDE one. (leaving rolling distros aside)
> 
> Yes, my idea is to have interested parties to maintain whatever branch they
> are interested on, for example I know that Redhat is still maintaining
> 3.5.10 branch, which I think it is awesome but we have moved on.
> 
> We can develop tools to make your life easier (distros) so you can maintain
> yourselves branches for things like LTS easier, I will be willing to develop
> such tools if needed.

Well, I can't speak for the company, but RH have the resource to maintain that 
(subset) of packages in RHEL5. Ditto for the subset of 4.3 in RHEL6. But not 
all distributions can do it, the community ones do rely more on upstream work. 

Having something slightly more stable than a 3-month moving target (which 
pieces that still needs to be coordinated anyway) could help a lot. IMHO.

> > What would at least make my life easier here would be a way to easily get
> > a
> > list of all patches that were applied to a stable release (esp. when
> > someone bothers to backport a fix after the last point release is out).
> > The only way to do that, that I found so far, is filtering out mails from
> > kde- commits, which is neither very easy nor reliable.
> 
> If this is what it takes for having distros in, I propose myself to develop
> this system ! we can have a BoF in akademy perhaps to design such tool.
... so first the tool, then the change in the schedule!

Ciao
-- 
Luigi





More information about the kde-core-devel mailing list