patches, bundles, etc
BTW, what's the policy on submitting sizable changes with multiple revisions, such as the configurable keybindings? Is it okay to send a changeset bundle, or do the changes need to be flattened into a single patch? It probably doesn't matter for small changes, but it might be nice to include the history for large changes. -- Scott
It is always difficult for users to track changes between larger patches. I think Johannes did it right with his css-prototype repository. It is not the best thing to directly integrate bigger patches into mainline as they might be yet incomplete or lead to instabilities. Thus, having additional repositories is a good thing. If the features are stable enough and are thought to be useful, they can be simply merged into the main tree. In the Git world, where nearly everything is decentralized, it frequently happens that every core developer has an own repository for experimental changes. Of course this approach might not be always practical for smaller projects but we all can benefit from the fundamental idea of decentralisation. For Dillo, experimental per-feature repositories would be very useful before not well-tested patches go into mainline and risk the application's stability. Hence, I advocate that we make use of external repositories more frequently assuming it makes sense based on the changes' size. --Tim
On Tue, Feb 24, 2009 at 06:35:50PM +0100, Tim Nieradzik wrote:
It is always difficult for users to track changes between larger patches. I think Johannes did it right with his css-prototype repository.
+1. Forking a repository and merging changes in small pieces is the way to go. Regards, Jeremy Henty
* Tim Nieradzik <tim.nieradzik@gmx.de> wrote:
For Dillo, experimental per-feature repositories would be very useful ...
Yes, I agree. I make feature branches all the time, and I think they're great. But that's not really what I was getting at. Basically, there are a few different ways to merge... - patch: send the output of 'hg diff' to the list, apply it via 'patch', and commit one revision - bundle: send the output of 'hg bundle' to the list, apply it via 'hg unbundle', and commit with full history - repository: send an URL to the list, apply via 'hg pull' and 'hg merge', and commit with full history I've seen patch and repository methods used here, but haven't really seen any bundles. So, I'm just wondering if that sort of thing is acceptable. I think it's probably preferable to plain patches, and easier than hosting repositories. -- Scott
The copyright notice in source files use an outdated FSF Address -- By by ... Detlef
Detlef wrote:
The copyright notice in source files use an outdated FSF Address
Hmm...I see that the GPLv3 says "You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>." It might be good for us to change to that.
The license notice in GPL v3 source files use an outdated FSF Address. This version use the suggestions from Place (corvid) Things to do: dw/fltkcomplexbutton.hh: GNU Library General Public License v2 (or later) dw/fltkcomplexbutton.cc: GNU Library General Public License v3 (or later) Such licenses does not exits. LGPL is GNU Lesser General Public License Some Files mention GPL v3, but the license Note is incomplete. Some Files are missing a copyright / license Note -- By by ... Detlef
On Wed, Feb 25, 2009 at 05:39:13PM +0100, Detlef Riekenberg wrote:
The license notice in GPL v3 source files use an outdated FSF Address. This version use the suggestions from Place (corvid)
Good! Committed.
Things to do: dw/fltkcomplexbutton.hh: GNU Library General Public License v2 (or later) dw/fltkcomplexbutton.cc: GNU Library General Public License v3 (or later) Such licenses does not exits. LGPL is GNU Lesser General Public License
Some Files mention GPL v3, but the license Note is incomplete. Some Files are missing a copyright / license Note
OK, if you can submit a patch that addresses those problems, please do so. -- Cheers Jorge.-
On Tue, Feb 24, 2009 at 12:22:21PM -0700, Scott Scriven wrote:
* Tim Nieradzik <tim.nieradzik@gmx.de> wrote:
For Dillo, experimental per-feature repositories would be very useful ...
Yes, I agree. I make feature branches all the time, and I think they're great. But that's not really what I was getting at. Basically, there are a few different ways to merge...
- patch: send the output of 'hg diff' to the list, apply it via 'patch', and commit one revision
- bundle: send the output of 'hg bundle' to the list, apply it via 'hg unbundle', and commit with full history
- repository: send an URL to the list, apply via 'hg pull' and 'hg merge', and commit with full history
I've seen patch and repository methods used here, but haven't really seen any bundles. So, I'm just wondering if that sort of thing is acceptable. I think it's probably preferable to plain patches, and easier than hosting repositories.
We have been using bundles a few times. But this may have been off list. I would suggest to use plain patches for simple short changes, as they are easy to review and immediately viewable in the mail archives. For longer living feature branches a separate repository can be helpful. Check out http://freehg.org it's really simple to setup a repo there. Bundles can be used in some cases, but I wouldn't recommend them for general use on the mailling list. BTW: It seems mercurial itself also suggests patches according to: http://www.selenic.com/mercurial/wiki/index.cgi/ContributingChanges Cheers, Johannes
participants (7)
-
corvid＠lavabit.com -
dillo-dev＠toykeeper.net -
jcid＠dillo.org -
Johannes.Hofmann＠gmx.de -
onepoint＠starurchin.org -
tim.nieradzik＠gmx.de -
wine.dev＠web.de