Releases in 3 months

[Aaron J. Seigo]

On Monday, July 8, 2013 15:04:40 Àlex Fiestas wrote:
> You can read all the proposal in:
> http://community.kde.org/KDE_Core/ReleasesProposal

Neat ... some thoughts:

== On branching

this will be much easier for those who develop features in branches rather 
than use master as a big developer free for all. others have already  noted 
that, of course. for people who  don’t use branches, this would likely be a 
very difficult transition.  so the question is: why don’t people use branches?

well, we can discard “because i don’t like it”. all developer routines require 
some matching discipline and adoption of the idea.

there are some very  real issues related to our lack of workflow related to 
branches, however. 

one is developer education: not everyone  is used to working with branches and 
just as we made recipes and started recommending things like kdesrc-build with 
more emphasis during the move to git, i think we will need to do similarly for 
branches.
 
then there is workflow .. we have review board, which was also met with a lot 
of scepticism at first just like branches are by some now, and it is widely 
used with a lot of success. however, it is not as easy as it could or should 
be. managing branch reviews with merge requests and what not is more painful 
than it ought to be. sys admin had made clear that gerrit is not an option, 
and i support that position for the  numerous reasons they have provided.

so for me, moving to a 3 month cycle would require first having good branch 
management and review tools for our workflow. it would make a shorter dev cycle 
so much easier for so many more of our developers.

== On branding and visual presentation

some have noted that faster release cycles would make it hard to  implement 
branding updates and artwork refreshes such as wallpapers. the answer to that 
is simple: these efforts must not be tied to the development cycle.

the development cycle has for too long dictated the pace of everything else, 
even though “everything else” does not follow the same natural pace of 
development!

in the case of artwork, my proposal would be to aim for exactly one refresh 
per year. do it in the new year, perhaps? the first release of every year could 
come with a visual refresh and a branding refinement.

this would give us a full year to draft and implement these changes.

my experience with the branding and visual side of our efforts is that the 
areas that get touched  by these changes are very, very rarely touched by the 
development of features or bug fixes. so these efforts could have a release 
cycle of 1  year while the source code development could have a release cycle 
of 3 months (or whatever)

i think this would actually make the changes more impactful on our users and 
ease the burdon on our art and branding teams

== On marketing

marketing needs to be separated from development cycles.

there is  no  reason that marketing could not do a twice-yearly big splash 
announcement about releases that highlights the current status and major 
progress points of KDE software. note that i did not write ‘KDE SC’. these  
pushes should try to include a broader picture that includes the frameworks, 
the workspaces and applications across the KDE community. why shouldn’tAmarok  
or K3B or Digikam or Calligra pumped in those announcements?

there could be a january and a july PR push that woudl pull together all the 
changes, all the important bits, etc. releases of the SC between those could 
be released with simplified annnouncements with less fanfare much as we 
currently do the monthly maintenance updates.

it could be even be more dramatic of a change of course: there could be just a 
single annual Big PR Splash with the rest of the year being filled with smaller 
and more regular PR announcements.

or maybe all releases are done with a simple announcement and instead of tying 
announcements to releases, a “KDE Magazine” is put out much as KDE e.V. does 
with quarterly reports that covers the last N months of activity in KDE.

in any case, the idea that development cycles dictate when we speak to the 
public is an anachronism. it really does not have the major impact many of us 
may think it does because we are no longer a young exciting project (which 
means we are most repeating ourselves, which is boring) and our bi-annual 
announcements not only skip over non-SC software but it is does not create 
much attention-grabbing engagement with people, something a magazine would do 
much better at.

imho, marketing should should be thinking outside the box and release 
schedules should not be tethered to those efforts.

== On scheduling mainenance releases

one of the benfits of a shorter cycle, to me, is that the need for monthly 
mainenance releases is lessened. with a 3 month cycle, i don’t see the point 
of having 2 bug fix updates. i’d instead suggest having just 1. in such a case, 
there would be a release every 6 weeks: major, minor, major, minor, etc.

in a longer 4 month cycle, i’d cut that to 8 weeks and keep just the  one 
update.

this would ease the burdon on our release team (and by extension packagers) 
while also giving developers more time to get better tested fixes in.

== On why 3 months?

personally, I’m unsure why 3 months ... 2 months, 4 months .. 2 could let us 
get rid of minor releases altogether. 4 might align better for distributions. 
i don’t have a strong opinion or compelling thoughts here, other than to 
remind us that 3 is not the only number we can consider in this :)

== On people being awesome

Alex: thanks to taking this topic on. much respect and thanks. even if it does 
not happen, the discussion has been very valuable already.

everyone who has engaged in the discussion so far has been pretty awesome. 
pretty much no bikeshedding, no flaming, thoughtful input. holy crap. :)

-- 
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/20130710/b96431e0/attachment.sig>