Re: Backports removed from sources.list ;-(
On Sun, Apr 19, 2015 at 12:01 PM, Michael Gilbert wrote: > On Sun, Apr 19, 2015 at 11:44 AM, Paul van der Vlis wrote: >> Hello, >> >> I saw backports has been removed as default setting from sources.list in >> Jessie RC3. I am very disappointed by this last minute change, without >> much discussion so far I know. > > The installer's export mode allows you to make a choice about this, so s/export/expert/ -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMKRBbPo0c7ZFwsLTgTOCRatyW=6kozqxyve93qfp+...@mail.gmail.com
Re: Backports removed from sources.list ;-(
On Sun, Apr 19, 2015 at 11:44 AM, Paul van der Vlis wrote: > Hello, > > I saw backports has been removed as default setting from sources.list in > Jessie RC3. I am very disappointed by this last minute change, without > much discussion so far I know. The installer's export mode allows you to make a choice about this, so please consider using that mode for all of your installs. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MMdNUkCrnhHBPv6m=uav4+bfxzcn-rsaoxnaswmvoy...@mail.gmail.com
Re: draft alternative proposal: fix problem at the root
On Wed, Dec 3, 2014 at 9:31 AM, Sam Hartman wrote: >> "Russ" == Russ Allbery writes: > > Russ> There's another alternative to using the CTTE, and my > Russ> understanding is that this was generally the method used prior > Russ> to the existence of the CTTE, but I'm not sure it's really any > Russ> better. > > Russ> There are specific teams in Debian, generally delegates at > Russ> this point, that sit at choke points and can effectively make > Russ> decisions like this as part of the course of their duties. > Russ> For example, for the init system decision, I suspect a lot of > Russ> the pressure would have been on the d-i team to pick a > Russ> default. In the past, the usual victim for many of our > Russ> disputes has been ftp-master, since they can block archive > Russ> uploads or eject things from the archive. For others (and I > Russ> can recall some epic ones), it was the DAM. > > I remember back in my first years of Debian thinking that the TC wasn't > very effective. Stuff would get brought to them and not really > decided. > > Some folks (Ian's name springs to mind particularly but I don't recall > without going back to mail from the 2004-2006 time frame) really made an > effort to make sure that the TC responded to issues brought to it. The > TC became effective in that it gave answers if you brought issues to > them. > > Today, I think we have an opportunity to see if we can transform the TC > into a body that's good at helping people make these sorts of decisions > when there is conflict. I think it will be as much about mediation, > about asking people to work together, about pointing out to people they > are talking past each other, about asking people to reconsider their > decisions with certain criteria in mind than about overriding people. Doesn't that require constitutional change? The current powers as written make the TC a decision-making body, not a mediation body. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mm2pblhvxhpeyzq6k9y2wqv47fjaomuvbcehob_bda...@mail.gmail.com
Re: DEP-5 (copyright file format) ... gap with practice
On Wed, Sep 10, 2014 at 12:48 AM, Andrey Rahmatullin wrote: >> another clear benefit is reduced package cruft. > The only thing that is reduced is the size of the orig tarball. People do actually do review package source changes (think every release team unblock, security analysis, etc.), and the hugeness of autotools diff is more often than not rather burdensome. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MPBCrq5J8yTvkQm1eHnwv6tM=VCnDoQpWn2EQ=08xu...@mail.gmail.com
Re: DEP-5 (copyright file format) ... gap with practice
On Tue, Sep 9, 2014 at 8:40 AM, Andrey Rahmatullin wrote: >> You could always use the Files-Excluded field to make uscan remove >> those files from the upstream tarball, > Too much work (at least when you are not repacking the tarball for other > reasons) for absolutely no gain. Not sure how that's a lot of work since uscan does all the magic for you. One benefit is less time on copyright file research/review, and another clear benefit is reduced package cruft. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mnsnyjinwj7znpd9pmev+mrz+tso2da8j1awodhyne...@mail.gmail.com
Re: DEP-5 (copyright file format) ... gap with practice
On Mon, Sep 8, 2014 at 11:38 AM, Osamu Aoki wrote: > Hi, > > DEP-5 as defined in http://dep.debian.net/deps/dep5/ does not have any > clause allowing us to skip license entries for certain class of files. > > In practice, many packages lack entries for autotools generated files > which come with very permissive license with mostly identical but not > quite the same copyright phrases which reqire us to quote them > separately. > > I am talking about autotools files such as: > PERMISSIVE > * */Makefile.in > * m4/*.m4 > * configure > * INSTALL > * aclocal.m4 > GPL-2.0+ with autoconf exception > * compile > * depcomp > * missing > * py-compile > * test-driver > * m4/introspection.m4 > * m4/intltool.m4 > GPL-2.0+ with libtool exception > * ltmain.sh > GPL-3.0+ with autoconf exception > * config.sub > * config.guess > MIT > * install-sh You could always use the Files-Excluded field to make uscan remove those files from the upstream tarball, then use dh-autoreconf (or symlinks for e.g. config.sub and config.guess) to recover them at build time. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mm2lqhhckiejq4q7qj+ethi3uuxmor9s9hfvtoyhfc...@mail.gmail.com
Re: Reverting to GNOME for jessie's default desktop
On Fri, Aug 8, 2014 at 11:52 AM, Camaleón wrote: > I really (and still) like the idea of having no default desktop at all > and let the users decide by themselves if they even want to get a DE when > performing a DVD based installation. Including all potential DE options on the main install disc (so the user can make that choice in a no-net install) will mean a huge bandwidth increase, not to mention that probably means bluray-only. There already exist netinst media that solve that problem much better by including no DE packages on the media. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=MO1_EwWrpCvWML6B0u_=y8z8bvoiyumhq8efdscziy...@mail.gmail.com
Re: Maximum term for tech ctte members
On Tue, May 27, 2014 at 2:18 PM, Ian Jackson wrote:
> Michael Gilbert writes ("Re: Maximum term for tech ctte members"):
>> On Sun, May 25, 2014 at 2:22 PM, Russ Allbery wrote:
>> > I don't think this achieves the goal of rotating more project members
>> > through the TC.
>>
>> You could rotate people in to serve in place of the TC members that
>> are on sabbatical, which means at least one new perspective per year.
>
> I really don't like the idea of having two tiers of TC members -
> "permanent" ones and these new rotating one-year ones.
A simple analogy, people in the rotating seats are to the permanent TC
members as debian-maintainers are to debian-developers.
DM has some definite advantages, people more autonomy and have a whole
lot more to show when going for DDship, and some flaws, it makes the
process of becoming a DD longer and possibly more tedious (depending
on perspective) than the question and answer process.
The same could be said for rotating TC members. So, I think it worth
considering the larger perspective that the project may view the TC as
insular, and that possibly something should be done about that.
Best wishes,
Mike
--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/CANTw=mnc3brpt2qnu86kopt3+yhq7po1+nncrscnx57f7ae...@mail.gmail.com
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 2:22 PM, Russ Allbery wrote: >>> We could combine both features, though: set a term length of two years, >>> and then say that people can serve for two terms in succession but then >>> have to leave the committee for at least one term. > >> 8 seems like it would be near ideal: turnover is dealt with only about >> once per year, it is close to the average of the existing members terms >> (7.385 years), and it's likely close the historical average (although I >> haven't calculated that, would be interesting for someone to research). > > I don't think this achieves the goal of rotating more project members > through the TC. You could rotate people in to serve in place of the TC members that are on sabbatical, which means at least one new perspective per year. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mnofybvzozunp6o2sdxh2+t0r4bwaeye_90jgaexqh...@mail.gmail.com
Re: Maximum term for tech ctte members
On Sun, May 25, 2014 at 1:37 PM, Russ Allbery wrote: > We could combine both features, though: set a term length of two years, > and then say that people can serve for two terms in succession but then > have to leave the committee for at least one term. 8 seems like it would be near ideal: turnover is dealt with only about once per year, it is close to the average of the existing members terms (7.385 years), and it's likely close the historical average (although I haven't calculated that, would be interesting for someone to research). A 1 year sabbatical could be imposed every 7 years with the seat remaining available upon return (the TC still works, and is even possibly more effective with on average 7 members rather than 8)? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANTw=mo2aezfkriccisjt13cj1s9odnb8q8ryjxw4mxxn0x...@mail.gmail.com
Re: systemd bad press? score card?
On Tue, Feb 11, 2014 at 10:08 AM, Matthew Vernon wrote: > Joey Hess writes: > >> Russ Allbery wrote: >> > I think we're still in the middle of our process, which I understand >> > that a lot of people outside the project find baffling and protracted. >> >> Well, not only outside the project. >> >> The tech ctte has always operated in the past by coming to a consensus >> and then voting to satisfy the constitution's procedural requirements. > > The split in the cttee on this issue makes me wonder whether the > answer is "none of the proposed systems is Correct", so we should not > tie ourselves too tightly to any particular answer just yet. That's > not to say that we shouldn't decide upon a default init system for > jessie, but rather that we shouldn't do anything that would make it > harder to change our init system to the Correct one, once the Correct > one is found/decided upon/written/... This is the exact point I've been making for two months now, but the TC went been full steam ahead on immediate change, disregarding nuanced efforts like init-select making multiple inits more usable. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MN0Dp7USENJX+J6Bmwgj7cYt5rOtrwuZG+BKfxQHzwg=g...@mail.gmail.com
Re: systemd bad press? score card?
On Mon, Feb 10, 2014 at 7:22 PM, Joey Hess wrote: > Russ Allbery wrote: >> I think we're still in the middle of our process, which I understand >> that a lot of people outside the project find baffling and protracted. > > Well, not only outside the project. > > The tech ctte has always operated in the past by coming to a consensus > and then voting to satisfy the constitution's procedural requirements. > Since the constitutional procedure as applied to the small scope of the > ctte is now demonstratably broken in cases where a consensus cannot be > reached, why are we waiting around for the full horribleness of it to > manifest? > > I'd be in favor of a GR to fix the constitution to not mandate > that the ctte use untested and nonfunctional procedures. Seconded (if this were -vote). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPoJB2x+XP29JtdGZL2XfWq7p+=nlywupmdbewhrvm...@mail.gmail.com
Re: upload processing resumed
On Sat, Dec 8, 2012 at 11:41 AM, Paul Tagliamonte wrote: > It's my understanding that this is a result of a debianqueued bug, not dak > it's self. > > It's unlikely other people are using it, IMHO That's making another assumption and isn't provable or disprovable. Even it is somehow true now, future adopters may start making use of it, and they should be aware of past issues to make sure they check out a new enough release. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MPDbBTeorgR0RnzhN=xtucboiwxisehneqgecebcfb...@mail.gmail.com
Re: upload processing resumed
On Sat, Dec 8, 2012 at 3:32 AM, Joerg Jaspert wrote: > On 13054 March 1977, Yves-Alexis Perez wrote: >> Is dak is present in a “released” state somewhere? Do other people use >> those releases? Meaning, should we ask for a CVE for this? > > No, no and no. > > We have git. We have people use that, thats for sure. Checked out at > various dates. I don't think thats something a CVE should be issued > for. Though I won't block it if someone does, but the only thing you can > do is "anything before commit XY, update with the latest". CVE is an awareness thing, helping people become aware of the vulnerabilities they may have. The above wording would be a fine line in terms of defining what is vulnerable. > I really hope (and we silently somehow assume) that those who use dak > are following at least debian-...@lists.debian.org. I really don't think anything like that can be assumed. My guess is that a larger percentage of clones have had no reason to subscribe to the ml, and thus won't know about the problems in their versions. Overall, it's better to be as transparent as possible to diffuse knowledge further. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MNnejU4BfYbHOdXccoXnp1z71gjBYu3WQWLdhnuH=f...@mail.gmail.com
Re: Feedback on your Whois system proposal - Was: Re: Review of personal information sources in Debian
On Thu, Aug 16, 2012 at 8:52 AM, Enrico Zini wrote: > Recklessly exposing too much information outside the context in which it > was published can in some cases turn people away from contributing. If > ohloh were actually being taken seriously by people in my professional > circle, I would probably have to consider going through the extra > trouble of not using my real identity while contributing to Free > Software. We do not want that. Couldn't most of these problems be solved by making the system opt-in (i.e. requiring the user to do some manual configuration under his alioth home with the ability to enable only the appropriate bits that he/she wants)? Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MP2E4CwFzP8f1DbLf9iorVD=i9on895wmrfgl8dkgd...@mail.gmail.com
Re: trademark policy draft
On Tue, Aug 14, 2012 at 11:25 AM, Thijs Kinkhorst wrote: > The benefit is that we have a legal tool against someone doing something > nasty with our name. Which is nice to have, but doesn't come for free. > It's hard to quantify as well: the benefit is for a future situation of > which we do not know if or when it will happen. For what its worth, there are existing situations: e.g. debian-news.net, debian-administration.org, debianadmin.com, debian-handbook.info, debian-multimedia.org. Only one of those has been specifically opposed by the project, and a kind request resulted in a domain rename without any kind of legal wrangling (now deb-multimedia.org). So, point being that results can already be achieved without any kind of legal hammer. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mnyo4-xitacfbbspqh_yjufkedoroupz7a0xq4qvv_...@mail.gmail.com
Re: General Resolution: Diversity statement results
On Wed, Jun 6, 2012 at 12:45 PM, Kurt Roeckx wrote: > On Wed, Jun 06, 2012 at 05:08:52PM +0100, Ian Jackson wrote: >> >> If I could get a copy of the Secretary's running source code I could >> also change it so that options were lettered rather than numbered. >> That would be /much/ less confusing... > > master.debian.org:/org/vote.debian.org/ > > It's about to move to a new host, and I'm not sure if DSA is still > going to give everybody access to that host. Why is it that devotee has moved to a private development model? This seems to be contrary to Debian's goal of maximal openness, and the previous secretary openly published his work: http://anonscm.debian.org/gitweb/?p=users/srivasta/debian/devotee.git That's nice for review and study, bit it would be even more ideal if the code were available on a DD-writable repo (perhaps within collab-maint). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MN8guM+mu+08GAx=qhxz8qhifd_o872lbcx1+gqpdt...@mail.gmail.com
Re: 1 year release good enough.
On Sun, Jan 1, 2012 at 1:21 AM, dE . wrote: > Hi. > > I was wondering about the 2 year release cycle of Debian and it's > adaptability on the Desktops. If you want something with a faster release cycle, there is always testing, which is updated four times a day. If you want something slightly more stable than that but not on a two-year cycle, there are now (unofficial) monthly snapshot releases too: http://cut.debian.net Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=MM_Ox07E7O8TGAm7mS7cuppqieHw1ugBZiPCqQqV=h...@mail.gmail.com
Re: gnome2
On Sun, Jun 12, 2011 at 12:04 AM, Michael Fogg wrote: > will debian in future releases use gnome 2.32 becuse gnome 3s fallback mode > just is not gnome 2.32. > i know it takes a lot to maintain gnome 2 but will you please keep it in the > system. > even if you dont maintain gnome 2 at lest keep it in the system. > i really dont care if gnome 2 gets maintained just as long as i have it the > debain. > maybye what you can do is make two gnome distros one for gnome 3 and gnome 2 > that looks good to > me and hopefully to you. > reply. :) Debian is an all volunteer project, so if you're interested in this, you can be the one to make it happen! Find a team of like-minded individuals, come up with a solution that respects gnome3 as the default, convince some DDs to sponsor your work, and just do it. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/BANLkTi=fdwfer4g6ygqerr5pb-fwwzy...@mail.gmail.com
Re: Debian netinstaller
On Sat, 5 Feb 2011 11:57:43 -0700 Yacin Belmihoub wrote: > > Hi there, I would just like to know how to recompile Debian > netinstaller, I really need help for this. Thx and hopefully you can help me > :) $ sudo apt-get build-dep debian-installer $ apt-get source debian-installer $ cd debian-installer*/build $ make build_netboot This is really a question for the debian-user mailing list. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110205142740.6340824d.michael.s.gilb...@gmail.com
Re: What is annoying in the flattr buttons?
On Fri, 12 Nov 2010 17:27:08 +0100, Tollef Fog Heen wrote: > ]] Tshepang Lekhonkhobe > > | It's more like "use this thing that I produced, and if you want, you > | can reward me with a few cents". There simply is nothing distasteful > | about that. > > You don't think so. I do. One of the reasons is it puts a, IMO too low > value on other, similar work, so by taking petty donations for small > pieces of work, you are lowering the value of my work too. Lowering the > value of the work your codevelopers are doing is, IMO, rude. I realise > that's not the intention of asking for money, but the effect is there. How can you possibly reduce the monetary value of volunteer work? Or more inquisitively, how is it even feasible to assign a price to such work in the first place? In fact, some have tried. Using a metric such as sloccount, the Debian operating system is valued at $13 billion (I forget the reference, but its out there), and yet I can get it for $0. According to your argument, all of Debian's volunteers are doing the world a major disservice in actively preventing a potential $13 billion in revenue from infusing into the economy. How cruel!? Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101112150447.cf326285.michael.s.gilb...@gmail.com
Re: What is annoying in the flattr buttons?
On Wed, 10 Nov 2010 13:56:18 -0800, Russ Allbery wrote: > Tshepang Lekhonkhobe writes: > > > Anyways, you should not complain when someone asks you to give them > > money, even if it results in you feeling guilty for not complying. > > I respectfully disagree. Depending on the context and the situation, I > may consider someone asking me to give them money to be intrusive and > obnoxious, and I reserve the right to complain when it happens in shared > public space. You can complain all you want (a valid expression of your freedom of speech), but you have no right to restrict others' freedom of the same. If you find particular words annoying, feel free to exercise your own freedom to ignore them, but don't impose restrictions based on your own preferences. Raphael has every right to attempt to pursue his field of endeavor in any tolerant/respectful manner he chooses. Let him experiment. The only legitimate argument I've seen in this thread is the privacy concern. Since flattr, and of course any other external site, has the ability to collect browsing habits without click throughs (a privacy violation), all external content should be blocked, as mentioned previously. Of course, that creates a new problem; desired content is obstructed as well. Then again a quick and easy solution is to duplicate that lost content directly on the planet server. Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101110193639.9d02f450.michael.s.gilb...@gmail.com
Re: Dropping the .0 on release numbers?
On Wed, 15 Sep 2010 17:12:15 +0200, Mehdi Dogguy wrote: > On 15/09/2010 16:27, Michael Gilbert wrote: > > > > I was thinking about this overnight, and I think dropping .0 does > > actually make a lot of sense for marketing/publicity purposes. A > > release announcement along the lines of "The Debian project is proud > > to announce the release of version 6 of the Debian operating system" > > seems a bit cleaner/professional than the same statement with 6.0 > > instead of 6. > > > > You forgot the argument about “stability”, which is as pertinent as > “professional” and “clean”, imho. Yes, of course any discussion on this matter is subjective. This is simply my opinion, which I understand carries absolutely no weight since I have no authority. As a release manager, feel free to make your decision with or without taking my, and other, opinions into account. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915111653.3f99c0a6.michael.s.gilb...@gmail.com
Re: Dropping the .0 on release numbers?
On Wed, 15 Sep 2010 15:23:30 +0200, Thijs Kinkhorst wrote: > On tiisdei 14 Septimber 2010, Gunnar Wolf wrote: > > So, for the past years we have had x.0.y with growing `y' for point > > releases, and skiping to (x+1).0.0. And the zero in the middle carries > > no meaning anymore. > > It also doesn't do any harm, does it? > > I would vastly prefer not to change our version numbering scheme yet again. > It > was already changed for Lenny to replace r1 with .1. Your proposal would give > us the following followup of numberings for the first point update of our > recent releases: > > Sarge: 3.1r1 > Etch: 4.0r1 > Lenny: 5.0.1 > Squeeze: 6.0.1 > Weezy: 7.1? > > Our users have come to understand now that 5.0.1 is equivalent to 4.0r1, and > that 3.1 is a different full release fom 4.0. Changing it after squeeze to > something different yet again buys them and us nothing but unnecessary churn. > Stability in numbering is worth a lot more than removing an extra ".0" from > the string. +1 also. I was thinking about this overnight, and I think dropping .0 does actually make a lot of sense for marketing/publicity purposes. A release announcement along the lines of "The Debian project is proud to announce the release of version 6 of the Debian operating system" seems a bit cleaner/professional than the same statement with 6.0 instead of 6. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100915102713.d4a070f8.michael.s.gilb...@gmail.com
Re: Dropping the .0 on release numbers?
On Tue, 14 Sep 2010 14:13:35 -0400, Noah Meyerhans wrote: > On Tue, Sep 14, 2010 at 01:58:51PM -0400, Michael Gilbert wrote: > > The .0 actually has quite a bit relevance since it signifies a new > > major long-term release. It also demonstrates stability when used in > > conjunction with the third digit. 6.0.1 seems like a rather minor > > update, which accurately describes stable point updates. Whereas, 6.1 > > seems like a much more experimental update. > > If somebody wants to infer such meaning from the version strings we use, > that's up to them, but such an inference really isn't accurate. When > you only have one "stable" version at a time, and every new stable > version constitutes a major release, the .0 is redudant. [0] isn't a definitive source, but it does state a standard versioning convention pretty much in line with what most users are accustomed to. Using that scheme, minor (i.e. point releases) are signified via third digit updates. > IMO, when a release identifier consists of just an integer, incrementing > that integer is a pretty strong suggestion that a new major release has > happened. A .0 suffix isn't necessary for that. IMO, its cleaner to go from 1.0 to 1.1, but then again we're all experts in version numbers, so my opinion, and yours, carry little weight with respect to the the totality of version number opinions. > To signify minor releases, some people do things like 5.01, indicating a > smaller change than 6.1. That'd be one possibility for stable updates. > Or maybe just something like 5r1 as we've done in the past. > > > Also, as I mentioned elsewhere, testing could start to get beta-like > > versions numbers, which would be useful for branding snapshots (e.g. > > 6.9.20100912). > > Why not just 20100912? What does "6.9" actually signify, and how is > 6.9.20100912 distinguishable from some update to 6.9 in this scheme? It signifies that the release was somewhere between version 6 and version 7. The .9 signifies that its closer to 7 than 6. 20100912 itself doesn't convey where it stands in the overall release scheme. > For the record, count me in as supporting integer release numbers. I've > wanted to see this for some time. This discussion is a bikesheddding effort. I suggest limiting further discussion toward finding an appropriate standard so those with authority to make a decision have a basis for their choice. Best wishes, Mike [0] http://www.everything2.com/index.pl?node_id=1128644 -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100914154535.11852033.michael.s.gilb...@gmail.com
Re: Dropping the .0 on release numbers?
On Tue, 14 Sep 2010 12:25:25 -0500, Gunnar Wolf wrote: > Hi, > > We have carried a major.minor scheme as a release numbering scheme > since the Early Days, but it has lost relevance basically since Sarge > (3.1 - But by the time it was finally released, some discussion was > made whether Sarge should be 4.0 as the difference from Woody was > already too large, to which the release team IIRC answered "it would > be right but it's too late"). Since Etch released (2007), we have > always used x.0. The .0 actually has quite a bit relevance since it signifies a new major long-term release. It also demonstrates stability when used in conjunction with the third digit. 6.0.1 seems like a rather minor update, which accurately describes stable point updates. Whereas, 6.1 seems like a much more experimental update. Also, as I mentioned elsewhere, testing could start to get beta-like versions numbers, which would be useful for branding snapshots (e.g. 6.9.20100912). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100914135851.939aa4a8.michael.s.gilb...@gmail.com
Re: Support timeframe
On Wed, 23 Jun 2010 12:22:36 -0500, Steve Smith wrote: > Hello, > > In general, how long is a version for Debian supported? Ie, I believe that > it is Microsoft's policy to stop providing support (patches, fixes, etc) > after 6 years from a release. Is there any such policy for Debian and if so- > what is it? What would it be for version 5? Ie, is it safe to say that > version 5 will not be supported after 2014? > > The reason why I ask is because we have a hardware appliance that is based on > Debian and we are working on upgrading to version 5. Because the previous > version is not longer supported, we need to provide a patch policy for our > appliance. Stable releases are supported for one year following the release date of the subsequent stable release. Hence, support for Debian Lenny (5.0) well end sometime toward the end of 2011 (assuming Squeeze is released toward the end of 2010). Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100623140040.d14d3dce.michael.s.gilb...@gmail.com
Re: Squeeze, firmware and installation
On Wed, 05 May 2010 21:57:46 +0300, Arto Jantunen wrote: > Seriously speaking, to me it seems very clear that non-free firmware > will not be present on official installer images. Then again, the > installer team has made it very easy to inject firmware during > installation on machines where it's needed. The non-free archive is actively maintained and supported by the Debian project, so a precedent is already set. I personally don't see any difference with respect to providing an option for non-free installation media as well; so long as there remains a fully free option. The developers that are interested in that feature should be free to implement it if they so choose, and users should be free to make their own choices about their use of non-free software. Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100505161923.a8ff3f40.michael.s.gilb...@gmail.com
Re: dpkg feature implementation
On Tue, 5 Jan 2010 13:55:34 +0530, dE . wrote: > The solution that I'm proposing is a super dep package. A single > 'sdebp' file which's suppose to install a singe software (mostly a > meta package for e.g kde) but contains all dependencies which might be > required by the package relative to a fresh OS install. A command to > make dpkg install this package will make it check all the dependencies > which are required to be installed from this super deb package in the > current system. Thus only the required will be installed to satisfy > the dependency of the meta package. This is an overly complicated solution to an already solved problem. Just mount the debian dvd/cd isos using the "loop" option (can be done automatically with an appropriate /etc/fstab) and add the mounted path to your apt sources.list. Best wishes, Mike -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
