subject:"Re\: \[Cooker\] Creation of a community"

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 )

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 isinevitable )

On Sat, 2003-02-08 at 08:49, Buchan Milne wrote:
 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).

s/Debain/Debian/

I was just kidding, please don't attack my directly.I'm trying help here
explaining some points about the Debian Project like Goerzen is doing.

My two cents:
You can do the same thing using Debian (no, it isn't the default).It's
really easy.But can you run Mandrake on more than ten architectures?

Finally, i didn't talk anything about apt x urpmi.

bye,
-- 
Gustavo Franco [EMAIL PROTECTED]
p.s: http://people.debian.org/~blade/XFS-Install/

Re: [Cooker] Creation of a community ( was : the end isinevitable )

On Sat, 2003-02-08 at 07:47, Michael Scherer wrote:
 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.
Read the documentation, here:
http://www.openbsd.org/porting.html

 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 ?
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.

 [...]

 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 :-)
I was reading the source code.It's simple and functional in my view,
i've some suggestions.Definitely, *it works*. ;)

bye,
-- 
Gustavo Franco [EMAIL PROTECTED]

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 )


 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 isinevitable )

On Sat, 2003-02-08 at 17:39, Michael Scherer wrote:
 [...]
  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 ?

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.

2) Mandrake Community and the SPI:
First read the SPI goals at: http://www.spi-inc.org/goals.

If the new Mandrake Community will follow these terms you can contact
SPI members about your interests using spi-general[1].

[1] = http://lists.spi-inc.org/cgi-bin/listinfo/spi-general

Bye,
-- 
Gustavo Franco [EMAIL PROTECTED]

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 isinevitable )

On Sat, 2003-02-08 at 18:49, Michael Scherer wrote:
   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.
Do you known debconf? or cdebconf? It's a configuration management
system (for Debian packages) which supports many frontends including:
gnome, readline and dialog.debconf supports i18n too. 

debconf and the documentation:
http://ftp.debian.org/debian/pool/main/d/debconf/debconf_1.2.23.tar.gz

debconf reimplementation in C(the original is in Perl):
http://ftp.debian.org/debian/pool/main/c/cdebconf/cdebconf_0.30.tar.gz

It isn't a troll: Is any Mandrake piece of software doing the same
thing? Can you clarify to me?

 There is msec, deeply rooted in the security mechanism of the project.
I known msec and it's really good.

 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.
Yes, but we can share our experiences.

Bye,
-- 
Gustavo Franco [EMAIL PROTECTED]

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 )

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 isinevitable )

Michael Scherer [EMAIL PROTECTED] writes:

  The difference must be who is a mandrake developer and who is not, and
  forget who is mandrakesoft employee and who is not.

 We should stive to create a TWO tier system
 Developer
 User

 This sounds great, so , now, what is the definition of a developer ?

 I propose ( as a draft ) someone having write access to some part of the 
 distribution, this will include website developers, documentation writers, 
 and packagers.

 How do we decide who become developer, what will be their responsabilities, 
 their ressources ?

 When you say we should divide people by task, what do you mean ?

I mainly mean creating sort of groupware database where each person todo
is displayed. This will help contributors knowing that it is worthless 
flaming Chmouel not backporting 2.5 new hyperthreading optimization when
he already has 10 or 20 more important things to do.

-- 
Warly

Re: [Cooker] Creation of a community ( was : the end isinevitable )

Austin Acton [EMAIL PROTECTED] writes:

 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.

Yes, but we should also be very careful on what we accept in the distro, we
should have quite strict rules not to make the distro go into a mess.

 How can we do that?

I think that we could first try to summarize who is doing what already, 
perhaps setting up a website or using part of mandrakeone to federate all this.

-- 
Warly

Re: [Cooker] Creation of a community ( was : the end isinevitable )

Stefan van der Eijk [EMAIL PROTECTED] writes:

 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?

We should progress step by step, the first step would be to create
first basic organisation, then to construct on it.


 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?

I think Mandrake goal has always be very different from debian one.

Mandrake is a distribution focused on user, aimed to ease linux access
to everybody, and which is very reactive and on the cutting edge.

Debian is more developper oriented and with a timeframe which is not
compliant with basic users needs.

