Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
jhell jh...@dataix.net wrote: Feel free to correct me if I am wrong but it is not going to matter much to what extent a license has to do with this besides ease of mind maybe. We would not be using the source for the VCS in a repo that holds the source that is being distributed and none of the contained software would be effected by a GPL'd VCS. I don't believe the GPL reaches out that far as to where it can effect the contents of a repo even if it would happen to be GPLv3. My primary concern is not that the GPL would extend to the contents of a GPL'd VCS -- AFAIK it would not -- but that the whole point of moving to a _distributed_ VCS is presumably that a significant fraction of ports contributors (not just committers and/or maintainers) would be running the VCS locally so as to maintain repositories. I have the impression that some fraction of those potential contributors will be less likely to participate if the price of doing so is running a VCS that is GPL'd. Beyone that, we should not overlook (what I understand to be) the general policy that I mentioned earlier: AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. As I understand it, what is being suggested is the adoption of a new code base for a significant piece of infrastructure. I think the proposal is at less risk of being summarily rejected if it can viably be based on BSD-licensed code rather than on GPL'd code. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Wed, Sep 22, 2010 at 3:27 AM, per...@pluto.rain.com wrote: As I understand it, what is being suggested is the adoption of a new code base for a significant piece of infrastructure. I think the proposal is at less risk of being summarily rejected if it can viably be based on BSD-licensed code rather than on GPL'd code. This dvcs is BSD licensed: http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki I believe it was originally GPL'd, and the author converted it BSD based license on request. The requests came from multiple people who didn't want to to incorporate GPL into their project(s). There is an interview about it here: http://bsdtalk.blogspot.com/2010/07/bsdtalk194-fossil-scm-with-d-richard.html Anyways, IMO license is quite a large deal when you're making this sort of decision. OS code infrastructure has a way of expanding around what's used(eg csup in base) and you'd want to ensure any potential development paths are not hindered by LICENSE. -- Adam Vande More ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
This dvcs is BSD licensed: IMHO, if it's worth to change VCS, it would be much wiser to use well-known one -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Wed, Sep 22, 2010 at 4:10 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: Given the amount of GPL'd software in the base system, why are we already fighting over licensing? What is it with the open-source world and obsessing with licensing? It should be up for discussion after alternatives have been determined as viable candidates (see below). Probably rhetorical, but not all licenses are created equal. BSD license has a particular advantage in embedded/black box systems, so not polluting base with more viral licensing is pretty important to project as whole I think. There's a reason things like IronPort aren't Linux based. Take for example the way ZFS was implemented. It was done that way to keep the CDDL out of the kernel. That's part of the reason booting of ZFS is the way it is as a separate loader, not integrated. Licenses are a big deal, our world is not laissez-faire regarding them. Yes there are still some GPL tools in base but the number is really quite small and shrinking, however what's there is pretty big and quite essential. There has long been active if not frequently vigorous work to remove those bits. It seems GNU grep is nearing it's end, and man page stuff is being worked on, CLANG over GCC, etc. Anyway, my point was not to advocate fossil for this task, but to point out BSD license is a concern. Perhaps if you are able to find consensus, requesting a license change might be an option. -- Adam Vande More ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
22.09.2010, 14:11, Adam Vande More amvandem...@gmail.com: BSD license has a particular advantage in embedded/black box systems, so not polluting base with more viral licensing is pretty important to project as whole I think. Do embedded systems really need to use ports tree? I guess no, or only during initial setup by manufacturer -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
Smells like Debian. Smells like Slashdot. I give up. On Wed, Sep 22, 2010 at 7:11 AM, Adam Vande More amvandem...@gmail.com wrote: On Wed, Sep 22, 2010 at 4:10 AM, Jeremy Chadwick free...@jdc.parodius.comwrote: Given the amount of GPL'd software in the base system, why are we already fighting over licensing? What is it with the open-source world and obsessing with licensing? It should be up for discussion after alternatives have been determined as viable candidates (see below). Probably rhetorical, but not all licenses are created equal. BSD license has a particular advantage in embedded/black box systems, so not polluting base with more viral licensing is pretty important to project as whole I think. There's a reason things like IronPort aren't Linux based. Take for example the way ZFS was implemented. It was done that way to keep the CDDL out of the kernel. That's part of the reason booting of ZFS is the way it is as a separate loader, not integrated. Licenses are a big deal, our world is not laissez-faire regarding them. Yes there are still some GPL tools in base but the number is really quite small and shrinking, however what's there is pretty big and quite essential. There has long been active if not frequently vigorous work to remove those bits. It seems GNU grep is nearing it's end, and man page stuff is being worked on, CLANG over GCC, etc. Anyway, my point was not to advocate fossil for this task, but to point out BSD license is a concern. Perhaps if you are able to find consensus, requesting a license change might be an option. -- Adam Vande More ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Not so young, but still crying out Full of anger full of doubt ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Mon, 20 Sep 2010 19:07:17 -0700 per...@pluto.rain.com wrote: Janne Snabb sn...@epipe.com wrote: On Mon, 20 Sep 2010, per...@pluto.rain.com wrote: One issue with either Git or Mercurial is that they are GPL. AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. The project currently uses Perforce for many sub-projects, so using GPL licenced solution could hardly be a problem. According to the General Information table here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Perforce is not GPL -- it is proprietary (but Free ... for OSS development). Thus the fact that FreeBSD currently uses Perforce tells us nothing about the acceptability of a GPL licensed solution. (Ditto for SVN, which -- as someone already pointed out -- is not GPL either.) There are two distributed, BSD-licensed VCS listed on that page: Codeville and Fossil. Both are in ports, but Codeville has been proposed for removal as it seems no longer to be under active development. That leaves Fossil as a possibly-viable BSD-licensed alternative to Mercurial. (Of course, there may be others that aren't listed on that particular Wikipedia page.) Keeping the original recipients when replying (all of them not only To:) would be greatly appreciated (and it's required by the list charted). Thanks, -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97Y8Xi 4). Because CVS just does not do any of this. Make your final comparison here: http://bit.ly/cyQBn8 For the sake of argument can you think of any reason to not switch ? Why not Git? Or you prefer to manage ports tree from Windows? -- Regards, Konstantin ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Mon, 20 Sep 2010 03:17, Konstantin Tokarev wrote: In Message-Id: 174981284967...@web24.yandex.ru 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97Y8Xi 4). Because CVS just does not do any of this. Make your final comparison here: http://bit.ly/cyQBn8 For the sake of argument can you think of any reason to not switch ? Why not Git? Or you prefer to manage ports tree from Windows? For one it really has a steeper learning curve for the interface than what mercurial presents. It presents a lot of information upfront to the user which tends to be overwhelming in some cases. GIT is nice, I like its speed but I have more of a preference to mercurial than anything else. I also like the fact that mercurial makes direct use of the python language but this is not really for this thread and could lead off in directions that were not intended. I do not do any development for anything to do with FreeBSD in a Window$ environment, Its not needed for me to do so because I always have access to a command line wherever I go. If the time comes and I would need to, it is nice to know that there is a front-end for Mercurial on Window$. Thanks for inquiring, -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On 20/09/2010 03:01, Carlos A. M. dos Santos wrote: On Sun, Sep 19, 2010 at 6:34 AM, Ion-Mihai Tetcu ite...@freebsd.org wrote: Insert VCS discussion here Is this just my impression or are we trying to build a bikeshed here? I think we all agree, that the stage is not set for a VCS change. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
Konstantin Tokarev annu...@yandex.ru wrote: Why not Git? One issue with either Git or Mercurial is that they are GPL. AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. Granted SVN, currently used to manage src, is GPL; but its critical use is only on the project's own servers whereas the use being proposed for Git or Mercurial would involve their being used in a distributed manner (that being the whole point). A second issue with Mercurial is that it is written in Python, which seems to have adopted -- granted to a lesser extent -- the unfortunate Perl tendency for newer versions to be less than completely compatible with earlier versions. It would seem problematic if the Python version used by Mercurial were to be superseeded by an incompatible version, requiring the entire distributed user base to migrate. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Mon, Sep 20, 2010 at 05:20:39AM -0700, per...@pluto.rain.com wrote: SVN [...] is GPL; nope, it's under Apache License 2.0, see: http://svn.apache.org/repos/asf/subversion/trunk/LICENSE -- Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/ pgp: 8234 9A78 E7C0 B807 0B59 80FF BA4D 1D95 5112 336F (ID: 0x5112336F) (plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated) pgpo43k4CGz1N.pgp Description: PGP signature
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Mon, 20 Sep 2010, per...@pluto.rain.com wrote: One issue with either Git or Mercurial is that they are GPL. AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. The project currently uses Perforce for many sub-projects, so using GPL licenced solution could hardly be a problem. I was shocked to notice that I need a proprietary binary-only software which does whatever unbeknownst to me to be able to access the TrustedBSD repositories. Using some free modern VCS for new sub-projects which would traditionally go to perforce would be a good way and first-use candidate to start experimenting with and getting developers used to the slightly different new way of doing things. From my point of view as a *user* it would be very nice to have some modern VCS interface to ports and src. The current system (SVN CVS) makes it troublesome for users to keep in sync with the central repository while maintaining their local modifications. Also, if I want to be able to access port version history easily, I need to use anoncvs to update my ports tree, but that is terribly slow (or I could mirror the whole CVS repository to my disk, but that is quite a bloat). Luckily src has been migrated to SVN, which makes my life slightly easier. The above is just a point of view as a pure consumer of the source tree. My contributions to the project come as patches in PRs (it would be easier to work on those patches with a modern VCS). My personal favourite is Bazaar as it tracks not only files but also directories properly, which I need for some projects, Mercurial comes 2nd and Git 3rd as it is quite a mess. All of them are tolerable :). I do know that the migration is a big burden which makes the whole thing very difficult to accomplish. -- Janne Snabb / EPIPE Communications sn...@epipe.com - http://epipe.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
Janne Snabb sn...@epipe.com wrote: On Mon, 20 Sep 2010, per...@pluto.rain.com wrote: One issue with either Git or Mercurial is that they are GPL. AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. The project currently uses Perforce for many sub-projects, so using GPL licenced solution could hardly be a problem. According to the General Information table here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Perforce is not GPL -- it is proprietary (but Free ... for OSS development). Thus the fact that FreeBSD currently uses Perforce tells us nothing about the acceptability of a GPL licensed solution. (Ditto for SVN, which -- as someone already pointed out -- is not GPL either.) There are two distributed, BSD-licensed VCS listed on that page: Codeville and Fossil. Both are in ports, but Codeville has been proposed for removal as it seems no longer to be under active development. That leaves Fossil as a possibly-viable BSD-licensed alternative to Mercurial. (Of course, there may be others that aren't listed on that particular Wikipedia page.) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On 09/20/2010 22:07, per...@pluto.rain.com wrote: Janne Snabb sn...@epipe.com wrote: On Mon, 20 Sep 2010, per...@pluto.rain.com wrote: One issue with either Git or Mercurial is that they are GPL. AFAIK FreeBSD prefers to avoid GPL in the base or in critical widely-used infrastructure if a viable non-GPL alternative exists. The project currently uses Perforce for many sub-projects, so using GPL licenced solution could hardly be a problem. According to the General Information table here: http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Perforce is not GPL -- it is proprietary (but Free ... for OSS development). Thus the fact that FreeBSD currently uses Perforce tells us nothing about the acceptability of a GPL licensed solution. (Ditto for SVN, which -- as someone already pointed out -- is not GPL either.) There are two distributed, BSD-licensed VCS listed on that page: Codeville and Fossil. Both are in ports, but Codeville has been proposed for removal as it seems no longer to be under active development. That leaves Fossil as a possibly-viable BSD-licensed alternative to Mercurial. (Of course, there may be others that aren't listed on that particular Wikipedia page.) Feel free to correct me if I am wrong but it is not going to matter much to what extent a license has to do with this besides ease of mind maybe. We would not be using the source for the VCS in a repo that holds the source that is being distributed and none of the contained software would be effected by a GPL'd VCS. I don't believe the GPL reaches out that far as to where it can effect the contents of a repo even if it would happen to be GPLv3. Lets not bring licensing into this unless the license clearly states that the beholder needs to be rewarded for their work by any use of so said product. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Distributed Version Control for ports(7) ( was: Re: autoconf update )
On 09/18/2010 07:17, Ion-Mihai Tetcu wrote: I'm still to see a concise, clear, precise, listing of advantages that switching from CVS would bring us, that would overcome the effort needed to do it (committers, users, infrastructure, tools). 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97Y8Xi 4). Because CVS just does not do any of this. Make your final comparison here: http://bit.ly/cyQBn8 For the sake of argument can you think of any reason to not switch ? lets hear those, I'm interested. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Sun, 19 Sep 2010 02:38:28 -0400 jhell jh...@dataix.net wrote: On 09/18/2010 07:17, Ion-Mihai Tetcu wrote: I'm still to see a concise, clear, precise, listing of advantages that switching from CVS would bring us, that would overcome the effort needed to do it (committers, users, infrastructure, tools). 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97 Y8Xi Make your final comparison here: http://bit.ly/cyQBn8 concise, clear, precise, listing of advantages, that switching from CVS would bring _us_ I have to work daily with 3-4 (D)VCSes for my work and OSS work, so I'm pretty well aware of some good and some bad points of each. 4). Because CVS just does not do any of this. Neither does any of them make coffee or pick up girls for me, but this neither here nor there, since we're talking about advantages - of switching - for ports. General this is why $VCS is the coolest and general features matrix are only the starting point. For the sake of argument can you think of any reason to not switch ? lets hear those, I'm interested. Well, first of all, since we are already using CVS, anyone wishing for a change will have to do the work to break the status quo (ie. convince the rest that is worth the effort). Quick args against: 1. Human side: - all existing committers know to use CVS - we have a few people that know its internals very well - most of the user base also - CVS is simple to use (yes, simple that any of the other; partially because it lacks complicated features) 2. Infrastructure: - everything we have revolves around CVS, from pointy to tindy to portsnap to mirrors to ... 3. All the scripts / apps / ... out there that make use of it or csup. About the only two things I see that we could benefit from switching to something else are: - easy move/rename while preserving history (repocopies now) - better speed for a whole tree checkout/update (if) I've watched the src switch from CVS to SVN, and I can't say it was fully a success. part of the problem is that even after all this time, people haven't completely made the switch in their minds. And the switch implies much more that a table of command equivalencies. Anyone wishing to push for a change will have to: 1. Produce a list of shortcomings of CVS in relation to our ports. 2. Produce a comparison of other VCSes in relation to CVS, CVS' shortcomings in relation to our ports, and each other. 3. Import the existing ports CVS history in the VCS they'd recommend to switch to. 4. Produce a tested migration path (exporter to CVS that works, etc.). 5. Produce a tested migration path for part of the pieces in our infrastructure. 6. Document 4. and 5. and CVS to $VCS user giude and be available to run/fix things related to 4. and 5. for months if not years. 1. to 4. are prerequisites of any serious endeavour to convince our committers and users (and pormgr@, core@). This implies a few month of work, without any guarantee that it won't be for nothing. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )
On Sun, Sep 19, 2010 at 6:34 AM, Ion-Mihai Tetcu ite...@freebsd.org wrote: On Sun, 19 Sep 2010 02:38:28 -0400 jhell jh...@dataix.net wrote: On 09/18/2010 07:17, Ion-Mihai Tetcu wrote: I'm still to see a concise, clear, precise, listing of advantages that switching from CVS would bring us, that would overcome the effort needed to do it (committers, users, infrastructure, tools). 1). http://bit.ly/d5UrtN 2). http://www.keltia.net/BSDCan/paper.pdf 3). http://bit.ly/97 Y8Xi Make your final comparison here: http://bit.ly/cyQBn8 concise, clear, precise, listing of advantages, that switching from CVS would bring _us_ I have to work daily with 3-4 (D)VCSes for my work and OSS work, so I'm pretty well aware of some good and some bad points of each. 4). Because CVS just does not do any of this. Neither does any of them make coffee or pick up girls for me, but this neither here nor there, since we're talking about advantages - of switching - for ports. General this is why $VCS is the coolest and general features matrix are only the starting point. You can keep discussing this subject forever, using this kind of argument. The point here is not if a DVCS is better than CVS or not. It is if FreeBSD ports will keep using CVS or move to something else, preferably a DCVS. This move will happen if - and only if - somebody volunteers to to the work or get paid to do it. So I suggest you to 1. Define what must be done, as well as a deadline. 2. Calculate the amount necessary to pay somebody with the right skills to do the work. 3. Create a bounty to raise the required funds. 4. Start working on the task. And yes, I'd happily donate some money to such initiative. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
On Fri, 17 Sep 2010 08:12:02 +0200 Dominic Fandrey kamik...@bsdforen.de wrote: On 17/09/2010 06:41, Doug Barton wrote: On 9/16/2010 6:15 PM, Doug Barton wrote: On 9/16/2010 3:35 PM, Anonymous wrote: Dominic Fandreykamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. We shouldn't use our users to beta-test infrastructure changes. Sorry, I'm not feeling well atm and realize that I didn't write what I was thinking here. What I intended to say was that we _don't_ intentionally use the ports system to force our users to beta test changes. I think it goes without saying that we _shouldn't_ do this, although I think that changes like this are a platinum-coated example of why we need to have -stable and -dev branches for ports. I used to disagree with this, because I thought it would create additional work load. Indeed. And the increase it's not linear. I have come to think more favourably of the idea, because you can make more daring commits on a -dev branch and don't have to quick-fix everything that goes wrong. Oh? (Not that I think fixes are being done that quick right now.) You need to do it fast, except for tip ports, because ports depend one on an other. Also the time between a MFC does not have to be very long. A week should be more than enough time to uncover and solve all problems. So the delay to get updates and fixes on the -stable branch is not very long. So you'd need a large userbase running -dev ports and updating very frequently. My2c: let's concentrate on pkg_install for now. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: autoconf update
On Sat, 18 Sep 2010 08:51:39 +0200 Dominic Fandrey kamik...@bsdforen.de wrote: On 18/09/2010 01:13, per...@pluto.rain.com wrote: jhell jh...@dataix.net wrote: ... Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree ... At the risk of starting the VCS variant of the vi vs emacs wars :) why Mercurial (rather than, say, GIT or SVK)? And no, I have nothing against Mercurial. I don't know _any_ distributed VCS well enough to have an opinion of which would be best suited. There is great documentation and re-education material (for SVN users) out there for Mercurial. I'm sure. But this is not going to happen any way. The ports are still stuck with _CVS_. I'm still to see a concise, clear, precise, listing of advantages that switching from CVS would bring us, that would overcome the effort needed to do it (committers, users, infrastructure, tools). -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: autoconf update
On 17/09/2010 00:35, Anonymous wrote: Dominic Fandrey kamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. Example is the breakage of databases/postgresql84-server + WITH_ICU. I second the question. Revision bump seem absolutely unnecessary. There was the sweeping commit reason in another thread. But I don't really think it would have been a sweeping commit if it weren't for the version bump. Did you forget that autoconf262 was removed? I don't get it. I've been really dumb a couple of times lately. Maybe that's it. So if you have the patience, explain it like you would to a dumb person. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
On 17/09/2010 06:41, Doug Barton wrote: On 9/16/2010 6:15 PM, Doug Barton wrote: On 9/16/2010 3:35 PM, Anonymous wrote: Dominic Fandreykamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. We shouldn't use our users to beta-test infrastructure changes. Sorry, I'm not feeling well atm and realize that I didn't write what I was thinking here. What I intended to say was that we _don't_ intentionally use the ports system to force our users to beta test changes. I think it goes without saying that we _shouldn't_ do this, although I think that changes like this are a platinum-coated example of why we need to have -stable and -dev branches for ports. I used to disagree with this, because I thought it would create additional work load. I have come to think more favourably of the idea, because you can make more daring commits on a -dev branch and don't have to quick-fix everything that goes wrong. Also the time between a MFC does not have to be very long. A week should be more than enough time to uncover and solve all problems. So the delay to get updates and fixes on the -stable branch is not very long. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
On 09/17/2010 00:41, Doug Barton wrote: On 9/16/2010 6:15 PM, Doug Barton wrote: On 9/16/2010 3:35 PM, Anonymous wrote: Dominic Fandreykamik...@bsdforen.de writes: On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. My guess is to uncover *early* build failures that exp-run didn't catch. We shouldn't use our users to beta-test infrastructure changes. Sorry, I'm not feeling well atm and realize that I didn't write what I was thinking here. What I intended to say was that we _don't_ intentionally use the ports system to force our users to beta test changes. I think it goes without saying that we _shouldn't_ do this, although I think that changes like this are a platinum-coated example of why we need to have -stable and -dev branches for ports. Doug I agree with this to an extent. Having two branches while being a nice idea is not really needed with some of the version control software that is out there. Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree. This would allow the same work that is being done on ports right now continue to happen with less effort and greater amount of cooperation between users and developers alike. The ports tree is a prime example of why we need a distributed version control. Personally I would love to be able to say HEY! I just made these changes to this port because it was not acting right and you can pull my patch for it here: http://host/repo/. Once tested by whomever Joe Blow Committee they can choose to modify it further test and or push it to the main tree where others can update from. Main Tree Users pull and clone from here | `- Dev CloneDevs pull and clone from here and push to main Ports is a distributed project being used in an old non distributed version control system. If this is going to get anywhere something needs to change and it needs to start from the ground up. Lets do it! no excuses, it does not take very long to convert to mercurial including keeping history intact and there is front-ends for this all over the place. -- jhell,v ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
jhell jh...@dataix.net wrote: ... Mercurial being the distributed version control that it is allows you to clone, make the changes you need to the clone test it thoroughly and then either push or pull them to the main tree ... At the risk of starting the VCS variant of the vi vs emacs wars :) why Mercurial (rather than, say, GIT or SVK)? And no, I have nothing against Mercurial. I don't know _any_ distributed VCS well enough to have an opinion of which would be best suited. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
* Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. I second the question. Revision bump seem absolutely unnecessary. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amd...@amdmi3.ru ..: jabber: amd...@jabber.ruhttp://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: autoconf update
On 16/09/2010 19:17, Dmitry Marakasov wrote: * Dominic Fandrey (kamik...@bsdforen.de) wrote: Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. I second the question. Revision bump seem absolutely unnecessary. There was the sweeping commit reason in another thread. But I don't really think it would have been a sweeping commit if it weren't for the version bump. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
autoconf update
Just out of curiosity, why a version bump because of a build dependency? I don't think an autoconf update should have an effect on any /running/ software but build systems. And I don't see how rebuilding all the software improves it. This is not a criticism - I just think there is something I don't understand and that worries me. Regards -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
