From: Chris S. <ir0...@gm...> - 2012-01-16 20:46:40
|
Hi Keith, Not sure if this was accidental or not, but Corinna requested that configure remain in the repository, so not sure why it was added to .cvsignore again. Chris ---------- Forwarded message ---------- From: <kei...@cy...> Date: 16 January 2012 15:26 Subject: src/winsup/w32api .cvsignore ChangeLog lib/Mak ... To: cyg...@cy... CVSROOT: /cvs/src Module name: src Changes by: kei...@so... 2012-01-16 20:26:49 Modified files: winsup/w32api : .cvsignore ChangeLog winsup/w32api/lib: Makefile.in Log message: Generalise makefile references to subdirectories of lib. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/.cvsignore.diff?cvsroot=src&r1=1.2&r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/ChangeLog.diff?cvsroot=src&r1=1.1111&r2=1.1112 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/w32api/lib/Makefile.in.diff?cvsroot=src&r1=1.57&r2=1.58 -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie B. <ea...@us...> - 2012-01-16 22:01:40
|
On Mon, Jan 16, 2012 at 3:46 PM, Chris Sutcliffe <ir0...@gm...> wrote: > Hi Keith, > > Not sure if this was accidental or not, but Corinna requested that > configure remain in the repository, so not sure why it was added to > .cvsignore again. > See archive title "mingwrt and w32api build system clean-up", it was intentionally added. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Chris S. <ir0...@gm...> - 2012-01-16 22:05:33
|
On 16 January 2012 17:01, Earnie Boyd wrote: > On Mon, Jan 16, 2012 at 3:46 PM, Chris Sutcliffe <ir0...@gm...> wrote: >> Hi Keith, >> >> Not sure if this was accidental or not, but Corinna requested that >> configure remain in the repository, so not sure why it was added to >> .cvsignore again. >> > > See archive title "mingwrt and w32api build system clean-up", it was > intentionally added. To which Corinna sent a personal email to Keith ccing myself and cgf asking that it not be put in the .cvsignore and removed the repository. She then reverted this change and checked it back in to CVS as apparently removing it broke the Cygwin build process. She also asked that intrusive changes like these be vetted with the Cygwin folks in the future. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Keith M. <kei...@us...> - 2012-01-17 03:24:42
|
On 16/01/12 22:05, Chris Sutcliffe wrote: >>> Not sure if this was accidental or not, but Corinna requested that >>> configure remain in the repository, so not sure why it was added to >>> .cvsignore again. It wasn't intentional. >> See archive title "mingwrt and w32api build system clean-up", it was >> intentionally added. > > To which Corinna sent a personal email to Keith ccing myself and cgf To which I intend to reply, (hopefully later today) > asking that it not be put in the .cvsignore and removed the > repository. Well, I think Corinna has made a terrible choice here -- and a heavy rod for your back, Chris; keeping generated files, such as configure, in any CMS is a right royal PITA. Corinna's reversion of my patch > confused my own CVS sandbox, to the extent that it believed configure existed BOTH as an untracked file polluting the workspace, and simultaneously as a tracked file, with a merge conflict. I don't agree with Corinna's decision, but I've no intention of becoming embroiled in a commit/revert war over the issue. I will assert, however, that if configure must remain in CVS -- hopefully as no more than a temporary measure -- then there MUST be only one nominated maintainer, with sole responsibility for regenerating and committing it as required; as package maintainer, I guess that would have to be you, Chris, and you'll need to keep a watching brief on the commit notifications, for configure.ac changes. To work around the conflicts, my local .cvsignore now looks like this: $ cat .cvsignore .hg .hgignore .hgtags .cvsignore configure autom4te.cache so I expected my last commit to leave the repository copies of both configure and .cvsignore itself untouched; I don't know why that intent wasn't honoured. > She then reverted this change and checked it back in to > CVS as apparently removing it broke the Cygwin build process. The cygwin build process is comprehensively FUBAR; it should be fixed. I'm more than willing to work with anyone who cares, to facilitate that. > She also asked that intrusive changes like these be vetted with the > Cygwin folks in the future. Well, Corinna and CGF are both more than welcome to participate in discussion HERE, where it matters; if they couldn't be bothered, then I consider their opinions to be irrelevant. AFAIAC, you are my liaison with the cygwin folks, Chris; both Earnie and Chuck said "go ahead", and, in line with your previous directive, I took your silence as agreement. -- Regards, Keith. |
From: Chris S. <ir0...@gm...> - 2012-01-17 12:33:05
|
Hi Keith, On 16 January 2012 22:24, Keith Marshall wrote: > On 16/01/12 22:05, Chris Sutcliffe wrote: >> asking that it not be put in the .cvsignore and removed the >> repository. > > Well, I think Corinna has made a terrible choice here -- and a heavy rod > for your back, Chris; keeping generated files, such as configure, in > any CMS is a right royal PITA. Corinna's reversion of my patch > > confused my own CVS sandbox, to the extent that it believed configure > existed BOTH as an untracked file polluting the workspace, and > simultaneously as a tracked file, with a merge conflict. > > I don't agree with Corinna's decision, but I've no intention of becoming > embroiled in a commit/revert war over the issue. I will assert, > however, that if configure must remain in CVS -- hopefully as no more > than a temporary measure -- then there MUST be only one nominated > maintainer, with sole responsibility for regenerating and committing it > as required; as package maintainer, I guess that would have to be you, > Chris, and you'll need to keep a watching brief on the commit > notifications, for configure.ac changes. Agreed, I accept the responsibility of making sure that configure is up to date. However, I would argue that if someone makes a change that requires configure to be regenerated, they would need to regenerate configure to make use of the change themselves. That being the case, is it unreasonable to expect them to check in the regenerated configure? >> She then reverted this change and checked it back in to >> CVS as apparently removing it broke the Cygwin build process. > > The cygwin build process is comprehensively FUBAR; it should be fixed. > I'm more than willing to work with anyone who cares, to facilitate that. It does seem less than ideal, and could likely do with an overhaul. >> She also asked that intrusive changes like these be vetted with the >> Cygwin folks in the future. > > Well, Corinna and CGF are both more than welcome to participate in > discussion HERE, where it matters; if they couldn't be bothered, then I > consider their opinions to be irrelevant. AFAIAC, you are my liaison > with the cygwin folks, Chris; both Earnie and Chuck said "go ahead", > and, in line with your previous directive, I took your silence as agreement. You were correct in taking my silence as acceptance. To be honest, I'm not fussed either way. I understand your preference for removing it and your reasoning for doing so, and I also understand Corinna's response (holds true to the "if it ain't broke don't fix it" mantra). I guess this is one of those issues that comes up when you have 2 projects with different sets of developers depending on the same core package. Since it seems that cgf no longer subscribes to this list and I don't thing Corinna ever did, the onus is on me to bridge the gap. I look forward to your response to Corinna, I may piggy back it and suggest that at least one of the two (cgf of Corinna) subscribe to the dvlpr list so that they are aware of these changes going forward. Chris -- Chris Sutcliffe http://emergedesktop.org http://www.google.com/profiles/ir0nh34d |
From: Earnie B. <ea...@us...> - 2012-01-17 14:39:22
|
On Tue, Jan 17, 2012 at 7:32 AM, Chris Sutcliffe wrote: > Hi Keith, > > On 16 January 2012 22:24, Keith Marshall wrote: >> On 16/01/12 22:05, Chris Sutcliffe wrote: >>> asking that it not be put in the .cvsignore and removed the >>> repository. >> >> Well, I think Corinna has made a terrible choice here -- and a heavy rod >> for your back, Chris; keeping generated files, such as configure, in >> any CMS is a right royal PITA. Corinna's reversion of my patch > >> confused my own CVS sandbox, to the extent that it believed configure >> existed BOTH as an untracked file polluting the workspace, and >> simultaneously as a tracked file, with a merge conflict. >> >> I don't agree with Corinna's decision, but I've no intention of becoming >> embroiled in a commit/revert war over the issue. I will assert, >> however, that if configure must remain in CVS -- hopefully as no more >> than a temporary measure -- then there MUST be only one nominated >> maintainer, with sole responsibility for regenerating and committing it >> as required; as package maintainer, I guess that would have to be you, >> Chris, and you'll need to keep a watching brief on the commit >> notifications, for configure.ac changes. > > Agreed, I accept the responsibility of making sure that configure is > up to date. However, I would argue that if someone makes a change > that requires configure to be regenerated, they would need to > regenerate configure to make use of the change themselves. That being > the case, is it unreasonable to expect them to check in the > regenerated configure? > I've seen time stamp issues between configure.ac and configure where configure.ac has a time stamp that is younger than configure so the Makefile will attempt to autoreconf to create a newer configure. You must be careful with the ordering of the commit if you want to use the stored version. >>> She then reverted this change and checked it back in to >>> CVS as apparently removing it broke the Cygwin build process. >> >> The cygwin build process is comprehensively FUBAR; it should be fixed. >> I'm more than willing to work with anyone who cares, to facilitate that. > > It does seem less than ideal, and could likely do with an overhaul. > >>> She also asked that intrusive changes like these be vetted with the >>> Cygwin folks in the future. >> >> Well, Corinna and CGF are both more than welcome to participate in >> discussion HERE, where it matters; if they couldn't be bothered, then I >> consider their opinions to be irrelevant. AFAIAC, you are my liaison >> with the cygwin folks, Chris; both Earnie and Chuck said "go ahead", >> and, in line with your previous directive, I took your silence as agreement. > > You were correct in taking my silence as acceptance. To be honest, > I'm not fussed either way. I understand your preference for removing > it and your reasoning for doing so, and I also understand Corinna's > response (holds true to the "if it ain't broke don't fix it" mantra). But it is broken when compared to standard methods. What needs to occur is the top level Makefile needs to execute autoreconf in each of the sub directories based on configure being a target and configure.ac being the source. > I guess this is one of those issues that comes up when you have 2 > projects with different sets of developers depending on the same core > package. Since it seems that cgf no longer subscribes to this list > and I don't thing Corinna ever did, the onus is on me to bridge the > gap. > But if "standard methods" are followed the two can coexist reasonably peacefully. It is when we have to remember not to follow "standard methods" that it becomes slightly less ideal. > I look forward to your response to Corinna, I may piggy back it and > suggest that at least one of the two (cgf of Corinna) subscribe to the > dvlpr list so that they are aware of these changes going forward. I believe both can respond to the mingw-dvlpr list without being subscribed. At least at one time I had made that exception for them. If one of the four of us can add that exception again. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-01-17 21:50:03
|
On 17/01/12 12:32, Chris Sutcliffe wrote: >> I will assert, >> however, that if configure must remain in CVS -- hopefully as no >> more than a temporary measure -- then there MUST be only one >> nominated maintainer, with sole responsibility for regenerating >> and committing it as required; as package maintainer, I guess >> that would have to be you, Chris, and you'll need to keep a >> watching brief on the commit notifications, for configure.ac >> changes. > > Agreed, I accept the responsibility of making sure that configure is > up to date. However, I would argue that if someone makes a change > that requires configure to be regenerated, they would need to > regenerate configure to make use of the change themselves. That being > the case, is it unreasonable to expect them to check in the > regenerated configure? Been there; done that; got the tee-shirt; don't want to go back. Why? This is a predominant reason why it's a really bad idea to keep a generated configure script in CVS: 50 to 100 lines of configure.ac + aclocal.m4 can easily blow up to 10, 20, even 30,000 lines of generated configure script, and it's very sensitive to even a one point change in patchlevel of the generating autoconf code. Two developers, with even only slightly different autoconf versions can oh so easily get into a recurring merge conflict. Believe me, you don't want to try to resolve such a conflict by hand editing. You may work around it by discarding your local copy, replacing with a clean check out, and regenerate, but the problem is likely to come back. It becomes frustrating. Best is to avoid the problem entirely, by not keeping the generated script in CVS at all; next best, (and a long way behind), is to have only one person exclusively manage commits for that troublesome script. > You were correct in taking my silence as acceptance. To be honest, > I'm not fussed either way. I understand your preference for removing > it and your reasoning for doing so, and I also understand Corinna's > response (holds true to the "if it ain't broke don't fix it" mantra). Normally, I would subscribe whole heartedly to this philosophy. On this occasion, however, "it ain't broke" doesn't apply. It *is* broke, and so badly broke that "don't fix it" simply isn't an option. We *must* fix it. -- Regards, Keith. |