From: Earnie B. <ear...@ya...> - 2003-05-21 11:00:20
|
I understand why we don't want to have a GCC CVS Repository apart from the main GCC CVS Repository. However, is it possible to have a branch in the GCC CVS that all MinGW compiler developers can use to sandbox? If the answer is no, shouldn't we allow for a CVS sandbox here? That way each individual sandbox can update the CVS sandobx on a regular basis and allow for mutual collaberation as CVS was meant to be used for. The daily changes could be committed to the sandbox and everyone stays current. I see binutils benefitting from this method as well. The way I would like this sandbox to be structured is: 1) Import the Official CVS version. 2) Create a sandbox branch 3) Periodically update the Official CVS version with Official changes 4) Merge those changes to the sandbox. Pros? Cons? Earnie. |
From: Danny S. <dan...@cl...> - 2003-05-21 21:29:13
|
----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Wednesday, 21 May 2003 12:00 Subject: [MinGW-dvlpr] GCC Cvs - MinGW branch > I understand why we don't want to have a GCC CVS Repository apart from > the main GCC CVS Repository. However, is it possible to have a branch > in the GCC CVS that all MinGW compiler developers can use to sandbox? > If the answer is no, shouldn't we allow for a CVS sandbox here? That > way each individual sandbox can update the CVS sandobx on a regular > basis and allow for mutual collaberation as CVS was meant to be used > for. The daily changes could be committed to the sandbox and everyone > stays current. I see binutils benefitting from this method as well. > > The way I would like this sandbox to be structured is: > > 1) Import the Official CVS version. > 2) Create a sandbox branch > 3) Periodically update the Official CVS version with Official changes > 4) Merge those changes to the sandbox. > > Pros? > > Cons? If your volunteering to do the maintenance? Wouldn't you like mingw changes to be in sync with cygwin too? FSF is the best place for this kind of thing. Chris has tried it. Ask him if it is worth it. Not having a local branch forces us to make every effort to get our patches committed and forces other interested folk to download, test and hopefully patch official sources. That is a good thing. Danny > > Earnie. > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Mohan E. <gnu...@th...> - 2003-05-22 01:26:16
|
Hi All, >Not having a local branch forces us to make every effort to get our >patches committed and forces other interested folk to download, test and >hopefully patch official sources. That is a good thing. I tend to agree with Danny, although it would be nice if we could track the differences in some other way, like a master list or perhaps some way of automatically generating a global patchset. -- Mohan |
From: Christopher F. <cg...@re...> - 2003-05-25 16:18:17
|
[sorry for the delay in responding. I'm at the gcc conference] On Wed, May 21, 2003 at 10:30:17PM +0100, Danny Smith wrote: >If your volunteering to do the maintenance? Wouldn't you like mingw >changes to be in sync with cygwin too? > >FSF is the best place for this kind of thing. Chris has tried it. Ask >him if it is worth it. Except for the maintenance aspect, I think it is well worth having the source code in cvs, just for the code sharing aspect. It cuts down on the "Danny, could you send me your latest patches" aspect of maintenance. I was just merging changes to the official release to the branch on a regular basis. But then I got busy with other things. It's not *that* big a deal to keep things merged. You just have to be rigorous in how you do it. >Not having a local branch forces us to make every effort to get our >patches committed and forces other interested folk to download, test and >hopefully patch official sources. That is a good thing. I don't think having the branch affects the possibility of eventually getting things into the trunk. It would be nice to have a champion who was willing to do the pinging required to get patches into the sources. I can and will approve patches in the limited parts of the code that I maintain but changes are needed in parts of the code that need global maintainer approval. That means jumping up and down in front of busy maintainers to get their attention. cgf |
From: Paul G. <pga...@at...> - 2003-05-26 02:30:19
|
> [sorry for the delay in responding. I'm at the gcc conference] > On Wed, May 21, 2003 at 10:30:17PM +0100, Danny Smith wrote: > >If your volunteering to do the maintenance? Wouldn't you like mingw > >changes to be in sync with cygwin too? > > > >FSF is the best place for this kind of thing. Chris has tried it. > >Ask him if it is worth it. > > Except for the maintenance aspect, I think it is well worth having the > source code in cvs, just for the code sharing aspect. It cuts down on > the "Danny, could you send me your latest patches" aspect of > maintenance. Personal experience, I have attempted to find the Mingw specific modifications to gcc (FSF) on a number of ocassions, only to be discouraged by the sheer number of variations which do not even remotely, in some cases, come close to the Mingw specific variations of GCC. That , of course, is before even being able to consider all of the most recent patches that must be added to the existing FSF cvs (updates) in order to obtain what I define as a "reasonable snapshot" of GCC - Mingw. It was, and, without an official Mingw Branch remains, frustrating. Paul G. |