Re: [Cooker] Creation of a community ( was : the end is inevitable )
- Original Message -
From: "Adam Williamson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, February 10, 2003 4:34 PM
Subject: Re: [Cooker] Creation of a community ( was : the end is inevitable )
> On Mon, 2003-02-10 at 15:06, tarvid wrote:
> > On Thursday 06 February 2003 05:06 pm, Pixel wrote:
> > > Stefan van der Eijk <[EMAIL PROTECTED]> writes:
> > > > PS: Some friends have always argued that the debian way is the only
> > > > sustainable way to go. If mdk is going to do it just like debian, why not
> > > > fold and move the idea's and effort into making debian a better distro
> > > > instead of duplicating the effort?
> > >
> > > one main difference with debian, is that mandrake (tries to) takes
> > > into account the users's needs (and not only the developers's needs)
> > >
> > > another difference is the timing of stabilisation: someone told me
> > > that debian is either not uptodate (the "stable" branch), or less
> > > stable than Mandrake ("testing")
> >
> > For not entirely logical reasons, I keep one Debian "testing" box around.
> >
> > It is acceptably stable for what it does (backup) but is is not as close to
> > the edge as 9.0.
> >
> > For example:
> >
> > samnite:~# uname -a
> > Linux samnite 2.4.17-bf2.4 #1 Son Feb 24 13:00:32 CET 2002 i686 AMD Duron(tm)
> > Processor AuthenticAMD GNU/Linux
> > samnite:~# gcc -v
> > Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> > gcc version 2.95.4 20011002 (Debian prerelease)
> >
> > I ran apt-get update and upgrade this morning.
>
> Is "testing" or "unstable" more up to date?
> --
> adamw
>
>
I think unstable is the bleeding edge and testing is the cutting edge:)
--
Per Øyvind
Re: [Cooker] Creation of a community ( was : the end is inevitable )
On Mon, 2003-02-10 at 15:06, tarvid wrote:
> On Thursday 06 February 2003 05:06 pm, Pixel wrote:
> > Stefan van der Eijk <[EMAIL PROTECTED]> writes:
> > > PS: Some friends have always argued that the debian way is the only
> > > sustainable way to go. If mdk is going to do it just like debian, why not
> > > fold and move the idea's and effort into making debian a better distro
> > > instead of duplicating the effort?
> >
> > one main difference with debian, is that mandrake (tries to) takes
> > into account the users's needs (and not only the developers's needs)
> >
> > another difference is the timing of stabilisation: someone told me
> > that debian is either not uptodate (the "stable" branch), or less
> > stable than Mandrake ("testing")
>
> For not entirely logical reasons, I keep one Debian "testing" box around.
>
> It is acceptably stable for what it does (backup) but is is not as close to
> the edge as 9.0.
>
> For example:
>
> samnite:~# uname -a
> Linux samnite 2.4.17-bf2.4 #1 Son Feb 24 13:00:32 CET 2002 i686 AMD Duron(tm)
> Processor AuthenticAMD GNU/Linux
> samnite:~# gcc -v
> Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
> gcc version 2.95.4 20011002 (Debian prerelease)
>
> I ran apt-get update and upgrade this morning.
Is "testing" or "unstable" more up to date?
--
adamw
Re: [Cooker] Creation of a community ( was : the end is inevitable )
On Thursday 06 February 2003 05:06 pm, Pixel wrote:
> Stefan van der Eijk <[EMAIL PROTECTED]> writes:
> > PS: Some friends have always argued that the debian way is the only
> > sustainable way to go. If mdk is going to do it just like debian, why not
> > fold and move the idea's and effort into making debian a better distro
> > instead of duplicating the effort?
>
> one main difference with debian, is that mandrake (tries to) takes
> into account the users's needs (and not only the developers's needs)
>
> another difference is the timing of stabilisation: someone told me
> that debian is either not uptodate (the "stable" branch), or less
> stable than Mandrake ("testing")
For not entirely logical reasons, I keep one Debian "testing" box around.
It is acceptably stable for what it does (backup) but is is not as close to
the edge as 9.0.
For example:
samnite:~# uname -a
Linux samnite 2.4.17-bf2.4 #1 Son Feb 24 13:00:32 CET 2002 i686 AMD Duron(tm)
Processor AuthenticAMD GNU/Linux
samnite:~# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
I ran apt-get update and upgrade this morning.
Jim Tarvid
Re: [Cooker] Creation of a community ( was : the end is inevitable )
On Thu, 2003-02-06 at 22:06, Pixel wrote:
> Stefan van der Eijk <[EMAIL PROTECTED]> writes:
>
> > PS: Some friends have always argued that the debian way is the only
> > sustainable way to go. If mdk is going to do it just like debian, why not fold
> > and move the idea's and effort into making debian a better distro instead of
> > duplicating the effort?
>
> one main difference with debian, is that mandrake (tries to) takes
> into account the users's needs (and not only the developers's needs)
>
> another difference is the timing of stabilisation: someone told me
> that debian is either not uptodate (the "stable" branch), or less
> stable than Mandrake ("testing")
Pixel, if you're going to start distro wars, it's probably at least a
good idea to USE the other distro first. "someone told me" isn't really
good enough...
--
adamw
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Stefan van der Eijk <[EMAIL PROTECTED]> writes:
> PS: Some friends have always argued that the debian way is the only
> sustainable way to go. If mdk is going to do it just like debian, why not fold
> and move the idea's and effort into making debian a better distro instead of
> duplicating the effort?
one main difference with debian, is that mandrake (tries to) takes
into account the users's needs (and not only the developers's needs)
another difference is the timing of stabilisation: someone told me
that debian is either not uptodate (the "stable" branch), or less
stable than Mandrake ("testing")
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> > So , merging the differences would not be interesting, for all the works > > it represent. > > Yes, but we can share our experiences. Well, of course, I agree at 100 % . But I really hope that nobody has waited this discussion to do so. -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> > If it was accepted, can you explain what we would do ? > > We've two scenarios here: > > 1) Mandrake as a new subproject: > If accepted, you can contact Debian developers through two MLs: > debian-project and debian-devel.To discuss about a internal merge > with Desktop subproject or not and others aspects, obviously. > The new subproject automatically will be under Debian Free Software > Guidelines, Constitution and in my view some(or many) adaptions to > Debian Policy will be necessary to cover it. Well, obviously, this is not possible. Maybe Mandrake seems to be only a nice installer with some software, but, this is more than that. There is the numerous wizard, working closely with the distribution. There is msec, deeply rooted in the security mechanism of the project. There is a lot of customized software, such as KDE, the kernel, or xmms ( http://people.mandrakesoft.com/~gc/ ) And there is more, but, this should be enough. So , merging the differences would not be interesting, for all the works it represent. -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> Read the documentation, here: > http://www.openbsd.org/porting.html Well, I just missed this one. That is the problem to work when there is too much people in a small room. > Mandrake as a new project inside Debian.But it was refused here, many feels > involved.But if you change the original idea, try debian-project ML.The > Debian-Mandrake can receive financial support of SPI as described by > Goerzen, more and more developers, because Debian Developers > automatically can help this new project...But it's only a > proposition.Already refused, i known. Well, I can't see how it could be accepted. I have understand all words, but it still don't understand. If it was accepted, can you explain what we would do ? -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> But can you run Mandrake on more than ten architectures? Well, if it was the main reason to use a Debian instead of another distro, we should all be using NetBSD... -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Le Samedi 8 Février 2003 10:47, Michael Scherer a écrit : > OpenBSD team release CDs each 6 month, as said before. They maintain the > four last release. Well, a small mistake, they maintain two previous release. ie, actually, 3.1 and 3.2. -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Le Samedi 8 Février 2003 01:13, Gustavo Franco a écrit : > > But, I don't think we need to be a carbon copie of Debian. > > Debian is not the only volunteers OS project, everybody seems to forget > > FreeBSD, and other, or even some smalls os, such as AtheOs, OpenBeOS, and > > others, who don't work in the same way as Debian. > > In this case, you can try collect information about organization of the > projects cited above, and nothing only about Debian. Well, I did, but they are far from being well documented. All BSD have a core team, who make technical decision. This provides conservatism, and they are sure that the goals of the projects are respected. ( this and some dinosaurs that should have disappeared, such as csh :-) ) I don't know exactly how you can become one of the "technical chief", probably based on merit. OpenBSD team release CDs each 6 month, as said before. They maintain the four last release. I have seen a card with the location of the developpers, but, they are less than 20 ! They don't talk on how they add software to the ports ( contributed software, such as KDE ), or who maintain it. NetBSD release frequently, something as each 6 months, more or less, and the work is divided in 2 or more branchs ( 1.6,1.5,Current ), I think. FreeBSD works as NetBSD, but, they release less, and they maintain 2 or 3 branche ( 3.X,4.X,5.X ), + the cvs one, called current. I don't remember all details, so they may be wrong. You can check their website. As far as i know, OpenBEos is still in pre-alpha stage. And, Atheos was based on the work of only one person, who stopped it, and so, some project begin to fork and then to work together. I don't have take a look to this since 6 months, so this may be greatly inaccurate. And, to finish, did you know that Gentoo has adopted the Debian Social Contract ? > > Some parts of Debian are great, some parts can be changed, and some parts > > don't really correspond to the Mandrake's touch. Just my view on this. > > Many parts can be changed and we're working on it.Why can't Mandrake > approach change with us too? Well, of course, why not. What are your proposition ? > > But what I want is to help Mandrake. Because, if I wanted to use Debian > > and to help Debian, I should have done it earlier. > > In one months or two you're doing: "apt-get update; apt-get -uy > upgrade".I can see :P Well, I can already, thanks to Connectiva who ported apt-get for rpm. Except i do not have enough bandwidth... And, if it didn't exist, we still have the wonderful urpmi. I think this is the place to greatly thank François Pons for this wonderful piece of software :-) -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable)
On 7 Feb 2003, Gustavo Franco wrote: > In one months or two you're doing: "apt-get update; apt-get -uy > upgrade".I can see :P > We have 'urpmi.update -a; urpmi --auto-select --auto' (I have this in cron), and it gives me more than Debain does, unless Debian has XFS+ACL support in the default kernel and samba packages supporting ACLs out the box (just to mention one reason why no other free distro is useful to me at present). Buchan -- |Registered Linux User #182071-| Buchan MilneMechanical Engineer, Network Manager Cellphone * Work+27 82 472 2231 * +27 21 8828820x121 Stellenbosch Automotive Engineering http://www.cae.co.za GPG Key http://ranger.dnsalias.com/bgmilne.asc 1024D/60D204A7 2919 E232 5610 A038 87B1 72D6 AC92 BA50 60D2 04A7
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Le Vendredi 7 Février 2003 18:04, Gustavo Franco a écrit : > On Thu, 2003-02-06 at 20:28, Michael Scherer wrote: > > Well, we could try something like morethan one developper per package. > > Actually, in Debian, only the packager can change something. > > If you take a look to the changelog of any of our package, this is not > > the way it works. This works for debian since they have a lot of > > developpers. I think we should try something different for here, > > something more flexible. > > It's wrong! If the package has a security flaw, the Debian Security Team > can do a NMU.In "bug squashing parties" maintainers usually do NMUs. Well, I know, but, it is only for security flaw, and since not everybody can correct a security flaw, it is better to have a security team to do it. I don't think I'm wrong when I say that is the way it work with all serious vendors. And a bug squashing party only occurs when the number of bugs is high. What I had in mind is something a litle bit less strict. Something more than the way that KDE works, with write access to a pool of file, for each developper. The association "1 file = 1 developper " is not true for this case, maybe something like this should be tried. Something like ( this is a draft ) : "everybody can change a package, with CVS,and the maintener choose if the change is taken in account, or not". In fact, just consider that the spec files of the distribs in the same way we consider source code for free software project. This not explained very well, I agree. > Do you known about Co-Maintainers ? :) No, I didn't know. I don't know all Debian subtilities, only those some people have been talking about with me. But well, you can explain us :-). Or any debian developper reading this mail > See, i'm an apllicant, i've some packages sponsored by a > maintainer(developer).I'm not officially a developer, only a applicant > waiting the DAM approval in the nm queue.But i've packages in the > distribution! I would say this work the same for Mandrake, but, in fact, I don't know how to become a contrib mainteners. But, on the other hand, i didn't ask on this list, or on irc. I agree with you to say this is a good way to do it. And this is exactly what should be done for Mandrake. > > > PS: Some friends have always argued that the debian way is the only > > > sustainable way to go. If mdk is going to do it just like debian, why > > > not fold and move the idea's and effort into making debian a better > > > distro instead of duplicating the effort? > > Sorry, but i've the same view! Don't be sorry. I don't agree, but, I may be wrong. This is duplication, but, Gnome and KDE too, and , this is good to have choice, don't you think ? But, I don't think we need to be a carbon copie of Debian. Debian is not the only volunteers OS project, everybody seems to forget FreeBSD, and other, or even some smalls os, such as AtheOs, OpenBeOS, and others, who don't work in the same way as Debian. To give a example, OpenBSD choose to release Cd of the project each 6 months. Some parts of Debian are great, some parts can be changed, and some parts don't really correspond to the Mandrake's touch. Just my view on this. > Do you known anything about Debian subprojects like: Debian Edu or > Debian Desktop? You can help with the new installer, called: d-i based > on cdebconf and start a new subproject or enhance a existing one. Yes, I have talked of this almost one day each week with my teammate for 3 months during last fall. I don't think this is the place to talk about the Debian Desktop project and, I know that if I want to help Debian, I will be welcome. But what I want is to help Mandrake. Because, if I wanted to use Debian and to help Debian, I should have done it earlier. -- Mickaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Le Vendredi 7 Février 2003 12:35, Han Boetes a écrit : > Michael Scherer <[EMAIL PROTECTED]> wrote: > > Just take a look at the discussion for Maildir in /etc/skel, which > > involves changes in main. If there is a distinction between developers, > > because some of them have control on main, and the others not, this is no > > good. > > On the contrairy. If I _think_ I have a good idea it doesn't mean it is a > good idea. So I make a suggestion. If it convinces the mdk people they will > implement it and if they don't that's too bad. > > Often it happens that what is good for me isn't good for a distro. Should > it be added? Nope. But I will certainly add to my own install. This is not the pb of a good idea or not, it is the 'only main is supported' and 'only mdk people have control over main'. This was a example, a bad one, I agree. If you look to previous post, you see that I'm not against the idea of a technical comitee. This is mandatory for quality, so, obviously, we can't accept any change, of course. But, the point of the thread was to remove distinction between mdk employees and other people. And, well, this is a huge difference between the two. This is not the most annoying thing. The lack of guidelines, and of good policy is annoying. I'm pretty sure that a lot of people would contribute if we give them the occasion. Of course, this need precise and strict rules, but, I don't see anything on mandrake website. Nothing more than 'use rpmlint'... > > IMHO, the problem of contrib support is the lack of people. > > But, if the support team grow bigger, by including volunteers > > developpers, if the bug are handled by the mainteners, and if each people > > have fewer packages, this is solved, no ? > > > > I think that everything should be equally supported by the community, > > and, if someone want to pay for having Mandrake supporting a program for > > them, they can. > > > > We can provide normal support, Mandrake can and should provides > > commercial support. Then, they can pay developpers, they can provides > > bandwidth and CPU, and so on. > > Hmmm hard to descibe all possible situations isn't it? This may not be a good example, but, a french consulting firm named Alcove was sponsoring Debian developpers, only to works as consultant for them, or to maintain packages. This is not a good example, since they ran ou of business, but, this seems a good business model. Of course, this is not a miracle solution. But, it has to be discussed. -- Mickaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Michael Scherer <[EMAIL PROTECTED]> wrote: > > The problem is that if some people, ie Mandrake employees, have full control > of main, this would means that we are not fully equal. That's not a problem, thats a fact of life ;) Ever heard of Damocles sword? :) > Just take a look at the discussion for Maildir in /etc/skel, which involves > changes in main. If there is a distinction between developers, because some > of them have control on main, and the others not, this is no good. On the contrairy. If I _think_ I have a good idea it doesn't mean it is a good idea. So I make a suggestion. If it convinces the mdk people they will implement it and if they don't that's too bad. Often it happens that what is good for me isn't good for a distro. Should it be added? Nope. But I will certainly add to my own install. > IMHO, the problem of contrib support is the lack of people. > But, if the support team grow bigger, by including volunteers developpers, if > the bug are handled by the mainteners, and if each people have fewer > packages, this is solved, no ? > > I think that everything should be equally supported by the community, and, if > someone want to pay for having Mandrake supporting a program for them, they > can. > > We can provide normal support, Mandrake can and should provides commercial > support. Then, they can pay developpers, they can provides bandwidth and CPU, > and so on. Hmmm hard to descibe all possible situations isn't it? # Han -- http://www.xs4all.nl/~hanb/software
Re: [Cooker] Creation of a community ( was : the end is inevitable )
Le Vendredi 7 Février 2003 00:50, Austin Acton a écrit : > On Thu, 2003-02-06 at 17:38, Michael Scherer wrote: > > We also need to support equaly contribs and main, don't you think ? > > Well, the problem is Mandrake says publicly "we fully support the > packages in main, but not in contribs" so they do need to have tight > control over main. > > Maybe a fair solution would be > -make main much smaller, just core apps: kernel, daemons, drivers, main > GUI > -Mandrake keeps full control of that > -make contribs much larger: include office apps, the smaller desktop > environments > -give developers much more control of contribs > > Then of course they would have to decide whether to ship a one CD distro > and tell users to get all contribs online, OR ship some contribs stuff > and say: CD 2+3 are unsupported. > > Tough call. The problem is that if some people, ie Mandrake employees, have full control of main, this would means that we are not fully equal. Just take a look at the discussion for Maildir in /etc/skel, which involves changes in main. If there is a distinction between developers, because some of them have control on main, and the others not, this is no good. IMHO, the problem of contrib support is the lack of people. But, if the support team grow bigger, by including volunteers developpers, if the bug are handled by the mainteners, and if each people have fewer packages, this is solved, no ? I think that everything should be equally supported by the community, and, if someone want to pay for having Mandrake supporting a program for them, they can. We can provide normal support, Mandrake can and should provides commercial support. Then, they can pay developpers, they can provides bandwidth and CPU, and so on. -- Mickaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> But demand high quality for what they deliver. Otherwise, send it back. Well, of course. Peer reviews, but this would say tht some developpers hav more power than others. All developers should be treated as equals, but, some of them should be "team chief" , or something like that... > >>How do we decide who become developer, what will be their > >> responsabilities, their ressources ? > > > >I dunno. How does debian do it? > > I beleive a maintainer per package. See: Well, we could try something like morethan one developper per package. Actually, in Debian, only the packager can change something. If you take a look to the changelog of any of our package, this is not the way it works. This works for debian since they have a lot of developpers. I think we should try something different for here, something more flexible. Maybe, a team of developpers for some category of package ? > I also like their "package adoption" system: > http://www.debian.org/devel/wnpp/ Package adoption is great, but, to orphan a package is not really seen as a good thing by others developpers. > >Maybe some sort of wiki system. That could organize people and tasks, > >and let new people sign up, and see what needs to be done. > > Just like the debian system. I wrote to the cooker list last week > describing a web based package submission system, see: > http://archives.mandrakelinux.com/cooker/2003-01/msg02998.php Well, a wiki may not be the right thing. A lot of people tends to think that a wiki is good, but, few have tried. Of course I have never tried :-) , but I don't think this could be better than a real groupware system. > >How can we do that? > > Q: when can we do that? And who will make it happen... There are a lot > of bright people on the list that can help to make it happen. How do we > first define an architecture for this. > Produce a document first? Right. First a name for the document :-) > PS: Some friends have always argued that the debian way is the only > sustainable way to go. If mdk is going to do it just like debian, why > not fold and move the idea's and effort into making debian a better > distro instead of duplicating the effort? What about doing it the same way than Netbsd and FreeBSD. Debian is ported on a lot of processor, we can focus on a smaller subset. They have goals for each release in term of version of software, we can have more frequent releases, based on time. This is possible, just take a look at the openbsd life cycle, one release each 6 months. If we clone debian, this is useless. But we can try something different. -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable )
> > This sounds great, so , now, what is the definition of a developer ? > > One who contributes tangible material to the distro. Software, > documentation, detailed bug-reports, graphics. > > > I propose ( as a draft ) "someone having write access to some part of the > > distribution", this will include website developers, documentation > > writers, and packagers. > > I don't agree, necessarily. A leading distro has to have tight > standards. > It's hard to get people to closely follow these standards. So, we need to have a "review standard" team. We need to have written standards. And the review team will check if everything is in order before realeasing a new version, during the features frezzes. We also need to support equaly contribs and main, don't you think ? What about plf ? > That said, there > must be a quick and easy way for new developers to have their work > appraised, committed, and acknowledged. You are right, so, changes should be check by others, by a senior developper. So, we need to have a team for this, so, secund team is "senior developper charged of the initiation of young jedi". -- Michaël Scherer
Re: [Cooker] Creation of a community ( was : the end is inevitable)
I propose ( as a draft ) "someone having write access to some part of the distribution", this will include website developers, documentation writers, and packagers. I don't agree, necessarily. A leading distro has to have tight standards. It's hard to get people to closely follow these standards. I know this from working with volunteers on the club. So write access must be given out gingerly. That's not to say there should be a limited number of people with access, but limited quality. That said, there must be a quick and easy way for new developers to have their work appraised, committed, and acknowledged. But demand high quality for what they deliver. Otherwise, send it back. Just giving someone write access isn't going to work, it's how you check the delievrables (in a smart & automated way) that's going to keep quality up to par. How do we decide who become developer, what will be their responsabilities, their ressources ? I dunno. How does debian do it? I beleive a maintainer per package. See: http://www.debian.org/devel/join/ http://www.debian.org/devel/join/newmaint I also like their "package adoption" system: http://www.debian.org/devel/wnpp/ Maybe some sort of wiki system. That could organize people and tasks, and let new people sign up, and see what needs to be done. Just like the debian system. I wrote to the cooker list last week describing a web based package submission system, see: http://archives.mandrakelinux.com/cooker/2003-01/msg02998.php When you say we should divide people by task, what do you mean ? I mean now, people are divided into categories like: contribs, club, installation, documentation, printing, Mandrake employee, paying club member, club VIP memeber, etc. etc. That bugs me. Somehow everyone who's contributing tangible work to the distro should feel like part of the same team. It should be easy to join the team, to find out what needs to be done, to tell others that you are working on that specific task, and to have your work added to the distro as soon as it's done. With the proper QA in place. How can we do that? Q: when can we do that? And who will make it happen... There are a lot of bright people on the list that can help to make it happen. How do we first define an architecture for this. Produce a document first? Stefan PS: Some friends have always argued that the debian way is the only sustainable way to go. If mdk is going to do it just like debian, why not fold and move the idea's and effort into making debian a better distro instead of duplicating the effort? smime.p7s Description: S/MIME Cryptographic Signature
