Re: 1.16 beta 1 ?

On Mon, May 7, 2012 at 9:55 AM, Guillaume Lelarge
<guillaume(at)lelarge(dot)info> wrote:
> On Mon, 2012-05-07 at 09:20 +0200, Magnus Hagander wrote:
>> On Mon, May 7, 2012 at 9:18 AM, Guillaume Lelarge
>> <guillaume(at)lelarge(dot)info> wrote:
>> > Hi,
>> >
>> > Even after reading the whole thread on pgsql-hackers, I don't understand
>> > if they're going to release the beta this week or anytime soon. Anyway,
>>
>> The plan is beta1 before pgcon.
>>
>>
>> > if we want to release our beta at the same time, we need to know that a
>> > bit ahead so that we can push the database designer on its own branch,
>> > and drop it from master?
>>
>> There's about a week of warning at this point, provided the schedule
>> for the main project holds.
>>
>>
>> > BTW, has anyone a strong opinion on how we should do this?
>>
>> Not really...
>>
>
> I think the best way would be to:
>
>  * create a patch from all the new files, and all the changes brought by
>   the database designer ;
>  * drop all this stuff from master ;
>  * commit it (but don't push it) ;
>  * create the new branch ;
>  * apply the patch on this branch ;
>  * commit it (but don't push it) ;
>  * check everything works fine in master and the new branch ;
>  * push both branches if it works.

You can probably do this part a lot easier by reordering the operations:
* Create a new branch first. It will take off from where we are now,
which has the db designed
* Revert the code, either by isolating it and manually doing the patch
thing, or using "git revert" (this is what you had under "drop all
this stuff from master" - which still is the hardest part)

There's no need to recreate the history on the separate branch, since
it's already there in master and we can't back that out (we can only
revert it with reverse patches)

> I understand that the first step will be the harder one. The good thing
> is that the database designer is pretty well self-contained. Apart from
> an icon on frmMain and some options in the command line, there are no
> other changes. At least, IIRC. BTW, "best way" really means "best way I
> could imagine". I don't have the git-fu knowledge of Magnus.

The best way, obviously, was to have kept it as a separate branch from
day one, but we've been over that...

Given that it's self contained, and we *do* expect it to get in
eventually, how many places would you have to put #ifdef's in to leave
the code in the main branch and just not have it build there?

Further development could then happen on the branch, and the code
would just linger around as dead code on master. It wouldn't be as
pretty, but the work to do it might be a *lot* eaiser. This does
assume that we eventually expect it to go in, but AFAIK we still do
that,right?

> Another question: how should we name to new branch? database_designer
> would be my choice as it is self-explaining, maybe a bit verbose. Any
> objection?

I have no objections to verbose names - it's self explaining, that's a
big feature in itself. If you want it to be shorter, you can use
db_designer ;)

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/