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
signature.asc
Description: This is a digitally signed message part.
