Обсуждение: Trac tickets
Why are trac tickets being created for the recent change history? That's what the changelog and svn history is for... -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : > Why are trac tickets being created for the recent change history? > That's what the changelog and svn history is for... Yes. I created them to try to use the roadmap system. See this: http://code.pgadmin.org/trac/roadmap and this: http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component (which is kind of a changelog and a todo list) -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Thu, Aug 6, 2009 at 12:22 PM, Guillaume Lelarge<guillaume@lelarge.info> wrote: > Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >> Why are trac tickets being created for the recent change history? >> That's what the changelog and svn history is for... > > Yes. I created them to try to use the roadmap system. See this: > > http://code.pgadmin.org/trac/roadmap > and this: > > http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component > (which is kind of a changelog and a todo list) OK, well if you want to start maintaining this, please have a think about how we can modify the existing processes to accomodate it. At the very least, I would like to avoid the changelog duplication - can we drop that file, or auto-create it for example? -- Dave Page EnterpriseDB UK: http://www.enterprisedb.com
On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: > On Thu, Aug 6, 2009 at 12:22 PM, Guillaume > Lelarge<guillaume@lelarge.info> wrote: >> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >>> Why are trac tickets being created for the recent change history? >>> That's what the changelog and svn history is for... >> >> Yes. I created them to try to use the roadmap system. See this: >> >> http://code.pgadmin.org/trac/roadmap >> and this: >> >> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component >> (which is kind of a changelog and a todo list) > > OK, well if you want to start maintaining this, please have a think > about how we can modify the existing processes to accomodate it. At > the very least, I would like to avoid the changelog duplication - can > we drop that file, or auto-create it for example? Yes, we should definitely be able to do that. However, I think we should do *both* for a while just to fill things with some data, so we can reasonably compare the outcome. yes, it means duplicated work during that time, but as long as we have the end-goal to drop one of the two. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : > On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: > > On Thu, Aug 6, 2009 at 12:22 PM, Guillaume > > > > Lelarge<guillaume@lelarge.info> wrote: > >> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : > >>> Why are trac tickets being created for the recent change history? > >>> That's what the changelog and svn history is for... > >> > >> Yes. I created them to try to use the roadmap system. See this: > >> > >> http://code.pgadmin.org/trac/roadmap > >> and this: > >> > >> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= > >>id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone > >>nt (which is kind of a changelog and a todo list) > > > > OK, well if you want to start maintaining this, please have a think > > about how we can modify the existing processes to accomodate it. At > > the very least, I would like to avoid the changelog duplication - can > > we drop that file, or auto-create it for example? > > Yes, we should definitely be able to do that. However, I think we > should do *both* for a while just to fill things with some data, so we > can reasonably compare the outcome. yes, it means duplicated work > during that time, but as long as we have the end-goal to drop one of > the two. Dropping one is not enough. We need to have more. And trac gives us more than just a changelog. So, I agree with Magnus. We should really check that trac works great enough for us before dropping any existing processes. -- Guillaume. http://www.postgresqlfr.org http://dalibo.com
On Fri, Aug 7, 2009 at 14:09, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : >> On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: >> > On Thu, Aug 6, 2009 at 12:22 PM, Guillaume >> > >> > Lelarge<guillaume@lelarge.info> wrote: >> >> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >> >>> Why are trac tickets being created for the recent change history? >> >>> That's what the changelog and svn history is for... >> >> >> >> Yes. I created them to try to use the roadmap system. See this: >> >> >> >> http://code.pgadmin.org/trac/roadmap >> >> and this: >> >> >> >> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= >> >>id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone >> >>nt (which is kind of a changelog and a todo list) >> > >> > OK, well if you want to start maintaining this, please have a think >> > about how we can modify the existing processes to accomodate it. At >> > the very least, I would like to avoid the changelog duplication - can >> > we drop that file, or auto-create it for example? >> >> Yes, we should definitely be able to do that. However, I think we >> should do *both* for a while just to fill things with some data, so we >> can reasonably compare the outcome. yes, it means duplicated work >> during that time, but as long as we have the end-goal to drop one of >> the two. > > Dropping one is not enough. We need to have more. And trac gives us more than > just a changelog. So, I agree with Magnus. We should really check that trac > works great enough for us before dropping any existing processes. Here's to bring up a really old thread. We've run it for a while now. Are we ready to drop the changelog and use trac reports instead? Or are we ready to drop the changelog and use git log? Or a combination, for different users? (Hint: I hate the changelog file because I keep forgetting to update it, and it sucks to handle it in the main repo due to how it integrates with branches) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 30/12/2010 11:32, Magnus Hagander a écrit : > On Fri, Aug 7, 2009 at 14:09, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : >>> On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: >>>> On Thu, Aug 6, 2009 at 12:22 PM, Guillaume >>>> >>>> Lelarge<guillaume@lelarge.info> wrote: >>>>> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >>>>>> Why are trac tickets being created for the recent change history? >>>>>> That's what the changelog and svn history is for... >>>>> >>>>> Yes. I created them to try to use the roadmap system. See this: >>>>> >>>>> http://code.pgadmin.org/trac/roadmap >>>>> and this: >>>>> >>>>> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= >>>>> id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone >>>>> nt (which is kind of a changelog and a todo list) >>>> >>>> OK, well if you want to start maintaining this, please have a think >>>> about how we can modify the existing processes to accomodate it. At >>>> the very least, I would like to avoid the changelog duplication - can >>>> we drop that file, or auto-create it for example? >>> >>> Yes, we should definitely be able to do that. However, I think we >>> should do *both* for a while just to fill things with some data, so we >>> can reasonably compare the outcome. yes, it means duplicated work >>> during that time, but as long as we have the end-goal to drop one of >>> the two. >> >> Dropping one is not enough. We need to have more. And trac gives us more than >> just a changelog. So, I agree with Magnus. We should really check that trac >> works great enough for us before dropping any existing processes. > > Here's to bring up a really old thread. > Wait, it's only 17 months old ;) > We've run it for a while now. Are we ready to drop the changelog and > use trac reports instead? Or are we ready to drop the changelog and > use git log? Or a combination, for different users? > No to trac reports as they ain't complete now. Dave and I talked about that in Stuttgart, and we decided that quick bugs to fix won't have a trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. I would be much more in favor to drop the changelog and use "git log" instead. > (Hint: I hate the changelog file because I keep forgetting to update > it, and it sucks to handle it in the main repo due to how it > integrates with branches) > Can't agree more :) -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Dec 30, 2010 at 18:29, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 30/12/2010 11:32, Magnus Hagander a écrit : >> On Fri, Aug 7, 2009 at 14:09, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>> Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : >>>> On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: >>>>> On Thu, Aug 6, 2009 at 12:22 PM, Guillaume >>>>> >>>>> Lelarge<guillaume@lelarge.info> wrote: >>>>>> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >>>>>>> Why are trac tickets being created for the recent change history? >>>>>>> That's what the changelog and svn history is for... >>>>>> >>>>>> Yes. I created them to try to use the roadmap system. See this: >>>>>> >>>>>> http://code.pgadmin.org/trac/roadmap >>>>>> and this: >>>>>> >>>>>> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= >>>>>> id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone >>>>>> nt (which is kind of a changelog and a todo list) >>>>> >>>>> OK, well if you want to start maintaining this, please have a think >>>>> about how we can modify the existing processes to accomodate it. At >>>>> the very least, I would like to avoid the changelog duplication - can >>>>> we drop that file, or auto-create it for example? >>>> >>>> Yes, we should definitely be able to do that. However, I think we >>>> should do *both* for a while just to fill things with some data, so we >>>> can reasonably compare the outcome. yes, it means duplicated work >>>> during that time, but as long as we have the end-goal to drop one of >>>> the two. >>> >>> Dropping one is not enough. We need to have more. And trac gives us more than >>> just a changelog. So, I agree with Magnus. We should really check that trac >>> works great enough for us before dropping any existing processes. >> >> Here's to bring up a really old thread. >> > > Wait, it's only 17 months old ;) Yeah :-) >> We've run it for a while now. Are we ready to drop the changelog and >> use trac reports instead? Or are we ready to drop the changelog and >> use git log? Or a combination, for different users? >> > > No to trac reports as they ain't complete now. Dave and I talked about > that in Stuttgart, and we decided that quick bugs to fix won't have a > trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. I agree, but what are people mainly looking for in CHANGELOG today do you think? bugfixes or new features? > I would be much more in favor to drop the changelog and use "git log" > instead. That's obviously the authoritarian source. If we could just link to http://git.postgresql.org/gitweb?p=pgadmin3.git;a=shortlog;h=refs/heads/master (and another link for the stable branch), that would certainly be the easiest. Is that going to be enough, or do we *really* need something user-formatted? (Other than in the release notes, perhaps?) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 30/12/2010 18:33, Magnus Hagander a écrit : > On Thu, Dec 30, 2010 at 18:29, Guillaume Lelarge <guillaume@lelarge.info> wrote: >> Le 30/12/2010 11:32, Magnus Hagander a écrit : >>> On Fri, Aug 7, 2009 at 14:09, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>>> Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : >>>>> On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: >>>>>> On Thu, Aug 6, 2009 at 12:22 PM, Guillaume >>>>>> >>>>>> Lelarge<guillaume@lelarge.info> wrote: >>>>>>> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >>>>>>>> Why are trac tickets being created for the recent change history? >>>>>>>> That's what the changelog and svn history is for... >>>>>>> >>>>>>> Yes. I created them to try to use the roadmap system. See this: >>>>>>> >>>>>>> http://code.pgadmin.org/trac/roadmap >>>>>>> and this: >>>>>>> >>>>>>> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= >>>>>>> id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone >>>>>>> nt (which is kind of a changelog and a todo list) >>>>>> >>>>>> OK, well if you want to start maintaining this, please have a think >>>>>> about how we can modify the existing processes to accomodate it. At >>>>>> the very least, I would like to avoid the changelog duplication - can >>>>>> we drop that file, or auto-create it for example? >>>>> >>>>> Yes, we should definitely be able to do that. However, I think we >>>>> should do *both* for a while just to fill things with some data, so we >>>>> can reasonably compare the outcome. yes, it means duplicated work >>>>> during that time, but as long as we have the end-goal to drop one of >>>>> the two. >>>> >>>> Dropping one is not enough. We need to have more. And trac gives us more than >>>> just a changelog. So, I agree with Magnus. We should really check that trac >>>> works great enough for us before dropping any existing processes. >>> >>> Here's to bring up a really old thread. >>> >> >> Wait, it's only 17 months old ;) > > Yeah :-) > > >>> We've run it for a while now. Are we ready to drop the changelog and >>> use trac reports instead? Or are we ready to drop the changelog and >>> use git log? Or a combination, for different users? >>> >> >> No to trac reports as they ain't complete now. Dave and I talked about >> that in Stuttgart, and we decided that quick bugs to fix won't have a >> trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. > > I agree, but what are people mainly looking for in CHANGELOG today do > you think? bugfixes or new features? > Nothing. People able to read the CHANGELOG file will probably just use "git log" (the only way to be sure to miss nothing, and have much more comments). >> I would be much more in favor to drop the changelog and use "git log" >> instead. > > That's obviously the authoritarian source. If we could just link to > http://git.postgresql.org/gitweb?p=pgadmin3.git;a=shortlog;h=refs/heads/master > (and another link for the stable branch), that would certainly be the > easiest. > > Is that going to be enough, or do we *really* need something > user-formatted? (Other than in the release notes, perhaps?) > Well, the CHANGELOG isn't that much formatted. It isn't user oriented (can't be translated for example (and to make sure you understand me, I don't think it needs to be)). -- Guillaume http://www.postgresql.fr http://dalibo.com
On Thu, Dec 30, 2010 at 18:49, Guillaume Lelarge <guillaume@lelarge.info> wrote: > Le 30/12/2010 18:33, Magnus Hagander a écrit : >> On Thu, Dec 30, 2010 at 18:29, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>> Le 30/12/2010 11:32, Magnus Hagander a écrit : >>>> On Fri, Aug 7, 2009 at 14:09, Guillaume Lelarge <guillaume@lelarge.info> wrote: >>>>> Le vendredi 7 août 2009 à 13:35:51, Magnus Hagander a écrit : >>>>>> On Fri, Aug 7, 2009 at 10:48, Dave Page<dpage@pgadmin.org> wrote: >>>>>>> On Thu, Aug 6, 2009 at 12:22 PM, Guillaume >>>>>>> >>>>>>> Lelarge<guillaume@lelarge.info> wrote: >>>>>>>> Le jeudi 6 août 2009 à 13:10:24, Dave Page a écrit : >>>>>>>>> Why are trac tickets being created for the recent change history? >>>>>>>>> That's what the changelog and svn history is for... >>>>>>>> >>>>>>>> Yes. I created them to try to use the roadmap system. See this: >>>>>>>> >>>>>>>> http://code.pgadmin.org/trac/roadmap >>>>>>>> and this: >>>>>>>> >>>>>>>> http://code.pgadmin.org/trac/query?milestone=1.10.1&order=priority&col= >>>>>>>> id&col=summary&col=status&col=type&col=priority&col=milestone&col=compone >>>>>>>> nt (which is kind of a changelog and a todo list) >>>>>>> >>>>>>> OK, well if you want to start maintaining this, please have a think >>>>>>> about how we can modify the existing processes to accomodate it. At >>>>>>> the very least, I would like to avoid the changelog duplication - can >>>>>>> we drop that file, or auto-create it for example? >>>>>> >>>>>> Yes, we should definitely be able to do that. However, I think we >>>>>> should do *both* for a while just to fill things with some data, so we >>>>>> can reasonably compare the outcome. yes, it means duplicated work >>>>>> during that time, but as long as we have the end-goal to drop one of >>>>>> the two. >>>>> >>>>> Dropping one is not enough. We need to have more. And trac gives us more than >>>>> just a changelog. So, I agree with Magnus. We should really check that trac >>>>> works great enough for us before dropping any existing processes. >>>> >>>> Here's to bring up a really old thread. >>>> >>> >>> Wait, it's only 17 months old ;) >> >> Yeah :-) >> >> >>>> We've run it for a while now. Are we ready to drop the changelog and >>>> use trac reports instead? Or are we ready to drop the changelog and >>>> use git log? Or a combination, for different users? >>>> >>> >>> No to trac reports as they ain't complete now. Dave and I talked about >>> that in Stuttgart, and we decided that quick bugs to fix won't have a >>> trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. >> >> I agree, but what are people mainly looking for in CHANGELOG today do >> you think? bugfixes or new features? >> > > Nothing. People able to read the CHANGELOG file will probably just use > "git log" (the only way to be sure to miss nothing, and have much more > comments). > >>> I would be much more in favor to drop the changelog and use "git log" >>> instead. >> >> That's obviously the authoritarian source. If we could just link to >> http://git.postgresql.org/gitweb?p=pgadmin3.git;a=shortlog;h=refs/heads/master >> (and another link for the stable branch), that would certainly be the >> easiest. >> >> Is that going to be enough, or do we *really* need something >> user-formatted? (Other than in the release notes, perhaps?) >> > > Well, the CHANGELOG isn't that much formatted. It isn't user oriented > (can't be translated for example (and to make sure you understand me, I > don't think it needs to be)). So, I suggest we just flip the links to point to git and get rid of it then :-) Dave, you planning to veto that? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Thu, Dec 30, 2010 at 5:29 PM, Guillaume Lelarge <guillaume@lelarge.info> wrote: > No to trac reports as they ain't complete now. Dave and I talked about > that in Stuttgart, and we decided that quick bugs to fix won't have a > trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. > > I would be much more in favor to drop the changelog and use "git log" > instead. > >> (Hint: I hate the changelog file because I keep forgetting to update >> it, and it sucks to handle it in the main repo due to how it >> integrates with branches) >> > > Can't agree more :) The CHANGELOG is supposed to be a list of "changes that are interesting to the user", ie. the changes that we include in release notices etc. Git log includes a ton of extra stuff, and would require significant manual filtering at release time to produce the change log data. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Dec 31, 2010 at 02:30, Dave Page <dpage@pgadmin.org> wrote: > On Thu, Dec 30, 2010 at 5:29 PM, Guillaume Lelarge > <guillaume@lelarge.info> wrote: >> No to trac reports as they ain't complete now. Dave and I talked about >> that in Stuttgart, and we decided that quick bugs to fix won't have a >> trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. >> >> I would be much more in favor to drop the changelog and use "git log" >> instead. >> >>> (Hint: I hate the changelog file because I keep forgetting to update >>> it, and it sucks to handle it in the main repo due to how it >>> integrates with branches) >>> >> >> Can't agree more :) > > The CHANGELOG is supposed to be a list of "changes that are > interesting to the user", ie. the changes that we include in release > notices etc. Git log includes a ton of extra stuff, and would require > significant manual filtering at release time to produce the change log > data. Yes, but it requires significant manual filtering *now* to produce it as well. And it misses stuff (I *know* that I keep forgetting and don't always pick up on it and fix it later, and I'm pretty sure others do as well). So you'd have to make a pass through all the git logs *anyway* if you want to keep it up to date. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
Le 31/12/2010 10:52, Magnus Hagander a écrit : > On Fri, Dec 31, 2010 at 02:30, Dave Page <dpage@pgadmin.org> wrote: >> On Thu, Dec 30, 2010 at 5:29 PM, Guillaume Lelarge >> <guillaume@lelarge.info> wrote: >>> No to trac reports as they ain't complete now. Dave and I talked about >>> that in Stuttgart, and we decided that quick bugs to fix won't have a >>> trac ticket. We'll only use trac's bugtracker to keep track of unfixed bugs. >>> >>> I would be much more in favor to drop the changelog and use "git log" >>> instead. >>> >>>> (Hint: I hate the changelog file because I keep forgetting to update >>>> it, and it sucks to handle it in the main repo due to how it >>>> integrates with branches) >>>> >>> >>> Can't agree more :) >> >> The CHANGELOG is supposed to be a list of "changes that are >> interesting to the user", ie. the changes that we include in release >> notices etc. Git log includes a ton of extra stuff, and would require >> significant manual filtering at release time to produce the change log >> data. > > Yes, but it requires significant manual filtering *now* to produce it > as well. Even if I mostly agree with you, significant is a bit too much :) > And it misses stuff (I *know* that I keep forgetting and > don't always pick up on it and fix it later, and I'm pretty sure > others do as well). I'm sure I'm one of the others. I missed several times. > So you'd have to make a pass through all the git > logs *anyway* if you want to keep it up to date. > Well, if we miss one or two things in the CHANGELOG, that's not a big issue. Anyway, you're right that this is what I do for the visual tour. -- Guillaume http://www.postgresql.fr http://dalibo.com
On Fri, Dec 31, 2010 at 9:52 AM, Magnus Hagander <magnus@hagander.net> wrote: > > Yes, but it requires significant manual filtering *now* to produce it > as well. No, it requires 30 seconds per commit that is worthy of mention. Dropping the changelog will mean that work gets pushed to me (or Guillaume) to do immediately prior to release, in a way that could take a few hours to extract and format the data appropriately. At a time when we're usually pretty darn busy already. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Dec 31, 2010 at 15:53, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Dec 31, 2010 at 9:52 AM, Magnus Hagander <magnus@hagander.net> wrote: >> >> Yes, but it requires significant manual filtering *now* to produce it >> as well. > > No, it requires 30 seconds per commit that is worthy of mention. > Dropping the changelog will mean that work gets pushed to me (or > Guillaume) to do immediately prior to release, in a way that could > take a few hours to extract and format the data appropriately. At a > time when we're usually pretty darn busy already. Well, fair enough, i guess the answer is "yes" to the question "will you veto this" :-) BTW, if we're keeping it, it would certainly be good if there was a useful policy for how to deal with it wrt back branches. Perhaps there is one today and I just don't know it? Looking at it now it seems that the head version has a mix of head and backbranches and backbranch versions has nothing? ISTM that's pretty hard to parse - thus I'm not even sure that's how it's meant to be now? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Dec 31, 2010 at 15:59, Magnus Hagander <magnus@hagander.net> wrote: > On Fri, Dec 31, 2010 at 15:53, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Dec 31, 2010 at 9:52 AM, Magnus Hagander <magnus@hagander.net> wrote: >>> >>> Yes, but it requires significant manual filtering *now* to produce it >>> as well. >> >> No, it requires 30 seconds per commit that is worthy of mention. >> Dropping the changelog will mean that work gets pushed to me (or >> Guillaume) to do immediately prior to release, in a way that could >> take a few hours to extract and format the data appropriately. At a >> time when we're usually pretty darn busy already. > > Well, fair enough, i guess the answer is "yes" to the question "will > you veto this" :-) > > BTW, if we're keeping it, it would certainly be good if there was a > useful policy for how to deal with it wrt back branches. Perhaps there > is one today and I just don't know it? Looking at it now it seems that > the head version has a mix of head and backbranches and backbranch > versions has nothing? ISTM that's pretty hard to parse - thus I'm not > even sure that's how it's meant to be now? Actually, I take it back. The CHANGELOG on the REL-1_12_PATCHES has some changes for 1.12.1, 1.12.2, 1.12.3. And surprisingly enough also 1.14.0, which certainly didn't exist back then... Which kind of proves my point about the confusion;) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Dec 31, 2010 at 3:03 PM, Magnus Hagander <magnus@hagander.net> wrote: > Actually, I take it back. > > The CHANGELOG on the REL-1_12_PATCHES has some changes for 1.12.1, > 1.12.2, 1.12.3. And surprisingly enough also 1.14.0, which certainly > didn't exist back then... Yes - we've done it that way for years. > Which kind of proves my point about the confusion;) Meh. Someone committed a bad merge. The doesn't mean it hasn't worked for the most part. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
On Fri, Dec 31, 2010 at 16:07, Dave Page <dpage@pgadmin.org> wrote: > On Fri, Dec 31, 2010 at 3:03 PM, Magnus Hagander <magnus@hagander.net> wrote: >> Actually, I take it back. >> >> The CHANGELOG on the REL-1_12_PATCHES has some changes for 1.12.1, >> 1.12.2, 1.12.3. And surprisingly enough also 1.14.0, which certainly >> didn't exist back then... > > Yes - we've done it that way for years. I know - and it's been itching me for years ;) >> Which kind of proves my point about the confusion;) > > Meh. Someone committed a bad merge. The doesn't mean it hasn't worked > for the most part. So, just to be clear: Something that's backpatched goes into both master and the backpatch CHANGELOG. And the order in the CHANGELOG is chronological, *not* version-ordered? (resulting in mixed versions in head, but consistent version ordering in backbranches)? -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
On Fri, Dec 31, 2010 at 3:09 PM, Magnus Hagander <magnus@hagander.net> wrote: > On Fri, Dec 31, 2010 at 16:07, Dave Page <dpage@pgadmin.org> wrote: >> On Fri, Dec 31, 2010 at 3:03 PM, Magnus Hagander <magnus@hagander.net> wrote: >>> Actually, I take it back. >>> >>> The CHANGELOG on the REL-1_12_PATCHES has some changes for 1.12.1, >>> 1.12.2, 1.12.3. And surprisingly enough also 1.14.0, which certainly >>> didn't exist back then... >> >> Yes - we've done it that way for years. > > I know - and it's been itching me for years ;) > > >>> Which kind of proves my point about the confusion;) >> >> Meh. Someone committed a bad merge. The doesn't mean it hasn't worked >> for the most part. > > So, just to be clear: > > Something that's backpatched goes into both master and the backpatch CHANGELOG. > > And the order in the CHANGELOG is chronological, *not* > version-ordered? (resulting in mixed versions in head, but consistent > version ordering in backbranches)? Yes. And for the record - I find it a PITA too; but... it's *much* easier for me than trying to find another few hours for additional tedious release prep tasks. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Le 31/12/2010 16:07, Dave Page a écrit : > On Fri, Dec 31, 2010 at 3:03 PM, Magnus Hagander <magnus@hagander.net> wrote: >> Actually, I take it back. >> >> The CHANGELOG on the REL-1_12_PATCHES has some changes for 1.12.1, >> 1.12.2, 1.12.3. And surprisingly enough also 1.14.0, which certainly >> didn't exist back then... > > Yes - we've done it that way for years. > +1 >> Which kind of proves my point about the confusion;) > > Meh. Someone committed a bad merge. The doesn't mean it hasn't worked > for the most part. > Yeah, there probably are some errors, but they should be fixed. I do the same kind of mistake when I first fix an issue that I think should only be commited to master, but have to commit it to the previous branch. -- Guillaume http://www.postgresql.fr http://dalibo.com