Thread: 1.16 beta 1 ?
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, 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? BTW, has anyone a strong opinion on how we should do this? -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Mon, May 7, 2012 at 9:18 AM, Guillaume Lelarge <guillaume@lelarge.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... -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, 2012-05-07 at 09:20 +0200, Magnus Hagander wrote: > On Mon, May 7, 2012 at 9:18 AM, Guillaume Lelarge > <guillaume@lelarge.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. 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. 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 can start working on this this week. The simpler would be tomorrow for me because I don't have to work tomorrow. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Mon, May 7, 2012 at 9:55 AM, Guillaume Lelarge <guillaume@lelarge.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@lelarge.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/
On Monday, May 7, 2012, Magnus Hagander <magnus@hagander.net> wrote:
> 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?
If Guillaume is going to continue to work on the feature, I'd be happy with #ifdef's and a configure switch to enable that code.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Mon, 2012-05-07 at 09:11 +0100, Dave Page wrote: > > > On Monday, May 7, 2012, Magnus Hagander <magnus@hagander.net> wrote: > > 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? > Not much. It would be quite easy to do. > If Guillaume is going to continue to work on the feature, I'd be happy > with #ifdef's and a configure switch to enable that code. > I want to continue the work on it. But to be completely honest, it isn't my priority. My priority is to get new releases of pgAdmin with the biggest support of the new PostgreSQL features. I'll work on a patch with the ifdef's. It'll be much less work. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
On Mon, May 7, 2012 at 10:29 AM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Mon, 2012-05-07 at 09:11 +0100, Dave Page wrote: >> >> >> On Monday, May 7, 2012, Magnus Hagander <magnus@hagander.net> wrote: >> > 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? >> > > Not much. It would be quite easy to do. Then I suggest that path. >> If Guillaume is going to continue to work on the feature, I'd be happy >> with #ifdef's and a configure switch to enable that code. >> > > I want to continue the work on it. But to be completely honest, it isn't > my priority. My priority is to get new releases of pgAdmin with the > biggest support of the new PostgreSQL features. That seems like reasonable priorities. But if it were to decent to the point of being basically "dead code", it shuld be removed. > I'll work on a patch with the ifdef's. It'll be much less work. Good. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Mon, 2012-05-07 at 10:32 +0200, Magnus Hagander wrote: > On Mon, May 7, 2012 at 10:29 AM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: > > On Mon, 2012-05-07 at 09:11 +0100, Dave Page wrote: > >> > >> > >> On Monday, May 7, 2012, Magnus Hagander <magnus@hagander.net> wrote: > >> > 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? > >> > > > > Not much. It would be quite easy to do. > > Then I suggest that path. > See attached patch. > >> If Guillaume is going to continue to work on the feature, I'd be happy > >> with #ifdef's and a configure switch to enable that code. > >> > > > > I want to continue the work on it. But to be completely honest, it isn't > > my priority. My priority is to get new releases of pgAdmin with the > > biggest support of the new PostgreSQL features. > > That seems like reasonable priorities. But if it were to decent to the > point of being basically "dead code", it shuld be removed. > I agree. > > I'll work on a patch with the ifdef's. It'll be much less work. > > Good. > Waiting comments before applying. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com
Attachment
Looks reasonable to me. On Mon, May 7, 2012 at 8:46 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > On Mon, 2012-05-07 at 10:32 +0200, Magnus Hagander wrote: >> On Mon, May 7, 2012 at 10:29 AM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >> > On Mon, 2012-05-07 at 09:11 +0100, Dave Page wrote: >> >> >> >> >> >> On Monday, May 7, 2012, Magnus Hagander <magnus@hagander.net> wrote: >> >> > 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? >> >> >> > >> > Not much. It would be quite easy to do. >> >> Then I suggest that path. >> > > See attached patch. > >> >> If Guillaume is going to continue to work on the feature, I'd be happy >> >> with #ifdef's and a configure switch to enable that code. >> >> >> > >> > I want to continue the work on it. But to be completely honest, it isn't >> > my priority. My priority is to get new releases of pgAdmin with the >> > biggest support of the new PostgreSQL features. >> >> That seems like reasonable priorities. But if it were to decent to the >> point of being basically "dead code", it shuld be removed. >> > > I agree. > >> > I'll work on a patch with the ifdef's. It'll be much less work. >> >> Good. >> > > Waiting comments before applying. > > > -- > Guillaume > http://blog.guillaume.lelarge.info > http://www.dalibo.com -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Mon, 2012-05-07 at 20:48 +0100, Dave Page wrote: > Looks reasonable to me. > Commited and pushed. Thanks. -- Guillaume http://blog.guillaume.lelarge.info http://www.dalibo.com