On Wed, Mar 25, 2009 at 02:00:19PM +, James Westby wrote:
On Mon, 2009-03-23 at 18:41 +0100, martin f krafft wrote:
I will probably be there and I am definitely interested in doing
something vcs-pkg. I am a little weary though about doing something
in a Debian/Ubuntu-only context,
also sprach Stefano Zacchiroli z...@debian.org [2009.03.25.1625 +0100]:
Martin, given that you are also among DebConf organizers, how about
hosting *at* DebCamp a vcs-pkg meeting? We can announce it here and
see whether other people, not necessarily related to Debian, are
willing to attend
Hi everybody,
my name is Hauke (yes, I use my middle name for everyday talk) and I'm a
Debian Maintainer who's interested in this project.
Enough introduction? :)
Some time ago I started contributing to svn-buildpackage, a build helper
for Debian packages which are stored in subversion
I've a simple problem with apparently a not so simple solution.
Before the advent of stuff like topgit, we all used patch stacks in
which you de facto have that the n-th patch (implicitly) depends on
all n-1 patches. When migrating to stuff like topgit you have the
ability to structure the patches
Stefano Zacchiroli z...@debian.org writes:
Would you just give up and declare the patches as depending on each
other according to the stack discipline? [1] ... or would you rather
figure out a clever way to detect real patch dependencies
automatically?
With quilt you can use `quilt graph' to
Hello,
I am trying to find a good workflow to maintain a package in git. The
package requires several patches to its configure.ac and Makefile.am
files, and upstream is generally too overworked to be able to review and
integreate patches.
I also want to stick to existing tools like
Enrico Zini enr...@enricozini.org writes:
The way I figured so far is this:
1. git-import-dsc --pristine-tar
2. branch off upstream and create a topic branch
3. do my changes and test them
4. commit only the files that I have changed, and not the files that
autotools has
Twas brillig at 23:07:49 06.03.2009 UTC+06 when dotted...@dottedmag.net did
gyre and gimble:
** Scenario 3. Full-blown development.
This is scenario for the packages which need the lot of work downstream
(e.g. kernel).
Branches:
upstream
topic-A
topic-B
...
master
Tree layout:
foo/
Twas brillig at 22:14:39 05.03.2009 UTC+06 when dotted...@dottedmag.net did
gyre and gimble:
** Scenario 2. Small fixes.
This is scenario for the packages which need the small non-overlapping
fixes here and there. This is also easiest scenario to use.
Branches in repository:
master
upstream
Twas brillig at 23:07:49 06.03.2009 UTC+06 when dotted...@dottedmag.net did
gyre and gimble:
MG diff: diff: v...@version@:foo foo
FIX:
diff: v...@version@:foo foo
--
pgpP4tkfJ0ElJ.pgp
Description: PGP signature
___
vcs-pkg-discuss mailing
Twas brillig at 14:45:05 05.03.2009 UTC+01 when madd...@debian.org did gyre and
gimble:
mfk I hope that's not asking too much, and sorry for the late reply!
Well, we really need some introductory information for gear. Thanks for
forcing me for finally writing it down :) I will keep page
Hello,
gear [1] is a set of tools developed in course of Sisyphus project,
grouped around the idea of storing source code for packages in the git
repository with flexible structure.
Unfortunately there is no introductory information in English, but there
are extensive manpages [2] and Russian
Hi,
I have been meaning to write this up for a long time now, since
I vaguely made a promise to do so last Debconf. I have also been
wondering about the inefficiencies in my work-flow, but I kept
postponing my analysis since there were still large gaps in my
packaging automation since
Asians Know the Score on the Jews
by Ian Mosley
February 15, 2009
An Australian News article reports A Chinese bestseller titled The Currency
War describes how Jews are planning to rule the world by manipulating the
international financial system. The book is reportedly read in the highest
Asians Know the Score on the Jews
by Ian Mosley
February 15, 2009
An Australian News article reports A Chinese bestseller titled The Currency
War describes how Jews are planning to rule the world by manipulating the
international financial system. The book is reportedly read in the highest
Title: util
Evrika Group - cursuri de perfectionare :
- contabilitate costul cursului este de 300 ron cu incepere din23februarie 2009.
-expert fiscal costul cursului este de 1000 ron cu incepere in04 martie 2009.
-inspector protectia muncii studii medii
Wealth of U.S.A. Plundered by Jews
Thursday, 05 February 2009
By Texe Marrs
It's all over the media, how one Wall Street crook, Bernie Madoff, masterminded
the greatest Ponzi scheme in history. Bernie ripped off investors to the tune
of $50 billion, and they're still counting.
Fifty billion!
If you want to know who the real establishment is in America and around the
world, the real power behind the so-called military-industrial complex, the
real maleficent power that has led this world to inexorable conflict, war,
hatreds, destruction of real human values, morality, conscience
On Thu, Dec 18, 2008 at 09:26:17PM +0100, martin f krafft wrote:
Do you know of any instances of cross-distro collaboration where the
VCS is shared between packagers?
Have any of you reached out to other distros' packagers? Would you
share your experiences?
For packaging OCaml stuff, we are
Title: util
Evrika Group - cursuri de perfectionare :
- contabilitate costul cursului este de 300 ron cu incepere din25 ianuarie 2009.
-expert fiscal costul cursului este de 1000 ron cu incepere in21 ianuarie2009.
-inspector protectia muncii studii
Hey folks,
Do you know of any instances of cross-distro collaboration where the
VCS is shared between packagers?
Have any of you reached out to other distros' packagers? Would you
share your experiences?
Cheers,
--
.''`. martin f. krafft madd...@d.o Related projects:
: :' : proud
Hi,
On Thu, Dec 18, 2008 at 09:26:17PM +0100, martin f krafft wrote:
Do you know of any instances of cross-distro collaboration where the
VCS is shared between packagers?
Have any of you reached out to other distros' packagers? Would you
share your experiences?
you might want to stop
Hi,
i'm Ronny Pfannschmidt a CS student and one of the developers of the
pida ide.
Im interested in the vcs-pkg project, cause the ide needs a reasonably
sane abstraction for vcs's and the vcs-pkg project is aiming for
discussing/implementing that.
I already started a simple implementation in
On Mon, Dec 01, 2008 at 05:09:58PM +, James Westby wrote:
Why you don't think it would be a good idea?
I'm not sure whether providing branches for each VCS is a good idea,
as I'm not sure it would help collaboration that much. If I grab a
bzr branch to work on a feature, and you want to
On Mon, 2008-12-01 at 09:15 +0100, Stefano Zacchiroli wrote:
I meant to ask whether you plan to look at bzr access logs and compare
them with HTTP access logs to source packages from the archive. The
goal of that would be to evaluate how many users shift to bzr for
retrieving Ubuntu source
On Sun, Nov 23, 2008 at 02:25:14PM +0100, martin f krafft wrote:
(b) I provide the pristine source and a quilt series in
debian/patches, which applies, and thus gives very specific
information about how the upstream source gets altered before
building the Debian package.
On Thu, 2008-11-27 at 09:28 +, James Westby wrote:
Hi,
If you go visit
http://package-import.ubuntu.com/
you will find bzr branches available for (almost) all Ubuntu source
packages. These branches are a new service available to all Ubuntu
developers.
Hi,
Paul suggested that I
Hi,
If you go visit
http://package-import.ubuntu.com/
you will find bzr branches available for (almost) all Ubuntu source
packages. These branches are a new service available to all Ubuntu
developers.
These Bazaar branches are available for anyone to use in any way
that is useful to them. I
also sprach Adeodato Simó [EMAIL PROTECTED] [2008.11.22.1838 +0100]:
* attachment: New plugin for uploading and managing attachments.
This is now enabled on vcs-pkg.org with a maxsize of 50Kb and
limited to image/* and text/* mime types.
--
.''`. martin f. krafft [EMAIL PROTECTED]
: :' :
also sprach Sam Liddicott [EMAIL PROTECTED] [2008.11.24.1549 +0100]:
how do you or does it select the commits/branches to turn into
patches,
it has a concept of origin and release.
It does a git-export on origin and then patches from
origin..release
I assume you mean git-archive to create
also sprach Sam Vilain [EMAIL PROTECTED] [2008.11.20.2221 +0100]:
potentially do this; I don't know that there is a normal UI way of doing
it[1]; it's the sort of thing I normally do using my 'git-amend' script
(http://utsl.gen.nz/git/git-amend ) which just pops open HEAD in an
editor and lets
* martin f krafft wrote, On 22/11/08 13:57:
also sprach Sam Liddicott [EMAIL PROTECTED] [2008.11.19.1533 +0100]:
err how shall I post it for comment?
As I said in the other mail, ikiwiki does not really do attachments
yet, I think. If someone wanted to work out how to do that,
On Thu, Nov 20 2008, Sam Vilain wrote:
On Thu, 2008-11-20 at 12:56 -0600, Manoj Srivastava wrote:
Manoj, could you detail a particular scenario where you had conflicts
between the topic branches ?
Sure. Back when I was still the sole maintainer of refpolicy, I
had a branch where
On Wed, Nov 19 2008, Nicolas Duboc wrote:
Manoj, could you detail a particular scenario where you had conflicts
between the topic branches ?
Sure. Back when I was still the sole maintainer of refpolicy, I
had a branch where we had a Debian specific user role called netuser --
this
On Tue, Nov 18, 2008 at 04:22:08PM -0800, Russ Allbery wrote:
The tmp-merge branch doesn't have this problem
since it's branched off upstream and doesn't have your old B and C
branches merged, and by the time you merge tmp-merge into master, you have
all of your conflicts resolved already and
Sam Liddicott said on Wed, Nov 19, 2008 at 02:33:09PM -:
I'm lately playing with building rpm's from GIT and SVN repositories.
You may find what I'm doing around project-builder interesting then. I'd
be happy to receive feedbacks ... and contributions ;-)
Cf:
On Mon, Nov 17, 2008 at 03:56:06PM -0800, Russ Allbery wrote:
Manoj Srivastava [EMAIL PROTECTED] writes:
Well, I have seen this happen.
a) update the upstream branch (merge from remote/upstream, or
git_load_dirs).
b) Merge upstream branch into topic branches; resolve
On Tue, Nov 18 2008, Nicolas Duboc wrote:
On Mon, Nov 17, 2008 at 03:56:06PM -0800, Russ Allbery wrote:
Manoj Srivastava [EMAIL PROTECTED] writes:
Well, I have seen this happen.
a) update the upstream branch (merge from remote/upstream, or
git_load_dirs).
b) Merge
Manoj Srivastava [EMAIL PROTECTED] writes:
On Tue, Nov 18 2008, Nicolas Duboc wrote:
Rather than using rerere, I create a temporary merge branch based off
upstream and merge each topic branch into it in sequence, and then
merge the temporary merge branch into the integration branch, which
martin f krafft [EMAIL PROTECTED] writes:
also sprach Russ Allbery [EMAIL PROTECTED] [2008.11.18.0056 +0100]:
Rather than using rerere, I create a temporary merge branch based off
upstream and merge each topic branch into it in sequence, and then
merge the temporary merge branch into the
On Sun, Nov 16 2008, martin f krafft wrote:
But this script will checkout the build branch and try to merge
the upstream branch in. That should fail due to the same conflicts
which were resolved in the deb/conffile-location branch. That's
actually what I experience with my tests.
Manoj Srivastava [EMAIL PROTECTED] writes:
Well, I have seen this happen.
a) update the upstream branch (merge from remote/upstream, or
git_load_dirs).
b) Merge upstream branch into topic branches; resolve conflicts.
c) Merge topic branches into the integration branch (master,
On Thu, 2008-11-13 at 10:11 -0500, James Westby wrote:
No, why? Short commit IDs are usually enough in Git.
Why not use [f] then?
The short ID may be unambiguous when you create the entry, but it's not
future proof. The chances of a collision increase over time.
Right, but every digit
also sprach Nicolas Duboc [EMAIL PROTECTED] [2008.11.16.1700 +0100]:
There's one point I didn't really understand and with which I have a
problem when I tried to switch my jython package to git.
Hm, I really ought to update the article and state that it is aged.
The concepts still hold, but the
On Sat, Nov 15 2008, martin f krafft wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.11.14.0719 +0100]:
f) edit ./debian/changelog, adding in any additional language. I
generally keep my commit messages and changlog entries distinct,
since commit messages explain the
On Sat, Nov 15 2008, martin f krafft wrote:
also sprach Petr Baudis [EMAIL PROTECTED] [2008.11.14.1301 +0100]:
In the long run, I really want to supersede Closes: anyway.
Ideally, the bug gets marked 'fix-committed' when a signed-off
commit closing the bug hits the repo (or a tag like
On Thu, Nov 13, 2008 at 10:11:15AM -0500, James Westby wrote:
You mean [fc5473a06be960382582ddbfb40e2a5f824be122] don't you?
No, why? Short commit IDs are usually enough in Git.
Why not use [f] then?
Well, even thought the likelihood of clashes increase trivially with
time, we are in the
On Fri, Nov 14, 2008 at 07:42:02AM +0100, martin f krafft wrote:
also sprach Martin Bähr [EMAIL PROTECTED] [2008.11.13.1540 +0100]:
On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote:
Except, of course, there is no such thing as an SVN-Commit. r123
is a state, a snapshot, the
* martin f krafft [Fri, 14 Nov 2008 07:42:02 +0100]:
Yes, but we are talking about commits, about changes which resolve
a given bug. It's only SVN's limitation that you cannot do 'svn show
r123' and get what you want to see.
% svn diff -c 123
HTH,
--
Adeodato Simó
On Wed, Nov 12, 2008 at 01:20:10PM +0100, Stefano Zacchiroli wrote:
Following the (good) path of Closes, it should probably be something
like [Commit: fed3f3d]. Also, can't it be put inside the same
parentheses than Closes, as in (Closes: #7005180, #7005181; Commit:
fed3f3d).
If we really want
On Wed, Nov 12, 2008 at 11:09:45AM -0500, James Westby wrote:
On Wed, 2008-11-12 at 08:39 +0100, martin f krafft wrote:
also sprach Guido Günther [EMAIL PROTECTED] [2008.11.08.1419 +0100]:
Does this look like a worthwhile extension to the current changelog
format? For me it makes
On Thu, Nov 13, 2008 at 10:40:15AM +0100, Guido Günther wrote:
I don't have a need for it either - just iff we want to have a
qualifier inside the braces we should at least use the type of VCS
not only Commit:.
OK, but note that there are drawbacks. For example if we go for
(Git:af14e5) that
Am Donnerstag, den 13.11.2008, 12:54 +0100 schrieb Adeodato Simó:
Though I agree with your reasoning here, I find (2) a tad too verbose
(mostly because of the colon appearing twice, which requires two passes
from your brain, if you see what I mean). May I suggest:
3) (Closes: #1234567,
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.11.13.1109 +0100]:
OK, but note that there are drawbacks. For example if we go for
(Git:af14e5) that would be annoying, as parsing will depend on the
number of supported, or known, VCS. That was a wrong design choice
of Vcs-* which I don't
On Thu, Nov 13, 2008 at 11:22:56AM +0100, martin f krafft wrote:
But instead of one parser, I'd really rather think of it as a number
of parsers, each getting a chance. So Closes would be handled by the
dak-bts parser, and Git: by a git parser, SVN: by an SVN parser,
etc.
Consider the
On Thu, Nov 13, 2008 at 01:42:44PM +0100, martin f krafft wrote:
Except, of course, there is no such thing as an SVN-Commit. r123 is
a state, a snapshot, the commit if the diff against r-1. I think hg
is like Git
well, in git the commit-ids also represent the state of the whole tree
like in
* James Westby [Wed, 12 Nov 2008 11:09:45 -0500]:
How would this differ from using annotate on the changelog? Do some
people write the changelog at the end?
I think that's what git-dch(1) does.
--
Adeodato Simó dato at net.com.org.es
Debian Developer
also sprach Guido Günther [EMAIL PROTECTED] [2008.11.08.1419 +0100]:
Does this look like a worthwhile extension to the current changelog
format? For me it makes reviewing changes a lot easier.
I think this is very important to have, but why put them at the
front? Changelogs are for consumption
Hi,
I think i'd be nice if once could link changelog entries back to VCS
commits more easily (to see how a bug actually got fixed). Git-dch has
support for including parts of the SHA1 for some time so together with
Vcs-Browser we can easily link back to the VCS:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.04.0735 +0200]:
Right. The diff.gz is what the buildd's are fed, each of the
patchsets in ./debian/topic recreate exactly the feature branches used
to develop the code, the orig.tar.gz is the upstream branch. So, just
using the
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.02.2006 +0200]:
Now suppose you have your _own_ heirarchy of debian
directories. You can just change the submodule location, which is only
referred to in the build branch, and continue with ever other feature
branch inherited
On Mon, Oct 06 2008, martin f krafft wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.04.0735 +0200]:
Right. The diff.gz is what the buildd's are fed, each of the
patchsets in ./debian/topic recreate exactly the feature branches used
to develop the code, the
On Mon, Oct 06 2008, martin f krafft wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.02.2006 +0200]:
Now suppose you have your _own_ heirarchy of debian
directories. You can just change the submodule location, which is only
referred to in the build branch, and
Hi,
Perhaps I should wait after drinkina high sugar content drink
before posting.
On Mon, Oct 06 2008, Manoj Srivastava wrote:
On Mon, Oct 06 2008, martin f krafft wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.04.0735 +0200]:
Right. The diff.gz is what the
On Thursday 02 October 2008 20:33:00 Manoj Srivastava wrote:
On Thu, Oct 02 2008, George Danchev wrote:
Quoting Manoj Srivastava [EMAIL PROTECTED]:
--cut--
Nobody is comparing git with quilt, really. Obviously you are trying
to compare different unit types as a result of muddle thinking.
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.02.0236 +0200]:
Emacs has a gret package called dvc - that provides a consistent
front end to all the VCS' I mentioned above. You use the same commands
irrespective of your actual VCS. Perhaps some front ends like that can
be
Quoting Manoj Srivastava [EMAIL PROTECTED]:
--cut--
Well, You look at the public branches to see the divergence. and
if you think my repo does not match the sources (which is a trust
issue, I suppose), You'll have ot do whatever you need to, since
obviously you do not believe my
On Tue, Sep 30, 2008 at 10:27:13PM +0200, Martin Bähr wrote:
On Tue, Sep 30, 2008 at 02:27:34PM -0500, Manoj Srivastava wrote:
Not really. I prefer to have the source packages be unpackged
even on a machine which does not run Debian, using just plain old tar
and patch. Thus I tend
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.01.0302 +0200]:
Only if you like working with patch series, and prefer to lose
all the information that the original VCS contained. I prefer to see
the whole history, not just a snapshot, when I am joining a development
effort.
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.10.01.0302 +0200]:
This is a strawman, really. The options are not the giant big
diff vs quilt (equally horrible, IMHO). The options are 3.0 (quilt) vs
3.0 (git). I would have gone for the 3.0 (git) format myself, except
that it
On Wed, Oct 01 2008, martin f krafft wrote:
Assuming we have a number of feature branches, we may well have to
resolve conflicts among them, so an integration branch seems like
the right way forward. So unless we just build the package from the
integration branch to produce a monolithic
Quoting Manoj Srivastava [EMAIL PROTECTED]:
On Wed, Oct 01 2008, martin f krafft wrote:
Assuming we have a number of feature branches, we may well have to
resolve conflicts among them, so an integration branch seems like
the right way forward. So unless we just build the package from the
On Wed, Oct 01 2008, George Danchev wrote:
Quoting Manoj Srivastava [EMAIL PROTECTED]:
On Wed, Oct 01 2008, martin f krafft wrote:
Assuming we have a number of feature branches, we may well have to
resolve conflicts among them, so an integration branch seems like
the right way forward. So
* Manoj Srivastava [EMAIL PROTECTED] [081001 20:46]:
This might be you, but not the rest of the world. Also, people are
hardly trying to develop large and nifty features in their
debian/patches/ seriously. These are for tracking divergencies, not
accepted upstream X.Y for any reason.
On Mon, Sep 29, 2008 at 08:43:18AM +0200, martin f krafft wrote:
[..snip..]
If git-buildpackage expects master, then it is inflexible; you
should be able to tell it to build from build.
git-buildpackage builds from any branch you tell it to.
-- Guido
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.09.29.1908 +0200]:
My goal is not to have a patch series in a Debian package. My goal
is to be able to develop software that is packaged for Debian --
This argument has been taken ad infinitum on debian-devel. The idea
of a patch series in
On Mon, Sep 29 2008, martin f krafft wrote:
also sprach Manoj Srivastava [EMAIL PROTECTED] [2008.09.29.1908 +0200]:
My goal is not to have a patch series in a Debian package. My goal
is to be able to develop software that is packaged for Debian --
This argument has been taken ad infinitum on
On Sun, Sep 28, 2008 at 11:58:37AM +0200, Stéphane Glondu wrote:
I've read topgit's README.source. I am currently experimenting with it.
Shameless OT: Stéphane, I had a look at topgit myself, and I was going
to propose on top of it a workflow to be adopted for *all*
debian-ocaml-maint packages
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.09.28.1756 +0200]:
Thinking out loud: remember the bug you (or me, doesn't matter)
reported against debcheckout in Debian to better support, via
heuristics, topgit? Well, once I have time to fix it :), we can
ask debcheckout if some
On Tue, Sep 23, 2008 at 08:25:38AM +0200, martin f krafft wrote:
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.07.15.2031 +0200]:
I'm a happy (Debian) package maintainer which have just switched
most of his packages from svn to git. All nice, finally I can work
directly on a real
also sprach Stefano Zacchiroli [EMAIL PROTECTED] [2008.07.15.2031 +0200]:
I'm a happy (Debian) package maintainer which have just switched
most of his packages from svn to git. All nice, finally I can work
directly on a real source code tree instead of fiddling with patch
management system.
On Thu, Aug 21, 2008 at 4:31 PM, martin f krafft [EMAIL PROTECTED] wrote:
also sprach Teemu Ikonen [EMAIL PROTECTED] [2008.04.03.1058 +0200]:
I've made a python program (actually a rather thin wrapper around git
and various tools from patchutils) which makes this transformation
from an
On Fri, 2008-08-08 at 14:06 -0300, martin f krafft wrote:
Hm, I am not entirely following. I understand that I can get
a topological list of branches, but why don't I need the diff from
branch-base to branch-head?
Well, if the patches can be assembled into it, why would you?
Also, what
I've not tested the tool right now, but it feel like solving many of
the concerns manoj had with patches.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
---BeginMessage---
On
On Wed, Jul 16, 2008 at 12:04:38AM +0200, Stefano Zacchiroli wrote:
On Tue, Jul 15, 2008 at 01:45:16PM -0700, Russ Allbery wrote:
[..snip..]
FWIW, I've been keeping notes on what I'm personally doing at:
http://www.eyrie.org/~eagle/notes/debian/git.html
Very interesting reading!
This
I'm a happy (Debian) package maintainer which have just switched most of
his packages from svn to git. All nice, finally I can work directly on a
real source code tree instead of fiddling with patch management system.
Nevertheless, patches are separate in topic branches which enable
knowing the
On Tue, Jul 15, 2008 at 01:38:14PM -0500, John Goerzen wrote:
I don't split out patches, but all my Debian packages live on
git.debian.org (except software where I'm the upstream, in which case
it's on my own git server). Using gitweb, people can inspect the
changelog and download diffs of
Stefano Zacchiroli wrote:
Specifically for Debian: do we have any guideline on how to do that? If
not it is probably worth to create one ...
And finally, the problem of the problems: how about the situation where
one patch for topic branch is not enough as topic branches have got
Stefano Zacchiroli [EMAIL PROTECTED] writes:
My question is whether we have a guideline about *where* to document
branch layout for a given package. Regarding Debian,
debian/README.source comes to mind quickly, but its current description
in policy does not make it clear that it is the
also sprach martin f krafft [EMAIL PROTECTED] [2008.05.18.1512 +0200]:
Since we couldn't meet in April [0] (it was too short notice), we
now have another chance from 2-7 September 2008 to meet in
Extremadura and concentrate on getting vcs-pkg further.
0.
Jelmer Vernooij [EMAIL PROTECTED] writes:
Have you seen bugs everywhere (http://www.bugseverywhere.org) ? It's a
distributed bug tracker that stores bug information as metadata in VCS
branches.
I'm currently working on URL:http://bugs.debian.org/477125 a Debian
package for Bugs Everywhere
On Fri, May 16, 2008 at 04:04:20PM -0400, Joey Hess wrote:
Raphael Hertzog wrote:
I totally agree that we need to make our changes more visible. In the
openssl case, the patch in question is inside the .diff.gz and you don't
notice it in the unpacked source package. I tend to give a look to
2008/5/16 martin f krafft [EMAIL PROTECTED]:
Please Cc vcs-pkg-discuss@lists.alioth.debian.org on this thread!
Done.
also sprach Raphael Hertzog [EMAIL PROTECTED] [2008.05.16.1654 +0100]:
Add to this that each patch should have some standardized header on top
stating:
- a description of
also sprach Donnie Berkholz [EMAIL PROTECTED] [2008.05.16.1853 +0100]:
http://patches.ubuntu.com/by-release/extracted/ contains patches
for both Debian and Ubuntu. It's quite useful.
Lucas Nussbaum threw the idea of having a webpage with posisbly
annotated patches for each Debian package on
also sprach Yaroslav Halchenko [EMAIL PROTECTED] [2008.04.04.0315 +0200]:
But in this case for feature branches imho a branch without multiple
merges from upstream branch looks much cleaner and it is easy to rebase
it if needed against any ref in repository (e.g. you need to apply that
branch
Both rebasing and cherry-picking don't work well with published
repos because they change commit IDs.
I don't see why cherry-picking is an issue -- it just replicates commit
(patch) into current branch from another branch. It is quite different
from rebasing where commits are moved, thus ref
Stefano Zacchiroli wrote:
However in general it is not possible to
require that all patches apply properly to pristine source. In some
(rare fortunately) cases two patches will conflict with each other on
the pristine source and you need to make one depend on the other or the
other way round.
Out of curiosity (and this is one of the places where I'm just a Git
newbie), why would I ever want to rebase and not merge? I'm currently
merging and it works great. I'm not sure what the advantage of
rebasing instead would be.
there are many use cases (there are some in git rebase
On Mo, 2008-03-17 at 18:38 +, James Westby wrote:
Support common tasks easily
---
There are certain common tasks which should be made easy to do.
* New upstream release
- The process of incorporating a new upstream release, making
the necessary
On Tue, 2008-03-25 at 18:49 +0100, Jelmer Vernooij wrote:
I think there is a point missing here:
* Importing patches from other distros
If this was easier, I think sharing patches across distros could be more
common. More specifically, it could help the cooperation between Debian
and
201 - 300 of 308 matches
Mail list logo
