Re: [9fans] plan9port lacks exportfs server
[I believe we should go off-line if you're interested in continuing this discussion, since it has very little to do with plan9port at this point. I'll reply to the portion that has relevance on the list here, and will reply to the rest of your email privately] On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote: > Of course I'm building > binary packages, too, but they're always specialized for some > particular target system, not general purpose, not comparable > to what common binary distros do. So you DO build binary packages. And you WANT to build plan9port as a binary package? Then, you should be expected to put a reasonable effort into making that happen. Doing virtual Tom Sawyering and trying to convince developers that they should be putting that effort instead of you is fine tactic, I don't deny. Tom Sawyer got lucky doing that, you seem to be out of luck so far :-) > > The kind of value that project members are simply not interested in. > > I know, and that tends to be the point where I fork. Yep. And that's the entire point here. See, I happen to also work on a project where we can *afford* to be arrogant and self-serving. The world needs us, not the other way around. Hence we don't even do formal dotted releases anymore. We try to be diligent about tracking the progress of the external APIs by bumping a version number in a couple of macros, but otherwise -- all packagers have is our history in an SCM. It is up to them to decide that a particular point in that history has certain properties (like stability, or even fitness for a given purpose). It is up to them to fork and work on those properties. We, as developers, are not interested in making these claims. In fact, if we were making these claims without proper investment in QA and design specs we would be grossly misleading the public. We don't want to be liars. Now, most of the stuff written by the likes of Ken and Russ and the rest of the usual Plan9 suspects always works (and now, I'm not being sarcastic one bit here -- I'm actually constantly amazed at how superior these human beings are at software engineering). Thus when Russ says it is 0.4.1 it really *is* 0.4.1. So may be the QA argument doesn't apply to plan9port all that much. But the fitness for a particular purpose probably does. Only you as a packager can answer the question: who are you building your stuff for. And once you do -- you will see a much clearer picture of how it is supposed to be packaged. More to the point, that picture is very unlikely to have anything to do with source code development practices. Thanks, Roman.
Re: [9fans] plan9port lacks exportfs server
On Mon, 2008-11-03 at 01:15 +0100, Enrico Weigelt wrote: > * Roman Shaposhnik <[EMAIL PROTECTED]> wrote: > > Hi, > > > >Besides the fact that I'm not making binary packages at all, > > >splitted / small sources make packaging a lot easier. > > > > So let me get this straight: you're trying to solve a problem > > that you don't have, right? > > No, I got a problem to be solved, but it's not to produce > general-purpose binary packages. Instead the problem is to > produce buildfiles for Gentoo on the one and my own embedded > systems builder "Briegel" on the other side. Both have in > common that they always work ontop the source (hopefully the > upstream's source, but unfortunately often requiring additional > patches), while Briegel has some harder constraints, eg. always > doing crosscompiling, basing on sysroot (a kind of chroot for > from the compiler's perspective), etc. Of course I'm building > binary packages, too, but they're always specialized for some > particular target system, not general purpose, not comparable > to what common binary distros do. > > Embedded systems tend to have a lot harder constraints than > common ws's or servers - what I'm doing is applying embedded > constraints to them, too, since I have to face these constraints > anyways. It's also a matter of a strict QA, which starts at > the source. > > > IOW, don't ever assume that you can simply take a source > > code repository (however well it might be designed) and > > produce a product by simply doing ./configure ; make ; > > make install ; make pkg. > > Neither do I, instead I first fix the packages so I can do this. > Actually, my Briegel buildsystem works exactly this way: > > #1: make a fresh sysroot image (eg. install prev. built deps) > #2: fetch the source (via the CSDB - source database) > #3: uncompress and apply the normalized patch from OSS-QM rep. > #4: configure stage (eg. ./configure) > #5: build stage (eg. make) > #6: install stage (eg. make install) > #7: create the binary package (eg. tgz, rpm, whatever ...) > > Any package that doesn't run cleanly through this process is > declared broken and has to be fixed first. Briegel has no > room for workarounds, intentionally. > > > The role of a packager is to address the end-users and thus > > add value. > > The role of a packager (for a specific package) shouldn't be > necessary at all. With a properly designed source package, > that job can be completely done automatically. Leaving only > the role of the distro/system maintainer, who decides things > like which packages to get in, where to put certain types of > files, some default configs, etc. > > > The kind of value that project members are simply not interested in. > > I know, and that tends to be the point where I fork. > > > >What does prevent you from having lots of separate packages > > >in the same SCM ? > > > > Internal dependencies that are troublesome to externalize > > if you break a single source code repository into multiple ones. > > Which ones exactly (specifically on p9p) ? > > > Updates of a non-trivial software projects are transactional in nature. > > The key question for me is: why is the sw so complex at all ? > More to the point: what's so complex on p9p ? From what I see, > it's structure is quite simple (especially compared with monsters > like mozilla), since simplicity is actually one of Plan9's major > design goals. > > > Breaking these transactions apart either by non grouping them > > into a changeset, or applying them to different repositories > > leads to all sorts of complications, such as inability to use > > binary search efficiently for tracking down regressions and > > the need for use of broken dynamic linking interfaces to > > describe the connections between a single transaction > > that spans different repos. > > Wououow ... binary interfaces ... we're still at the source > level, aren't we ? > > *If* you want to nail down a fixed binary interface, you should > to this exactly at that point which defines the interface: the > package (eg. library) defining it. In other words: add appropriate > regress tests to the library package, not abusing others that just > happen to depend on it as regress test. > > Keyword: design by contract ;-P > > > cu > -- > -- > Enrico Weigelt, metux IT service -- http://www.metux.de/ > > cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 > -- > Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme > -- >
Re: [9fans] plan9port lacks exportfs server
* Roman Shaposhnik <[EMAIL PROTECTED]> wrote: Hi, > >Besides the fact that I'm not making binary packages at all, > >splitted / small sources make packaging a lot easier. > > So let me get this straight: you're trying to solve a problem > that you don't have, right? No, I got a problem to be solved, but it's not to produce general-purpose binary packages. Instead the problem is to produce buildfiles for Gentoo on the one and my own embedded systems builder "Briegel" on the other side. Both have in common that they always work ontop the source (hopefully the upstream's source, but unfortunately often requiring additional patches), while Briegel has some harder constraints, eg. always doing crosscompiling, basing on sysroot (a kind of chroot for from the compiler's perspective), etc. Of course I'm building binary packages, too, but they're always specialized for some particular target system, not general purpose, not comparable to what common binary distros do. Embedded systems tend to have a lot harder constraints than common ws's or servers - what I'm doing is applying embedded constraints to them, too, since I have to face these constraints anyways. It's also a matter of a strict QA, which starts at the source. > IOW, don't ever assume that you can simply take a source > code repository (however well it might be designed) and > produce a product by simply doing ./configure ; make ; > make install ; make pkg. Neither do I, instead I first fix the packages so I can do this. Actually, my Briegel buildsystem works exactly this way: #1: make a fresh sysroot image (eg. install prev. built deps) #2: fetch the source (via the CSDB - source database) #3: uncompress and apply the normalized patch from OSS-QM rep. #4: configure stage (eg. ./configure) #5: build stage (eg. make) #6: install stage (eg. make install) #7: create the binary package (eg. tgz, rpm, whatever ...) Any package that doesn't run cleanly through this process is declared broken and has to be fixed first. Briegel has no room for workarounds, intentionally. > The role of a packager is to address the end-users and thus > add value. The role of a packager (for a specific package) shouldn't be necessary at all. With a properly designed source package, that job can be completely done automatically. Leaving only the role of the distro/system maintainer, who decides things like which packages to get in, where to put certain types of files, some default configs, etc. > The kind of value that project members are simply not interested in. I know, and that tends to be the point where I fork. > >What does prevent you from having lots of separate packages > >in the same SCM ? > > Internal dependencies that are troublesome to externalize > if you break a single source code repository into multiple ones. Which ones exactly (specifically on p9p) ? > Updates of a non-trivial software projects are transactional in nature. The key question for me is: why is the sw so complex at all ? More to the point: what's so complex on p9p ? From what I see, it's structure is quite simple (especially compared with monsters like mozilla), since simplicity is actually one of Plan9's major design goals. > Breaking these transactions apart either by non grouping them > into a changeset, or applying them to different repositories > leads to all sorts of complications, such as inability to use > binary search efficiently for tracking down regressions and > the need for use of broken dynamic linking interfaces to > describe the connections between a single transaction > that spans different repos. Wououow ... binary interfaces ... we're still at the source level, aren't we ? *If* you want to nail down a fixed binary interface, you should to this exactly at that point which defines the interface: the package (eg. library) defining it. In other words: add appropriate regress tests to the library package, not abusing others that just happen to depend on it as regress test. Keyword: design by contract ;-P cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] plan9port lacks exportfs server
On Nov 1, 2008, at 12:05 PM, Enrico Weigelt wrote: I really fail to see what is your problem here. There's no rule that source code repository has to correspond 1-1 to the binary package. In fact, it is quite common to use a single repository for producing a number of different binary packages. Besides the fact that I'm not making binary packages at all, splitted / small sources make packaging a lot easier. So let me get this straight: you're trying to solve a problem that you don't have, right? One of the biggest mistake an open source distro maintainer could make is to assume that his role is trivial. It is not. If the source is well designed, it actually *is* trivial ;-p Of course it is not. But then again, I'd rather argue that point with a person who knows first-hand what is involved in a binary packaging exercise. Here's my personal experience working for a company that both produces open source projects and builds commercial products on a foundation of various projects: don't ever assume that projects == products. IOW, don't ever assume that you can simply take a source code repository (however well it might be designed) and produce a product by simply doing ./configure ; make ; make install ; make pkg. Most of the time projects exist for other software developers, not end users. The role of a packager is to address the end-users and thus add value. The kind of value that project members are simply not interested in. As a software developer, not a user, I do have a different set of constraints to optimize for. I would prefer a single source repository for plan9port under a reasonable DSCM so that I don't have to mix and match bits and pieces by hand. What does prevent you from having lots of separate packages in the same SCM ? Internal dependencies that are troublesome to externalize if you break a single source code repository into multiple ones. It is the same reason that makes non-changeset SCMs like CVS so dumb of choice for a source repository. Updates of a non-trivial software projects are transactional in nature. Breaking these transactions apart either by non grouping them into a changeset, or applying them to different repositories leads to all sorts of complications, such as inability to use binary search efficiently for tracking down regressions and the need for use of broken dynamic linking interfaces to describe the connections between a single transaction that spans different repos. But we've been there before with dynamic linking with you, haven't we? Thanks, Roman.
Re: [9fans] plan9port lacks exportfs server
* Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote: > On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote: > > Hi folks, > > > > > > I'd like to vote against feeding up p9p with more things, > > instead split it up into smaller pieces. Modern distros tend > > to have quite convenient package management systems ;-p > > I really fail to see what is your problem here. There's no > rule that source code repository has to correspond 1-1 > to the binary package. In fact, it is quite common > to use a single repository for producing a number of > different binary packages. Besides the fact that I'm not making binary packages at all, splitted / small sources make packaging a lot easier. > One of the biggest mistake an open source distro maintainer > could make is to assume that his role is trivial. It is not. If the source is well designed, it actually *is* trivial ;-p > As a software developer, not a user, I do have a different > set of constraints to optimize for. I would prefer a single > source repository for plan9port under a reasonable DSCM > so that I don't have to mix and match bits and pieces by > hand. What does prevent you from having lots of separate packages in the same SCM ? cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] plan9port lacks exportfs server
On Thu, 2008-10-30 at 19:07 +0100, Enrico Weigelt wrote: > Hi folks, > > > I'd like to vote against feeding up p9p with more things, > instead split it up into smaller pieces. Modern distros tend > to have quite convenient package management systems ;-p I really fail to see what is your problem here. There's no rule that source code repository has to correspond 1-1 to the binary package. In fact, it is quite common to use a single repository for producing a number of different binary packages. If you are a binary package maintainer it is your responsibility to package the software in such a way that it ends up being of the most benefit for potential users. One of the biggest mistake an open source distro maintainer could make is to assume that his role is trivial. It is not. As a software developer, not a user, I do have a different set of constraints to optimize for. I would prefer a single source repository for plan9port under a reasonable DSCM so that I don't have to mix and match bits and pieces by hand. Thanks, Roman.
Re: [9fans] plan9port lacks exportfs server
Hi folks, I'd like to vote against feeding up p9p with more things, instead split it up into smaller pieces. Modern distros tend to have quite convenient package management systems ;-p I've did a few steps in this direction (but due lack of time not finished yet :(). cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ cellphone: +49 174 7066481 email: [EMAIL PROTECTED] skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme --
Re: [9fans] plan9port lacks exportfs server
> Thus, I was thinking that perhaps if you could > lay the ground rules for how new things could > be added to your canonical plan9port tree these > little annoyances could be dealt with. The ground rules are: you make it work with as few changes as possible from the Plan 9 original, and then you send me the changes. If you are using Mercurial, it is easiest if you check it into your own tree and then send me the output of "hg export" as an attachment. Russ
Re: [9fans] plan9port lacks exportfs server
On Sat, 2008-10-18 at 10:20 -0700, Russ Cox wrote: > > Hence the question -- would you be in favor > > of continue adding things as needed. And > > if so, what kind of of groundwork would > > you expect from the contributors? > > Usually it is as simple as adding it to your own tree, > adapting the mkfile, and making it build. Absolutely! And for the internal project I'm already doing exactly that for nfsserver. My question had more to do with the usability issues, rather than engineering. It seems that useful bits that didn't get into plan9port right away tend to be scattered throughout "other trees" instead of being available at a canonical location. 9pcon comes readily to mind, but I'm sure there are others. Personally, I've only stumbled on a need to fetch 9pcon so far plus my own changes, but even that can be described as a mild inconvenience. Thus, I was thinking that perhaps if you could lay the ground rules for how new things could be added to your canonical plan9port tree these little annoyances could be dealt with. Thanks, Roman.
Re: [9fans] plan9port lacks exportfs server
> Hence the question -- would you be in favor > of continue adding things as needed. And > if so, what kind of of groundwork would > you expect from the contributors? Usually it is as simple as adding it to your own tree, adapting the mkfile, and making it build. U9fs is somewhat special since it is not a Plan 9 program. You can probably simplify things quite a bit by making it use the Plan 9 calls. Russ
Re: [9fans] plan9port lacks exportfs server
Hi Russ! First of all -- thanks a lot for answering. On Mon, 2008-10-06 at 09:24 -0700, Russ Cox wrote: > > somehow it dawned on me that plan9port lacks > > an application to serve a local filesystem > > over 9P. Is this on purpose? Am I missing > > something fundamental that would allow > > for a moral equivalent of exportfs? > > I pull things in as they are needed. > I have not needed to serve 9P. > Adding u9fs sounds reasonable, but of > course it is already in Unix-compilable > form elsewhere. Of course, although the utility of plan9port as a one stop shop for everything Plan9 on UNIX platforms is quite significant. Hence the question -- would you be in favor of continue adding things as needed. And if so, what kind of of groundwork would you expect from the contributors? Thanks, Roman. P.S. I see that sqweek has the 9pcon and (not to overcommit myself ;-)) I also might be able to contribute things like u9fs and nfsserver.
Re: [9fans] plan9port lacks exportfs server
On Tue, Oct 7, 2008 at 12:24 AM, Russ Cox <[EMAIL PROTECTED]> wrote: >Roman Shaposhnik wrote: >> somehow it dawned on me that plan9port lacks >> an application to serve a local filesystem >> over 9P. Is this on purpose? > > I pull things in as they are needed. > I have not needed to serve 9P. This reminds me, I recently compiled aux/9pcon against p9p to test some connections (which was delightfully easy, only some minor rfork changes required). The result is at http://sqweek.dnsdojo.org/plan9/p9p-9pcon.c should anyone be interested. -sqweek
Re: [9fans] plan9port lacks exportfs server
> somehow it dawned on me that plan9port lacks > an application to serve a local filesystem > over 9P. Is this on purpose? Am I missing > something fundamental that would allow > for a moral equivalent of exportfs? I pull things in as they are needed. I have not needed to serve 9P. Adding u9fs sounds reasonable, but of course it is already in Unix-compilable form elsewhere. Russ
