Ok, I'm just going to rebut everything because I'm in that sort of mood. >P2 has a strong sense of design >and authorship, as do JOSM and osm.org itself. We don't accept any and >every patch - that way would lie chaos.
It would be good if the mechanism by which this happens were a little more transparent. Also, if there was more feedback when patches don't get make the cut. I'd love to know what happened to my 'magic roundabout' patch, for instance. >you can send a pull >request to my github account which says "hey! look! here's some code! why >not take a look?". Pull request - cool. That would be a useful tip for the git wiki page. > I see this and either think "yeah, that looks good", >which means I simply press a button and merge it in; or "hmmm, that needs >some more work", in which case I make a branch and work on it from there. I think I'm what I'm reacting to is the sense that my code has to wait "outside the tent", whereas in other environments I'm more used to (Wikipedia, and OSM editing itself), the change is "inside" to begin with, but can be rolled back. >So basically you're complaining that your edits now have to be reviewed before >they are >merged and you can't ram them down people's throats anymore? What a spectacularly poorly worded comment. Moving on. >Well, they are honest. I'd rather not mislead anyone by saying "You >must sign up for github" or "you must clone from this repository" or >anything like that. I'd write it as "Here's the easiest way: xxx (There are alternatives, see yyy)". >Yes, but this was causing lots of issues, as I'm sure you remember. Actually not - apart from my commiting changes in insufficient granularity. Happy to take your word for it, though. >I can (and frequently have) published >half-working, half-finished things on a branch and asked others to >take a look, or made a few commits on one topic before changing to >another I guess the "taking a look" is easier with Git - pulling in changes then reversing them again. >is more than made up for by the ability to >properly review things before they hit master. You're probably aware of the long-running debates about pre-commit review versus post-commit review. Quick summary: pre-commit review reduces developer activity level but improves quality. >As Richard has said, his "master" branch is the canonical 'this is >Potlatch2', so he's in charge Cool. This is the definitive statement lacking from the wiki page, which confused me. >1. You work in your sandbox, and when your work is ready, you show it off. Yeah. Well, I already did that, but I agree that having local source code version control will be beneficial. >There may be changes you make that either aren't applicable to all of >PL2 (or whatever project) or else are changes you don't want to share. Likewise, I already had such changes, and generally didn't find it too hard to avoid committing them. (But again local source code control is no doubt better.) >Sooner or later, your repo will be the canonical repo. Ok, that's not going to happen. (Only rebutting this point in order to be thorough. I don't think it matters.) >I hope this explanation >by Andy, with followup by me, explains why this is absolutely a great >direction for the project. Yes, thanks - it does make more sense now. The key things I was missing: 1) There is still a definitive repository 2) pull requests Steve On Wed, Aug 31, 2011 at 11:13 PM, Serge Wroclawski <emac...@gmail.com> wrote: > On Wed, Aug 31, 2011 at 8:28 AM, Andy Allan <gravityst...@gmail.com> wrote: > >> Yes, but this was causing lots of issues, as I'm sure you remember. >> Think of it instead as being a much more relaxing way of developing - >> you can make your changes public without needing to worry about >> stepping on anyone's toes - I can (and frequently have) published >> half-working, half-finished things on a branch and asked others to >> take a look, or made a few commits on one topic before changing to >> another. Previously I'd need to make sure it was completely finished >> and polished or open the can of worms that was svn branching. > > +1 > > The advantages are several fold. > > 1. You work in your sandbox, and when your work is ready, you show it off. > > As Andy says, this is liberating. If a new feature takes a week, or a > month, no problem. I have my private branches. I can show them to some > people, not show them to others, etc. And when it's ready, I can make > a pull request back to the project maintainer, saying "Okay, this is > now ready to be put back to the canonical branch. > > No worrying about permissions or access, or asking "May I please have > commit rights?" or not being able to save until the patch is > absolutely positively ready. As Andy says, it's more relaxed, and more > collaborative. > > 2. Private changes > > There may be changes you make that either aren't applicable to all of > PL2 (or whatever project) or else are changes you don't want to share. > > I have one of these; a stylesheet for a PL2 instance that would not be > appopriate for PL2 general use. I maintain my own repo, my own > branches, And in that way, I keep up to date without needing to be in > lock-step with Andy and Richard. > > 3. The canonical repo can change > > Let's say that the PL2 team contracts brain slugs which make them slow > and unresponsive. PL2 languishes as a result, with no bug fixes and no > new features. But during this time, your branch is up to date, has bug > fixes and accepts new features. > > Sooner or later, your repo will be the canonical repo. > > A less extreme example might be that Andy wants to see a feature "in > action" before accepting it. Maybe you're on the bleeding edge and > he's a bit cautious. > > I feel like we've been here before with Git. I hope this explanation > by Andy, with followup by me, explains why this is absolutely a great > direction for the project. > > - Serge > > _______________________________________________ > Potlatch-dev mailing list > Potlatch-dev@openstreetmap.org > http://lists.openstreetmap.org/listinfo/potlatch-dev > _______________________________________________ Potlatch-dev mailing list Potlatch-dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/potlatch-dev
