Re: [Jsynthlib-devel] Name for refactored branch

[Joachim <li...@sd...>]

 >  it shall stay clean and functional at any moment.

If only clean stuff is commited this would still be possible.

 > What if we do not want to go back? Breaking up things is inevitable in
 > process of changing. And broken period can take extended time.

We could still use a refactoring branch.

 > And like is said, what if there will be no common agreement in the list?
 > Start voting? I do not think we should limit peoples creativity with
 > democracy

If that is the case we can still think about a solution like yours.
Anyway: How would you fit this into the project.

 > I think I would rest my case here.

I'm just expressing my opinion like you are. I'm not the dictator of JSynthLib
or something like that.

Cheers
Joachim

Am 02.09.2011 19:13, schrieb Vladimir Avdonin:
> On 09/02/2011 11:57 AM, Joachim wrote:
>> Ah, I don't think it makes sense to make a branch for every bug.
>
> Not every bug, just complicated ones, involving non-obvious changes and
> requiring extensive testing
>
>>
>>    >   and it might be not clear at start towards what release it
>>    >   will be targeted
>>
>> The target release is not a problem if the development takes place
>> in the trunk.
>
> Well, I have different phylosophy - I believe no development shall
> happen trunk, it shall stay clean and functional at any moment. The only
> commits that shall go there should be from tested working branch.
>
> This way any parallel developments that happen on branches will not
> break each others during syncing with trunk.
>
>>
>>    >   it probably would break everything in the project
>>
>> Remember: We can always go back and only working code should be
>> checked in, so the mess up shouldn't be too much anyway.
>> I don't see a big danger there.
>
> What if we do not want to go back? Breaking up things is inevitable in
> process of changing. And broken period can take extended time.
>
>>
>>    >   suppose I got some stupid
>>    >   idea that i am not even sure it make sense
>>
>> Develop it lokally and ask the list if it shall be added or not.
>> I would ask prior to putting any effort in it.;)
>
> And like is said, what if there will be no common agreement in the list?
> Start voting? I do not think we should limit peoples creativity with
> democracy
>
>>
>> Such a concept would only complicate the development process in my eyes
>> and I still don't see a benefit.
>
> I think I would rest my case here. Whatever goes
>