On 2020-02-18 23:14:14, Simon McVittie wrote:
> On Tue, 18 Feb 2020 at 15:47:17 -0500, Antoine Beaupré wrote:
>> The tricky part here is generating a new version without mangling
>> debian/changelog all the time. I haven't found a great story for that
>> that works with git, but maybe you can
On Tue, 18 Feb 2020 at 15:47:17 -0500, Antoine Beaupré wrote:
> The tricky part here is generating a new version without mangling
> debian/changelog all the time. I haven't found a great story for that
> that works with git, but maybe you can generate syntetic commits to fake
> a new Debian
On 2020-02-08 22:07:48, Otto Kekäläinen wrote:
> Hello!
>
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the
Hello,
On Sun 09 Feb 2020 at 10:57PM +02, Otto Kekäläinen wrote:
> Most interesting was perhaps Seans git-remote-gcrypt. You even have a
> rpm spec file included which helps illustrate this is a true upstream
> and not a fully native Debian package.
>
> There does not seem to be any automation
On 2/8/20 7:57 PM, Simon Richter wrote:
> In my experience, it was often a good idea to separate my upstream and
> Debian hats.
+1
My current situation is that I'm a Debian packager who has then over
time become more involved in upstream and eventually ended up with a
commit bit.
On a different
Hello!
Currently the project where I am closest to this goal is in
rdiff-backup. The upstream debian/ is almost 1:1 to the downstream
debian/. I've made a dh_gencontrol override to ensure the upstream CI
always builds binaries with the correct version number inherited from
a git tag in upstream:
Hello!
Thanks for all the examples (LXQt [where I looked at the sources of
lxqt-panel], git-remote-gcrypt, nbd, review, glibc).
Most interesting was perhaps Seans git-remote-gcrypt. You even have a
rpm spec file included which helps illustrate this is a true upstream
and not a fully native
* Otto Kekäläinen:
> Is somebody else already doing something similar like this?
We are doing this with glibc in Fedora, which is not Debian, but kind
of similar. We try to push all backportable fixes to the upstream
release branches (and master) and synthesize new pseudo-release
tarballs from
On Sat, Feb 08, 2020 at 10:07:48PM +0200, Otto Kekäläinen wrote:
> Hello!
>
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
>
Hello Otto,
On Sat 08 Feb 2020 at 10:07PM +02, Otto Kekäläinen wrote:
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly
Hi Otto,
i'm doing this for years now (LXQt)
To sum it up:
* there are no special rules, but i suggest to keep your hats strictly
separated
* if there are some doubts upstream - just think how you would feel with
a release with your downstream hat on
* if you release something upstream and have
Hi,
On 08.02.20 21:07, Otto Kekäläinen wrote:
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the upstream
Otto Kekäläinen writes:
> Hi!
>
> Thanks for the example. I see you even maintain the changelog in upstream:
> https://git.notmuchmail.org/git?p=notmuch;a=blob;f=debian/changelog;h=4f7457cd7f588e6d3a821bf1530cc1f8742c8d6f;hb=refs/heads/master
Yes.
>
> But apparently "upstream" releases are
Hi!
Thanks for the example. I see you even maintain the changelog in upstream:
https://git.notmuchmail.org/git?p=notmuch;a=blob;f=debian/changelog;h=4f7457cd7f588e6d3a821bf1530cc1f8742c8d6f;hb=refs/heads/master
But apparently "upstream" releases are decoupled from also bumping the
Debian
Otto Kekäläinen writes:
> Hello!
>
> I've ended up in being both the maintainer in Debian and an upstream
> developer for a couple of packages and I have been fantasizing about
> how to optimize my workflow so that I primarily fix all bugs and do QA
> directly on the upstream development version
Hello!
I've ended up in being both the maintainer in Debian and an upstream
developer for a couple of packages and I have been fantasizing about
how to optimize my workflow so that I primarily fix all bugs and do QA
directly on the upstream development version (=upstream git master)
and then have
16 matches
Mail list logo