-- 
Warly

Re: [Cooker] Creation of a community

Austin Acton [EMAIL PROTECTED] writes:

 On Thu, 2003-02-06 at 16:06, Stefan van der Eijk wrote:
 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?

 Well preliminary questions are:

 1.  Is there any hope of MandrakeSoft adopting a plan like this?

I do not think this is against Mandrakesoft, mandrake community already
exists, making it more structured could only benefit the distribution
and as a consequence Mandrakesoft.

 2.  If so, will they administer it?  In other words, do THEY want to
 reorganize into a more community-based distro, or do they want US to
 form our own community and then reject it if they don't like it?

My view is to organize the current mandrake developer community, not
to change anything in mandrakesoft. Developers works on the
distribution anyway.

 Personally I look at it as a chance for Mandrake to reorganize, to see
 ways to improve the shortcomings of the distro, to attract more
 developers, to keep them longer, and to do things more efficiently.  I
 hope nobody sees it as a bunch of renegade wanna-be programmers trying
 to steal the distro.  The employees at MandrakeSoft work their asses off
 making a good distro.  We want to make their life easier, not put them
 out of work, right?

yes

-- 
Warly

Re: [Cooker] Creation of a community

Le Vendredi 7 Février 2003 01:16, Austin Acton a écrit :
 1.  Is there any hope of MandrakeSoft adopting a plan like this?

Since the beginning of the thread was Warly's post, I hope MandrakeSoft will 
adopt this plan. After all, nobody talk about this after Ben Reser's post on 
Slashdot ( http://slashdot.org/articles/03/01/18/2219215.shtml?tid=99 ), but, 
now we have the idea from a mandrake employee, we see it as possible.

  I
 hope nobody sees it as a bunch of renegade wanna-be programmers trying
 to steal the distro.

If we wanted to steal the distribution, we could simply fork, in the same way 
they did for RH
So , I hope they see we want to help them.


-- 

Mickaël Scherer

Re: [Cooker] Creation of a community ( was : the end is inevitable )

2003-02-07 Thread Han Boetes

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 endis inevitable )

2003-02-07 Thread Gustavo Franco

On Thu, 2003-02-06 at 20:28, Michael Scherer wrote:
  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.

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.

NMU = Non Maintainer Upload

Do you known about Co-Maintainers ? :)

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!

 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?

Sorry, but i've the same view!

 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.

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.


 If we clone debian, this is useless. But we can try something different.

Right!


Just for fun:
http://www.debian.org/doc/developers-reference/
http://www.debian.org/doc/maint-guide/
http://www.debian.org/doc/devel-manuals#policy
http://www.debian.org/doc/misc-manuals#history


Bye,
-- 
Gustavo Franco [EMAIL PROTECTED]

Re: [Cooker] Creation of a community ( was : the end isinevitable )

2003-02-07 Thread Gustavo Franco

On Fri, 2003-02-07 at 08:21, Warly wrote:
 Stefan van der Eijk [EMAIL PROTECTED] writes:
 [..]
 Mandrake is a distribution focused on user, aimed to ease linux access
 to everybody, and which is very reactive and on the cutting edge.
 
 Debian is more developper oriented and with a timeframe which is not
 compliant with basic users needs.

'focused on user' as in end user or system admins?

Wrong! Debian isn't developer oriented! The stability and portability
are the keywords.Is much easy(in my view) manage a ia-32 focused
distribution with newer(buggy) packages and flame about Debian project.

bye,
-- 
Gustavo Franco [EMAIL PROTECTED]

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 )

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 isinevitable )

2003-02-07 Thread Marcel Pol

On Fri, 7 Feb 2003 10:39:19 +0100
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.

Maybe it's time then that non-emplyees/contributors get write access to main.
I believe Stefan has. If apache2 gets moved to main I could imagine to see
Oden be (co-)maintainer of apache. Or Ben Reser to be maintainer of
everybuddy. Or Danny/Mark to be comaintainers of wine.
It could be set up then that you can send patches to the maintainer of a
certain package. If he thinks it's good, he can decide with Warly, or with a
team of senior people to give write access and (co-)maintainership of a
package in main.
I can imagine that Mandrakesoft doesn't want these changes to be too sudden,
so maybe the upload script could do a check with rpmmon if the uploader is
listed as (co-)maintainer, and if that's true, then upload it. That should
make it that not every developer/volunteer can change every package.
I also can imagine that employees/developers have global write access to main.
So yes, the Great Divide is still there. I would agree with that, just let
things evolve, there's no need for a revolution. (I hope)

 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 ?

