next release and release pace in general

[Yuë Liu]

We talked about having a testing branch before commit into master
branch last year. We can restrict commit right to master, let the
features committed to and tested in testing branch thoroughly. So
master will always keep stable.

On Thu, Jan 24, 2013 at 4:13 AM, Pierre Stirnweiss
<pstirnweiss at googlemail.com> wrote:
>
>
> On Wed, Jan 23, 2013 at 8:07 PM, C. Boemann <cbo at boemann.dk> wrote:
>>
>> On Wednesday 23 January 2013 18:25:59 Inge Wallin wrote:
>> > On Wednesday, January 23, 2013 12:05:43 C. Boemann wrote:
>> > > Hi
>> > >
>> > > I'm worried about our release pace. For 2.6 Words was able to make
>> > > exactly 0 new features. Sure we made several fixes, but apart from a
>> > > few
>> > > strings those could (almost) just as well have gone into a bugfix
>> > > release.
>> > >
>> > > I'm also worried that even though we do manage to put in an occasional
>> > > new feature, we don't make good enough PR out of it, simply because
>> > > every release contains so few new things that people miss the big
>> > > picture. I think Amarok has released new features over the last few
>> > > years but because they do like we do, I'm not at all sure they even
>> > > released.
>> > >
>> > > What I'm saying is that I think we are not making a big enough splash.
>> > >
>> > > And I'm also saying that personally I feel like I've been in a
>> > > constant
>> > > release mode, fixing bugs, since our first release. Now bug fixes are
>> > > needed for sure and I also like that we are stabilizing. Don't get me
>> > > wrong here.
>> > >
>> > > But hacking should also be about having fun and having time to make
>> > > new
>> > > stuff.
>> > >
>> > > Personally I think we should go back to release when we have enough to
>> > > make a splash. That can be 2 months or 9 months. It will vary. I still
>> > > think we should have always summer in master and that we never litter
>> > > master with half baked features, so we are always ready to branch out.
>> >
>> > I agree with this (mostly).  I don't think we should release as often as
>> > 2
>> > months even if we do have some new features. But I do also think that 4
>> > months is too close.
>> Well yes,
>>
>> > The idea was that we would have 4 months for feature development since
>> > master is always open to new features. But in reality this doesn't
>> > happen
>> > because the release branch does need bugfixes and polish and this eats
>> > into people's time in creating new features.
>> >
>> > Personally I like the 6 months cycle but I am flexible. But 4 months is
>> > too
>> > short for reasons shown above. Also, there is no linux distribution that
>> > has a 4 month release cycle so we can't get our software out to the
>> > users
>> > every 4 months. We have a break in the distribution chain there, meaning
>> > that some versions will be skipped by users because their distros simply
>> > won't package them.
>> >
>> > > Well this is just the general considerations. Specifically I think we
>> > > shouldn't branch 2.7 in a month. That is way too short. Yes I may have
>> > > the new side panel in words and sheets, and krita will no doubt have
>> > > features too, but the other features i have which will be ready in
>> > > time,
>> > > will not be user visible.
>> >
>> > Agreed here as well.
>> >
>> > > That means that in 8 months all words has progressed visibly is a new
>> > > side panel (modebox)
>> > >
>> > > I'd really like time to actually do some visible feature development
>> > > now
>> > > and then. It's important to show that we are not a dead project in
>> > > maintenance mode.
>> >
>> > Do you have a suggestion for a different schedule?
>> >
>> for 2.7 just add 2 more months giving you the 6 months you asked for
>>
>> with 2 more months I will be able to deliver
>>  - new interactive anchor ui
>>  - insertion of hyperlinks
>>  - restoring the review tool (without changetracking but with ui for
>> spellchecking, tagging text with language)
>>  - new modebox (the sidebar thing) [done]
>>  - new zoom mode in Words [done]
>>  - new config widgets to replace dockers
>>  - table config dialog (possibly)
>>
>> Possibly ingwa/moji and a little help from me would give ui for adding
>> comments/annotations with the review tool and showing it too. It doesn't
>> seem
>> too far fetched with our recent design plans and hacking by moji
>>
>> Also not going to promise anything from pierre but a new stylemanager
>> might
>> happen too
>>
>> best regards
>> boemann
>> _________
>
>
> Well, for 2.7 the sorting of styles according to usage is already in master,
> as well as a number of fixed bugs (which have admittedly mostly been back
> ported to 2.6, lessening the novelty factor of them). As soon as I have
> fixed the bug in Krita, I'll go back to the style manager. The first step is
> to make it look and behave the same as the current one. Then I will add some
> requested features to it. I hope to pass the state of no user visible change
> before 2.7 (at least the current buggy behaviour will be gone).
>
> In general I think a 6 month release plan is quite good. Also, if we really
> manage to push to master only finished features (to which I think we slowly
> get), we can have more flexibility in the release schedule. We could
> eventually do an anticipated release if one application has this really
> killing feature which in itself could create a big buzz.
> All in all I think we should really make sure that what we push to master is
> in a releasable state (which does not mean super optimised and stuff, but at
> least known bug free, usable and data safe).
>
> Pierre
>
>
> Pierre
>
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel
>