On Thursday, May 19, 2011 10:05:27 Cornelius Schumacher wrote: > On Thursday 19 May 2011 Aaron J. Seigo wrote: > > http://techbase.kde.org/Development/Tutorials/Git/Feature_Development_Wo > > rkf low > > Wow. This is a pretty complex workflow, and it's breaking with quite some > practices KDE used to use for a very long time. We have to make sure that we > don't leave developers behind with such a drastic change.
this is why we need to have work on it together. while a few of us have taken first steps in terms of drafting something, basically because someone has to otherwise we all stay in limbo with nothing being done, this is more of a provocative call to participate than anything even close to a final proposal. if we don't participate as if we care about this, we will get a workflow that doesn't serve us very well. which is what we have now. ;) so consider this a process in creating our shared future workflow with everything on the table to be modified, changed and improved as we see fit. note that there wasn't unanimous agreement on this workflow at Tokamak, but it at least gave us a starting point. we've openly documented it, brought the discussion to k-c-d and want input. there's a reason for that: we don't want to leave anyone behind and we want a workflow that, well, works. :) with a few iterations of this approach, i think we can have something pretty damn good put together. > The approach of having one central repository and all committers being equal > has served us well. i don't think that will change much. what is likely to change is that we won't be developing in a one mainline branch that we expect to become stable. it's nearly magical thinking that this is possible, in fact. in the goal of increasing the predictability of master, we can (and should) all still be equal in our interactions. > Maybe it's time to move forward to a different model, > but I think this should be done with care, and without changing more than > needed. yes, hopefully we change only what is needed and no more. :) > A lot of this is about semantics and how to name things, not > necessarily about technical processes. For example, if master is the stable > branch or a release branch doesn't make a big difference technically, but > it might affect our development culture quite a bit. agreed; note that the suggestion is not to make master _the_ stable branch (release branches would still maintain that position) but to make master as stable as possible over any given period of time. right now we have unpredictable levels of stability in master depending on the phase of the moon and where in the release cycle we are. this makes many things more difficult (including making time based releases) than it probably needs to be. at times it results in us shipping releases with more defects than we ought to. increasing the day-to-day stability and predictability of master by using git's strength in merging could probably do wonders for our releases. not to mention it would be very welcome by people working on device targets for which the release date of a given KDE SC event is less important compared to always having a place to pull from that is reasonably safe and not feature-stale. > This needs to be discussed. I'm looking forward to the upcoming face-to-face > meetings, but we should also have a wider discussion, as this is affecting > many more people than those who will have the opportunity to be at these > meetings. let's just be careful with the definition of "wider". we need a representative sampling of people from across KDE's community in terms of skill levels, needs and perspectives (e.g. casual developer, core developer, sys admin, writers of the commit digest ..). we don't need every possible individual involved, however. as such, if we do these discussions at Platform 11 and then again at BDS, and document results as we go, we probably will reach that level of coverage. we don't need everyone involved, we just need the various points of view and needs represented. as such, i do think the F2F meetings are likely to suffice. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks
signature.asc
Description: This is a digitally signed message part.