You can ask contrib write access to Lenny, but this is not documented anywhere
I believe, so the word only goes mouth to mouth. This should be documented.
When you are a contributor, you have global write access to contrib. Is that
seen as a problem? With the number of people who have write access now, I
guess not. But if the number of people with write access grows, maybe the
rules should get somewhat stricter.


--
Marcel Pol

Re: [Cooker] Creation of a community ( was : the end isinevitable )

2003-02-07 Thread Gustavo Franco

On Fri, 2003-02-07 at 18:17, Michael Scherer wrote:
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.
No, bug squashing parties are like parties.Occurs periodically at the
freeze stage, any doubt you can ask at #debian-bugs (freenode).

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
From Debian Developers reference:
http://www.debian.org/doc/manuals/developers-reference/ch-pkgs.en.html#s-collaborative-maint

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.
In this case, you can try collect information about organization of the
projects cited above, and nothing only about Debian.

To give a example, OpenBSD choose to release Cd of the project each 6 months.
I'm a OpenBSD user too, OpenBSD isn't like Debian.

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?

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.
In one months or two you're doing: apt-get update; apt-get -uy
upgrade.I can see :P

bye,
--
Gustavo Franco [EMAIL PROTECTED]

Re: [Cooker] Creation of a community ( was : the end isinevitable )

On Thu, 2003-02-06 at 15:17, Michael Scherer wrote:
 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. 
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.

 How do we decide who become developer, what will be their responsabilities, 
 their ressources ?

I dunno.  How does debian do it?
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.

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.

How can we do that?
Austin

-- 
Austin Acton Hon.B.Sc.
 Synthetic Organic Chemist, Teaching Assistant
   Department of Chemistry, York University, Toronto
 MandrakeClub Volunteer (www.mandrakeclub.com)
 homepage: www.groundstate.ca

Re: [Cooker] Creation of a community ( was : the end is inevitable)

2003-02-06 Thread Stefan van der Eijk




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

Re: [Cooker] Creation of a community ( was : the end is inevitable )

2003-02-06 Thread Michael Scherer

  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 )

2003-02-06 Thread Michael Scherer


 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

On Thu, 2003-02-06 at 17:28, Michael Scherer wrote:
  Produce a document first?
 
 Right.
 First a name for the document :-)

Well:

a Code of Conduct would be required, outlining how people are to act,
how they are to make decisions, who makes what decisions, etc.

a Code of Standards also: RPM standards, documentation standards, etc.

a Mission statement: I'm sure MandrakeSoft would not accept such a
project (read: loss of control) without very clear guidelines on what
the community is going to do, and how they will interact with the
corporate backing

 If we clone debian, this is useless. But we can try something different.

Oh definitely.  If we wanted debian's OS, we'd be over there working on
it right now, wouldn't we.  The main reason I contribute to Mandrake is
because I use it, so I have a vested interest in making it better.

The point is not to become debian.  The point is to learn from their
organizational success.

Austin

-- 
Austin Acton Hon.B.Sc.
 Synthetic Organic Chemist, Teaching Assistant
   Department of Chemistry, York University, Toronto
 MandrakeClub Volunteer (www.mandrakeclub.com)
 homepage: www.groundstate.ca

Re: [Cooker] Creation of a community ( was : the end isinevitable )

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.

 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. 

I don't think there's anything wrong with having 'senior' developers. 
This isn't supposed to be communism.  But the point is that everyone
involved gets treated like a developer, not a peasant.

Austin

-- 
Austin Acton Hon.B.Sc.
 Synthetic Organic Chemist, Teaching Assistant
   Department of Chemistry, York University, Toronto
 MandrakeClub Volunteer (www.mandrakeclub.com)
 homepage: www.groundstate.ca

Re: [Cooker] Creation of a community