Re: [dev] surf release?
On Tue, Jun 02, 2015 at 02:59:00PM +0200, Christoph Lohmann wrote: > I could push out more releases and tag nearly every new feature that’s > stable, if you like. But here’s my view that struggles me. I am using > releases to reconsider what’s done in the project and what could be done > next. Just tagging it would be a soft hint for you what’s changed. This > would be solved by having a simple Changelog file in the project, which > I would accept. > > But you being a packager, here’s my most important question: Do you need > the checksum of the tarball? If not, then the link to the cgit interface > would be enough for download. This saves much time in the release gener‐ > ation. Due to how we do things in Arch, I don't need a checksum provided by the upstream, no. I download it once, record the checksum in the PKGBUILD, build the package and test it. The checksum is needed more for the benefit of knowing that you are building the same thing as the packager did, not for any actual verification of the source. That would require a proper signature. signature.asc Description: Digital signature
Re: [dev] surf release?
On Mon, Jun 1, 2015 at 3:23 PM, Aditya Goturu wrote: > Why do we need to "appear busy". If people want to use better > software, they will. We don't need to "appear busy" > It was a joke. This entire thread is a joke.
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 10:28:40AM -0600, Anthony J. Bentley wrote: > Suckless has settled on the wrong solutions for years. Case in point: > customizing software by compiling it. Seriously? Compiling dwm or st takes less than a second, sucks a lot less (in of itself, without regard for context) than building your own parser for some config language, when you already have one in the form of a C compiler. > How often do you recompile mv, cp and rm? False analogy. These are not meant to be customized. They do (or should) do one job, well, and be orthogonal. No need. > Even compiling your kernel is something that should be discouraged. Debatable. Not everybody needs or wants a glut of features exposed by the distro stock config, like half a dozen MACs. Anyhow, keeping up with the stable queue yourself is not such a bad idea if your distro doesn't. That and out of tree patches to make the block elevator suck less, adding support for hardware not yet supported by even mainline, etc. > Customization, knobs, conditional compilation... all of these things > are anti-Unix. So it's anti-UNIX for me to bump the border width font size up because my vision is terrible? What if I want some blue and orange dwm because the stock choice pale-ish blue and grey (in the 5.x days) is in humble my opinion ugly? Regards, Alex Pilon pgptGQ_Aq_fsk.pgp Description: PGP signature
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 08:40:40PM +0200, Dmitrij D. Czarkoff wrote: > Greg Reagle said: > > I don't know git well, just the basics, but why don't you use a git > > commit id as the target for patching and packaging? As far as I > > understand, a tag is just a "friendly" name for a commit id anyway. > > 1. In some packaging software that will fuck up package versioning and >updates beyond repairs. > 2. If there is any review process, maintainer will have hard time >explaining why he packages snapshot - it is widely believed that >maintainers make releases when they consider software stable enough >for packaging. > 3. It requires quirks that suck so much that it is not suckless any >more. Good evening, I'm no suckless expert, and this will probably sound really trollish and asshole-ish, but you know what wouldn't suck? A human who loves package managers and mirrors surf git, tests it periodically, and tags it, with a third version number (e.g. 0.6.x), anytime he/she/it (and whoever files his/her/it issue tickets) deems it stable, to help package mantainers! -- Teodoro Santoni
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 10:28:40AM -0600, Anthony J. Bentley wrote: > 7heo writes: > > Suckless comes from suck less. We're not here to settle down on wrong > > solutions. > > Suckless has settled on the wrong solutions for years. Case in point: > customizing software by compiling it. How often do you recompile mv, cp > and rm? Even compiling your kernel is something that should be > discouraged. Not because compiling is bad, but because a glut of > features is bad. Customization, knobs, conditional compilation... > all of these things are anti-Unix. > > Suckless is full of people who fetishize Unix without understanding it. I'm gonna eat your bait: you're mismatching Unix with BSD. Furthermore, out-of-the-box, convention-without-configuration software and software shipping with their own DSLs, scripting engines, and/or plethora of .so plugins equally suck. Suckless.org software is not TRV VNIX either, some of the devs are plan9 fetishists and hate heartily some parts of the Unix design (or whatever remained from SysV and posix standards) too, so what's the point in searching true unixness in here? Configuration at compile-time is something that caters to an user who would like to dedicate sometimes to one of the few clients he/she/it will use in his/her/its life for who knows, years or even decades: compile, evaluate, edit, recompile. When it's good it'll change only when it'll become bad. I've compiled st once in a year. Recompiled it only recently to change font to Inconsolata. It isn't the way to go for devs which live off their program, or for programs which have to handle ten thousand RFCs, work under fast-pace in hardware development or defend millions of dollars from dozens of different attacks from the network. Imho this development model isn't the right one for a web browser, too. (not developing any browser, my opinion is very humble) And surely is not the way to go for users that don't have no time to waste in screwing up their unix offspring and download warez bundled from your favourite repo tree. But this project is aimed to users who like the suckless way, the users who like the pacman way or the apt way or the whateverbsd way and like surf too should give you money to configure and tag the source in the tidy way you love. -- Teodoro Santoni
Re: [dev] surf release?
On Mon, Jun 1, 2015, at 03:31 PM, Jack L. Frost wrote: > 1) How do I know if a certain tag is stable enough to use? Do I just take > the > current HEAD? Do I spend my time extensively testing a few latest tags to > figure out if they are stable or not? I assume by tag you mean commit because we are discussing a lack of tags. Ask the developer(s) about which commit is considered stable. Or use the current HEAD. Both are reasonable options (for a suckless project, not saying that using current HEAD would be good for other projects). It's up to you how you want to spend your time, but I certainly don't think there is any *need* for you to do any testing to determine what is stable, when you can just ask the developer(s) and/or use the current HEAD. You could also, if you want to be very conservative, use the latest tag, which in surf was 0.6 on 2013-02-10. I am not a surf developer with any authority (I guess I am technically a surf developer since I submitted 2 minor patches, but I have no power or authority at all), but as a surf user, I would be happier with the packaged version being the current HEAD at time of packaging. -- http://www.fastmail.com - A no graphics, no pop-ups email service
Re: [dev] surf release?
Greg Reagle wrote: > To follow up on my suggestion to use a git commit as a version, the > following command in fish automatically produces a version number: > date --date (git log -1 --pretty=format:%aD) -u +%Y.%m.%d.%H.%M.%S > > In bash, it would be: > date --date "$(git log -1 --pretty=format:%aD)" -u +%Y.%m.%d.%H.%M.%S Heyho Greg, git timestamps are not guaranteed to be monotonic. Also there could be two commits with the same timestamp. --Markus
Re: [dev] surf release?
Greg Reagle said: > In bash, it would be: > date --date "$(git log -1 --pretty=format:%aD)" -u +%Y.%m.%d.%H.%M.%S date: unknown option -- - usage: date [-aju] [-d dst] [-r seconds] [-t minutes_west] [-z output_zone] [+format] [[cc]yy]mm]dd]HH]MM[.SS]] But you have a point - this idea would sound awesome to some GNU folks. I bet autoconf people would absolutely love it. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
To follow up on my suggestion to use a git commit as a version, the following command in fish automatically produces a version number: date --date (git log -1 --pretty=format:%aD) -u +%Y.%m.%d.%H.%M.%S In bash, it would be: date --date "$(git log -1 --pretty=format:%aD)" -u +%Y.%m.%d.%H.%M.%S -- http://www.fastmail.com - Or how I learned to stop worrying and love email again
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: > I don't know git well, just the basics, but why don't you use a git > commit id as the target for patching and packaging? As far as I > understand, a tag is just a "friendly" name for a commit id anyway. 1) How do I know if a certain tag is stable enough to use? Do I just take the current HEAD? Do I spend my time extensively testing a few latest tags to figure out if they are stable or not? 2) Git makes it annoying to do integrity checks vs tarballs. 2) Patches. When you don't give people targets to write patches for once in a while, you get a zoo of patches that re each written for an arbitrary commit (usuall the latest one at the time of writing the patch). It's a mess. signature.asc Description: Digital signature
Re: [dev] surf release?
Why do we need to "appear busy". If people want to use better software, they will. We don't need to "appear busy" On Tue, Jun 2, 2015 at 12:42 AM, Greg Reagle wrote: > On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote: >> On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: >> > I don't know git well, just the basics, but why don't you use a git >> > commit id as the target for patching and packaging? As far as I >> > understand, a tag is just a "friendly" name for a commit id anyway. >> >> If $APPLICATION versions 4541b821941a65e9c220acec2ab7256d7b21d690 and up >> support features X, Y and Z, can you tell me whether or not version >> 02e09b181db9b55d93a43a943d49048a4aeb0364 also has those features? > > Based on only the git commit id, the answer is no, and traditional > version numbers are generally easier to compare; I see your point. But > with access to the git log, then the answer is yes. Also, each git > commit has a time-stamp (AFAIK). So the timestamp might be a way to > express the version number, for example 2015.06.01.15.00.29 > (year.month.day.hours.minutes.seconds in UTC), in a packaging system > that expects a traditional version number. These could be compared like > traditional version numbers. > >> This >> become even more of a nuisance when you only have immediate access to a >> compiled binary; I often build packages on one machine then distribute >> only the binaries. Using hashes for versioning means you can't >> $APPLICATION -V to easily figure out how old the binary is I'm using. > > I see your point. One way to resolve this problem is to have the -V > option display the git commit id and timestamp. > > Just to clarify, I'm not saying that using the git commit id and/or > timestamp is better than or as good as a traditional version number. > What I'm saying is that, given an upstream that doesn't tag versions > often enough for your liking, using the git commit id and/or timestamp > seems like a workable solution. > > -- > http://www.fastmail.com - Does exactly what it says on the tin > > -- Aditya Goturu Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.
Re: [dev] surf release?
On Mon, Jun 1, 2015, at 02:36 PM, Eric Pruitt wrote: > On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: > > I don't know git well, just the basics, but why don't you use a git > > commit id as the target for patching and packaging? As far as I > > understand, a tag is just a "friendly" name for a commit id anyway. > > If $APPLICATION versions 4541b821941a65e9c220acec2ab7256d7b21d690 and up > support features X, Y and Z, can you tell me whether or not version > 02e09b181db9b55d93a43a943d49048a4aeb0364 also has those features? Based on only the git commit id, the answer is no, and traditional version numbers are generally easier to compare; I see your point. But with access to the git log, then the answer is yes. Also, each git commit has a time-stamp (AFAIK). So the timestamp might be a way to express the version number, for example 2015.06.01.15.00.29 (year.month.day.hours.minutes.seconds in UTC), in a packaging system that expects a traditional version number. These could be compared like traditional version numbers. > This > become even more of a nuisance when you only have immediate access to a > compiled binary; I often build packages on one machine then distribute > only the binaries. Using hashes for versioning means you can't > $APPLICATION -V to easily figure out how old the binary is I'm using. I see your point. One way to resolve this problem is to have the -V option display the git commit id and timestamp. Just to clarify, I'm not saying that using the git commit id and/or timestamp is better than or as good as a traditional version number. What I'm saying is that, given an upstream that doesn't tag versions often enough for your liking, using the git commit id and/or timestamp seems like a workable solution. -- http://www.fastmail.com - Does exactly what it says on the tin
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: > On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote: > > As a packager, I'd very much appreciate tagging once in a while so that > > we have > > static targets for patching and packaging. > > I don't know git well, just the basics, but why don't you use a git > commit id as the target for patching and packaging? As far as I > understand, a tag is just a "friendly" name for a commit id anyway. This is what actually is happening recently in several distributions, but it has drawbacks.
Re: [dev] surf release?
Greg Reagle said: > I don't know git well, just the basics, but why don't you use a git > commit id as the target for patching and packaging? As far as I > understand, a tag is just a "friendly" name for a commit id anyway. 1. In some packaging software that will fuck up package versioning and updates beyond repairs. 2. If there is any review process, maintainer will have hard time explaining why he packages snapshot - it is widely believed that maintainers make releases when they consider software stable enough for packaging. 3. It requires quirks that suck so much that it is not suckless any more. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 02:18:01PM -0400, Greg Reagle wrote: > On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote: > > As a packager, I'd very much appreciate tagging once in a while so that > > we have > > static targets for patching and packaging. > > I don't know git well, just the basics, but why don't you use a git > commit id as the target for patching and packaging? As far as I > understand, a tag is just a "friendly" name for a commit id anyway. If $APPLICATION versions 4541b821941a65e9c220acec2ab7256d7b21d690 and up support features X, Y and Z, can you tell me whether or not version 02e09b181db9b55d93a43a943d49048a4aeb0364 also has those features? This become even more of a nuisance when you only have immediate access to a compiled binary; I often build packages on one machine then distribute only the binaries. Using hashes for versioning means you can't $APPLICATION -V to easily figure out how old the binary is I'm using. Eric
Re: [dev] surf release?
On Mon, Jun 1, 2015, at 01:46 PM, Jack L. Frost wrote: > As a packager, I'd very much appreciate tagging once in a while so that > we have > static targets for patching and packaging. I don't know git well, just the basics, but why don't you use a git commit id as the target for patching and packaging? As far as I understand, a tag is just a "friendly" name for a commit id anyway. -- http://www.fastmail.com - The professional email service
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 11:16:52AM +0200, Dmitrij D. Czarkoff wrote: > Hi! > > There have been more then 2 years since 0.6 surf release (2013-02-10). > Maybe it is time for 0.7? As a packager, I'd very much appreciate tagging once in a while so that we have static targets for patching and packaging. signature.asc Description: Digital signature
Re: [dev] surf release?
Martti Kühne said: > Did you release your "big" patch to the public? It is a set of patches. Some are from wiki; some are mine; some are published. > Is it that hard to port it to HEAD? Trivial in my case. The point still stands though. Also, I am planning to add gtk3 patch to the mix - gtk2 webkit fails on several "web applications" I am forced to use - and then porting effort won't be trivial any more. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
On Mon, Jun 1, 2015 at 7:08 PM, Dmitrij D. Czarkoff wrote: > Martti Kühne said: >> However upstream is not everyone's taste either, in that configuration >> changes require recompiling of the respective binary. > > Exactly! I have a big patch for surf 0.6; it takes time to adopt these > changes to current snapshot, and there are better ways to waste that > time then to cherry-pick the changes. > > You may argue that I could follow the development closely and update my > patch with every commit. But that actually requires even more time, and > yet more time to build every revision. > > My solution is simple - I have a patch against surf package (which is - > wait for it! - of latest *version*). This way I only have to modify my > patch with every release. This works perfectly when maintainer indeed > bumps package version when user-visible feature lands in source tree. > Of course, this fails miserably when maintainer doesn't grasp the > concept of version. > You raise a valid point there regarding patches. surf is one of the larger projects in suckless, and porting a patch to HEAD may not be as trivial as an additional function in, say, a majority of dwm patches, which usually fail because the patch tool can't fit them into the right context. Did you release your "big" patch to the public? Is it that hard to port it to HEAD? I am not the guy who maintains the surf repository. And it's his decision and his behind to lift, and I also can't tell you how heavy that is. cheers! mar77i
Re: [dev] surf release?
Martti Kühne said: > However upstream is not everyone's taste either, in that configuration > changes require recompiling of the respective binary. Exactly! I have a big patch for surf 0.6; it takes time to adopt these changes to current snapshot, and there are better ways to waste that time then to cherry-pick the changes. You may argue that I could follow the development closely and update my patch with every commit. But that actually requires even more time, and yet more time to build every revision. My solution is simple - I have a patch against surf package (which is - wait for it! - of latest *version*). This way I only have to modify my patch with every release. This works perfectly when maintainer indeed bumps package version when user-visible feature lands in source tree. Of course, this fails miserably when maintainer doesn't grasp the concept of version. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
7heo writes: > Suckless comes from suck less. We're not here to settle down on wrong > solutions. Suckless has settled on the wrong solutions for years. Case in point: customizing software by compiling it. How often do you recompile mv, cp and rm? Even compiling your kernel is something that should be discouraged. Not because compiling is bad, but because a glut of features is bad. Customization, knobs, conditional compilation... all of these things are anti-Unix. Suckless is full of people who fetishize Unix without understanding it.
Re: [dev] surf release?
Hey Frign. > I'd be happy to see this annoying discussion resolved in the short term. > More and more Arch hipsters found their way on this ML You're doing it wrong then. It's not by calling people names that you're going to make the discussion any shorter. ;) Else, why the big fuss; because it's wrong. Please read my previous mails if you wanna know why/how. Suckless comes from suck less. We're not here to settle down on wrong solutions. Now, I said what I think, unless something meaningful comes up, count me out. On June 1, 2015 5:39:17 PM CEST, FRIGN wrote: >On Mon, 01 Jun 2015 17:34:28 +0200 >7heo <7...@mail.com> wrote: > >Hey Theo, > >> So yeah, it would solve your problem in the short term, but it would >> also encourage bad practices, which is a real problem on the long >run. > >I'd be happy to see this annoying discussion resolved in the short >term. >Regular tags on git make sense, why the big fuss? It depends on the >suckless project how much you depend on your own configuration. >For testing purposes or a quick setup, the defaults are enough. > >> Let's drop versions. Especially in the case of suckless, where >> software configuration is achieved via compilation, and thus where >> packages are counter productive. > >There's often a debate on idealism vs. realism. I wouldn't say suckless >is unpopular. More and more Arch hipsters found their way on this ML >and >fill it with useless discussions like these. >The time spent to write these silly mails and the time wasted by those >who are kind enough to read this stuff could have been used more >productively. > >The maintainer is welcome to tag a new release when he thinks the >program is stable enough for a new "resting point". >I guess it's about time for surf, even though I remember some guys >have bigger plans for this program. > >> So TL;DR: it's not hard, it's just wrong. > >That's what she said. > >Cheers > >FRIGN
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 05:34:28PM +0200, 7heo wrote: > I personally understand your problem (I shortly contributed to alpine and had > to report problems upstream, and I was more than glad when they accepted to > merge my patches upstream, so I hear you), but I still think that arbitrary > versions are the wrong approach. Arbitrary versions exist only so marketing > departments all over the world can charge customers for a "new" product. > Developers work with version-control systems, which aren't using anything > close to arbitrary, semantically. > > So yeah, it would solve your problem in the short term, but it would also > encourage bad practices, which is a real problem on the long run. > > Let's drop versions. Especially in the case of suckless, where software > configuration is achieved via compilation, and thus where packages are > counter productive. Me and others do not think that packages are counter productive. As I said in another mail, if you drop versions, package maintainer will start rolling own versions or will start using/tagging random VCS revisions. > So TL;DR: it's not hard, it's just wrong. No matter if this is wrong or not, with most distributions packages and versions are there and will not go away soon. Regards, Joerg > On June 1, 2015 5:07:15 PM CEST, Joerg Jung wrote: > >Hi, > > > >you are both wrong. > > > >On Mon, Jun 01, 2015 at 04:39:39PM +0200, 7heo wrote: > >> My point exactly. Plus, it does not even solve an actual problem. > > > >It does, it makes life for downstream package maintainers (like me) > >easier, as no cherry-picking of patches or own releases are required. > > > >> On June 1, 2015 4:33:55 PM CEST, "Martti Kühne" > >wrote: > >> >No it wouldn't help downstream package maintainers. > > > >It helps, see above. > > > >> >You're right in that package maintainers can't tell where the fixes > >> >and new features are coming in, they'll not introduce their own > >> >releases. > > > >Right, you disproved your own sentence above. > > > >> >However upstream is not everyone's taste either, > > > >The default setting match the taste of *enough* people, so that it is > >worthwhile to roll a package based on releases. This is proven by > >the available packages in the various distributions. > > > >> > in that configuration > >> > changes require recompiling of the respective binary. > > > >There are package managers which allow very easy re-compiling of > >packages with own patch-sets, especially due to projects like suckless. > >Several people, still prefer re-compiling of packages based on the > >given > >releases. Because from sysadmin point of view, packages are always > >wanted and preferred over random source builds. > > > >> >Releases hence make sense for software that fits everyone's needs > >with > >> >their configuration files, which is untrue either for most suckless > >> >projects. > > > >Releases make sense for several reasons, even for suckless projects and > >and adding a tag is not hard, right? > > > >Regards, > >Joerg > > >
Re: [dev] surf release?
On Mon, 01 Jun 2015 17:34:28 +0200 7heo <7...@mail.com> wrote: Hey Theo, > So yeah, it would solve your problem in the short term, but it would > also encourage bad practices, which is a real problem on the long run. I'd be happy to see this annoying discussion resolved in the short term. Regular tags on git make sense, why the big fuss? It depends on the suckless project how much you depend on your own configuration. For testing purposes or a quick setup, the defaults are enough. > Let's drop versions. Especially in the case of suckless, where > software configuration is achieved via compilation, and thus where > packages are counter productive. There's often a debate on idealism vs. realism. I wouldn't say suckless is unpopular. More and more Arch hipsters found their way on this ML and fill it with useless discussions like these. The time spent to write these silly mails and the time wasted by those who are kind enough to read this stuff could have been used more productively. The maintainer is welcome to tag a new release when he thinks the program is stable enough for a new "resting point". I guess it's about time for surf, even though I remember some guys have bigger plans for this program. > So TL;DR: it's not hard, it's just wrong. That's what she said. Cheers FRIGN -- FRIGN
Re: [dev] surf release?
We should seriously discuss this and settle down to a consistent guideline, agreed. On June 1, 2015 5:33:03 PM CEST, Joerg Jung wrote: >On Mon, Jun 01, 2015 at 05:14:17PM +0200, Martti Kühne wrote: >> On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote: >> >> From the average suckless user's view, knowing what source is >compiled >> and what config included is always wanted and preferred over other >> people's builds. >> > >Average suckless user... I hope this one does not exist. :) >However, you can still check the source with/of a build. > >There are people who prefer compiling from latest git source and others >prefer releases and using packages based on these releases. > >Actually, the whole discussion came up several times on this list and >in >the past, releases were provided for most of the suckless projects. > >Is this changing now? I'm fine with this, but then the workflow will >change for package maintainers and they might start rolling own >releases. > >Regards, >Joerg
Re: [dev] surf release?
I personally understand your problem (I shortly contributed to alpine and had to report problems upstream, and I was more than glad when they accepted to merge my patches upstream, so I hear you), but I still think that arbitrary versions are the wrong approach. Arbitrary versions exist only so marketing departments all over the world can charge customers for a "new" product. Developers work with version-control systems, which aren't using anything close to arbitrary, semantically. So yeah, it would solve your problem in the short term, but it would also encourage bad practices, which is a real problem on the long run. Let's drop versions. Especially in the case of suckless, where software configuration is achieved via compilation, and thus where packages are counter productive. So TL;DR: it's not hard, it's just wrong. On June 1, 2015 5:07:15 PM CEST, Joerg Jung wrote: >Hi, > >you are both wrong. > >On Mon, Jun 01, 2015 at 04:39:39PM +0200, 7heo wrote: >> My point exactly. Plus, it does not even solve an actual problem. > >It does, it makes life for downstream package maintainers (like me) >easier, as no cherry-picking of patches or own releases are required. > >> On June 1, 2015 4:33:55 PM CEST, "Martti Kühne" >wrote: >> >No it wouldn't help downstream package maintainers. > >It helps, see above. > >> >You're right in that package maintainers can't tell where the fixes >> >and new features are coming in, they'll not introduce their own >> >releases. > >Right, you disproved your own sentence above. > >> >However upstream is not everyone's taste either, > >The default setting match the taste of *enough* people, so that it is >worthwhile to roll a package based on releases. This is proven by >the available packages in the various distributions. > >> > in that configuration >> > changes require recompiling of the respective binary. > >There are package managers which allow very easy re-compiling of >packages with own patch-sets, especially due to projects like suckless. >Several people, still prefer re-compiling of packages based on the >given >releases. Because from sysadmin point of view, packages are always >wanted and preferred over random source builds. > >> >Releases hence make sense for software that fits everyone's needs >with >> >their configuration files, which is untrue either for most suckless >> >projects. > >Releases make sense for several reasons, even for suckless projects and >and adding a tag is not hard, right? > >Regards, >Joerg
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 05:14:17PM +0200, Martti Kühne wrote: > On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote: > > From the average suckless user's view, knowing what source is compiled > and what config included is always wanted and preferred over other > people's builds. > Average suckless user... I hope this one does not exist. :) However, you can still check the source with/of a build. There are people who prefer compiling from latest git source and others prefer releases and using packages based on these releases. Actually, the whole discussion came up several times on this list and in the past, releases were provided for most of the suckless projects. Is this changing now? I'm fine with this, but then the workflow will change for package maintainers and they might start rolling own releases. Regards, Joerg
Re: [dev] surf release?
> There are package managers which allow very easy re-compiling of > packages with own patch-sets, especially due to projects like suckless. > Several people, still prefer re-compiling of packages based on the given > releases. Because from sysadmin point of view, packages are always > wanted and preferred over random source builds. HAHAHAHAHA
Re: [dev] surf release?
On Mon, Jun 1, 2015 at 5:07 PM, Joerg Jung wrote: >> >You're right in that package maintainers can't tell where the fixes >> >and new features are coming in, they'll not introduce their own >> >releases. > > Right, you disproved your own sentence above. > No need to get nitpicking, I saw and still see the counterargument beneath overweighing the one in favor. >> > in that configuration >> > changes require recompiling of the respective binary. > > There are package managers which allow very easy re-compiling of > packages with own patch-sets, especially due to projects like suckless. > Several people, still prefer re-compiling of packages based on the given > releases. Because from sysadmin point of view, packages are always > wanted and preferred over random source builds. > >From the average suckless user's view, knowing what source is compiled and what config included is always wanted and preferred over other people's builds. >> >Releases hence make sense for software that fits everyone's needs with >> >their configuration files, which is untrue either for most suckless >> >projects. > > Releases make sense for several reasons, even for suckless projects and > and adding a tag is not hard, right? > I'm not going to tell other people what to do. Good luck. cheers! mar77i.
Re: [dev] surf release?
Hi, you are both wrong. On Mon, Jun 01, 2015 at 04:39:39PM +0200, 7heo wrote: > My point exactly. Plus, it does not even solve an actual problem. It does, it makes life for downstream package maintainers (like me) easier, as no cherry-picking of patches or own releases are required. > On June 1, 2015 4:33:55 PM CEST, "Martti Kühne" wrote: > >No it wouldn't help downstream package maintainers. It helps, see above. > >You're right in that package maintainers can't tell where the fixes > >and new features are coming in, they'll not introduce their own > >releases. Right, you disproved your own sentence above. > >However upstream is not everyone's taste either, The default setting match the taste of *enough* people, so that it is worthwhile to roll a package based on releases. This is proven by the available packages in the various distributions. > > in that configuration > > changes require recompiling of the respective binary. There are package managers which allow very easy re-compiling of packages with own patch-sets, especially due to projects like suckless. Several people, still prefer re-compiling of packages based on the given releases. Because from sysadmin point of view, packages are always wanted and preferred over random source builds. > >Releases hence make sense for software that fits everyone's needs with > >their configuration files, which is untrue either for most suckless > >projects. Releases make sense for several reasons, even for suckless projects and and adding a tag is not hard, right? Regards, Joerg
Re: [dev] surf release?
On 1 June 2015 at 15:33, Martti Kühne wrote: > However upstream is not everyone's taste either, in that configuration > changes require recompiling of the respective binary. I'm quite happy using the default configuration for most tools though, as are a lot of people. And since it's the default it's a perfectly reasonable candidate for packaging. The only changes I would expect in Debian would be things like using "x-terminal-emulator" in place of "st" in dwm/config.h. Ultimately the problem being solved is that the code in git can be fairly unstable, as they're being actively worked on. Releases are intended to be stable snapshots of the code. Whether or not you then proceed to package the release is neither here nor there really. Thanks, cls
Re: [dev] surf release?
My point exactly. Plus, it does not even solve an actual problem. On June 1, 2015 4:33:55 PM CEST, "Martti Kühne" wrote: >No it wouldn't help downstream package maintainers. >You're right in that package maintainers can't tell where the fixes >and new features are coming in, they'll not introduce their own >releases. >However upstream is not everyone's taste either, in that configuration >changes require recompiling of the respective binary. >Releases hence make sense for software that fits everyone's needs with >their configuration files, which is untrue either for most suckless >projects. > >cheers! >mar77i
Re: [dev] surf release?
No it wouldn't help downstream package maintainers. You're right in that package maintainers can't tell where the fixes and new features are coming in, they'll not introduce their own releases. However upstream is not everyone's taste either, in that configuration changes require recompiling of the respective binary. Releases hence make sense for software that fits everyone's needs with their configuration files, which is untrue either for most suckless projects. cheers! mar77i
Re: [dev] surf release?
> Am 01.06.2015 um 11:16 schrieb Dmitrij D. Czarkoff : > > There have been more then 2 years since 0.6 surf release (2013-02-10). > Maybe it is time for 0.7? Yes, please. Tagging a new release would help downstream package maintainers. Thanks, Regards, Joerg
Re: [dev] surf release?
7heo said: > Package management is none of suckless's concern. Not in case of package that has a metric fucktone of dependencies. -- Dmitrij D. Czarkoff
Re: [dev] surf release?
Which brings us back to the question: what problem does it solve? Package management is none of suckless's concern. I would go for removing versions rather. We don't need those capitalist lies. On June 1, 2015 2:38:27 PM CEST, "Dmitrij D. Czarkoff" wrote: >7heo said: >> I don't get how that is a problem. Versions don't have a 1:1 mapping >> to any mathematical function taking SLOCs as input, do they? > >If you are done with pretending to be clueless, can we just assume that >versions have something to do with package management?
Re: [dev] surf release?
7heo said: > I don't get how that is a problem. Versions don't have a 1:1 mapping > to any mathematical function taking SLOCs as input, do they? If you are done with pretending to be clueless, can we just assume that versions have something to do with package management? -- Dmitrij D. Czarkoff
Re: [dev] surf release?
On Mon, Jun 1, 2015 at 8:26 AM, 7heo <7...@mail.com> wrote: > I don't get how that is a problem. Versions don't have a 1:1 mapping to any > mathematical function taking SLOCs as input, do they? No, but some software has a 1:1 mapping with a date and its version. I propose a new suckless version ticket system, where every 1 year since initial commit a new version is tagged on suckless git repositories, unless there are no new changes. Then we wait for another year to pass. Got to stay relevant and appear busy somehow.
Re: [dev] surf release?
I don't get how that is a problem. Versions don't have a 1:1 mapping to any mathematical function taking SLOCs as input, do they? On June 1, 2015 1:47:19 PM CEST, Martin Kopta wrote: >On Mon, Jun 01, 2015 at 01:15:36PM +0200, 7heo wrote: >> On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff" > wrote: >> >Hi! >> > >> >There have been more then 2 years since 0.6 surf release >(2013-02-10). >> >Maybe it is time for 0.7? >> >> What problem does it solve? > ># Archlinux >$ pacman -Si surf | grep ^Version >Version: 0.6-2 > ># OpenBSD -current >$ pkg_info -Q surf | grep ^surf- >surf-0.6p1 > ># Ubuntu 15.04 >$ apt-cache show surf | grep ^Version >Version: 0.6-1 > >$ git diff 0.6..HEAD --stat >.hgtags | 10 - >FAQ.md | 10 + >README |6 +- >TODO.md |3 +- >config.def.h | 94 ++-- >config.mk|2 +- >surf-open.sh |4 +- >surf.1 | 189 -- >surf.c | 770 >+- >9 files changed, 847 insertions(+), 241 deletions(-) > > >This?
Re: [dev] surf release?
On Mon, Jun 01, 2015 at 01:15:36PM +0200, 7heo wrote: > On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff" > wrote: > >Hi! > > > >There have been more then 2 years since 0.6 surf release (2013-02-10). > >Maybe it is time for 0.7? > > What problem does it solve? # Archlinux $ pacman -Si surf | grep ^Version Version: 0.6-2 # OpenBSD -current $ pkg_info -Q surf | grep ^surf- surf-0.6p1 # Ubuntu 15.04 $ apt-cache show surf | grep ^Version Version: 0.6-1 $ git diff 0.6..HEAD --stat .hgtags | 10 - FAQ.md | 10 + README |6 +- TODO.md |3 +- config.def.h | 94 ++-- config.mk|2 +- surf-open.sh |4 +- surf.1 | 189 -- surf.c | 770 +- 9 files changed, 847 insertions(+), 241 deletions(-) This?
Re: [dev] surf release?
What problem does it solve? On June 1, 2015 11:16:52 AM CEST, "Dmitrij D. Czarkoff" wrote: >Hi! > >There have been more then 2 years since 0.6 surf release (2013-02-10). >Maybe it is time for 0.7?
