From kde-core-devel Tue Jul 09 10:43:48 2013 From: Scott Kitterman Date: Tue, 09 Jul 2013 10:43:48 +0000 To: kde-core-devel Subject: Re: openSUSE packagers' take on the 3 month release cycle Message-Id: <1889259.kRWxsxcIJt () scott-latitude-e6320> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=137336667905880 On Tuesday, July 09, 2013 12:11:48 PM =C0lex Fiestas wrote: > On Monday 08 July 2013 20:16:16 Scott Kitterman wrote: > > For Kubuntu (also mostly volunteer effort), it took about two weeks= to > > package the 4.11 beta. For generating package updates for already > > existing > > packages, we have a script that will produce initial packages. >=20 > This is quite fast, should be compatible with 3 month release apparen= tly. It's about 4% of a 6 month cycle and 8% of a 3 month cycle, so the time= does=20 become more significant on the shorter cycle.=20 > > These all have to be test compiled, checked for new or missing file= s, > > checked for files that have moved between packages, checked for > > license/copyright updates, etc. >=20 > I guess you have all this mostly automagically done? Some yes, some no. The copyright/licensing stuff is the hardest and it= 's very=20 manual. It's work that has to be done to ensure we are legally distrib= uting=20 the packages, so there's no way around it. > > In the case of new packages (which the newly split modules are), pa= ckaging > > needs to be developed. For a split module, the information can lar= gely be > > derived from the old mega-module, but it's done by hand, it's not > > automated. Also, all new packages undergo an extra layer of review = before > > they are accepted into the archive that takes more time. >=20 > Maybe I'm wrong, but until plasma-workspace2 I don't see any more spl= itting > happening, all modules are now in git, have been split, and in anyway= > "spliting" is something we do exceptionally, we can add rules for tha= t. Some of the recent releases were more work than we'll probably see in t= he near=20 future, I wasn't trying to predict workload, but describe what's my rec= ent=20 experience has been. > > For 4.11, the new packages took most of the time, but checking all = the > > existing ones still took substantial time due to changes. Beta 2 t= ook > > substantially less time, but there are still changes that need to b= e > > checked. Assuming no changes that impact the packaging, the RC's, f= inal, > > and point releases will be mostly running a script and sanity check= ing the > > results. > >=20 > > For us, each new major release is a significant effort. For the ad= ded > > releases (at the halfway mark from where releases would be expected= with > > the current cycle) the .0 release will land just about at the same = time as > > feature freeze for the distro release. This means not a lot of tim= e to > > get > > a fair amount of work done. >=20 > Have you taken into account that releases will be smaller? the amount= of > changes in every release can be expected to be smaller, less breakage= , less > "splitin" less everything. That's a theory. I expect it will be someone less churn, but every mod= ule has=20 to be checked to some degree, so even if it's half the develop changes=20= landing, it's not half the work for us. > > My assessment is that we could live with the three month release cy= cle > > from > > a development perspective. The biggest thing we'd lose having fewe= r point > > releases for post-release updates (we ship all the point releases t= o our > > end users and appreciate the added stability they provide). If we = could > > figure out a good plan to deal with better post-release testing/sup= port, > > then I think the proposal would be manageable for us (my opinion on= ly, not > > a collective Kubuntu position). >=20 > Awesome! this is the kind of feedback I want :) >=20 > If we could make all developers make better use of commit tags, I thi= nk this > could help. Once we get use to that we could develop scripts or websd= ites > showing all fixes, maybe even with categories, kinda: >=20 > FIX: IMPORTANT > FIX: MINOR > FIX: .... >=20 > Also, in the case of BUG: we could extract from bugzilla some informa= tion, > so you can decide whether backport it or not. >=20 > What do you think? I want the point releases. The reasons for wanting them are for consis= tency,=20 marketing, and for distro policy releases its' much easier to get a set= of=20 packages that are part of a release through the post distro release QA = process=20 than a set of indiviual changes. Also, as a pratical matter, we manage= to find=20 the volunteer motivation to package a point release, but only rarely fo= r=20 individual changes. I don't think it would help much. A related point is KDE support policy. AIUI, currently KDE will provid= e=20 security support for the previous two releases. After that, distros ar= e on=20 their own. Did you envision that changing to four with this proposal? = If=20 not, you're cutting my upstream security support in half. I would like to figure out something about a better way to test point r= eleases=20 and be able to do them more reliably/longer. I'll think about it. I d= o think=20 this has to be addressed in some manner before going to your proposed=20= schedule. Scott K