Hi,
Whilst I really welcome progress on this DEP, as I believe it's really
important to codify best practice, and that's what you're trying to do
:-),
On Sat, Aug 29, 2020 at 01:01:09AM +0200, Raphael Hertzog wrote:
> proposing the changes below to DEP-14. Basically it replaces debian/master
> wi
On 2020-08-29 Raphael Hertzog wrote:
> +URL: https://dep-team.pages.debian.net/deps/dep14/
[...]
| When a package targets any release that is not one of the usual
| development releases (i.e. stable releases or a frozen development
| release), it should be prepared in a branch named with the
On Sun, Sep 13, 2020 at 10:32:36AM -0700, Sean Whitton wrote:
> Hello,
>
> > On Sat, 12 Sep 2020, Sean Whitton wrote:
> >> There are arguments both ways here but as you're the person driving
> >> this, I'm still keen to hear more from you about why debian/unstable is
> >> to be preferred over debi
Hello,
> On Sat, 12 Sep 2020, Sean Whitton wrote:
>> There are arguments both ways here but as you're the person driving
>> this, I'm still keen to hear more from you about why debian/unstable is
>> to be preferred over debian/sid giving the existing convention
>> established by dgit. Thanks.
>
>
Hi,
On Sat, 12 Sep 2020, Sean Whitton wrote:
> There are arguments both ways here but as you're the person driving
> this, I'm still keen to hear more from you about why debian/unstable is
> to be preferred over debian/sid giving the existing convention
> established by dgit. Thanks.
I don't hav
Hello Raphael,
On Sat 05 Sep 2020 at 04:31PM -07, Sean Whitton wrote:
> Hello Raphael,
>
> On Sun 30 Aug 2020 at 10:02AM -07, Sean Whitton wrote:
>
>> I think we should recommend debian/sid because for some years dgit has
>> been generating branches called dgit/sid. I think it would smooth the
>
Richard Laager wrote on 06/09/2020:
On 8/31/20 8:53 AM, Raphael Hertzog wrote:
I already agreed that we can tweak the wording to document that it's
I don't think the people on the list saw that message, as it had an
attachment. It's below (unabridged).
OK to use debian/unstable as default br
On 9/7/20 5:33 AM, Raphael Hertzog wrote:
> On Sat, 05 Sep 2020, Richard Laager wrote:
>> I do not see why we have to prohibit occasional uploads to experimental
>> from debian/unstable. If this is permitted, then that also avoids the
>> busywork of creating debian/experimental in that scenario.
>
On Sat, 05 Sep 2020, Richard Laager wrote:
> > OK to use debian/unstable as default branch even if you are not a
> > complex package that require multiple branches, provided that you will
> > not use debian/unstable when you decide to push something to
> > experimental.
>
> I do not see why we hav
On Fri, 04 Sep 2020, The Wanderer wrote:
> As long as this is being patched anyway, how about fixing the "others
> vendors" duplicate pluralization? I'd suggest either "but all other
> vendors should do so" or "as all others should do", but other variations
> are possible and I don't have a strong
(Resending without the attachment for posterity sinte the message didn't
make it to -devel, but I also had no bounce notifying me that it was
discarded...)
Hello,
On Sun, 30 Aug 2020, Richard Laager wrote:
> You could use debian/experimental all the time and then merge down to
> debian/unstable o
Hello Raphael,
On Sun 30 Aug 2020 at 10:02AM -07, Sean Whitton wrote:
> I think we should recommend debian/sid because for some years dgit has
> been generating branches called dgit/sid. I think it would smooth the
> integration between branches on salsa and branches on dgit.debian.org
> if both
On 8/31/20 8:53 AM, Raphael Hertzog wrote:
> I already agreed that we can tweak the wording to document that it's
I don't think the people on the list saw that message, as it had an
attachment. It's below (unabridged).
> OK to use debian/unstable as default branch even if you are not a
> complex
On 2020-09-04 at 11:42, Raphael Hertzog wrote:
> So here's my counter proposal:
>
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -201,12 +201,16 @@ Native packages
>
> The above conventions mainly cater to the case where the upstream
> developers and the package maintainers are
Raphael Hertzog wrote on 04/09/2020:
Hi,
On Fri, 04 Sep 2020, Paride Legovini wrote:
As the name of the development branch is not specified anymore, should dep14
ask for it to be the repository default branch? Otherwise there's no safe
I took this as granted. But maybe we should make it expli
Hi,
On Fri, 04 Sep 2020, Paride Legovini wrote:
> As the name of the development branch is not specified anymore, should dep14
> ask for it to be the repository default branch? Otherwise there's no safe
I took this as granted. But maybe we should make it explicit, yes. I also
clarified that those
Raphael Hertzog wrote on 29/08/2020:
@@ -200,7 +204,7 @@ developers and the package maintainers are not the same set
of persons.
When upstream is Debian (or one of its derivative), the upstream vendor
should not use the usual `/` prefix (but all others vendors should
-do so). The main d
Raphael Hertzog wrote on 31/08/2020:
> Hi,
>
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> A tl;dr version of my idea is: let's remove the special treatment for
>> development releases, treating e.g. debian/unstable like a stable
>> release. Optionally use a 'debian/devel' branch for developmen
Hi,
On Mon, 31 Aug 2020, Paride Legovini wrote:
> A tl;dr version of my idea is: let's remove the special treatment for
> development releases, treating e.g. debian/unstable like a stable
> release. Optionally use a 'debian/devel' branch for development work.
> The only "workflow" bit is: if you w
Raphael Hertzog wrote on 31/08/2020:
> On Mon, 31 Aug 2020, Paride Legovini wrote:
>> What I propose is to require for dep14 compliance that uploads to
>> are to be cut from debian/ branches, unless
>> is experimental. This allows to checkout the "maintainer
>> view" of a given (nonexperimental)
On Mon, 31 Aug 2020, Paride Legovini wrote:
> What I propose is to require for dep14 compliance that uploads to
> are to be cut from debian/ branches, unless
> is experimental. This allows to checkout the "maintainer
> view" of a given (nonexperimental) version of a package by knowing only:
>
>
Hi,
The Wanderer wrote on 31/08/2020:
> On 2020-08-31 at 06:49, Paride Legovini wrote:
>
>> Simon McVittie wrote on 30/08/2020:
>>
>>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>>>
If I know that the next upstream release breaks backwards
compatitibly and that it wil
Raphael Hertzog wrote on 30/08/2020:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to DEP-14 supporting this workflow
>> with debian/latest. But I would like to see it (debian/latest)
>> rech
healthy for me.
Of course my packages are small and the chance that a newer release
breaks something fundamental is subtle, so it is low risk to target
unstable mst of the time.
On Sun, 2020-08-30 at 21:33 +0200, Mathias Behrle wrote:
> * Simon McVittie: " Re: RFC: Final update of DEP-14 on
On 2020-08-31 at 06:49, Paride Legovini wrote:
> Simon McVittie wrote on 30/08/2020:
>
>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>>
>>> If I know that the next upstream release breaks backwards
>>> compatitibly and that it will have to mature a long time in
>>> experimenta
On 8/31/20 7:49 AM, Paride Legovini wrote:
> Simon McVittie wrote on 30/08/2020:
>> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>>> If I know that the next upstream release
>>> breaks backwards compatitibly and that it will have to mature a long time
>>> in experimental until al
Simon McVittie wrote on 30/08/2020:
> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
>> If I know that the next upstream release
>> breaks backwards compatitibly and that it will have to mature a long time
>> in experimental until all other packages are ready, I might start to
>> pac
Hi,
From my point of view (newbie point of view) it's more natural use the
default branch as my "target" codename. I mean, if I'm working on a
package that I will upload to unstable I hope use debian/unstable branch
for that. If I want to test or for any reason upload package to
experimental (or b
Geert Stappers writes:
> On 2020-08-30 at 14:46, Richard Laager wrote:
>> Using debian/sid makes the branch name inconsistent with
>> debian/changelog, which traditionally uses "unstable" not "sid".
> There no need to have consistency between a git branch name and
> debian/changelog saying wher
Richard Laager writes:
> On 8/29/20 5:19 PM, Russ Allbery wrote:
>> The problem in my case with not putting a branch name in Vcs-Git is
>> that, for packages for which I'm also upstream, the default branch in
>> the repository named in that header is the upstream development branch,
>> which cont
On Sun, 2020-08-30 at 14:52 -0400, The Wanderer wrote:
> On 2020-08-30 at 14:46, Richard Laager wrote:
[...]
> > (because there is no character code name for
> > experimental AFAIK).
>
> I thought the same at one point, but in fact, there is: it's called
> rc-buggy.
>
> https://wiki.debian.org/De
* Simon McVittie: " Re: RFC: Final update of DEP-14 on naming of git packaging
branches" (Sun, 30 Aug 2020 15:02:35 +0100):
> On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> > If I know that the next upstream release
> > breaks backwards compatitibly
On Sun, Aug 30, 2020 at 02:52:33PM -0400, The Wanderer wrote:
> On 2020-08-30 at 14:46, Richard Laager wrote:
> > On 8/30/20 12:02 PM, Sean Whitton wrote:
> >> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
> >>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> >>> index 0316fe1..b
On 2020-08-30 at 14:46, Richard Laager wrote:
> On 8/30/20 12:02 PM, Sean Whitton wrote:
>
>> Hello Raphael,
>>
>> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
>>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
>>> index 0316fe1..beb96ea 100644
>>> --- a/web/deps/dep14.mdwn
>>>
On 8/30/20 12:02 PM, Sean Whitton wrote:
> Hello Raphael,
>
> On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
>> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
>> index 0316fe1..beb96ea 100644
>> --- a/web/deps/dep14.mdwn
>> +++ b/web/deps/dep14.mdwn
>> +In the interest of homogene
Hello Raphael,
On Fri, 28 Aug 2020, at 4:01 PM, Raphael Hertzog wrote:
> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> index 0316fe1..beb96ea 100644
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> +In the interest of homogeneity and of clarity, we recommend the use of
> +`debi
I think I now have a better handle on how/why I disagree with the DEP-14
recommendation language.
On 8/30/20 8:36 AM, Raphael Hertzog wrote:
> On Sat, 29 Aug 2020, Richard Laager wrote:
>> That said, I do understand we give a lot of deference to developers'
>> workflows. So I have no objection to
On 8/29/20 5:16 PM, Simon McVittie wrote:
> On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
>> However, this is still saying that one should prefer debian/latest over
>> debian/unstable, and that debian/unstable is (sort of) only for use when
>> you're also uploading to experimental.
>
On 8/29/20 5:19 PM, Russ Allbery wrote:
> The problem in my case with not putting a branch name in Vcs-Git is that,
> for packages for which I'm also upstream, the default branch in the
> repository named in that header is the upstream development branch, which
> contains no Debian packaging files
On 2020-08-30 at 10:02, Simon McVittie wrote:
> Rationale: it seems very confusing if a branch with "latest" in its
> name does not contain the newest available version :-)
>
> (debian/master didn't have that problem because it's named by
> analogy to the "master" branch used in upstream git repo
On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> If I know that the next upstream release
> breaks backwards compatitibly and that it will have to mature a long time
> in experimental until all other packages are ready, I might start to
> package it rigth now in debian/experimental a
On Sat, 29 Aug 2020, Richard Laager wrote:
> That said, I do understand we give a lot of deference to developers'
> workflows. So I have no objection to DEP-14 supporting this workflow
> with debian/latest. But I would like to see it (debian/latest)
> recharacterized as the alternate approach rathe
On Sat, Aug 29, 2020 at 01:01:09AM +0200, Raphael Hertzog wrote:
> Hello,
>
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it
Richard Laager writes:
> On 8/29/20 3:33 PM, Russ Allbery wrote:
>> I think the primary thing that bothers me about this workflow is that
>> experimental becomes an ephemeral branch, which appears and disappears
>> based on the vagaries of the release cycle.
> To me, that feels like the branch i
On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
> However, this is still saying that one should prefer debian/latest over
> debian/unstable, and that debian/unstable is (sort of) only for use when
> you're also uploading to experimental.
The way I think of it phrases this a bit differ
On 8/29/20 3:33 PM, Russ Allbery wrote:
> I think the primary thing that bothers me about this workflow is that
> experimental becomes an ephemeral branch, which appears and disappears
> based on the vagaries of the release cycle.
To me, that feels like the branch is an accurate representation of
Seconded. Thanks!
Raphael Hertzog dijo [Sat, Aug 29, 2020 at 01:01:09AM +0200]:
> Hello,
>
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed e
Richard Laager writes:
> When I last brought this up [1], Russ Allbery said that debian/latest
> was desirable (to him, at least) because, "My normal use of experimental
> does not involve maintaining unstable and experimental branches
> simultaneously. I essentially never do that; instead, I ma
On 8/28/20 6:01 PM, Raphael Hertzog wrote:
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is pref
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.
+1 to this and the other changes.
I believe we will be able to easily perform the branch naming changes
under the pkg-sec team.
Reg
Le samedi, 29 août 2020, 01.01:09 h CEST Raphael Hertzog a écrit :
> Hello,
>
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
>
Le 28/08/2020 à 19:01, Raphael Hertzog a écrit :
Basically it replaces debian/master
with debian/latest for all the reasons already discussed earlier.
[…]
Let me know your thoughts:
diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
index 0316fe1..beb96ea 100644
--- a/web/deps/dep14.mdwn
Hello,
following the recent discussions of June and of the last days, I'm
proposing the changes below to DEP-14. Basically it replaces debian/master
with debian/latest for all the reasons already discussed earlier. And
it says that debian/unstable is preferred over debian/sid.
And it also marks t
53 matches
Mail list logo
