Re: [KMess-devel] On Microsoft doing nasty stuff and us pushing quick updates

[Adam G. <ada...@gm...>]

You hit the nail on the head with the last paragraph. Our weakness is
our slow release step. The bug was fixed within 24hrs of reporting but
we're only just now going to release 2.0.5. I think by adequately
documenting our *release* process (what to do, release news article
templates, how to upload to sourceforge, yada yada) we can really
speed up this process.

Putting small bug fixes into separate branches seems counter intuitive
to me - if the fix is that small, and we trust our work, just push it
into the kmess-2.0.x branch. Testers will download it with their next
git pull, they'll test it, report back, we're good to go.

Features, however, I agree with. In fact, we need to develop in a
separate branch (which we already do) but what's the point in
developing in a separate branch if nobody tests the code in it? IMO we
also need to tell our *testers* to switch to this new branch to test
it for us. I propose creating a kmess-testers mailing list which
people who want to help us test our new features can sign up to. When
we, for example, want them to test webcam in our "webcam" branch we'll
push out an email saying "hey, switch to kmess-3.0-webcam and test it
for us?".

We'll combine the two things you're looking for - we'll develop *and*
test in a separate branch. Then merge once stable.

-Adam.

On Mon, Oct 25, 2010 at 4:18 PM, Sjors Gielen <da...@da...> wrote:
> Hi all,
>
> Even though I'm not really active for KMess lately, spending most time on study and real life, I feel inclined to talk about this with the rest of you. It's not the first time Microsoft has pushed an update to their servers, breaking current protocol (even though it might still match with their internal specifications).
>
> 2.0.5, I saw, will probably come out today or very soon. However, this offline message bug has been around for at least two weeks. Now that we are using Git, releasing intermediate quick versions to fix an important bug should become a *lot* easier: if we create a policy that new features or even small bugfixes are *always* branched first, and only merged in mainline if we *know* they work, the mainline version is always ready to be released, at least in the stable branch. Imagine a branch where we have this policy: there might be six branches active for feature addition or bugfixes; that's not important: as soon as such a crash bug is seen, it's fixed, tested a few times, and a release can be initiated. The feature additions and bugfixes can be merged in later for the next release. (There could even be a web interface showing our mainline branches and their branched off features, so we can keep track of the small branches etc. Also keeping NEWS up to date should be way easier if a branch merge by policy requires a NEWS update...)
>
> I'm sure I'm not telling you anything new, but what do you think about 'formalizing' this policy and publishing it on the Wiki or so, and really follow it? At least, people can't complain to us about being slow anymore, even though we have real life really taking our time. A release could be a matter of bugfix, some testing, tarball, upload on Sourceforge, update kmess.org, e-mail kmess-announce@ :)
>
> Sjors
> ------------------------------------------------------------------------------
> Nokia and AT&T present the 2010 Calling All Innovators-North America contest
> Create new apps & games for the Nokia N8 for consumers in  U.S. and Canada
> $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
> Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
> http://p.sf.net/sfu/nokia-dev2dev
> _______________________________________________
> KMess-devel mailing list
> KMe...@li...
> https://lists.sourceforge.net/lists/listinfo/kmess-devel
>
>