headers
James Westby | 17 Mar 19:35

Requirements of a VCS packaging tool

Hi,

Martin asked that we look at what such a tool needs to do,
so here's my attempt at starting that discussion.

I do not believe this document will be entirely complete, please
add anything else that you think is important. This is obviously
also coloured by my own experience and views from developing a
tool, so please help to remove those biases.

Support Co-operation
--------------------

There are many workflows which could be adopted, but we require
that the any solution enhances our ability to co-operate.

There are many ways in which we should be able to co-operate

  * With upstream
    - Submitting patches back in their preferred format.
      - This will often be satisfied a plain patch that applies cleanly
        to the latest version or the tip of their development branch.
      - Providing it in their VCS's preferred format is another 
        possibility that many upstreams may prefer. However I doubt that
        any would refuse a patch not delivered using their VCS.
    - Taking individual patches from upstream in order to solve specific
      issues, for instance to fix a security bug in a stable release.

  * With other distros
    - If one distro uses a patch then others may or may not want to
(Continue reading)

Permalink | Reply |
headers
James Westby | 17 Mar 19:46

Re: Requirements of a VCS packaging tool

On Mon, 2008-03-17 at 18:38 +0000, James Westby wrote:
> Hi,
> 
> Martin asked that we look at what such a tool needs to do,
> so here's my attempt at starting that discussion.

Looking back this isn't what Martin asked for at all, oops.

I'll see if I can provide what he did want tomorrow.

I think that some guiding principles for where we want to
end up are worth having though.

Thanks,

James
Permalink | Reply |
headers
martin f krafft | 17 Mar 23:18
Favicon

Re: Requirements of a VCS packaging tool

also sprach James Westby <jw+debian@...> [2008.03.17.1938 +0100]:
> Martin asked that we look at what such a tool needs to do,
> so here's my attempt at starting that discussion.

As you already pointed out, this is not what I asked for, but it's
very useful nonetheless.

> I do not believe this document will be entirely complete, please
> add anything else that you think is important.

I made it a wiki page for this purpose:
  http://vcs-pkg.org/requirements/

--

-- 
 .''`.   martin f. krafft <madduck@...>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

hi! i'm a .signature virus!
copy me into your ~/.signature to help me spread!

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
Jelmer Vernooij | 25 Mar 18:49
Favicon

Re: Requirements of a VCS packaging tool

On Mo, 2008-03-17 at 18:38 +0000, 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 changes to the packaging data, and updating
>       any patches to apply to the new version should not be overly
>       complicated.
> 
>   * Submitting patches to upstream
>     - The patches that are used in the package may not apply directly
>       to the current upstream. If that is the case it should be as easy
>       as possible to rectify that for sending them upstream.

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 Ubuntu.

Cheers,

Jelmer

--

--
(Continue reading)

Permalink | Reply |
headers
Jesse Keating | 25 Mar 19:56
Favicon

Re: Requirements of a VCS packaging tool

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 Ubuntu.

And for that to work, the patches really need to be applied in part to a
pristine source.  Some of the problem is that Ubuntu is so far into
patch land that pulling a discrete fix out is nearly impossible.  Also,
diffs of diffs are an abomination (:

--

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

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 Ubuntu.

And for that to work, the patches really need to be applied in part to a
pristine source.  Some of the problem is that Ubuntu is so far into
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 25 Mar 23:09
Favicon

Re: Requirements of a VCS packaging tool

also sprach Jesse Keating <jkeating <at> redhat.com> [2008.03.25.1956 +0100]:
> And for that to work, the patches really need to be applied in
> part to a pristine source.  Some of the problem is that Ubuntu is
> so far into patch land that pulling a discrete fix out is nearly
> impossible.  Also, diffs of diffs are an abomination (:

Yes, that's been our main complaint about the way in which Ubuntu
claims to be giving back to Debian.

This sharing patches between distros is primarily why I started this
vcs-pkg effort. I don't think it's worth trying to work with Ubuntu
at this stage, but if Debian and Fedora ended up exchanging patches
for prominent packages, or rather: if our two distros just worked on
the same package repository and built our own packages from the same
source, that would be a major step, which Ubuntu could not ignore in
the long run. So while we've found it to be unnecessarily hard to
work with Ubuntu in the past, this way forward would basically
impose the burden on them.

--

-- 
 .''`.   martin f. krafft <madduck <at> debian.org>
