[BW-dev-discussion] Dev model (About the idea of release made every X Month

[Jose Aliste]

On Tue, Aug 24, 2010 at 5:49 AM,  <jeanyves.hegron at laposte.net> wrote:
>
> Hello,
>
> @Jose yes, this is a bit of topic, but in fact a very good idea. (Why didn't
> we think about this before ?).
>
I think that long time ago we decided that we didn't like branching.
Since now git is now defacto repository, we don't need to be afraid of
branching anymore.

> I see such a way (planned date for release, frozen one or two weeks before)
> a good solution to motivate people and product results. This provide
> concrete goals.

Yes, but I want to stress my point here even if you don't make
releases at a given time, is that you DON't MERGE trunk into alpha to
make some new feature available, you just branch trunk at this point
and then work on the new branch to stabilize the code. This way you
don't spend a lot of time merging alpha and master, which in my
opinion is slowing the dev down.


>
> This will also reduce the risk of me (or someone else) pushing for having
> his latest code to go online at the bad moment (when things are planned it
> is better for everything stability/organization)
>
> JeanYves
>

Greets

José


>
> -----Message d'origine-----
> De : bw-dev-discussion-bounces at bewelcome.org
> [mailto:bw-dev-discussion-bounces at bewelcome.org] De la part de Jose Aliste
> Envoyé : lundi 23 août 2010 17:53
> À : BeWelcome Developers Team
> Cc : Uwe Federer (Servas); Gary Sealey; Jean-Yves Hégron
> Objet : [BW-dev-discussion] Dev model (was Re: Is it important to adopt a
> new framework before proceeding?)
>
>
> Hi,
>
> I am sorry I go   off-topic, but I wanted to point you out that BW
> maybe needs a better model for development. I just saw that the
> alpha/production/master(trunk) branches have all very different code,
> and I guess that the current dev model (based on these three branches)
> might be slowing the development since the process of merging can be
> painful.
>
> What I would propose for this would be a more "feature-released" based
> dev. model. The idea would be to make releases every x months, so,
> one, you can make press releases and give  a good publicity of new
> features. The basic idea would be to follow Gnome dev. process. This
> is as follows:
>
> You code everything on master, there is a "feature Freeze" at some
> point, where you stop adding new features and concentrate on testing
> the added features and stabilizing the code. Then you have a "Hard
> code Freeze" meaning that only approved code can go in. At this point
> you create a new branch called (bw-version-of-the-release) and put
> that code on the alpha site.
> At this point, people that want to add new features can do so in the
> master branch, but if you find some bug in the alpha site, you fix it
> in the specific release-branch! Once it's stable enough on alpha, you
> make the release (which is just chaging some files with the version of
> the software) tag the release and you are back to add new features. If
> you find new bugs, you always fix them into the release-branch (of
> course you also fix them on the master branch, but you don't need to
> merge from the master branch to make the bugfix available to the
> users).
>
>
>
>
>
>
> On Mon, Aug 23, 2010 at 7:11 AM, Peter Lind <peter.e.lind at gmail.com> wrote:
>> On 23 August 2010 11:59, Tobias Brox <tobixen at gmail.com> wrote:
>>> On 22 August 2010 14:47, Peter Lind <peter.e.lind at gmail.com> wrote:
>>>> This avoids a big-bang strategy (one of the most likely risks of
>>>> failure for the project) while easing developers in.
>>>
>>> I don't know much about the bwrox application ... but I agree quite
>>> much to that, I've witnesses several failures or near-failures from
>>> when the programmers have become fed up with the mess, and tried to
>>> reimplement a project from scratch.  The new code will most likely
>>> miss some of the old features and will be with more bugs.  The users
>>> will see only the drawbacks, not the benefits with the "new and clean
>>> code", and the programmers will become disencouraged because the users
>>> prefers to run the old code.
>>>
>>> Then again ... isn't it slightly ironical, that one of the reasons
>>> stated why "bwrox sucks" is exactly because one has several times
>>> attempted to "switch framework" without fully succeeding with it?
>>
>> Sort of. There's been one attempted switch, then one attempt to
>> repair/extend the framework we switched to. But yeah, one should
>> definitely be aware of the possible risks.
>>
>>> Except for that, I'm quite much against reinventing the wheel.  For
>>> me, bwrox seems like "just another social networking site", with some
>>> extra emphasize on geolocation.  I would be amazed if there isn't some
>>> ready-to-use software in the open source domain that already supports
>>> many of the bwrox features out of the box.  Alternatively, for sure
>>> there exists many open-source applications supporting one or some of
>>> the features we want to deliver, i.e. discussion forums, wikis,
>>> calendar, blog, etc.  It could be possible to "stitch together" (i.e.
>>> single signon, good cross-linkage possibilities, etc) existing
>>> specialized applications and concentrate on the hospitality exchange
>>> specifics in our own application?  Well, I do see drawbacks with such
>>> solution ... but at least we would gain on it by having almost
>>> feature-complete and bugfree subsystems on our site without too much
>>> maintenance efforts.
>>
>> I agree up to a point. It would be nice to just be able to string
>> together a number of products and hey presto, system in place. I don't
>> believe this is feasible though, for the following reasons:
>> - we've already tried it with the ErfurtWiki we use now. It's utter
>> crap, we've had to hack it to make it work as we want it to (and it
>> still doesn't quite). The main wiki system that one benchmarks against
>> is - according to anecdote) - a nightmare to implement into existing
>> systems
>> - a platform like BW or the proposed cooperation goal is *not* just
>> the sum of it's parts. It's not just a forum with geolocation tacked
>> on to the outside. It's a forum where the geolocation is a central
>> part - and it's geolocation capable of pulling forum threads, member
>> profiles, etc into one. Trying to do this with several stand alone
>> components will probably result in massive overhead or a nightmare of
>> hacks.
>> - creating a uniform experience with several stand-alone projects is
>> very hard. It will likely be very easy to see that you're now leaving
>> the stand alone forum part and entering the stand alone wiki part.
>> That's not a nice user experience
>>
>> That said, the way one might be able to do this is by creating a set
>> of thin adapters/facades to the various systems, pull data out of them
>> and then present it outside each system, as a unified whole. That
>> might be a *lot* of work though - hard to gauge without experience (if
>> one could find a forum with a good api, a wiki with the same, etc,
>> then it might be easy enough to simply run those systems on their own
>> and just extract data from them).
>>
>> Regards
>> Peter
>>
>> --
>> <hype>
>> WWW: http://plphp.dk / http://plind.dk
>> LinkedIn: http://www.linkedin.com/in/plind
>> BeWelcome/Couchsurfing: Fake51
>> Twitter: http://twitter.com/kafe15
>> </hype>
>> _______________________________________________
>> bw-dev-discussion mailing list
>> bw-dev-discussion at bewelcome.org
>> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
>>
> _______________________________________________
> bw-dev-discussion mailing list
> bw-dev-discussion at bewelcome.org
> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
>
>
>
> _______________________________________________
> bw-dev-discussion mailing list
> bw-dev-discussion at bewelcome.org
> http://bewelcome.org/mailman/listinfo/bw-dev-discussion
>