On Fri, 21 May 2010 01:05:00 +0200, Sebastian Kügler <se...@kde.org> wrote: > Why not create a work branch for the feature development?
That would have been fine if I would have known you had a problem with it. The exception request for edu was made a month ago, and nobody objected to it, nobody even replied to it, so I considered it to be ok. In that light I considered KDEPIM could just jump on the exact same train. > I'm actually not too happy with individual modules branching off for > bugfixing > and using trunk for feature development. We have a freeze for a reason > (common > rythm of development, reaching acceptable level of quality), and if we > need to > explain SVN users which trunk branches are frozen, which ones are open for > features, and which ones should get the bugfixes, we're making things > *really* > complicated, as policies are KDE SC-wide, not only apply to a subset of > the > modules within it. It's not that bad as you describe. The branch is created in order to comply to the freezes we have set. We now have a clear distinction for what is stable and where features are going. It's not making things '*really* complicated', they just branch of a bit early, just like we would have done at release candidate time. Maybe we should just consider it as an experiment for the 'always <insert your favorite season here as long as it is not winter> in trunk' we talked about years ago. Let's see if it works out for edu and pim and _consider_ this the default for 4.6, and yes that needs discussion in any case. > I get it that feature development in trunk is easier, > but > the main focus is getting our current trunk release ready. That holds true > for > other modules as well, and it requires a bit of discipline from all or us. > Opening up parts of trunk for feature development just sends out the wrong > message, and I fear it might have negative effect on the quality of the > upcoming release. We're in release mode now, and it's not like that should > come as a surprise to anyone. > I'm not convinced we should open up trunk for development on features > we're > not even planning to release inside KDE SC now (i.e. akonadi / kmail > mobile). I don't think it will have any negative outcome, although you can only be sure if the time arrives. In any case in both cases a feature branch would have been created, there was no way around that. Doing it trunk with the branch for the stable stuff makes a lot of lives easier. Maybe not for release managers, but it is for teams working on those. Both teams have indicated that they will double check everything is kept in sync between the two code trees regarding bugfixes. For translators it is transparant. > Also, asking for delaying the PIM release because there's not enough time > to > get it to an acceptable level of quality in time for 4.5.0, and at the > same > time requesting opening trunk for new features is a bit odd. I do know the > business background here, but I would highly appreciate if KDE schedules > were > taken into account as well. Again, this situation is exactly to facilitate that. The PIM people need to honor the KDE Schedule and they know it. But you need to consider that PIM development is largely relying on commercial development, which has sometimes have a different schedule. We need to find a balance between that. Forking PIM because the schedule does not match the commercial one is to be avoided and on the other side delaying the releases because the commercial agenda does not match is unacceptable too. Balance. With this important kdepim release coming up, we need another month. But there are so many pim-developers that the features go hand-in-hand with them. Testing and creating the mobile apps makes sure they run into all kinds of bugs they have to fix and which also apply to the desktop applications. > I get it that lots of stuff is happening in PIM, and I'm really happy > about > that, but we need to keep things sane for others as well, and maintain a > leveled community. Agreed. Again I think we need to consider it as an experiment and let it go for now. We can decide to never do it again in the end if it sucks big time. Best, -- Tom Albers KDE Developer _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team