* sourceware and git [not found] <239280260.18333755.1406652387203.JavaMail.zimbra@redhat.com> @ 2014-07-29 16:57 ` Jeff Johnston 2014-07-29 18:14 ` Joseph S. Myers 2014-07-29 18:28 ` Tom Tromey 0 siblings, 2 replies; 19+ messages in thread From: Jeff Johnston @ 2014-07-29 16:57 UTC (permalink / raw) To: overseers There have been some requests to put newlib into git. I was wondering if the overseers have recently looked into putting sourceware into git. I am also wondering how a piece of sourceware can be put into git without disrupting it. What steps were needed to move binutils and gdb over? Apparently, the gdb-cvs mailing list continues to work and I would like to have the same occur for our newlib-cvs list. Any insight to the process would be appreciated including issues found. -- Jeff J. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-29 16:57 ` sourceware and git Jeff Johnston @ 2014-07-29 18:14 ` Joseph S. Myers 2014-07-30 1:13 ` Christopher Faylor 2014-07-29 18:28 ` Tom Tromey 1 sibling, 1 reply; 19+ messages in thread From: Joseph S. Myers @ 2014-07-29 18:14 UTC (permalink / raw) To: Jeff Johnston; +Cc: overseers On Tue, 29 Jul 2014, Jeff Johnston wrote: > There have been some requests to put newlib into git. I was wondering if > the overseers have recently looked into putting sourceware into git. > > I am also wondering how a piece of sourceware can be put into git > without disrupting it. What steps were needed to move binutils and gdb > over? Apparently, the gdb-cvs mailing list continues to work and I > would like to have the same occur for our newlib-cvs list. Any insight > to the process would be appreciated including issues found. The basic rule for moving pieces of src CVS is that you move just a logical project rather than a group of unrelated projects. I.e., if you want to move newlib to git, just move newlib (the directories and toplevel files that are used in a newlib build) rather than the whole repository. Then src CVS can be made readonly as I don't think any of the other projects have any significant activity. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-29 18:14 ` Joseph S. Myers @ 2014-07-30 1:13 ` Christopher Faylor 2014-07-30 7:48 ` Corinna Vinschen 2014-07-30 17:02 ` Joseph S. Myers 0 siblings, 2 replies; 19+ messages in thread From: Christopher Faylor @ 2014-07-30 1:13 UTC (permalink / raw) To: Jeff Johnston, Joseph S. Myers, overseers On Tue, Jul 29, 2014 at 06:14:30PM +0000, Joseph S. Myers wrote: >On Tue, 29 Jul 2014, Jeff Johnston wrote: > >> There have been some requests to put newlib into git. I was wondering if >> the overseers have recently looked into putting sourceware into git. >> >> I am also wondering how a piece of sourceware can be put into git >> without disrupting it. What steps were needed to move binutils and gdb >> over? Apparently, the gdb-cvs mailing list continues to work and I >> would like to have the same occur for our newlib-cvs list. Any insight >> to the process would be appreciated including issues found. > >The basic rule for moving pieces of src CVS is that you move just a >logical project rather than a group of unrelated projects. I.e., if you >want to move newlib to git, just move newlib (the directories and toplevel >files that are used in a newlib build) rather than the whole repository. >Then src CVS can be made readonly as I don't think any of the other >projects have any significant activity. I've been trying to convince Jeff and Corinna that the top-level stuff isn't really needed for newlib. I already have cygwin available as a self-contained git module which doesn't use the top-level configury but which can still be dropped into the standard tree along with gdb, gcc, binutils, and newlib. But, you can also just check cygwin out via, e.g., git clone ssh:sourceware.org/cygwin.git /usr/src/cygwin and start building from that source directory, as long as you point it to a version of newlib. I was thinking that newlib could do the same. Since cygwin needs newlib, I think that this means that cygwin could import newlib as a submodule if it needed it. The other proposal is to keep newlib and cygwin in one git project. That more or less keeps the status quo for newlib and cygwin but it means that people who use newlib without cygwin will have extra Windows-specific code that they don't care about. And, I think it would be nice to use the power of git to allow a logical separation between the two projects. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 1:13 ` Christopher Faylor @ 2014-07-30 7:48 ` Corinna Vinschen 2014-07-30 15:18 ` Christopher Faylor 2014-07-30 17:02 ` Joseph S. Myers 1 sibling, 1 reply; 19+ messages in thread From: Corinna Vinschen @ 2014-07-30 7:48 UTC (permalink / raw) To: Jeff Johnston, Joseph S. Myers, overseers [-- Attachment #1: Type: text/plain, Size: 2842 bytes --] On Jul 29 21:13, Christopher Faylor wrote: > On Tue, Jul 29, 2014 at 06:14:30PM +0000, Joseph S. Myers wrote: > >On Tue, 29 Jul 2014, Jeff Johnston wrote: > > > >> There have been some requests to put newlib into git. I was wondering if > >> the overseers have recently looked into putting sourceware into git. > >> > >> I am also wondering how a piece of sourceware can be put into git > >> without disrupting it. What steps were needed to move binutils and gdb > >> over? Apparently, the gdb-cvs mailing list continues to work and I > >> would like to have the same occur for our newlib-cvs list. Any insight > >> to the process would be appreciated including issues found. > > > >The basic rule for moving pieces of src CVS is that you move just a > >logical project rather than a group of unrelated projects. I.e., if you > >want to move newlib to git, just move newlib (the directories and toplevel > >files that are used in a newlib build) rather than the whole repository. > >Then src CVS can be made readonly as I don't think any of the other > >projects have any significant activity. > > I've been trying to convince Jeff and Corinna that the top-level stuff > isn't really needed for newlib. > > I already have cygwin available as a self-contained git module which > doesn't use the top-level configury but which can still be dropped into > the standard tree along with gdb, gcc, binutils, and newlib. But, you > can also just check cygwin out via, e.g., > git clone ssh:sourceware.org/cygwin.git /usr/src/cygwin > and start building from that source directory, as long as you point it > to a version of newlib. I was thinking that newlib could do the same. > > Since cygwin needs newlib, I think that this means that cygwin could > import newlib as a submodule if it needed it. The other proposal is to > keep newlib and cygwin in one git project. That more or less keeps the > status quo for newlib and cygwin but it means that people who use newlib > without cygwin will have extra Windows-specific code that they don't > care about. And vice versa, since libgloss is part of the newlib module, but not part of Cygwin. > And, I think it would be nice to use the power of git to > allow a logical separation between the two projects. I don't really care for the toplevel stuff, but what I would like to see is that both projects, newlib as well as Cygwin, can be checked out, updated, branched, tagged, etc, in a single operation, just as before. So git clone http://sourceware.org/cygwin.git should check out cygwin + newlib (as submodule?) and git clone http://sourceware.org/newlib.git should check out newlib + libgloss (as submodule?). Is that possible with git? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 7:48 ` Corinna Vinschen @ 2014-07-30 15:18 ` Christopher Faylor 2014-07-30 15:39 ` Corinna Vinschen 2014-07-30 17:27 ` Hans-Peter Nilsson 0 siblings, 2 replies; 19+ messages in thread From: Christopher Faylor @ 2014-07-30 15:18 UTC (permalink / raw) To: Jeff Johnston, overseers, Joseph S. Myers On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote: >On Jul 29 21:13, Christopher Faylor wrote: >> And, I think it would be nice to use the power of git to >> allow a logical separation between the two projects. > >I don't really care for the toplevel stuff, but what I would like to see >is that both projects, newlib as well as Cygwin, can be checked out, >updated, branched, tagged, etc, in a single operation, just as before. >So > > git clone http://sourceware.org/cygwin.git > >should check out cygwin + newlib (as submodule?) and > > git clone http://sourceware.org/newlib.git > >should check out newlib + libgloss (as submodule?). > >Is that possible with git? If git can't automatically check out newlib as a submodule then we could just include a 'tag' script somewhere in cygwin. You're going to have to learn a new command to tag things anyway so if it's "git tag" or "./tag-cygwin-newlib" it shouldn't be that big a deal. cgf ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 15:18 ` Christopher Faylor @ 2014-07-30 15:39 ` Corinna Vinschen 2014-07-30 17:06 ` Joseph S. Myers 2014-07-30 17:27 ` Hans-Peter Nilsson 1 sibling, 1 reply; 19+ messages in thread From: Corinna Vinschen @ 2014-07-30 15:39 UTC (permalink / raw) To: overseers; +Cc: Jeff Johnston, Joseph S. Myers [-- Attachment #1: Type: text/plain, Size: 1949 bytes --] On Jul 30 11:18, Christopher Faylor wrote: > On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote: > >On Jul 29 21:13, Christopher Faylor wrote: > >> And, I think it would be nice to use the power of git to > >> allow a logical separation between the two projects. > > > >I don't really care for the toplevel stuff, but what I would like to see > >is that both projects, newlib as well as Cygwin, can be checked out, > >updated, branched, tagged, etc, in a single operation, just as before. > >So > > > > git clone http://sourceware.org/cygwin.git > > > >should check out cygwin + newlib (as submodule?) and > > > > git clone http://sourceware.org/newlib.git > > > >should check out newlib + libgloss (as submodule?). > > > >Is that possible with git? > > If git can't automatically check out newlib as a submodule then we could > just include a 'tag' script somewhere in cygwin. You're going to have > to learn a new command to tag things anyway so if it's "git tag" or > "./tag-cygwin-newlib" it shouldn't be that big a deal. But it's not just that, it's about all bulk commands. You don't really want to create scripts for all these git actions just because git doesn't handle them, do you? What advantage has git if it doesn't allow to define stuff which was naturally under CVS. Moving to git is supposed to be progress and not a step back in the usage pattern. What about libgloss? If libgloss is an inherent part of the newlib git repo, a checkout of a newlib submodule would also pull in libgloss. Do we want to keep it or do we want to remove it post-clone? I'm concerned about creating the source packages as part of the distro packaging. A source checkout of Cygwin should checkout all sources and not only via some configure statement or by running another post-clone script. Am I really asking too much? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 15:39 ` Corinna Vinschen @ 2014-07-30 17:06 ` Joseph S. Myers 0 siblings, 0 replies; 19+ messages in thread From: Joseph S. Myers @ 2014-07-30 17:06 UTC (permalink / raw) To: Corinna Vinschen; +Cc: overseers, Jeff Johnston On Wed, 30 Jul 2014, Corinna Vinschen wrote: > But it's not just that, it's about all bulk commands. You don't really > want to create scripts for all these git actions just because git > doesn't handle them, do you? What advantage has git if it doesn't allow > to define stuff which was naturally under CVS. Moving to git is supposed > to be progress and not a step back in the usage pattern. Indeed. It's best if all operations work in their natural, native git ways, which may mean avoiding submodules. > What about libgloss? If libgloss is an inherent part of the newlib git > repo, a checkout of a newlib submodule would also pull in libgloss. Do > we want to keep it or do we want to remove it post-clone? I'm concerned > about creating the source packages as part of the distro packaging. A > source checkout of Cygwin should checkout all sources and not only via > some configure statement or by running another post-clone script. I'd say have all of libgloss, newlib, Cygwin in one repository - the irrelevant parts can always be removed on release branches of each component if you want, or people can simply use --disable-<dir> options as needed like they do for binutils-gdb checkouts. A practical mostly self-contained repository for those three (followed by making src CVS readonly) seems better and easier to achieve and use than some sort of theoretical purity. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 15:18 ` Christopher Faylor 2014-07-30 15:39 ` Corinna Vinschen @ 2014-07-30 17:27 ` Hans-Peter Nilsson 1 sibling, 0 replies; 19+ messages in thread From: Hans-Peter Nilsson @ 2014-07-30 17:27 UTC (permalink / raw) To: Christopher Faylor; +Cc: Jeff Johnston, overseers, Joseph S. Myers On Wed, 30 Jul 2014, Christopher Faylor wrote: > On Wed, Jul 30, 2014 at 09:47:58AM +0200, Corinna Vinschen wrote: > > git clone http://sourceware.org/cygwin.git > > > >should check out cygwin + newlib (as submodule?) and > > > > git clone http://sourceware.org/newlib.git > > > >should check out newlib + libgloss (as submodule?). > > > >Is that possible with git? (A subsequent command is needed with git submodules, which I see have no supporters here, so I'll refrain from saying "git submodule update --init --recursive" ...oops. :) > If git can't automatically check out newlib as a submodule then we could > just include a 'tag' script somewhere in cygwin. You're going to have > to learn a new command to tag things anyway so if it's "git tag" or > "./tag-cygwin-newlib" it shouldn't be that big a deal. It seems natural to amend the top-level src-release makefile with targets newlib.tar.bz2 and cygwin.tar.bz2, similar to sim, binutils and gdb that were at one time CVS modules (with the obvious caveat of no-longer-shared toplevel files). You'd have the git-checkout containing everything, but at least you can create official-release-type and snapshot tar-balls with the expected contents. brgds, H-P ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 1:13 ` Christopher Faylor 2014-07-30 7:48 ` Corinna Vinschen @ 2014-07-30 17:02 ` Joseph S. Myers 2014-07-30 18:45 ` Christopher Faylor 1 sibling, 1 reply; 19+ messages in thread From: Joseph S. Myers @ 2014-07-30 17:02 UTC (permalink / raw) To: overseers; +Cc: Jeff Johnston On Tue, 29 Jul 2014, Christopher Faylor wrote: > I've been trying to convince Jeff and Corinna that the top-level stuff > isn't really needed for newlib. It's needed as the way that newlib gets configured for the right set of multilibs, to be installed in the right directories! > Since cygwin needs newlib, I think that this means that cygwin could > import newlib as a submodule if it needed it. The other proposal is to > keep newlib and cygwin in one git project. That more or less keeps the > status quo for newlib and cygwin but it means that people who use newlib > without cygwin will have extra Windows-specific code that they don't > care about. And, I think it would be nice to use the power of git to > allow a logical separation between the two projects. I think having them in one git project (that includes libgloss and the relevant toplevel) would be fine. I'm generally dubious of things such as submodules; I think basic requirements include: checking out with git:// gets a git:// checkout of everything; checking out with git+ssh:// gets a git+ssh:// checkout of everything; pulling automatically pulls changes to everything; branching, tagging etc. (and pushing those branches or tags) automatically branches, tags etc. everything. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 17:02 ` Joseph S. Myers @ 2014-07-30 18:45 ` Christopher Faylor 2014-07-30 20:57 ` Joseph S. Myers 0 siblings, 1 reply; 19+ messages in thread From: Christopher Faylor @ 2014-07-30 18:45 UTC (permalink / raw) To: Jeff Johnston, overseers, Joseph S. Myers On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote: >I think having them in one git project (that includes libgloss and the >relevant toplevel) would be fine. I'm generally dubious of things such as >submodules; Your dubiousity doesn't have any bearing if it isn't backed up by facts. If submodules can't be made to work transparently then that is an argument for why they might not be used. A fear of submodules doesn't translate into rejecting the concept. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 18:45 ` Christopher Faylor @ 2014-07-30 20:57 ` Joseph S. Myers 2014-07-30 21:33 ` Christopher Faylor 0 siblings, 1 reply; 19+ messages in thread From: Joseph S. Myers @ 2014-07-30 20:57 UTC (permalink / raw) To: Jeff Johnston; +Cc: overseers On Wed, 30 Jul 2014, Christopher Faylor wrote: > On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote: > >I think having them in one git project (that includes libgloss and the > >relevant toplevel) would be fine. I'm generally dubious of things such as > >submodules; > > Your dubiousity doesn't have any bearing if it isn't backed up by facts. It's backed up by the list of requirements I gave for git to work smoothly in the presence of submodules as if there were a single repository, none of which (according to the git-submodule manpage) git submodules meet. We have many years' experience of the src repository being problematic because of the use of a special feature of CVS (modules files for partial checkouts of a directory in the repository) that doesn't work well with other features of CVS (cvs update -d; the interaction of modules file changes with tagging and branching). That also provides a basis for caution about such features in other version control systems, and for preferring an ordinary git repository whose clones work with ordinary git commands just like those commands work with clones of any other random git repository. -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 20:57 ` Joseph S. Myers @ 2014-07-30 21:33 ` Christopher Faylor 2014-07-30 21:47 ` Joseph S. Myers 2014-07-30 23:41 ` Yaakov Selkowitz 0 siblings, 2 replies; 19+ messages in thread From: Christopher Faylor @ 2014-07-30 21:33 UTC (permalink / raw) To: Joseph S. Myers, overseers, Jeff Johnston On Wed, Jul 30, 2014 at 08:57:20PM +0000, Joseph S. Myers wrote: >On Wed, 30 Jul 2014, Christopher Faylor wrote: > >> On Wed, Jul 30, 2014 at 05:02:47PM +0000, Joseph S. Myers wrote: >> >I think having them in one git project (that includes libgloss and the >> >relevant toplevel) would be fine. I'm generally dubious of things such as >> >submodules; >> >> Your dubiousity doesn't have any bearing if it isn't backed up by facts. > >It's backed up by the list of requirements I gave for git to work smoothly >in the presence of submodules as if there were a single repository, none >of which (according to the git-submodule manpage) git submodules meet. You mentioned that you were dubious of "things such as submodules" which sounds a lot like an unreasoning prejudice rather than an informed opinion. And, you specified a list of what you think is needed but didn't back it up with "...and here's why submodules won't work". From what I've read on the internet it is possible to make a lot (if not all) of the submodule stuff happen automatically. But, even if it wasn't we're talking about Cygwin here which I'm willing to bet is not something that you even have occasion to build. >We have many years' experience of the src repository being problematic >because of the use of a special feature of CVS (modules files for >partial checkouts of a directory in the repository) that doesn't work >well with other features of CVS (cvs update -d; the interaction of >modules file changes with tagging and branching). That also provides a >basis for caution about such features in other version control systems, >and for preferring an ordinary git repository whose clones work with >ordinary git commands just like those commands work with clones of any >other random git repository. Hopefully you aren't trying to one-up me on "devo" experience. You're overplaying the problems with CVS modules but since git is obviously intended to be several orders of magnitude improvement over CVS (which is the point of converting) there is no reason to automaticaly avoid something called a "module" in git because you didn't like how CVS implemented them. CVS also had pecularities with branching and tagging but we're still talking about branching and tagging in git. As far as tagging is concerned, I don't see any reason why newlib should be tagged when cygwin is tagged. Cygwin shouldn't care about newlib tags. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 21:33 ` Christopher Faylor @ 2014-07-30 21:47 ` Joseph S. Myers 2014-07-30 23:41 ` Yaakov Selkowitz 1 sibling, 0 replies; 19+ messages in thread From: Joseph S. Myers @ 2014-07-30 21:47 UTC (permalink / raw) To: overseers; +Cc: Jeff Johnston On Wed, 30 Jul 2014, Christopher Faylor wrote: > >From what I've read on the internet it is possible to make a lot (if not > all) of the submodule stuff happen automatically. But, even if it > wasn't we're talking about Cygwin here which I'm willing to bet is not > something that you even have occasion to build. I'm concerned with newlib checkouts working smoothly (and consider newlib to include libgloss and the associated toplevel build support, toplevel config/ directory which has settings that affect newlib, etc.). I'm not concerned with what Cygwin does. If you have an approach that treats Cygwin as a completely separate project, so that a git clone of newlib gets newlib / libgloss / toplevel (all the files and directories that go in newlib release tarballs, basically) but not Cygwin, and normal git operations work normally in that clone, I'm not concerned with what sequence of commands may be needed to generate and use a Cygwin checkout if the sequence in question works for the Cygwin community. In principle I believe independent projects should be free to make their independent choices as far as possible - including choosing completely different version control systems if you want. So, I think separating newlib and libgloss, or newlib and toplevel, into separate repositories, and then trying to stitch them together, would be a bad idea - libgloss is part of newlib and the toplevel build is essentially tied to the subdirectories. But separating Cygwin from (newlib + libgloss + relevant toplevel) is a matter of what works for Cygwin people. > CVS (which is the point of converting) there is no reason to > automaticaly avoid something called a "module" in git because you didn't > like how CVS implemented them. It's nothing to do with the name - it's a common issue with both features (that if you use them, various operations no longer work as smoothly as if you don't). -- Joseph S. Myers joseph@codesourcery.com ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 21:33 ` Christopher Faylor 2014-07-30 21:47 ` Joseph S. Myers @ 2014-07-30 23:41 ` Yaakov Selkowitz 2014-07-31 2:22 ` Christopher Faylor 1 sibling, 1 reply; 19+ messages in thread From: Yaakov Selkowitz @ 2014-07-30 23:41 UTC (permalink / raw) To: overseers On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote: > As far as tagging is concerned, I don't see any reason why newlib > should be tagged when cygwin is tagged. Cygwin shouldn't care about > newlib tags. What I don't understand yet is why our situation is different than binutils-gdb, the two of which also have separate release schedules and yet share enough code that they chose to use a single repository. Given that, IIUC: * newlib and libgloss are developed in tandem; * newlib and libgloss are meant to be built together; * newlib and libgloss require the top-level configury in order to build; then wouldn't the most straightforward (and reliable) method for newlib/libgloss be to have a single git repo matching the layout of cvs co newlib? As for cygwin's usage of newlib, since pulling in newlib would end up including libgloss and the top level configury, the only difference I see between a joint newlib/libgloss/cygwin repo and a separate cygwin repo would be that the former would not require any changes to the cygwin build system, where the latter would. Either way, yes, a cygwin checkout (or source tarball) would be somewhat larger then it is now by virtue of the addition of libgloss to the checkout. (The top-level configury already skips building libgloss for cygwin even when present.) If the newlib folks don't mind the same (although winsup is smaller than libgloss, so it's not quite an equal tradeoff :-) ), then following the lead of binutils-gdb and using a single repository makes a lot of sense to me. Yaakov ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-30 23:41 ` Yaakov Selkowitz @ 2014-07-31 2:22 ` Christopher Faylor 2014-08-01 11:05 ` Corinna Vinschen 0 siblings, 1 reply; 19+ messages in thread From: Christopher Faylor @ 2014-07-31 2:22 UTC (permalink / raw) To: Yaakov Selkowitz, overseers On Wed, Jul 30, 2014 at 06:41:25PM -0500, Yaakov Selkowitz wrote: >On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote: >> As far as tagging is concerned, I don't see any reason why newlib >> should be tagged when cygwin is tagged. Cygwin shouldn't care about >> newlib tags. > >What I don't understand yet is why our situation is different than >binutils-gdb, the two of which also have separate release schedules and >yet share enough code that they chose to use a single repository. Given >that, IIUC: I don't care about newlib/libgloss. The need for libgloss is enough for me to withdraw that newlib should be standalone. The difference here is that I'm involved with cygwin. I didn't care about binutils+gdb so I didn't weigh in. I'm weighing in now. >* newlib and libgloss are developed in tandem; > >* newlib and libgloss are meant to be built together; > >* newlib and libgloss require the top-level configury in order to build; > >then wouldn't the most straightforward (and reliable) method for >newlib/libgloss be to have a single git repo matching the layout of cvs >co newlib? > >As for cygwin's usage of newlib, since pulling in newlib would end up >including libgloss and the top level configury, the only difference I >see between a joint newlib/libgloss/cygwin repo and a separate cygwin >repo would be that the former would not require any changes to the >cygwin build system, where the latter would. I have already made the changes for cygwin. Is this not sinking in somehow? I was trying to make cygwin like most other GNU projects out there, unencumbered by decades of top-level build accretion, relying on only one other library, similar to the way other projects do it. Anyway, nevermind. I see that I'm in the minority. My changes and git repository are withdrawn. Do what you like. cgf ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-31 2:22 ` Christopher Faylor @ 2014-08-01 11:05 ` Corinna Vinschen 2014-08-01 22:54 ` Frank Ch. Eigler 0 siblings, 1 reply; 19+ messages in thread From: Corinna Vinschen @ 2014-08-01 11:05 UTC (permalink / raw) To: overseers [-- Attachment #1: Type: text/plain, Size: 2414 bytes --] On Jul 30 22:22, Christopher Faylor wrote: > On Wed, Jul 30, 2014 at 06:41:25PM -0500, Yaakov Selkowitz wrote: > >On Wed, 2014-07-30 at 17:33 -0400, Christopher Faylor wrote: > >> As far as tagging is concerned, I don't see any reason why newlib > >> should be tagged when cygwin is tagged. Cygwin shouldn't care about > >> newlib tags. > > > >What I don't understand yet is why our situation is different than > >binutils-gdb, the two of which also have separate release schedules and > >yet share enough code that they chose to use a single repository. Given > >that, IIUC: > > I don't care about newlib/libgloss. The need for libgloss is enough for > me to withdraw that newlib should be standalone. > > The difference here is that I'm involved with cygwin. I didn't care > about binutils+gdb so I didn't weigh in. I'm weighing in now. > > >* newlib and libgloss are developed in tandem; > > > >* newlib and libgloss are meant to be built together; > > > >* newlib and libgloss require the top-level configury in order to build; > > > >then wouldn't the most straightforward (and reliable) method for > >newlib/libgloss be to have a single git repo matching the layout of cvs > >co newlib? > > > >As for cygwin's usage of newlib, since pulling in newlib would end up > >including libgloss and the top level configury, the only difference I > >see between a joint newlib/libgloss/cygwin repo and a separate cygwin > >repo would be that the former would not require any changes to the > >cygwin build system, where the latter would. > > I have already made the changes for cygwin. Is this not sinking in > somehow? I was trying to make cygwin like most other GNU projects out > there, unencumbered by decades of top-level build accretion, relying on > only one other library, similar to the way other projects do it. > > Anyway, nevermind. I see that I'm in the minority. My changes and git > repository are withdrawn. Do what you like. Hmm, that wasn't exactly what I was looking for. I was just trying to make sure that the git repo for Cygwin contains all of Cygwin, and that includes newlib. It's not just an external library, it's an inherent part of Cygwin. You can't build Cygwin without newlib and you can't build a standalone newlib for Cygwin without the Cygwin sources. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-08-01 11:05 ` Corinna Vinschen @ 2014-08-01 22:54 ` Frank Ch. Eigler 2014-08-02 0:12 ` Yaakov Selkowitz 0 siblings, 1 reply; 19+ messages in thread From: Frank Ch. Eigler @ 2014-08-01 22:54 UTC (permalink / raw) To: overseers Hi - On Fri, Aug 01, 2014 at 01:05:18PM +0200, Corinna Vinschen wrote: > [...] I was just trying to make sure that the git repo for Cygwin > contains all of Cygwin, and that includes newlib. It's not just an > external library, it's an inherent part of Cygwin. Well, not in the usual sense of "part of". > You can't build Cygwin without newlib That sounds like any normal dependency. > and you can't build a standalone newlib for Cygwin without the > Cygwin sources. That sounds like a possible packaging/bootstrapping detail, not an "is-part-of" relationship. (Consider glibc vs. linux-kernel, or gcc vs. glibc, etc.) Rather than focus on the building dependency aspects though, consider focusing on actual project operation / community. Are newlib/libgloss is maintained/released by a different group of people on a different schedule than cygwin? - FChE ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-08-01 22:54 ` Frank Ch. Eigler @ 2014-08-02 0:12 ` Yaakov Selkowitz 0 siblings, 0 replies; 19+ messages in thread From: Yaakov Selkowitz @ 2014-08-02 0:12 UTC (permalink / raw) To: overseers On Fri, 2014-08-01 at 18:54 -0400, Frank Ch. Eigler wrote: > Rather than focus on the building dependency aspects though, consider > focusing on actual project operation / community. Are newlib/libgloss > is maintained/released by a different group of people on a different > schedule than cygwin? There is some overlap (namely Corinna), but mostly we are separate groups and the release schedule is definitely separate. But that too we have in common with binutils-gdb communities, yet the technical aspects obviously brought them to decide upon a single joint repository. I guess the question now is, are there any objections from the newlib/libgloss folks in doing the same? Yaakov ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: sourceware and git 2014-07-29 16:57 ` sourceware and git Jeff Johnston 2014-07-29 18:14 ` Joseph S. Myers @ 2014-07-29 18:28 ` Tom Tromey 1 sibling, 0 replies; 19+ messages in thread From: Tom Tromey @ 2014-07-29 18:28 UTC (permalink / raw) To: Jeff Johnston; +Cc: overseers Jeff> What steps were needed to move binutils and gdb over? The binutils-gdb move was very complicated, primarily because there were multiple repositories to stitch together, but relatedly because the original imports to sourceware were done inconsistently. The steps I followed are documented in the README.md here (just scroll down): https://github.com/tromey/gdb-git-migration All the scripts are there. If you want to reuse them, just fork the project and hack them up to do what you like. Jeff> Apparently, the gdb-cvs mailing list continues to work and I would Jeff> like to have the same occur for our newlib-cvs list. The mail hook stuff is already on sourceware but you can follow copies in the "finalize-git-repo" script to see how it is configured. "src-email" shows how this is done, though your setup may be simpler if you just have a single commits list. Tom ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2014-08-02 0:12 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <239280260.18333755.1406652387203.JavaMail.zimbra@redhat.com> 2014-07-29 16:57 ` sourceware and git Jeff Johnston 2014-07-29 18:14 ` Joseph S. Myers 2014-07-30 1:13 ` Christopher Faylor 2014-07-30 7:48 ` Corinna Vinschen 2014-07-30 15:18 ` Christopher Faylor 2014-07-30 15:39 ` Corinna Vinschen 2014-07-30 17:06 ` Joseph S. Myers 2014-07-30 17:27 ` Hans-Peter Nilsson 2014-07-30 17:02 ` Joseph S. Myers 2014-07-30 18:45 ` Christopher Faylor 2014-07-30 20:57 ` Joseph S. Myers 2014-07-30 21:33 ` Christopher Faylor 2014-07-30 21:47 ` Joseph S. Myers 2014-07-30 23:41 ` Yaakov Selkowitz 2014-07-31 2:22 ` Christopher Faylor 2014-08-01 11:05 ` Corinna Vinschen 2014-08-01 22:54 ` Frank Ch. Eigler 2014-08-02 0:12 ` Yaakov Selkowitz 2014-07-29 18:28 ` Tom Tromey
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).