From kde-release-team Fri May 21 18:55:47 2010 From: Sebastian =?utf-8?q?K=C3=BCgler?= Date: Fri, 21 May 2010 18:55:47 +0000 To: kde-release-team Subject: Re: Early Branch. Message-Id: <201005212055.47413.sebas () kde ! org> X-MARC-Message: https://marc.info/?l=kde-release-team&m=127446819013265 Hi Volker, *, On Friday 21 May 2010 11:10:55 Volker Krause wrote: > On Friday 21 May 2010 01:05:00 Sebastian Kügler wrote: > > On Thu May 20 2010 19:11:38 Tom Albers wrote: > > > The KDEPIM whishes to branch early, as there are lots of development in > > > KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I > > > suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM > > > releases will come from that 4.5 branch. Feature development can then > > > continue in trunk. > > > > Why not create a work branch for the feature development? > > > > 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. 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). > > > > 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. > > There are two things happening in KDE PIM right now, stabilizing the > desktop applications and completing their port to Akonadi and the > development of the KDE PIM mobile applications. Since the latter share the > vast majority or their code with the desktop applications, most work done > here directly benefits the desktop as well. I don't think it's an ideal situation, but I trust you guys to do the right thing and to be diligent enough to not cause havoc and not endanger a stable release of our beloved KMail "as soon as possible after 4.5.0". > > I do know > > the business background here, but I would highly appreciate if KDE > > schedules were taken into account as well. > > We (KDAB/Intevation) not only take them into account, but also take them > very seriously. However, we cannot just stop working on features if KDE > freezes since our deadlines unfortunately don't align perfectly. So, we > will do that work in a branch in the meantime, like we always have in the > past. Sure, nobody expects you guys to stop working, but during freezes, this should happen in a branch. Luckily, this all will become a lot easier once we've moved to Git. (Which of course is one of the reasons to migrate in the first place.) > When hearing about EDU branching early for 4.5 we (KDE PIM) decided to > follow that scheme during the meeting last week since it simplifies the > branch maintenance considerably and doesn't mess up svn history that much. > > If it now turns out that this approach is not supported by KDE then we will > of course go back to the old one using a development branch. In fact, > that's what we will do until this discussion is resolved. I think it's fine to delay the freeze when such a sprint happens right after a freeze, but after that, the freeze needs to take effect, and it needs to be in trunk, since that's what people are testing and stabilizing for the release. > > 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. > > > > > Any objections to this request? If not, Dirk, can you set that up? > > > > I'd like to find a better solution for the above problems. > > We (KDAB/Intevation) have a intermediate deadline for the kdepim mobile > work next week Wednesday, so we will go with the work branch until then > and hopefully the situation will be resolved by then and I'll adapt our > workflow to whatever is decided here. Thanks for understanding the concerns! I hope it doesn't create too much extra work for you guys. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 _______________________________________________ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team