Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Hello, On 30/06/2019 06:53, Alf Gaida wrote: >>> It will confuse me because in 2021 I will expect release 2021 . >>> Furthermore, will .7 stand for July ? >> I assume it's about point releases (which, again, Ubuntu doesn't do >> AFAIK). >> > The keyword will be education - i wrote some times ago: Let people use wht > they are happy with - it will take a blog entry or two to let users know what > 20xy.z means - i can't resist and bring it to the point: > > If there will be a release 2020.0 and 2020.1 - and there will be release > notes - do we really assume our users are to dumb to get it??? I assume that users can understand the current codename scheme used in Debian. And I found it funny when I read for the first time the explanation on the website (there was no blog at this glorious time). If order is a question (which version comes before the other one), we can impose that the first letter of the codenames must fellow the alphabetic order. Jerome > > Cheers Alf > -- Jerome BENOIT | calculus+at-rezozer^dot*net https://qa.debian.org/developer.php?login=calcu...@rezozer.net AE28 AE15 710D FF1D 87E5 A762 3F92 19A6 7F36 C68B signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Another issue is that with a sequential scheme I always know what the next version is whereas if a year based scheme is used without a set schedule the version after 19 may be anything from 19 to 25. Sincerely, Moshe Piekarski -- There's no such thing as a stupid question, But there are plenty of inquisitive idiots. signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). The keyword will be education - i wrote some times ago: Let people use wht they are happy with - it will take a blog entry or two to let users know what 20xy.z means - i can't resist and bring it to the point: If there will be a release 2020.0 and 2020.1 - and there will be release notes - do we really assume our users are to dumb to get it??? Cheers Alf
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 8:16 PM Tomas Pospisek wrote: > Let's seriously consider using year based release identifiers. At this point in the thread it is very clear that which identifier one prefers is very individual and dependent on use-cases. So we should add support for more individuals and use-cases in order to accommodate everyone's preferences. Killing off use-cases by switching between identifier styles isn't the right way to go. I suggest that we add an "Aliases" field to the Release file. Then apt could use that to silence its warnings about sources.list not matching Suite/Codename. Then we could request ftp-master update dak to populate the Aliases field and add symlinks for all aliases. Any volunteers to write the needed patches? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 6/29/19 3:33 PM, Tomas Pospisek wrote: > Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: >> On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >>> TLDR; year based release identifiers should be prefered since they are >>> much more intuitive to reason about than codenames and sequentialy >>> numbered release identifiers. >>> >>> If Debian should improve/change release identifiers, then I'd suggest to >>> ponder a year based versioning scheme (as Ubuntu is using). >> This only works with Ubuntu because they set the release date in advance. > > You assign the year to the release identifier when the release is ready: > release_id = now().year(). There's certainly some infrastructure stuff > that needs that release_id that needs to be prepared in advance, but I > think that can be done pragmatically, when the release is "99%" ready. > Am I missing something? > *t Thanks, but no. In some software we have in buster, they already have hard-wired the names of the 2 next Debian releases. How would you do this with years if we don't know the release dates in advance? Besides this, I very much dislike the way it sounds. :) Thomas
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
在 2019-06-29六的 20:21 +0500，Andrey Rahmatullin写道：
> On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote:
> > > > > As others here I am starting to get confused by the release code
> > > > > names, as are my peers that are not that much into Debian. And
> > > > > sequential release numbers are devoid of any semantics except for
> > > > > their monotonically increasing character.
> > > > [...]
> > > >
> > > > And yet you *wouldn't* be confused when Debian 2019.7 is released in
> > > > 2021?
> > >
> > > That's right, I don't think that'd confuse me. The reason it wouldn't
> > > confuse me, is that I expect releases to be updated eventually and that
> > > can happen at any time in the future - f.ex. in 2021.
> > > *t
> > >
> >
> > It will confuse me because in 2021 I will expect release 2021 .
> > Furthermore, will .7 stand for July ?
> I assume it's about point releases (which, again, Ubuntu doesn't do
> AFAIK).
I'm not sure about other issues but Ubuntu *do* make point releases for LTS.
There's something like Ubuntu 16.04.{,1,2,3,4}, etc. Their corresponding
(point) release dates are, of course, not in year 2016. As a result I think
it's not an issue.
Thanks,
Boyuan Yang
signature.asc
Description: This is a digitally signed message part
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 06:17:12PM +0400, Jerome BENOIT wrote: > >>> As others here I am starting to get confused by the release code > >>> names, as are my peers that are not that much into Debian. And > >>> sequential release numbers are devoid of any semantics except for > >>> their monotonically increasing character. > >> [...] > >> > >> And yet you *wouldn't* be confused when Debian 2019.7 is released in > >> 2021? > > > > That's right, I don't think that'd confuse me. The reason it wouldn't > > confuse me, is that I expect releases to be updated eventually and that > > can happen at any time in the future - f.ex. in 2021. > > *t > > > > It will confuse me because in 2021 I will expect release 2021 . > Furthermore, will .7 stand for July ? I assume it's about point releases (which, again, Ubuntu doesn't do AFAIK). -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 29/06/2019 17:27, Tomas Pospisek wrote: > Am 29.06.19 um 14:41 schrieb Jeremy Stanley: >> On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: >> [...] >>> As others here I am starting to get confused by the release code >>> names, as are my peers that are not that much into Debian. And >>> sequential release numbers are devoid of any semantics except for >>> their monotonically increasing character. >> [...] >> >> And yet you *wouldn't* be confused when Debian 2019.7 is released in >> 2021? > > That's right, I don't think that'd confuse me. The reason it wouldn't > confuse me, is that I expect releases to be updated eventually and that > can happen at any time in the future - f.ex. in 2021. > *t > It will confuse me because in 2021 I will expect release 2021 . Furthermore, will .7 stand for July ? Jerome signature.asc Description: OpenPGP digital signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 15:28 schrieb Andrey Rahmatullin: > On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: >> TLDR; year based release identifiers should be prefered since they are >> much more intuitive to reason about than codenames and sequentialy >> numbered release identifiers. >> >> If Debian should improve/change release identifiers, then I'd suggest to >> ponder a year based versioning scheme (as Ubuntu is using). > This only works with Ubuntu because they set the release date in advance. You assign the year to the release identifier when the release is ready: release_id = now().year(). There's certainly some infrastructure stuff that needs that release_id that needs to be prepared in advance, but I think that can be done pragmatically, when the release is "99%" ready. Am I missing something? *t
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On Sat, Jun 29, 2019 at 01:53:35PM +0200, Tomas Pospisek wrote: > TLDR; year based release identifiers should be prefered since they are > much more intuitive to reason about than codenames and sequentialy > numbered release identifiers. > > If Debian should improve/change release identifiers, then I'd suggest to > ponder a year based versioning scheme (as Ubuntu is using). This only works with Ubuntu because they set the release date in advance. -- WBR, wRAR signature.asc Description: PGP signature
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 29.06.19 um 14:41 schrieb Jeremy Stanley: > On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: > [...] >> As others here I am starting to get confused by the release code >> names, as are my peers that are not that much into Debian. And >> sequential release numbers are devoid of any semantics except for >> their monotonically increasing character. > [...] > > And yet you *wouldn't* be confused when Debian 2019.7 is released in > 2021? That's right, I don't think that'd confuse me. The reason it wouldn't confuse me, is that I expect releases to be updated eventually and that can happen at any time in the future - f.ex. in 2021. *t
Re: Survey results: git packaging practices / repository format
> "Enrico" == Enrico Zini writes: Enrico> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote: >> I hope you all won't mind too much that Sean and I have >> privileged our own point of view, in the columns which contain >> value judgements, and that we hope to retain that property of the >> page. Enrico> I have no problem with you making a collation of the results Enrico> from your point of view, but I would also like to see some Enrico> more objective presentation of the survey results, even if Enrico> in a more raw format. Hi. Ian is working to present this information at a BOF I'm running at Debconf targeted at understanding requirements people have for using git in Debian. I think it would be helpful for both of us to describe ways in which you find that there are objectivity problems that would get in the way of presenting the data in that context. I think especially at that bof we'd like to avoid people feeling that some practice that they cared about was mischaracterized or misrepresented. Yet we kind of need one person to give a short presentation to get it into something that can fit into a bof. So any help you can provide pointing at things that seem too subjective would be appreciated. --Sam
Re: Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
On 2019-06-29 13:53:35 +0200 (+0200), Tomas Pospisek wrote: [...] > As others here I am starting to get confused by the release code > names, as are my peers that are not that much into Debian. And > sequential release numbers are devoid of any semantics except for > their monotonically increasing character. [...] And yet you *wouldn't* be confused when Debian 2019.7 is released in 2021? -- Jeremy Stanley signature.asc Description: PGP signature
Let's consider using year based release identifiers [was: Re: getting rid of "testing"]
Am 25.06.19 um 08:08 schrieb Ansgar:
> what do people think about getting rid of current suite names ("stable",
> "testing", "unstable") for most purposes? We already recommend using
> codenames instead as those don't change their meaning when a new release
> happens.
>
> Related to that I would like to be able to write something like
>
> deb http://deb.debian.org/debian debian11 main
> deb http://security.debian.org/debian-security debian11-security main
>
> in sources.list as codenames confuse people.
>
> Ubuntu already has no suite names, only codenames, but having to map
> "Ubuntu 18.04" to "bionic" instead of just writing the version in
> sources.list is annoying (I always have to look up the codename to be
> sure as I don't use Ubuntu that much).
TLDR; year based release identifiers should be prefered since they are
much more intuitive to reason about than codenames and sequentialy
numbered release identifiers.
If Debian should improve/change release identifiers, then I'd suggest to
ponder a year based versioning scheme (as Ubuntu is using).
As others here I am starting to get confused by the release code names,
as are my peers that are not that much into Debian. And sequential
release numbers are devoid of any semantics except for their
monotonically increasing character.
On the other hand, using year numbers as release identifiers has the
advantage of:
* getting rid of the need to remember arbitrary names and their sequence
* being linked to and rooted in everyday human experience, which makes
it intuitive and easy to reason about releases
When reasoning about an installation of Ubuntu "14.04" one can easily
come to the conclusion, that it's probably wise to upgrade, that release
being 5 years old, whereas an "16.04" might still smell reasonably fresh
and is probalby still OK to run.
Let's seriously consider using year based release identifiers.
*t
Re: Survey results: git packaging practices / repository format
Enrico Zini writes ("Re: Survey results: git packaging practices / repository
format"):
> On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote:
> > I hope you all won't mind too much that Sean and I have privileged our
> > own point of view, in the columns which contain value judgements, and
> > that we hope to retain that property of the page.
>
> I have no problem with you making a collation of the results from your
> point of view, but I would also like to see some more objective
> presentation of the survey results, even if in a more raw format.
>
> I saw in your survey a great potential for documenting the existing
> workflows, and I'm having a hard time getting that documentation from
> the current presentation.
The current presentation lists *branch formats* not *workflows*.
Everything in the current page other than the comments and best
practices columns is objective, but I see it as lower level than what
I think you are looking for.
The problem with listing workflows is for any specific branch format,
there are generally many tools, and many possible approaches to each
task. So while it is meaningful to talk about "my workflow", as a
collection of practices, it is not really possible to enumerate whole
workflows because everyone's personal workflow can differ in lots of
different respects. So the number of different whole-workflows is
unmanageable.
It would probably be useful for there to be a wiki page for each
branch format which has a section for each kind of task ("modify an
upstream file", "cherry pick a patch from upstream", "switch to new
upstream version") etc. and describes all the different ways of
achieving that taxk with that branch format.
That would be "less raw" but perhaps is what you actually want ? :-)
> I could suggest a descriptive wiki page for each style you identified,
> that then the users of that workflow can add to, and can serve as seeds
> for growing comprehensive documentation, if that is doable with the data
> you collected.
I can probably write a skeleton for most of these workflows. At
least, for the most popular ones. In many cases a good starting point
is probably a copy of a README.source from some package which actually
mentions it, or of course the dgit workflow tutorial manpage.
Maybe I should write one skeleton and then others can help ?
> The current big table might end up being simplified by having links to
> the detail pages.
I think the table needs still to exist but certainly links will help.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: Survey results: git packaging practices / repository format
On Fri, Jun 28, 2019 at 10:42:29PM +0100, Ian Jackson wrote: > I hope you all won't mind too much that Sean and I have privileged our > own point of view, in the columns which contain value judgements, and > that we hope to retain that property of the page. I have no problem with you making a collation of the results from your point of view, but I would also like to see some more objective presentation of the survey results, even if in a more raw format. I saw in your survey a great potential for documenting the existing workflows, and I'm having a hard time getting that documentation from the current presentation. I could suggest a descriptive wiki page for each style you identified, that then the users of that workflow can add to, and can serve as seeds for growing comprehensive documentation, if that is doable with the data you collected. The current big table might end up being simplified by having links to the detail pages. Thank you for your work on this, by the way. I'm really excited at the idea of a taxonomy and details of debian mantenance workflows! Enrico -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Uninformative hyperlink in O: (package orphaning) bug reports
On Thu, Jun 27, 2019 at 03:38:48PM -0400, Boyuan Yang wrote: > Dear -devel list, > > (Please forward this email to proper mailing lists if there's other lists that > this email would suit in better.) > > I noticed that for all bug reports that orphan a package in Debian, a semi- > standard paragraph of words will be provided like this: > > > > ...Maintaining a package requires time and skills. Please only adopt this > package if you will have enough time and attention to work on it. > > If you want to be the new maintainer, please see > https://www.debian.org/devel/wnpp/#howto-o for detailed > instructions how to adopt a package properly > > This text comes from a template we use in the MIA-Team. You can find it here: https://salsa.debian.org/qa/qa/blob/master/mia/templates/wnpp-orphan.mia > However, https://www.debian.org/devel/wnpp/#howto-o provides almost zero > information for an enthusiast that want to adopt the package, i.e. there's no > detailed instruction on how to actually upload a package for a person not > quite familiar with Debian's packaging workflow. > > I'd suggest some kind of rewording on the website given that this link has > been posted everywhere in different BTS bug reports. Including a link to > https://mentors.debian.net/intro-maintainers might be a good idea. Anyway any > kind of improvement would be appreciated. A MR would be indeed very welcome! ;-) -- Cheers, tobi
