From: Danny S. <dan...@cl...> - 2007-02-02 09:15:27
|
> Before we do that we should discuss a standard. > > GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > binutils package with releases of 2.16.91, 2.15.91, 2.13.90 I like this better, but I don't know the best way of indicating status. Perhaps a file named, say, hint in each release with a line like: Status: Current Or incorporate the status into the release name like gcc-3.4.2 (Current) while snapshots retain date in the release name, as per usual gcc-4.2.0-20070202-1 convention. I can take care of the migration of GCC and binutils but I can't guarantee it will happen before May, 2007 :{ Danny |
From: Danny S. <dan...@cl...> - 2007-01-31 17:40:18
|
> > >Comment By: Jeremy Fincher (fincher) > Date: 2007-01-29 16:46 > > Message: > Logged In: YES > user_id=1019020 > Originator: NO > > Greetings, > > Unfortunately, what you're asking for is not possible. The issue, > however, exists because you're not using the File Release > System (FRS) as > intended. Each "release" that you currently have should be a > "package," > and different versions (current, candidate, etc.) should be a > "release" > for its particular package. The above organization of packages makes more sense to me than our current usage. I suggest we use the FRS as intended. Danny > > SourceForge.net Support > ------------------------------------------------------------------------ - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE V _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ea...@us...> - 2007-01-31 23:45:35
|
Quoting Danny Smith <dan...@cl...>: > I suggest we use the FRS as intended. I agree. Luke agrees. So now who wants to volunteer to move the FRS data around? We don't need to reupload just move the packages from one place to another. Before we do that we should discuss a standard. GCC package with releases of Current, Candidate, Snapshot and Previous binutils package with releases of Current, Candidate, Snapshot and Previous or GCC package with releases of 3.4.2, 3.3.1, 3.2.3 binutils package with releases of 2.16.91, 2.15.91, 2.13.90 Earnie Boyd -- Please post responsibly: * Use text posts instead of html; many list members just trash mail with html. * Do not use multipart mime to send both text and html versions. * Do not top post replies; post inline with the parts you are responding to. * Trim the post replies; remove irrelevant information from the quoted article. * Original posters: ** Provide small complete examples of the problem. ** Provide the full command that produced errors. ** Provide the versions of the software used. |
From: Julien L. <ju...@fa...> - 2007-02-01 12:32:16
|
Earnie Boyd wrote: > We don't need to reupload just move the packages from one place to > another. Before we do that we should discuss a standard. > > GCC package with releases of Current, Candidate, Snapshot and Previous > binutils package with releases of Current, Candidate, Snapshot and Previous > > or > > GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > binutils package with releases of 2.16.91, 2.15.91, 2.13.90 I vote for the second: when a package gets updated from current to previous, someone will have to do the change (at least renaming for example), with the second proposition, there's no need for extra maintaining. Maybe we could also trim down the choice of packages: there's over 10 choices of 'MinGW Runtime' for example, 5 would probably be more than enough. Julien |
From: Earnie B. <ea...@us...> - 2007-02-01 15:00:04
|
Quoting Julien Lecomte <ju...@fa...>: > Earnie Boyd wrote: >> We don't need to reupload just move the packages from one place to >> another. Before we do that we should discuss a standard. >> >> GCC package with releases of Current, Candidate, Snapshot and Previous >> binutils package with releases of Current, Candidate, Snapshot and Previous >> >> or >> >> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 >> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 > > I vote for the second: when a package gets updated from current to > previous, someone will have to do the change (at least renaming for > example), with the second proposition, there's no need for extra > maintaining. > That current to previous change is merely selecting the new package/release group and clicking a button. With the second method, I must create a new relesae, fill in the notes and the changes and then I must decide if I want two, three, four, ... releases availabe. And the ones that are not available are still in the way when I view the package to create another release. I like the first method better but I will go with majority on this one. > Maybe we could also trim down the choice of packages: there's over 10 > choices of 'MinGW Runtime' for example, 5 would probably be more than > enough. You mean in previous? I could care less. But once a release is created it is there for the developer to see forever. I can't delete the release and now I remember, this is the reason I went to the Current, Candidate, Snapshot and Previous in the first place. Really gets unruly, just finding Snapshot in the list of previous packages is a headache for this persons eyes. Earnie |
From: Chris S. <ir0...@gm...> - 2007-02-01 16:12:26
|
> >> GCC package with releases of Current, Candidate, Snapshot and Previous > >> binutils package with releases of Current, Candidate, Snapshot and Previous > >> > >> or > >> > >> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > >> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 > > > > I vote for the second: when a package gets updated from current to > > previous, someone will have to do the change (at least renaming for > > example), with the second proposition, there's no need for extra > > maintaining. > > > > That current to previous change is merely selecting the new > package/release group and clicking a button. With the second method, I > must create a new relesae, fill in the notes and the changes and then I > must decide if I want two, three, four, ... releases availabe. And the > ones that are not available are still in the way when I view the > package to create another release. > > I like the first method better but I will go with majority on this one. I prefer the first method, for the same reasons that Earnie mentioned. Chris -- Chris Sutcliffe http://ir0nh34d.googlepages.com http://ir0nh34d.blogspot.com http://emergedesktop.org |
From: Julien L. <ju...@fa...> - 2007-02-01 16:32:18
|
Earnie Boyd wrote: > Quoting Julien Lecomte <ju...@fa...>: > >> Earnie Boyd wrote: >>> We don't need to reupload just move the packages from one place to >>> another. Before we do that we should discuss a standard. >>> >>> GCC package with releases of Current, Candidate, Snapshot and Previous >>> binutils package with releases of Current, Candidate, Snapshot and Previous >>> >>> or >>> >>> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 >>> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 >> I vote for the second: when a package gets updated from current to >> previous, someone will have to do the change (at least renaming for >> example), with the second proposition, there's no need for extra >> maintaining. >> > > That current to previous change is merely selecting the new > package/release group and clicking a button. With the second method, I > must create a new relesae, fill in the notes and the changes and then I > must decide if I want two, three, four, ... releases availabe. And the > ones that are not available are still in the way when I view the > package to create another release. I went into the sf admin/release section; and yes, you're right about all the actions that must be taken in order to change a file release. I had also forgotten how much worse the sf backend is compared to the frontend! > I like the first method better but I will go with majority on this one. I'll revert my vote and choose the solution that requires the less maintaining for admins, which is also your choice, since both solutions present to me the same clarity for end-users. Julien |
From: Paul G. <pga...@co...> - 2007-02-04 05:25:30
|
On 1 Feb 2007 at 17:15, Julien Lecomte wrote: > Earnie Boyd wrote: > > Quoting Julien Lecomte <ju...@fa...>: > > > >> Earnie Boyd wrote: > >>> We don't need to reupload just move the packages from one place to > >>> another. Before we do that we should discuss a standard. > >>> > >>> GCC package with releases of Current, Candidate, Snapshot and > >>> Previous binutils package with releases of Current, Candidate, > >>> Snapshot and Previous > >>> > >>> or > >>> > >>> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > >>> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 > >> I vote for the second: when a package gets updated from current to > >> previous, someone will have to do the change (at least renaming for > >> example), with the second proposition, there's no need for extra > >> maintaining. My vote would be towards the former. It is both simple and straightforward. What reservations I had with the former have pretty much been addressed. Thanks! Paul G. |
From: Danny S. <dan...@cl...> - 2007-02-04 08:24:30
|
> > >>> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > > >>> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 > > >> I vote for the second: when a package gets updated from > current to > > >> previous, someone will have to do the change (at least > renaming for > > >> example), with the second proposition, there's no need for extra > > >> maintaining. > > My vote would be towards the former. It is both simple > and straightforward. > > What reservations I had with the former have pretty > much been addressed. Thanks! > For projects such as gcc which contain multiple src and binary components, creating a new candidate, changing the old candidate to current, canging the old current to previous and hiding the old previous may be conceptually simple but it is tedious and time-consuming using the FRS, to the point where it has deterred me from making new candidate releases. It will become evwn more confusing if we wish to maintain a "Current" 3.4.x (for stability) along with Current 4.x.x (for all the new features. Or maintain a DW2 series alonng with a SJLJ series) Or whatever. All the version info could be integratyed into the name of the release (and expanded on in a small test file) I was hoping there would be a better way. Danny > Paul G. > > -------------------------------------------------------------- > ----------- > Using Tomcat but need to do more? Need to support web > services, security? > Get stuff done quickly with pre-integrated technology to make > your job easier. > Download IBM WebSphere Application Server v.1.0.1 based on > Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057& dat=121642 _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: Earnie B. <ea...@us...> - 2007-02-04 15:37:42
|
Quoting Danny Smith <dan...@cl...>: >> > >>> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 >> > >>> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 >> > >> I vote for the second: when a package gets updated from >> current to >> > >> previous, someone will have to do the change (at least >> renaming for >> > >> example), with the second proposition, there's no need for extra >> > >> maintaining. >> >> My vote would be towards the former. It is both simple >> and straightforward. >> >> What reservations I had with the former have pretty >> much been addressed. Thanks! >> > > For projects such as gcc which contain multiple src and binary > components, creating a new candidate, changing the old candidate to > current, canging the old current to previous and hiding the old previous > may be conceptually simple but it is tedious and time-consuming using > the FRS, to the point where it has deterred me from making new candidate > releases. > I must be missing the time-consuming part of this. You goto file section on the release page and click which one to move to. Oh wait, the GCC release has 8 to 10 files to move and the click is one at a time. The click refreshes the browser and you have to go to the files section again. Can with live with, maintainer choice? > It will become evwn more confusing if we wish to maintain a "Current" > 3.4.x (for stability) along with Current 4.x.x (for all the new > features. Or maintain a DW2 series alonng with a SJLJ series) Or > whatever. All the version info could be integratyed into the name of the > release (and expanded on in a small test file) > So we have a GCC3 package, GCC4 package, GCC4-DW2 package. > I was hoping there would be a better way. > I don't think SF UI is really suited for us anymore. Perhaps the better way is to find a different interface? Mr Moorman, we can no longer work within the UI framework that SF has been driven to develop. We would really like to here from you to discuss alternatives. I have set your mo...@us... and mo...@so... addresses so that you may respond to the list without being bounced. If you forward to others I would need to adjust the list before they respond. Earnie |
From: Paul G. <pga...@co...> - 2007-02-05 01:00:39
|
On 4 Feb 2007 at 10:37, Earnie Boyd wrote: > Quoting Danny Smith <dan...@cl...>: > > >> > >>> GCC package with releases of 3.4.2, 3.3.1, 3.2.3 > >> > >>> binutils package with releases of 2.16.91, 2.15.91, 2.13.90 > >> > >> I vote for the second: when a package gets updated from > >> current to > >> > >> previous, someone will have to do the change (at least > >> renaming for > >> > >> example), with the second proposition, there's no need for > >> > >> extra maintaining. > >> > >> My vote would be towards the former. It is both simple > >> and straightforward. > >> > >> What reservations I had with the former have pretty > >> much been addressed. Thanks! > >> > > > > For projects such as gcc which contain multiple src and binary > > components, creating a new candidate, changing the old candidate to > > current, canging the old current to previous and hiding the old > > previous may be conceptually simple but it is tedious and > > time-consuming using the FRS, to the point where it has deterred me > > from making new candidate releases. Maintainers choice? Or, perhaps, define what it is that would be most efficient, both functionally and conceptually? |
From: techtonik <tec...@us...> - 2007-02-07 06:53:50
|
On 2/4/07, Danny Smith <dan...@cl...> wrote: > For projects such as gcc which contain multiple src and binary > components, creating a new candidate, changing the old candidate to > current, canging the old current to previous and hiding the old previous > may be conceptually simple but it is tedious and time-consuming using > the FRS, to the point where it has deterred me from making new candidate > releases. > > It will become evwn more confusing if we wish to maintain a "Current" > 3.4.x (for stability) along with Current 4.x.x (for all the new > features. Or maintain a DW2 series alonng with a SJLJ series) Or > whatever. All the version info could be integratyed into the name of the > release (and expanded on in a small test file) > > I was hoping there would be a better way. http://sfutils.sourceforge.net/ if you don't mind using ANT in release process. -- --t. |
From: Hin-Tak L. <hin...@ya...> - 2007-02-05 00:27:02
|
Earnie Boyd wrote: > Quoting Julien Lecomte <ju...@fa...>: <snipped> >> Maybe we could also trim down the choice of packages: there's over 10 >> choices of 'MinGW Runtime' for example, 5 would probably be more than >> enough. > > You mean in previous? I could care less. But once a release is > created it is there for the developer to see forever. I can't delete > the release and now I remember, this is the reason I went to the > Current, Candidate, Snapshot and Previous in the first place. That's not correct, I think; being a project-admin myself, I think it is correct to say that releases are there for the *project admin* to see forever, but the project admin has the choice of *hidding* specific releases and even specific packages so that they are not visible for casual downloading. (that's the machanism for releases that are so foundamentally broken/undesirable/too-out-dated/unmaintained, they need to be withdrawn from general circulation, unless somebody go to a sourceforge mirror manually and do a full-directory listing to get at them with some skill). HTL ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html |
From: Earnie B. <ea...@us...> - 2007-02-05 16:09:23
|
Quoting Hin-Tak Leung <hin...@ya...>: > Earnie Boyd wrote: >> Quoting Julien Lecomte <ju...@fa...>: > <snipped> >>> Maybe we could also trim down the choice of packages: there's over 10 >>> choices of 'MinGW Runtime' for example, 5 would probably be more than >>> enough. >> >> You mean in previous? I could care less. But once a release is >> created it is there for the developer to see forever. I can't delete >> the release and now I remember, this is the reason I went to the >> Current, Candidate, Snapshot and Previous in the first place. > > That's not correct, I think; being a project-admin myself, I think it > is correct to say that releases are there for the *project admin* to see > forever, We agree. > but the project admin has the choice of *hidding* specific > releases and even specific packages so that they are not visible for > casual downloading. So? The casual downloader doesn't create the releases. > (that's the machanism for releases that are so > foundamentally broken/undesirable/too-out-dated/unmaintained, > they need to be withdrawn from general circulation, unless > somebody go to a sourceforge mirror manually and do a full-directory > listing to get at them with some skill). > Wasn't at all my complaint. My complaint is that the dead releases get in the way, take time to ignore, when I need to upload a new release. Earnie |