requesting for changes to be sent to debian before sponsoring an upload
Lucas Nussbaum
lucas at lucas-nussbaum.net
Fri Jun 20 06:15:36 BST 2008
On 19/06/08 at 13:06 -0700, Jordan Mantha wrote:
> On Thu, Jun 19, 2008 at 10:07 AM, Reinhard Tartler <siretart at ubuntu.com> wrote:
> > Sebastien Bacher <seb128 at ubuntu.com> writes:
> >
> >> Le jeudi 19 juin 2008 à 08:09 -0700, Jordan Mantha a écrit :
> >>
> >>> tends to not take patches as readily when they're trying to freeze) so
> >>> I would have a really hard time blocking perfectly good packages from
> >>> being uploaded because of that.
> >>
> >> The suggestion is not to wait for the change to be available in debian
> >> and sync this one but to wait until the change is send to the bts before
> >> sponsoring the update
> >
> > This is a very good summary of your proposal. We perhaps should
> > therefore ask all sponsors of merges to insist references to bugreports
> > that document why that change is kept during the merge.
> >
> > The bugreport should go to ubuntu, if it is an ubuntu-only change and to
> > debian, if the developer (sponsor or contributing developer) think the
> > change might be acceptable for debian.
> >
>
> Combining thoughts from this and Lucas' thread, would it be reasonable
> to have a README.Ubuntu (or similar) where we specifically document
> the divergence? I'm not a big fan of epic changelog entries and I
> think it kind of leads people to be too terse.
This could be made optional, for packages with lots of changes.
Something like:
You must properly document the changes you make to the software. For each
change, explain the rationale for the change (possibly referencing a
Launchpad and/or an upstream bug report), and whether the change is
Ubuntu-specific, or might be a candidate for a merge upstream.
The changes must be fully documented in the changelog entries since the
last upstream changelog entry[*], or in a debian/README.Ubuntu file (if
there are too many changes, in that case, reference the README.Ubuntu
file in the changelog).
[*] Means that if we have:
1.0-2ubuntu3
1.0-2ubuntu2
1.0-2ubuntu1
1.0-2
1.0-1ubuntu1
1.0-1
All the changes must be described in 1.0-2ubuntu3, 1.0-2ubuntu2, or
1.0ubuntu1. You don't need to repeat the list of changes in
1.0-2ubuntu3. This doesn't change the current practice.
--
| Lucas Nussbaum
| lucas at lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas at nussbaum.fr GPG: 1024D/023B3F4F |
More information about the ubuntu-devel
mailing list