: :'  :  proud Debian developer, author, administrator, and user
`. `'`   http://people.debian.org/~madduck - http://debiansystem.info
  `-  Debian - when you have better things to do than fixing systems

"when zarathustra was alone... he said to his heart: 'could it be
 possible! this old saint in the forest hath not yet heard of it, that
 god is dead!'"
                                                 - friedrich nietzsche
(Continue reading)

Permalink | Reply |
headers
martin f krafft | 26 Mar 16:30
Favicon

Re: Requirements of a VCS packaging tool

also sprach martin f krafft <madduck <at> debian.org> [2008.03.25.2309 +0100]:
> source, that would be a major step, which Ubuntu could not ignore in
> the long run. So while we've found it to be unnecessarily hard to
> work with Ubuntu in the past, this way forward would basically
> impose the burden on them.

Let me clarify this a bit, because I certainly have not given up on
Ubuntu. In fact, I would still very much like to see better
cooperation with Ubuntu. That said, I am also aware and should point
out that several Ubuntu teams work incredibly well with their Debian
counterparts already.

The issue I alluded to is that certain people around Ubuntu keep
asserting how they're doing good and giving back to Debian, when in
fact that's not the general case. But this totally isn't within the
scope of our discussion here, and I don't want to rehash the topic,
to be honest.

I think we need to recognise that Ubuntu is just driven differently
than Debian and Fedora and accept as a fact that they *cannot* do
any more to give back to Debian because they don't have the time
and/or manpower. This is, in large part, because we (Debian) don't
make it easy for them to give back. Filing bugs and attaching
patches is exactly the kind of boring, repetitive and stupid work
that should be left to computers, we shouldn't expect Ubuntu
developers to do that just because their PR team claims that that's
what they're doing.

So assuming that Ubuntu actually wouldn't mind minimising the
patches they have to maintain, I bet that a cross-distro workflow,
(Continue reading)

Permalink | Reply |
headers
Stefano Zacchiroli | 26 Mar 08:54
Favicon

Re: Requirements of a VCS packaging tool

On Tue, Mar 25, 2008 at 02:56:18PM -0400, Jesse Keating wrote:
> And for that to work, the patches really need to be applied in part to
> a pristine source.

Ack on the basic principle. 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.

So I will relax your requirement stating that a patch in general should
not depend on anything else than the pristine source, but can depend on
some other patch which (following its dependency chain) reaches the
pristine source.

Cheers.

--

-- 
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org}  -<%>-  http://upsilon.cc/zack/
(15:56:48)  Zack: e la demo dema ?    /\    All one has to do is hit the
(15:57:15)  Bac: no, la demo scema    \/    right keys at the right time

On Tue, Mar 25, 2008 at 02:56:18PM -0400, Jesse Keating wrote:
> And for that to work, the patches really need to be applied in part to
> a pristine source.

Ack on the basic principle. However in general it is not possible to
require that all patches apply properly to pristine source. In some
(Continue reading)

Permalink | Reply |
headers
Jesse Keating | 26 Mar 12:36
Favicon

Re: Requirements of a VCS packaging tool

On Wed, 2008-03-26 at 08:54 +0100, Stefano Zacchiroli wrote:
> 
> Ack on the basic principle. 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.
> 
> So I will relax your requirement stating that a patch in general should
> not depend on anything else than the pristine source, but can depend on
> some other patch which (following its dependency chain) reaches the
> pristine source.

Sure, I didn't mean to state that it's an entirely black/white thing.  I
do think though that it should be possible to mark one patch as
dependent upon another patch and so on, to leave breadcrumbs for a
developer to extract a particular changeset.

--

-- 
Jesse Keating
Fedora -- All my bits are free, are yours?

_______________________________________________
vcs-pkg-discuss mailing list
vcs-pkg-discuss@...
http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
Permalink | Reply |
headers
James Westby | 9 Apr 23:53

Re: Requirements of a VCS packaging tool

On Mon, 2008-03-17 at 18:38 +0000, James Westby wrote:
> Support Co-operation
> --------------------

>   * With other people in the same distro
>     - The workflow should give everyone, not just one person, everything
>       needed to work on the package.

There was some discussion on this point on IRC after my
posting and I forgot to update the list on that.

My statement here is not very clear. My intention was to foster
collaboration by ensuring that everyone had access to the same
tools and workflows. For instance, if a package maintained by
you uses private, unpublished topic branches, then I may
not be able to do some things as easily as you. If I were
to only have the generated patches, then history based
merging would probably not be available to me.

I want to add another point here that is slightly different.
The workflow that is used shouldn't be obstructive to
anyone that collaborates with you. If this happens then it
takes some power away from other people.

As an example, rebasing a branch forces anyone else using that
branch to rebase as well. Then the choice of when to do this
is taken away from that person.

I don't mean to say that there isn't a place for rebasing, and
I don't want to make this discussion about implementation,
(Continue reading)

Permalink | Reply |

Gmane