Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello,

On Thu, Apr 19 2018, Sean Whitton wrote:

> In the next month or so we (Ian Jackson and I) will be releasing a
> workflow called dgit-maint-debrebase(7) which
>
> - is patches-applied; but
> - automatically generates a perfect 3.0 (quilt) representation of the
>   Debian changes.
>
> I.e. it should satisfy everyone.

Now available from unstable.  See dgit-maint-debrebase(7),
git-debrebase(1) etc.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

> > I am okay to wait for your next invention. Last one I remember --
> > separate patches instead of single squashed patch in
> > dgit-maint-merge(7) was awesome.
> 
> Sorry but I don't understand this last sentence.  Perhaps you could
> rephrase.

I mean, that I see improvements in dgit, and, while /now/ I do not
understand what 'debrebase' is about, do trust you, that it will
improve my dgit experience even more.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello,

On Fri, Apr 20 2018, kact...@gnu.org wrote:

> [2018-04-19 10:14] Sean Whitton 
>> Hello both,
>>
>> If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
>> (quilt) will not help.  It will not introduce any additional
>> metadata.  The only change will be the addition of a patch header
>> pointing to dgit-repos.
>
> What do you mean by 'additional metadata'? Patch headers generated
> from git commits?

No, I mean separate patches.

>> Switching to dgit-maint-gbp(7) means using a patches-unapplied
>> workflow.  [...]
>
> I want to be able to do raw `dpkg-buildpackage`. I guess it means
> patches-applied workflow, am I right.

I don't think so.  The advantages of patches-applied are different.

>> In the next month or so we (Ian Jackson and I) will be releasing a
>> workflow called dgit-maint-debrebase(7) which
>>
>> - is patches-applied; but
>> - automatically generates a perfect 3.0 (quilt) representation of the
>>   Debian changes.
>>
>> I.e. it should satisfy everyone.
>
> I am okay to wait for your next invention. Last one I remember --
> separate patches instead of single squashed patch in
> dgit-maint-merge(7) was awesome.

Not sure what you're referring to here.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello,

On Fri, Apr 20 2018, kact...@gnu.org wrote:

> [2018-04-19 10:14] Sean Whitton 
>> Hello both,
>>
>> If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
>> (quilt) will not help.  It will not introduce any additional
>> metadata.  The only change will be the addition of a patch header
>> pointing to dgit-repos.
>
> What do you mean by 'additional metadata'? Patch headers generated
> from git commits?

I mean separated patches.

>> Switching to dgit-maint-gbp(7) means using a patches-unapplied
>> workflow.  [...]
>
> I want to be able to do raw `dpkg-buildpackage`. I guess it means
> patches-applied workflow, am I right.

Basically yes.

>> In the next month or so we (Ian Jackson and I) will be releasing a
>> workflow called dgit-maint-debrebase(7) which
>>
>> - is patches-applied; but
>> - automatically generates a perfect 3.0 (quilt) representation of the
>>   Debian changes.
>>
>> I.e. it should satisfy everyone.
>
> I am okay to wait for your next invention. Last one I remember --
> separate patches instead of single squashed patch in
> dgit-maint-merge(7) was awesome.

Sorry but I don't understand this last sentence.  Perhaps you could
rephrase.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

[2018-04-19 10:14] Sean Whitton 
> Hello both,
> 
> If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
> (quilt) will not help.  It will not introduce any additional metadata.
> The only change will be the addition of a patch header pointing to
> dgit-repos.

What do you mean by 'additional metadata'? Patch headers generated from
git commits?
 
> Switching to dgit-maint-gbp(7) means using a patches-unapplied workflow.
> [...]

I want to be able to do raw `dpkg-buildpackage`. I guess it means
patches-applied workflow, am I right.

> In the next month or so we (Ian Jackson and I) will be releasing a
> workflow called dgit-maint-debrebase(7) which
> 
> - is patches-applied; but
> - automatically generates a perfect 3.0 (quilt) representation of the
>   Debian changes.
> 
> I.e. it should satisfy everyone.

