Re: Knowing the release names in advance (was: Feedback)
On Tue, Jan 01, 2013 at 10:56:53AM +0800, Paul Wise wrote: On Mon, Dec 31, 2012 at 7:18 PM, Dmitrijs Ledkovs wrote: $ man debian-distro-info Debian OS provides API to query such information. In addition, stable alias names are also provided (stable, testing, unstable, experimental). As a last resort you can also scrape archive mirrors dists (e.g. ftp-master, snapshot, old-releases) and check the symlinks. That seems like a hack to workaround the fact that the archive doesn't provide this information in one file. Like a machine-readable http://http.debian.net/debian/dists/README ? -- Simon Paillard -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130102123238.gc13...@glenfiddich.mraw.org
Re: Knowing the release names in advance (was: Feedback)
On 2 January 2013 14:32, Simon Paillard spaill...@debian.org wrote: On Tue, Jan 01, 2013 at 10:56:53AM +0800, Paul Wise wrote: On Mon, Dec 31, 2012 at 7:18 PM, Dmitrijs Ledkovs wrote: $ man debian-distro-info Debian OS provides API to query such information. In addition, stable alias names are also provided (stable, testing, unstable, experimental). As a last resort you can also scrape archive mirrors dists (e.g. ftp-master, snapshot, old-releases) and check the symlinks. That seems like a hack to workaround the fact that the archive doesn't provide this information in one file. Like a machine-readable http://http.debian.net/debian/dists/README ? Maybe distro-info-data's csv file should be published on mirrors, to even provide historical names. http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info-data.git;a=blob;f=debian.csv;h=ed3302e57d18f7697eec0b67fee259b904436684;hb=HEAD Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujqqxjppjeqcxbkmqeqr9zzfprevl-y40eawb4trqg...@mail.gmail.com
Re: Knowing the release names in advance (was: Feedback)
On Wed, Jan 2, 2013 at 8:32 PM, Simon Paillard wrote: Like a machine-readable http://http.debian.net/debian/dists/README ? Yeah, or something like this: http://changelogs.ubuntu.com/meta-release -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6Fy4i6JgE61=OQbRuOZ0BZ=3Em_-uq_o=7j7evsrzk...@mail.gmail.com
Re: Knowing the release names in advance (was: Feedback)
On Wed, Jan 2, 2013 at 8:51 PM, Dmitrijs Ledkovs wrote: Maybe distro-info-data's csv file should be published on mirrors, to even provide historical names. http://anonscm.debian.org/gitweb/?p=collab-maint/distro-info-data.git;a=blob;f=debian.csv;h=ed3302e57d18f7697eec0b67fee259b904436684;hb=HEAD deb822 would be better than CSV, I think something named dists/Releases or similar, with contents similar to Ubuntu's meta-release and parts of the Release files. It would need to indicate support periods so that apt can warn users when their security support is about to expire. Ubuntu might want to keep their release notes and upgrade tool links in it. Debian might want the release notes links but probably not the upgrade tool ones. It should probably be signed. PS: I'm subscribed, no need to CC me. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAKTje6GEeO0MaW-m4GUu1=drbq5eibb4psjhusog-s2pn17...@mail.gmail.com
Re: Knowing the release names in advance
On Tue, Jan 01, 2013 at 03:55:22AM +0800, Thomas Goirand wrote: Wouldn't it be more simple to just choose a name and we would never ever have to talk about it again, and never ever have to process any of such unblocks? Sure thing: The next release after Jessie will be called Thomas. [0] Neil [0] The chances of this actually being true is directly proportional to the amount of RC bugs you fix, minus the amount of time you've managed to waste for the release on this thread. -- signature.asc Description: Digital signature
Re: Knowing the release names in advance
Hi Thomas and everybody, and « bonne année » ! It seems to me that the main technical arguments advocating predictable or sortable release names have been given, so I think that the next step would be to make sure that they get to the right ears at the right time. While this discussion on -devel may help to strenghten your proposition, I have the impression that the current contributors to the discussion are not the persons who will decide. How about a DEP to organise the discussion ? It would help for the pros and cons to be recorded in a synthethic way in a document easy to find, which will be very useful if the persons in charge estimate that currently it is a development that has a lower priority than focusing on Wheezy's release. http://dep.debian.net/deps/dep0/ Cheers, -- Charles -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130101082136.ga23...@falafel.plessy.net
Re: Knowing the release names in advance
On 01/01/2013 04:21 PM, Charles Plessy wrote: Hi Thomas and everybody, and « bonne année » ! It seems to me that the main technical arguments advocating predictable or sortable release names have been given, so I think that the next step would be to make sure that they get to the right ears at the right time. While this discussion on -devel may help to strenghten your proposition, I have the impression that the current contributors to the discussion are not the persons who will decide. How about a DEP to organise the discussion ? It would help for the pros and cons to be recorded in a synthethic way in a document easy to find, which will be very useful if the persons in charge estimate that currently it is a development that has a lower priority than focusing on Wheezy's release. http://dep.debian.net/deps/dep0/ Cheers, Hi Charles! Maybe it's a bit overkill to do a DEP just for that no? Otherwise, I can make a sum-up of what has been said in the list, if you see fit. (Though probably, it would be best to find someone to do it that has a less strong point of view on the mater, and with better English skills than me...) Also, I do like the fact that the release team decides for the name, I think that's a very nice reward for their huge work. However, I think everyone in the project should have equal rights as to discuss and decide *when* we need such names (and, as always, best is to have a consensus). Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e2f209.9080...@debian.org
Re: Knowing the release names in advance
Le Tue, Jan 01, 2013 at 10:26:17PM +0800, Thomas Goirand a écrit : Maybe it's a bit overkill to do a DEP just for that no? For simple propositions, a DEP is not much more than giving a number to a wiki page, and keeping track if the proposition is under discussion, accepted or rejected. The goal is not to make the proposition more formal, but to provide a frame that helps to limit the repetition of the same arguments accross years. The DEP index at http://dep.debian.net/ is a ikiwiki page managed with Subversion, that is straightforward to modify. Every Debian Developer should have write access to it (svn+ssh://svn.debian.org/svn/dep/web/index.mdwn). In case of problems, do not hesitate to contact the DEP admins (https://lists.alioth.debian.org/mailman/listinfo/dep-plumbing). Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130101221806.gb15...@falafel.plessy.net
Re: Knowing the release names in advance
On Mon, Dec 31, 2012 at 02:28:04PM +0800, Thomas Goirand wrote: On 12/31/2012 04:16 AM, Philipp Kern wrote: Please don't. -devel is not a popularity contest. I'm stunted by the complexity of your argumentation. It for sure helps in the debate. Doing '+1' on an argument doesn't exactly help a debate forward, either. Technical arguments do. Phil is right. -- Copyshops should do vouchers. So that next time some bureaucracy requires you to mail a form in triplicate, you can mail it just once, add a voucher, and save on postage. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121231094721.ge16...@grep.be
Re: Knowing the release names in advance
On 12/31/2012 05:47 PM, Wouter Verhelst wrote: On Mon, Dec 31, 2012 at 02:28:04PM +0800, Thomas Goirand wrote: On 12/31/2012 04:16 AM, Philipp Kern wrote: Please don't. -devel is not a popularity contest. I'm stunted by the complexity of your argumentation. It for sure helps in the debate. Doing '+1' on an argument doesn't exactly help a debate forward, either. Technical arguments do. Phil is right. Sure, but talking only about this part of my post doesn't help going forward either, especially when I did give technical (and less technical) arguments. My point was only to invite others to express themselves on the topic, so that we have a larger consensus than only myself and Thijs. I do know others share my view but don't tell about it. Perhaps the +1 thing was a stupid way to ask for it, I can admit that. Thomas P.S: Of course, I wanted to write stunned not stunted ... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e1622b.1050...@debian.org
Re: Knowing the release names in advance (was: Feedback)
On 30 December 2012 19:23, Thomas Goirand z...@debian.org wrote: On 12/30/2012 04:26 PM, Thijs Kinkhorst wrote: Would it be an idea to publish the list of version numbers and associated code names a few releases ahead, say the upcoming three releases? Of course the prerogative of deciding on the names will remain with the release team, it would only be pulled forward a bit. I have 3 things to say about this. Yes, then yes, and yes again. Not only this is good for our users, but this is also technically needed for both upstream and us, doing the packaging. Let's say you have a software that somehow, installs Debian. Then it might require the user to select which name of the release to install. Currently, we knew about the name Jessie *after* the freeze, meaning that we couldn't have written a software that would debootstrap it without asking for an unblock. $ man debian-distro-info Debian OS provides API to query such information. In addition, stable alias names are also provided (stable, testing, unstable, experimental). As a last resort you can also scrape archive mirrors dists (e.g. ftp-master, snapshot, old-releases) and check the symlinks. I made that point very clear multiple times, and I haven't been the only one doing it. Yet, it hasn't been heard, and I never receive any technical argumentation as to why we shouldn't know the release names well in advance. Maybe if there was a greater number of DD insisting that this is necessary, this could change. Please +1 to this if you agree. -1. There is already multiple APIs provided to query such information in multiple ways as outlined above. Regards, Dmitrijs. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujfwh7su-yqulp8mcmavyh9kb2fcnulej7lphw3egd...@mail.gmail.com
Re: Knowing the release names in advance
On Mon, 31 Dec 2012 01:23:56 +0800 Thomas Goirand z...@debian.org wrote: Let's say you have a software that somehow, installs Debian. I use a lot of those and wrote one of them. Then it might require the user to select which name of the release to install. Or it could simply use the names which don't change: oldstable, stable, testing, unstable, experimental. That's what multistrap does. That's why the archive *has* names which don't change. We have names which have fixed content (lenny, squeeze, wheezy) and we have names which are always available (oldstable, stable, testing). Simple. An unblock request for this kind of change wouldn't be a problem, neither would a backport. It's not as if this is common. There aren't that many bootstrapping tools. There is no point having a name for release+2 because there will not be any content for that name until after the release of something which doesn't exist until after the current release. i.e. Jessie has no content currently. It won't have any content until after Wheezy is released. Talking about the name which comes after Jessie is pointless - nothing will exist for that name for years yet. Complete vapourware. Currently, we knew about the name Jessie *after* the freeze, meaning that we couldn't have written a software that would debootstrap it without asking for an unblock. Just use testing and provide the name via backports - it would only be moving a symlink anyway. Or, as above, a trivial unblock. This kind of thing is not even a problem - base-files has to do it every release. I made that point very clear multiple times .. wrongly. , and I haven't been the only one doing it. Yet, it hasn't been heard, and I never receive any technical argumentation as to why we shouldn't know the release names well in advance. I've not seen any valid technical reasons why we should know it beyond the start of the freeze. A name would be meaningless that far ahead. Just like the time-based freeze, we'd have people inventing policy / goals / content for the name which has no basis in anything and then getting annoyed when the actual content didn't fit their mistakes. Maybe if there was a greater number of DD insisting that this is necessary, this could change. Please +1 to this if you agree. It's not necessary. If there is a reason why we shouldn't know, please expose it in this list. I, don't see any. I don't see technical reasons to invent a label for vapourware. Naming something which (at that point) has a non-existent feature set is a nonsense. The next stable release at least has a likely availability date which can be based on real figures (like the RC bug count) - release+1 is needed only once the freeze starts, release+2 is nowhere, it makes no sense to label it. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpUXssElpwek.pgp Description: PGP signature
Re: Knowing the release names in advance
Dmitrijs Ledkovs wrote: $ man debian-distro-info Serious question - is this a real manpage? If so, which package is it in? I don't seem to have it available by default on any Debian system at hand, from etch through wheezy... Debian OS provides API to query such information. Second serious question - what is this API? I asked something along this line a number of years ago, and most of the responses could be summed up as a combination of a bewildered Why would you want/need to do *that*?!? and Your question has no useful answer because insert edge case. -kgd -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e1b18e.8020...@vianet.ca
Re: Knowing the release names in advance
On Mon, 31 Dec 2012 10:38:54 -0500, Kris Deugau wrote: Dmitrijs Ledkovs wrote: $ man debian-distro-info Serious question - is this a real manpage? If so, which package is it in? I don't seem to have it available by default on any Debian system at hand, from etch through wheezy... % apt-file search debian-distro-info distro-info: /usr/bin/debian-distro-info distro-info: /usr/share/distro-info/test-debian-distro-info distro-info: /usr/share/man/man1/debian-distro-info.1.gz % rmadison distro-info distro-info | 0.9~bpo60+1 | squeeze-backports | source, amd64, armel, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, sparc distro-info | 0.10| wheezy| source, amd64, armel, armhf, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc distro-info | 0.10| sid | source, amd64, armel, armhf, hurd-i386, i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390, s390x, sparc Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: Kurt Ostbahn Die Kombo: So im Eck signature.asc Description: Digital signature
Re: Knowing the release names in advance
On 2012-12-31 10:38:54 -0500 (-0500), Kris Deugau wrote:
Serious question - is this a real manpage? If so, which package is
it in?
[...]
It's introduced in Wheezy and available in backports for Squeeze:
http://packages.debian.org/distro-info
http://bugs.debian.org/559761
--
{ WHOIS( STANL3-ARIN ); WWW( http://fungi.yuggoth.org/ );
PGP( 48F9961143495829 ); MUD( kin...@katarsis.mudpy.org:6669 );
FINGER( fu...@yuggoth.org ); IRC( fu...@irc.yuggoth.org#ccl ); }
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20121231161436.gu6...@yuggoth.org
Re: Knowing the release names in advance
On Mon, Dec 31, 2012 at 10:38:54AM -0500, Kris Deugau wrote: Dmitrijs Ledkovs wrote: $ man debian-distro-info Serious question - is this a real manpage? If so, which package is it in? That was my initial reaction. Then I found it on my system... ??? This was because ubuntu-dev-tools depends on distro-info :-) Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20121231170700.GA6837@goofy.localdomain
Re: Knowing the release names in advance
On 12/31/2012 08:03 PM, Neil Williams wrote: Or it could simply use the names which don't change: oldstable, stable, testing, unstable, experimental. That's what multistrap does. That's why the archive *has* names which don't change. Then we release a new stable, and these names have a different meaning ... Not a great idea. Even less a good one when many servers are involved, and you need to update them all so that it continues to bootstrap the same flavor you used to setup, which can be the case when these servers are setting-up VMs. An unblock request for this kind of change wouldn't be a problem, neither would a backport. It's not as if this is common. There aren't that many bootstrapping tools. Wouldn't it be more simple to just choose a name and we would never ever have to talk about it again, and never ever have to process any of such unblocks? Do you have numbers available of how many software reference the names of the releases? I'd be very curious to know. What I saw in codesearch.debian.net when searching for both Wheezy and Jessie made me think otherwise (eg: there was a lot more wheezy occurrences than jessie, leading to potential problems when Wheezy is out and Jessie starts to exist). What about the social aspect of being able to actually talk and write about Jessie+1 with its name, rather than just Jessie+1? There is no point having a name for release+2 because there will not be any content for that name until after the release of something which doesn't exist until after the current release. i.e. Jessie has no content currently. It won't have any content until after Wheezy is released. Talking about the name which comes after Jessie is pointless - nothing will exist for that name for years yet. Complete vapourware. You still haven't made the (technical) point as to why it's a bad thing to know the names of release+2 in advance. Nobody ever did. I just had as an answer but it doesn't exist yet so it doesn't make sense, which isn't a satisfying answer, neither socially or technically. Just use testing and provide the name via backports What if I want to display to the user the names of releases, and not just testing? After all, it's my choice to make, no? What if I don't want to use backports (and I really don't, if I can avoid it)? I've not seen any valid technical reasons why we should know it beyond the start of the freeze. A name would be meaningless that far ahead. I just gave you one, and you've dismissed it completely saying that we can unblock packages after the freeze. Also, is it meaningless when I type jessie+1? A lot of people does us this. I see it in many threads. Especially as we get closer to the freeze. That alone, IMO, should be enough reason so that we have a name to talk about, and not just whatever+1 which I believe is the meaningless word. I don't understand how you can just dismiss this (social) fact. I don't see technical reasons to invent a label for vapourware. Wikipedia has the following definition for vapourware: Vaporware is a term in the computer industry that describes a product, typically computer hardware or software, that is announced to the general public but is never actually released nor officially cancelled. I don't claim that wikipedia is always right, but I do agree with such definition. So unless you are claiming Debian will die before Jessie+1 that's not matching what a vapourware is. Jessie+1 will really exist, and be released, at some point. So it's quite a natural thing to talk about it, and sometimes to reference it in some piece of software (funny thing: I now notice the added / removed u depending if you are American or English. :) ) Perhaps you see a better match with this: The term also generally applies to a product that is announced months or years before its release, and for which public development details are lacking. But I don't see why not knowing yet what feature/details will be in, is a blocker to decide the name in advance. That is, IMO, unrelated. Naming something which (at that point) has a non-existent feature set is a nonsense. The above sentence doesn't help me to understand what's wrong with my reasoning. You're not making any technical nor social point here, IMHO. Cheers, Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e1edaa.7010...@debian.org
Re: Knowing the release names in advance (was: Feedback)
On Mon, Dec 31, 2012 at 7:18 PM, Dmitrijs Ledkovs wrote: $ man debian-distro-info Debian OS provides API to query such information. In addition, stable alias names are also provided (stable, testing, unstable, experimental). As a last resort you can also scrape archive mirrors dists (e.g. ftp-master, snapshot, old-releases) and check the symlinks. That seems like a hack to workaround the fact that the archive doesn't provide this information in one file. -- bye, pabs http://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caktje6gvyqu6+zbbak8y-rf2ckxfyt5oqkc4bpfgsfmpy4k...@mail.gmail.com
Re: Knowing the release names in advance (was: Feedback)
On 12/30/2012 04:26 PM, Thijs Kinkhorst wrote: Would it be an idea to publish the list of version numbers and associated code names a few releases ahead, say the upcoming three releases? Of course the prerogative of deciding on the names will remain with the release team, it would only be pulled forward a bit. I have 3 things to say about this. Yes, then yes, and yes again. Not only this is good for our users, but this is also technically needed for both upstream and us, doing the packaging. Let's say you have a software that somehow, installs Debian. Then it might require the user to select which name of the release to install. Currently, we knew about the name Jessie *after* the freeze, meaning that we couldn't have written a software that would debootstrap it without asking for an unblock. I made that point very clear multiple times, and I haven't been the only one doing it. Yet, it hasn't been heard, and I never receive any technical argumentation as to why we shouldn't know the release names well in advance. Maybe if there was a greater number of DD insisting that this is necessary, this could change. Please +1 to this if you agree. If there is a reason why we shouldn't know, please expose it in this list. I, don't see any. Thomas P.S: I personally don't care at all what the name is, I just care to know it in advance. Please don't come with the argument that it is difficult to choose, that would be very backward, because a name has to be chosen sooner or later... -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e078ac.5010...@debian.org
Re: Knowing the release names in advance (was: Feedback)
On Mon, Dec 31, 2012 at 01:23:56AM +0800, Thomas Goirand wrote: Please +1 to this if you agree. Please don't. -devel is not a popularity contest. Kind regards Philipp Kern signature.asc Description: Digital signature
Re: Knowing the release names in advance
On 12/31/2012 04:16 AM, Philipp Kern wrote: Please don't. -devel is not a popularity contest. I'm stunted by the complexity of your argumentation. It for sure helps in the debate. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/50e13074.3020...@debian.org
