From: Keith M. <kei...@us...> - 2007-05-25 19:58:21
|
[Oops. I originally posted this on MinGW-MSYS, intending to post it here; (KMail lets me right-click the folder, and select `New message to mailing list'; I hit the wrong one of two adjacent folders). Never mind; let's have comments from both groups.] I'm considering reorganising the mingwPORTs, currently all collected together into a single `release' within the `Current' package, into a new `mingwPORT' package; this would hopefully make the mingwPORTs easier to locate, on the SF downloads page. Once I've created that, I'm undecided how best to categorise the `releases' within the new packages. Possibilities which spring to mind are: 1) `Current', `Candidate' and `Previous' *release* groups, with all files grouped into the three categories, as appropriate. 2) A separate release group for each ported package, with each new version of any port being added to its appropriate `release' group, as it becomes available. 3) A completely separate `release' for each and every port, as it becomes available. I think I'm leaning towards (1). This would kind of maintain our concept of current, candidate and previous categories, although by turning it around, I'm hoping it will improve the organisation of the downloads page. Technically, it's probably just another way to subvert the SF vision of how the FRS should be used. Any thoughts? Better ideas? Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-05-25 21:31:37
|
Quoting Keith Marshall <kei...@us...>: > > Any thoughts? Better ideas? > This is where the FRS doesn't work for our needs. I am not sure that there is a good plan to follow. I'm nearly of the opinion that just upload the file and use the CMS to control the download page at www.mingw.org. There are CCK and Views modules that may help with this. The pages would just link to the SF mirror picker for the download process. I still have to work out the RSS feeds from SF to the Drupal setup. Earnie |
From: Paul G. <pga...@co...> - 2007-05-26 18:13:35
|
I am inclined towards #1, as it seems most flexible in terms of the "point&click" approach. Besides the approach to FRS is already so warped (where Mingw and/or Msys are concerned) that it doesn't appear that it would be any more difficult or more time consuming to maintain than it already is. If the goal is to revamp the entire download interface then a severe simplification might be in order. But that requires a great deal of time and energy, something not very many of us really have. Paul G. On 25 May 2007 at 20:58, Keith Marshall wrote: > [Oops. I originally posted this on MinGW-MSYS, intending to post it > here; (KMail lets me right-click the folder, and select `New message > to mailing list'; I hit the wrong one of two adjacent folders). Never > mind; let's have comments from both groups.] > > > I'm considering reorganising the mingwPORTs, currently all collected > together into a single `release' within the `Current' package, into a > new `mingwPORT' package; this would hopefully make the mingwPORTs > easier to locate, on the SF downloads page. > > Once I've created that, I'm undecided how best to categorise the > `releases' within the new packages. Possibilities which spring to > mind are: > > 1) `Current', `Candidate' and `Previous' *release* groups, with all > files grouped into the three categories, as appropriate. > > 2) A separate release group for each ported package, with each new > version of any port being added to its appropriate `release' group, as > it becomes available. > > 3) A completely separate `release' for each and every port, as it > becomes available. > > I think I'm leaning towards (1). This would kind of maintain our > concept of current, candidate and previous categories, although by > turning it around, I'm hoping it will improve the organisation of the > downloads page. Technically, it's probably just another way to > subvert the SF vision of how the FRS should be used. > > Any thoughts? Better ideas? > > Regards, > Keith. > > ---------------------------------------------------------------------- > --- This SF.net email is sponsored by DB2 Express Download DB2 Express > C - the FREE version of DB2 express and take control of your XML. No > limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > _______________________________________________ MinGW-dvlpr mailing > list Min...@li... > https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |
From: techtonik <tec...@us...> - 2007-05-27 21:15:21
|
On 5/25/07, Keith Marshall <kei...@us...> wrote: > > 1) `Current', `Candidate' and `Previous' *release* groups, with all > files grouped into the three categories, as appropriate. > > 2) A separate release group for each ported package, with each new > version of any port being added to its appropriate `release' group, as > it becomes available. > > 3) A completely separate `release' for each and every port, as it > becomes available. > I'd stick with (2) abandoning "unportable" concept of current, candidate and previous in favour of SVN for the candidate, last available release for current and FRS archived files for previous. KISS. -- --anatoly t. |
From: Keith M. <kei...@us...> - 2007-05-28 15:28:54
|
On Sunday 27 May 2007 22:15, techtonik wrote: > On 5/25/07, Keith Marshall wrote: > > 1) `Current', `Candidate' and `Previous' *release* groups, with all > > files grouped into the three categories, as appropriate. > > > > 2) A separate release group for each ported package, with each new > > version of any port being added to its appropriate `release' group, > > as it becomes available. > > > > 3) A completely separate `release' for each and every port, as it > > becomes available. > > I'd stick with (2) abandoning "unportable" concept of current, > candidate and previous in favour of SVN for the candidate, last > available release for current and FRS archived files for previous. > KISS. On the KISS principle, I'd have to choose (1). It's simplest for me to set up and maintain; I also believe it will make it easier for users to locate the mingwPORT packages they are looking for. On reflection, I think two release categories will suffice; in the case of mingwPORTS, there seems little need for a `candidate' category, and I have no short term plans for keeping mingwPORTs in CVS. (Speaking of which: when are you going to abandon your crusade for SVN adoption? You have already beaten that horse to death; why do you persist in beating it, long after its demise)? Regards, Keith. |
From: techtonik <tec...@us...> - 2007-05-29 08:00:31
|
On 5/28/07, Keith Marshall <kei...@us...> wrote: > > > 1) `Current', `Candidate' and `Previous' *release* groups, with all > > > files grouped into the three categories, as appropriate. > > > > > > 2) A separate release group for each ported package, with each new > > > version of any port being added to its appropriate `release' group, > > > as it becomes available. > > > > > > 3) A completely separate `release' for each and every port, as it > > > becomes available. > > > > I'd stick with (2) abandoning "unportable" concept of current, > > candidate and previous in favour of SVN for the candidate, last > > available release for current and FRS archived files for previous. > > KISS. > > On the KISS principle, I'd have to choose (1). It's simplest for me to > set up and maintain; I also believe it will make it easier for users to > locate the mingwPORT packages they are looking for. Ohh, I see - in (2) SF FRS will show only three top packages from mingwPORTS and user will have to load extra page to see all ports that are available. Then it is unacceptable and indeed (1) is better. But.. > On reflection, I think two release categories will suffice; in the case > of mingwPORTS, there seems little need for a `candidate' category, and > I have no short term plans for keeping mingwPORTs in CVS. (Speaking of > which: when are you going to abandon your crusade for SVN adoption? You > have already beaten that horse to death; why do you persist in beating > it, long after its demise)? s/SVN/VCS/ - it is convenient to maintain ports collection there. You do not have to download, unpack and execute every needed package manually - just checkout the tree and install whatever you like. It also possible to quickly submit patches to fixed port just by running %VCS% diff. If you set VCS=svn you'll be able to give port maintainers secured access isolated from main CVS trunk of MinGW. Yep, Candidate is rather useless when it comes to ports. Although in the names of release packages "CurrentReleases" and "EarlierReleases" I'd rename latter "PreviousRelease" and perhaps even added "ArchivedReleases" to dump garbage. -- --anatoly t. |
From: Earnie B. <ea...@us...> - 2007-05-29 12:21:12
|
Quoting techtonik <tec...@us...>: > > s/SVN/VCS/ - it is convenient to maintain ports collection there. You > do not have to download, unpack and execute every needed package > manually - just checkout the tree and install whatever you like. CVS and others like it are Versioning Control Systems for controlling the maintenance of software and not a distribution mechanism for the end user. I agree with Keith that it is a waste of time to store the individual port packages in a VCS. If you have access to a VCS but not to FTP through your proxy then you're not going to be able to use the mingwPORT anyway because it uses wget to do its magic. BTW, remind me which mingwPORT packages you've contributed and maintain? Earnie |
From: techtonik <tec...@us...> - 2007-05-29 13:56:37
|
On 5/29/07, Earnie Boyd <ea...@us...> wrote: > > > > s/SVN/VCS/ - it is convenient to maintain ports collection there. You > > do not have to download, unpack and execute every needed package > > manually - just checkout the tree and install whatever you like. > > CVS and others like it are Versioning Control Systems for controlling > the maintenance of software and not a distribution mechanism for the > end user. Any explanations why? > I agree with Keith that it is a waste of time to store the > individual port packages in a VCS. Whatever you mean by "waste of time to store the individual port packages" it seems like we have different vision of the process. I proposed to store all _ports_ in VCS in unpacked form and you seem thinking about _port packages_ in a form of tar.gz archives. > If you have access to a VCS but not > to FTP through your proxy then you're not going to be able to use the > mingwPORT anyway because it uses wget to do its magic. I do not know about yours, but my VCS works over HTTP or HTTPS (presumably through the same proxy server that handles FTP connections), so I do not see any problems here. > > BTW, remind me which mingwPORT packages you've contributed and maintain? > You want to say that I am not competent enough to discuss these questions or what? BTW, could you tell me where from did you get an idea of "ports"? -- --anatoly t. |
From: Earnie B. <ea...@us...> - 2007-05-29 23:25:45
|
Quoting techtonik <tec...@us...>: > On 5/29/07, Earnie Boyd <ea...@us...> wrote: >> > >> > s/SVN/VCS/ - it is convenient to maintain ports collection there. You >> > do not have to download, unpack and execute every needed package >> > manually - just checkout the tree and install whatever you like. >> >> CVS and others like it are Versioning Control Systems for controlling >> the maintenance of software and not a distribution mechanism for the >> end user. > > Any explanations why? > You might find that the VCS is in a state of flux. The VCS is a developer tool and not an end user tool. Yes controls can be placed to tag this or that but still it shouldn't be the non technical using the VCS. The only reason to tag a release would be to apply critical updates to a release package and not to use if for a distribution system. >> I agree with Keith that it is a waste of time to store the >> individual port packages in a VCS. > > Whatever you mean by "waste of time to store the individual port > packages" it seems like we have different vision of the process. I > proposed to store all _ports_ in VCS in unpacked form and you seem > thinking about _port packages_ in a form of tar.gz archives. > Most of each mingwPORT package is exactly the same and is meant to be a distribution system for applying patches, using configuration and make commands and switches that are known to work. No, I was not talking about the tar.gz files but the individual files. I assume that most of the users of mingwPORT are those who are less technical and do not want to be bothered with those details. The portmaker scripts are available in our VCS for those technical enough to create the mingwPORT of a package. >> If you have access to a VCS but not >> to FTP through your proxy then you're not going to be able to use the >> mingwPORT anyway because it uses wget to do its magic. > > I do not know about yours, but my VCS works over HTTP or HTTPS > (presumably through the same proxy server that handles FTP > connections), so I do not see any problems here. > I've heard of others who have problem doing FTP even though HTTP is available. >> >> BTW, remind me which mingwPORT packages you've contributed and maintain? >> > You want to say that I am not competent enough to discuss these > questions or what? > I am implying that your contributions to date have been mostly verbal with no other contribution. Frankly I am quite tired of it since it takes time to read and respond. > BTW, could you tell me where from did you get an idea of "ports"? > Maybe it was a buzz word I just chose. There was discussion sometime ago about a port contribution that never came to fruition. MingwPORT was something I then dubbed my first script driven release. Keith took over and has it humming along quite well. Some of the mingwPORT packages contain no patch files at all but simply simplify the configure, make and make install process. Earnie |
From: techtonik <tec...@us...> - 2007-05-30 07:15:56
|
On 5/30/07, Earnie Boyd <ea...@us...> wrote: > Quoting techtonik <tec...@us...>: > > >> > s/SVN/VCS/ - it is convenient to maintain ports collection there. You > >> > do not have to download, unpack and execute every needed package > >> > manually - just checkout the tree and install whatever you like. > >> > >> CVS and others like it are Versioning Control Systems for controlling > >> the maintenance of software and not a distribution mechanism for the > >> end user. > > > > Any explanations why? > > You might find that the VCS is in a state of flux. The VCS is a > developer tool and not an end user tool. Yes controls can be placed to > tag this or that but still it shouldn't be the non technical using the > VCS. The only reason to tag a release would be to apply critical > updates to a release package and not to use if for a distribution > system. My question still isn't answered: Why VCS can't be used for distribution system? Maybe you've missed the point - VCS doesn't hold any packages or package sources - it contains port files including patches in their raw form. VCS always contains latest working version of a port. If you need any previous versions - they are tagged. If you need any branches to work through the complicated nature of some particular ports - feel free to open them separately. I do not see why VCS for ports will be in a state of flux. > Most of each mingwPORT package is exactly the same and is meant to be a > distribution system for applying patches, using configuration and make > commands and switches that are known to work. No, I was not talking > about the tar.gz files but the individual files. I assume that most of > the users of mingwPORT are those who are less technical and do not want > to be bothered with those details. The portmaker scripts are available > in our VCS for those technical enough to create the mingwPORT of a > package. It seems that you underestimate that majority of the users of MinGW and of ports are highly technical to figure out what a MinGW/MSYS/DTK is, WTF a port is, why do they need them and how to download and install them. Almost none of the ports I used worked automagically and I had to be bothered with portmaker details. It is a hell downloading and installing every and each autotools/flex/... tar.gz from SF. I do not care if you'd like to keep everything in tar.gz, but I'd like to see also another way to work with the ports collection through VCS. Just checkout, cd, run and enjoy dependency checking and installing. > >> If you have access to a VCS but not > >> to FTP through your proxy then you're not going to be able to use the > >> mingwPORT anyway because it uses wget to do its magic. > > > I do not know about yours, but my VCS works over HTTP or HTTPS > > (presumably through the same proxy server that handles FTP > > connections), so I do not see any problems here. > > I've heard of others who have problem doing FTP even though HTTP is available. You see - HTTP is always available. And your poor guys.. they won't be able to install your port even from a tar.gz Should we shoot them or provide HTTP mirrors instead? > I am implying that your contributions to date have been mostly verbal > with no other contribution. Frankly I am quite tired of it since it > takes time to read and respond. Isn't it the point of discussion to come up with a best solution? I told you an idea - you are free to answer it or to skip. If you do not care - I won't too. I am of no difference to others who can only contribute to things that I myself find acceptable or challenging. I have a daily job to listen and obey with no possibility to deviate from the course of my crazy master and that's suxx enough to avoid it when I am not trying to get something more than food in my stomach. > > BTW, could you tell me where from did you get an idea of "ports"? > > > > Maybe it was a buzz word I just chose. There was discussion sometime > ago about a port contribution that never came to fruition. MingwPORT > was something I then dubbed my first script driven release. Keith took > over and has it humming along quite well. Some of the mingwPORT > packages contain no patch files at all but simply simplify the > configure, make and make install process. Then take a look on what majority of us familiar with "ports" in unix word think when hearing this word. http://en.wikipedia.org/wiki/Ports_collection I'd prefer to have a similar system to BSD not only by name. -- --anatoly t. |
From: Keith M. <kei...@us...> - 2007-05-30 20:53:00
|
On Wednesday 30 May 2007 08:15, techtonik wrote: > I'd prefer to have a similar system to BSD not only by name. If you can produce a working prototype, based on the techniques you seem so keen to promote, then I may consider it further. While it remains pie in the sky, you are just wasting everybody's time by continuing to grouse about it. If you want a BSD system, why don't you just use {Free,Open,Net}BSD? Regards, Keith. |
From: Earnie B. <ea...@us...> - 2007-05-30 12:40:15
|
Quoting techtonik <tec...@us...>: > > Isn't it the point of discussion to come up with a best solution? The only discussion I have seen from you is always supporting some other method of operation that might better suite you. I am tired of that discussion it is not a solution we will consider. I'm becoming suspicious that you have yet to download a mingwPORT package and try to even execute one of the scripts much less look at what it is made of. Earnie |
From: techtonik <tec...@us...> - 2007-05-31 06:52:09
|
On 5/30/07, Earnie Boyd <ea...@us...> wrote: > > > > > Isn't it the point of discussion to come up with a best solution? > > The only discussion I have seen from you is always supporting some > other method of operation that might better suite you. I am tired of > that discussion it is not a solution we will consider. I am always considering other variants than suit you and do not see why it had caused so many problems with trying to be constructive. If you and Keith would like to continue unrelevant discussion about my particular behaviour - do it in private, please. > I'm becoming suspicious that you have yet to download a mingwPORT > package and try to even execute one of the scripts much less look at > what it is made of. http://sourceforge.net/tracker/index.php?func=detail&aid=1374554&group_id=2435&atid=302435 -- --anatoly t. |
From: Earnie B. <ea...@us...> - 2007-05-31 12:10:19
|
Quoting techtonik <tec...@us...>: > On 5/30/07, Earnie Boyd <ea...@us...> wrote: >> >> > >> > Isn't it the point of discussion to come up with a best solution? >> >> The only discussion I have seen from you is always supporting some >> other method of operation that might better suite you. I am tired of >> that discussion it is not a solution we will consider. > > I am always considering other variants than suit you and do not see > why it had caused so many problems with trying to be constructive. If > you and Keith would like to continue unrelevant discussion about my > particular behaviour - do it in private, please. > You asked publicly. There is no ``best solution'' for everyone; we can only hope to provide a solution suitable to most everyone. Keith, I and others who do not speak have an understanding of how we should work together. You, IMNSHO, are stretching beyond working together to pull us toward working a ``best solution'' as Anatoly sees it. >> I'm becoming suspicious that you have yet to download a mingwPORT >> package and try to even execute one of the scripts much less look at >> what it is made of. > > http://sourceforge.net/tracker/index.php?func=detail&aid=1374554&group_id=2435&atid=302435 > Thanks for the pointer. The portmaker package is designed as a facilitator for those created the mingwPORT package as you should already be familiar with. It is delivered in our chosen VCS. There is no reason that I can see to control versioning of the individual port packages. Our use of CVS is to control versions which is the purpose of CVS and not as a means of distribution which wasn't envisioned as a goal for CVS. The individual port packages are near copies of the portmaker package templates. The difference is small and the importance of versioning for these packages isn't seen. We've heard from Anatoly, are there others who want to see mingwPORT packages in CVS/SVN? Why? What is the importance of controlling versioning for these packages? The Keith and Earnie show has spoken, respond now or forever be banned from mentioning this issue again. ;p Earnie |