I am okay to wait for your next invention. Last one I remember -- 
separate patches instead of single squashed patch in dgit-maint-merge(7)
was awesome.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Jeremy Bicha]

On Thu, Apr 19, 2018 at 1:14 PM, Sean Whitton  wrote:
> Since we have submitted two sessions to DebConf18 about this new
> workflow, you can be confident the release will come before August :)  So
> what I would like to suggest is that both of you hang tight for now and
> then evaluate this new workflow.  inotify-tools can just stay how it is
> until then.

Sean, thanks for replying. This isn't an urgent issue for me, so I'm
happy to wait a few months.

Jeremy Bicha

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Sean Whitton]

Hello both,

If Dmitry wants to continue to use dgit-maint-merge(7), using 3.0
(quilt) will not help.  It will not introduce any additional metadata.
The only change will be the addition of a patch header pointing to
dgit-repos.

Switching to dgit-maint-gbp(7) means using a patches-unapplied workflow.
I assume Dmitry does not actually want to do that, but if he does, he
should be able to do this:

- `git revert` all commits to the upstream source
- `gbp pq import`
- `git cherry-pick` commits to the upstream source
- `gbp export`
- commit the new d/patches directory

Now `dgit quilt-fixup` should succeed.  Let me know if it doesn't.

There is, however, a third option.

In the next month or so we (Ian Jackson and I) will be releasing a
workflow called dgit-maint-debrebase(7) which

- is patches-applied; but
- automatically generates a perfect 3.0 (quilt) representation of the
  Debian changes.

I.e. it should satisfy everyone.

Since we have submitted two sessions to DebConf18 about this new
workflow, you can be confident the release will come before August :)  So
what I would like to suggest is that both of you hang tight for now and
then evaluate this new workflow.  inotify-tools can just stay how it is
until then.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Jeremy Bicha]

Sean,

Are you able to help out here?

I admittedly haven't really used dgit so I wouldn't really know if I
were doing things right.

Thanks,
Jeremy Bicha

On Thu, Apr 19, 2018 at 12:01 AM,   wrote:
>
> control: tags -1 help
>
> [2018-04-18 14:11] Jeremy Bicha 
>> Source: inotify-tools
>> Version: 3.14-5
>>
>> Please consider using the dgit-maint-gbp workflow instead of the
>> dgit-maint-merge workflow.
>>
>> The recent switch from 3.0 (quilt) eliminates useful context and
>> metadata from the Debian package itself. That metadata is now only
>> available in the git repo.
>> [...]
>
> Honestly, I now consider switch to 1.0 a mistake. But I do not know how
> to convert back to 3.0 in a way, that `dgit quilt-fixup` will succeed.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[KAction]

control: tags -1 help

[2018-04-18 14:11] Jeremy Bicha 
> Source: inotify-tools
> Version: 3.14-5
> 
> Please consider using the dgit-maint-gbp workflow instead of the
> dgit-maint-merge workflow.
> 
> The recent switch from 3.0 (quilt) eliminates useful context and
> metadata from the Debian package itself. That metadata is now only
> available in the git repo.
> [...]

Honestly, I now consider switch to 1.0 a mistake. But I do not know how
to convert back to 3.0 in a way, that `dgit quilt-fixup` will succeed.

Bug#896014: inotify-tools: Consider using dgit-maint-gbp workflow

[Jeremy Bicha]

Source: inotify-tools
Version: 3.14-5

Please consider using the dgit-maint-gbp workflow instead of the
dgit-maint-merge workflow.

The recent switch from 3.0 (quilt) eliminates useful context and
metadata from the Debian package itself. That metadata is now only
available in the git repo.

Direct changes to the upstream sources as done in the 1.0 source
format don't enforce a clean separation between upstream sources and
the Debian changes. This makes it more challenging for a downstream
like Ubuntu to apply security updates and it is harder to review
debdiffs.

Thanks,
Jeremy Bicha