[gentoo-dev] Sunrise contemplations

[gentoo-dev] Sunrise contemplations

[foser]

Hello,

since I've not really been involved in the whole Sunrise discussion I'd
like to give my view in a condensed form, instead of spreading it out
over 20 replies in the ongoing discussion. Also I hope to summarize the
main points a bit, but I know this mail is far from objective and as
such not much of good summary.

There are really 2 big discussion points in the whole Sunrise discussion
as far as I can see. First there is the purpose of Sunrise and how that
ties into Gentoo and secondly there's how it came into being. I would
also like to discuss how I think Sunrise will influence the work of
developers. Let's tackle them one by one.

* The purpose of Sunrise

The purpose of Sunrise as far as I can distill them from their goals :

1. Make stale ebuilds in bugzilla accessible
2. Provide some level of QA for user contributed ebuilds in bugzilla
3. Lower the step to becoming a developer

Let's handle them.

1. Stale ebuilds are often stale for a reason, there is obviously not
enough interest to add and maintain them. Not just on the developer
side, but also on the user side. If someone really cared enough he/she would
go trough the process of becoming a dev. As far as I know most
maintainer-wanted stuff just belongs in the category WONTFIX, but the
real problem is telling that to the user who sweated on it. I think most
of the devs have gone trough a close-reopen cycle on some ebuilds that
really added nothing useful to the tree and know how uncomfortable this
can make you feel.
Then what is a solution to these ebuilds ? I for one would like to see
them go upstream, like rpm's and deb's . That would make it clear that
these ebuilds are not Gentoo approved, but would provide a starting
point for the user who would want to use such a package. I think that
was always the main idea when overlays got introduced to portage.
Sunrise just lowers the step to get these often mediocre ebuilds, people
can get them right now, just not as easy.

2. QA for ebuilds is not just a question of making a package build, but
also knowing what it does and how it would tie into Gentoo. The fact
that some ebuild is semantically correct doesn't mean it is doing the
right thing. Very few of the newly proposed ebuilds I handled and eventually committed was actually without major
flaws. This was because the submitters lacked specific knowledge of either the eclasses to use and
the environment it belonged in. In my case : any gnome ebuild fits in a
larger set of applications/libraries that got more complex as time went
by, it is not trivial to understand all the interactions that take
place. Even Gentoo developers not in the gnome team make serious
mistakes in this sense in my experience. Therefore I do not believe that
QA for a tree that is as extensive as Sunrise done by a few 'official'
developers amounts to much real world quality.

3. Although I agree Sunrise may lower the step to becoming a dev, I doubt it will have a serious positive impact on our
developer base and as such there is no reason to support Sunrise officially.
I think the people attracted to Sunrise development are the ones that
fall in the category 'want to be there, but don't really have the
time/skills'. Those people will not evolve to real developers; they
either will stick it out in Sunrise for a short while or keep to a very
small subset of it.
My prediction is that Sunrise will see a high turnover of 'developers',
either because they are there for one specific package (probably fresh
and included in the main tree when mature) or find out they lack the
time to really invest in learning the full extent of ebuilding. Also
'junior' devs on Sunrise might not take that extra step towards devhood
because they got the influence they want, as such we might lose out on
devs that never develop beyond Sunrise contributors.
As a developer I would not really think of Sunrise developers
any different than someone coming 'fresh' to Gentoo developing. I
would still require them to work on real bugs for a good while to see
their intentions/devotion over time before I would even consider
submitting them for real developership. In that sense Sunrise would only lengthen the time a wannabe dev has to spend in the no-mans land between active user and official developer.

In conclusion these 3 points come together here : being a dev is not
about adding new ebuilds to the tree, it is about maintaining what is
already there. Dealing with bugs and users. That aspect of Sunrise is not at all tackled in its goals. What are the longterm
prospects of ebuilds in the Sunrise tree ? That is what QA is about,
providing a stable base to work on.
I do not think that devs who mainly add ebuilds and new packages
to the tree are good devs, the real job is maintenance and bughandling.
In that sense Sunrise might be giving the wrong impression to wannabe
devs.

* The rise of project Sunrise

Now for the second big point concerning Sunrise : how it came into
being.

I checked back on the initial announcement, where it Sunrise was made
public as an official Gentoo project without any prior discussion. The
announcement actually stated 'This is an announcement - No flamewars
allowed'. I guess the creators were already aware of the feelings of
some other developers on this issue and decided to just go ahead instead
of going through the proper channels (GLEP?) and do things as they
wished. As we all know this can be very effective, but this particular
time one of the largest and longest ongoing 'discussions' in Gentoo's
history ensued.
If you know it's flamewar material, why do you go ahead
so bluntly with your project ? Why not go trough the proper channels and
discuss it beforehand in a public place ?

Anyway, the project after the initial announcement got a 'temporarily removed' status
from gentoo.org . The problem here in my opinion is not so much that the
people who support the project needed to defend it, but that people who
are more conscious about the project need to prove it is wrong. This had
to happen in a mere 2 months where the project has had hardly any impact.
If you want to properly evaluate such an extensive project it needs to be given
much more time. The project should prove itself before it should be
allowed to 'join' Gentoo, not the other way around. I have seen no
tangible benefits from Sunrise so far, aside from the fact that
developers have left over it and the developer community is seriously
divided these days. As such Sunrise has been one big mistake, the
possible benefits at this point in time do not outweigh the havoc it has
caused.

* The implications of sunrise

What will Sunrise mean to the general developer ?
 
Again here I can share my experiences with a similar project, the
infamous BMG was created with similar goals and turned out to be a
serious nightmare for the gnome team. At a certain point in time every
bug we got had to be double checked for possible overlay problems. I
cannot count the times I had to spend hours on an unexplainable problem
to find out in the end that it was caused by BMG ebuilds. This is
incredibly destructive for my mood, not to mention the time wasted which
could've been spent on real problems. The other side of the medal is
that there are false-positives where you think it's BMG, but it really
isn't and I can tell you that is not a nice experience for the user and
dev alike. BMG was mainly gnome oriented, so a lot of devs may never
have noticed such problems, but they surely existed for the gnome team.
Another exponent of the BMG tree were the infamous love-sources which
also caused inexplicable problems left and right, which may ring a bell
with much more devs.

In short, from my experience Sunrise will only result in more work for
the general developer with little benefits. This may not happen often,
but every single time is one time too much. This is can be really
demotivating, which is probably the worst thing about it.

regards,
Marinus

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Tobias Klausmann]

Hi! 

I'm not a dev (just someone donating 10GB of traffic per day from
his private server to Gentoo), but that's exactly why I think I
need to chime in.

On Mon, 31 Jul 2006, foser wrote:
> 1. Stale ebuilds are often stale for a reason, there is
> obviously not enough interest to add and maintain them. Not
> just on the developer side, but also on the user side. If
> someone really cared enough he/she would go trough the process
> of becoming a dev. 

You're kidding, right? I for one simply can't spare the time to
become involved as a dev. Now before you're starting to say that
I'm a freeloader and I should just deal with what's there, a few
remarks:

- I *do* contribute. My private rsync-server has served over a terabyte
  of data since I've been running it for Gentoo (somewehre in
  2002? Years ago, in any case)
- I do contribute to other F/OSS projects. Do I have to
  contribute to any project where I'd like to see a change? Isn't
  a enhancement reuqest a kind of contribution (as long as it's
  beyond "this sucks, change it!")

> Then what is a solution to these ebuilds ? I for one would like
> to see them go upstream, like rpm's and deb's . That would make
> it clear that these ebuilds are not Gentoo approved, but would
> provide a starting point for the user who would want to use
> such a package. I think that was always the main idea when
> overlays got introduced to portage.  Sunrise just lowers the
> step to get these often mediocre ebuilds, people can get them
> right now, just not as easy.

It's about user experience. I'm not saying any and all M-W
ebuilds should get into the tree, but I have a strong feeling
that *more* should go in - in unison with stale stuff being
removed. But the latter is another project: treecleaners (at
least from what I've read).

I think Gentoo has a sort-of Debianesque problem: the tree is
ever growing which results in growing pains (Debian has other
pains but the problem is growth, still). I don't know any other
remedy than to keep the tree lean - but not only by being wary of
too many new ebuilds. Old ones have to go, too.

As a result, a question: how many Gentoo users need to voice
interest in an ebuild/package to make it "wortwhile"?

I initially provided an ebuild for a package I maintain. I also
provide a new ebuild for every new version. For this, proxy
maintainership is the thing to do, IMO. 

> 3. Although I agree Sunrise may lower the step to becoming a
> dev, I doubt it will have a serious positive impact on our
> developer base and as such there is no reason to support
> Sunrise officially.  I think the people attracted to Sunrise
> development are the ones that fall in the category 'want to be
> there, but don't really have the time/skills'. Those people
> will not evolve to real developers; they either will stick it
> out in Sunrise for a short while or keep to a very small subset
> of it.

What about those that are able to put together a dead simple
ebuild and just want it submitted and *not* rot in Bugzilla? 

I can understand that some people go for sunrise because some of
their ebuild submissions just went stale and then started to rot
in bgo. 

As for official vs. non-official: I don't care either which way.
I think it's mostly about truth in advertising: If it's treated
by the majority as being official, it's official. As for URLs:
how do you think phishing works? People (mostly) don't look too
closely at URLs. The layout/logos etc of a page are an entirely
different matter. Just my EUR0.02

> My prediction is that Sunrise will see a high turnover of
> 'developers', either because they are there for one specific
> package (probably fresh and included in the main tree when
> mature) or find out they lack the time to really invest in
> learning the full extent of ebuilding. Also 'junior' devs on
> Sunrise might not take that extra step towards devhood because
> they got the influence they want, as such we might lose out on
> devs that never develop beyond Sunrise contributors.

Well, I think having more candidates will not only result in more
"rejects" but also in more acceptable devs. As for the entry
step: maybe it's too high now and with Sunrise one could find out
where the sweet spot for it lies?

Also: do you really want to have junior devs that are only in it
for the influence? 

> As a developer I would not really think of Sunrise developers
> any different than someone coming 'fresh' to Gentoo developing.
> I would still require them to work on real bugs for a good
> while to see their intentions/devotion over time before I would
> even consider submitting them for real developership. In that
> sense Sunrise would only lengthen the time a wannabe dev has to
> spend in the no-mans land between active user and official
> developer.

So? Then Sunrise is a training ground. I don't see harm in that.

> In conclusion these 3 points come together here : being a dev
> is not about adding new ebuilds to the tree, it is about
> maintaining what is already there. Dealing with bugs and users.
> That aspect of Sunrise is not at all tackled in its goals. What
> are the longterm prospects of ebuilds in the Sunrise tree ?
> That is what QA is about, providing a stable base to work on.
> I do not think that devs who mainly add ebuilds and new
> packages to the tree are good devs, the real job is maintenance
> and bughandling.  In that sense Sunrise might be giving the
> wrong impression to wannabe devs.

Being a dev is three things I'd say: create, maintain, remove.
Some may lean more to any of the three (we're humans, after all).
The major part of the "workforce" should do maintenance, though.
This is independent of portage, btw, most other projects would
fall into the three-fold as well.

As for the ebuilds in Sunrise: Think of it as an ebuild checker
which is at least theoretically more capable than any automated
system: There are humans involved that are willing to check it.

People who use Sunrise as an overlay and then come whining to bgo
about their failed ebuild can be told. 

Idea: should it be more obvious in emerge --info and ebuild
failure that an overlay is involved? If it's obvious enough, I
don't see a problem. Also, a command that lists all installed
packages that come from an overlay might be useful (maybe even a
sa part of --info).

> * The rise of project Sunrise
> 
> Now for the second big point concerning Sunrise : how it came into
> being.

On this, I can hardly comment because I know very little of the
lifecycle of Gentoo projects. Also: if an idea is good, it may be
stained a bit if it's put through with the wrong measures. That
doesn't make it a *bad* idea out of the blue, though.

> * The implications of sunrise
> 
> What will Sunrise mean to the general developer ?
>  
> Again here I can share my experiences with a similar project, the
> infamous BMG was created with similar goals and turned out to be a
> serious nightmare for the gnome team. At a certain point in time every
> bug we got had to be double checked for possible overlay problems. 

This might be alleviated with the more prominent warning display
in --info as I noted above.

> I cannot count the times I had to spend hours on an
> unexplainable problem to find out in the end that it was caused
> by BMG ebuilds. This is incredibly destructive for my mood, not
> to mention the time wasted which could've been spent on real
> problems. 

I do understand this. There's little more frustrating than
trying to fix one's own stuff and after hours of running into
walls finding out that the problem was caused in some completely
different part of the world.

> The other side of the medal is that there are false-positives
> where you think it's BMG, but it really isn't and I can tell
> you that is not a nice experience for the user and dev alike.
> BMG was mainly gnome oriented, so a lot of devs may never have
> noticed such problems, but they surely existed for the gnome
> team.  Another exponent of the BMG tree were the infamous
> love-sources which also caused inexplicable problems left and
> right, which may ring a bell with much more devs.

Again: if you can be sure of the overlay-status of packages, this
might be less of a nightmare. 

> This is can be really demotivating, which is probably the worst
> thing about it.

That I agree on: if it's a motivation killer, it should be bound
to a rock and dumped in a lake. I just think that it can be
improved enough to not be such a dev nightmare. 

But then, I'm just a user and a server admin.

Regards,
Tobias
-- 
You don't need eyes to see, you need vision.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Jeroen Roovers]

On Tue, 1 Aug 2006 10:21:53 +0200
Tobias Klausmann <klausman@schwarzvogel.de> wrote:

> Idea: should it be more obvious in emerge --info and ebuild
> failure that an overlay is involved? If it's obvious enough, I
> don't see a problem. Also, a command that lists all installed
> packages that come from an overlay might be useful (maybe even a
> sa part of --info).

emerge --info can easily be forged. I've seen people asking for help on
#gentoo do it a few too many times (some even refuse to provide it),
and have wasted precious minutes not just wondering what the error
messages meant, but also whether I could trust the user.

Having to do the latter of these could hardly be called "supportive" of
Gentoo's user base, yet every so often you have to investigate whether
a user has been absolutely truthful about his or her problem. Sometimes
users have built their entire system using -fomg-fastwoah only to see
the system collapse at the NNth package, sometimes they've copied some
ebuilds/eclasses from an overlay. Sometimes they don't even use Gentoo
but go for the massive numbers of users and guess that someone in
#gentoo ought to be able to help them with their home-built packages.

The only way to have people submit emerge --info properly and reliably
would be to set up an online ticketing system - something like this:


# emerge --submit-info

* sys-apps/portage generates emerge --info output and uploads it
relatively tamper-proof to tickets.g.o, and

* returns a ticket to the user, a unique number that he or she can
communicate to developers and active users through a URL like
http://tickets.g.o/#ticket-number.

* --submit-info includes information about the emerge commandline that
was run last and what category/package/version emerge was
building/installing at the time.


This not only makes it a lot easier to find the causes of any bugs or
other problems, which helps Gentoo get the user entry level down,
in chime with efforts like the Gentoo Linux Installer project, it
might also help ensure that bug reports will in all likelihood not have
been tampered with, since tampering with the info would require
tampering with sys-apps/portage.

Now, do I appear to sound mistrustful of Gentoo users? Perhaps. Perhaps,
this --submit-info stuff reminds you of Product Activation routines
used by closed source software vendors. Perhaps you think I am being
paranoid. Maybe you think that FOSS should be a free-for-all exchange
of meaningful information, which I would whole-heartedly agree with -
the information would be meaningless if could not trust it.

All I know is that too many bugs on bugs.g.o and too many questions on
#gentoo remain unsolved or unanswered because of a lack of reliable
information. --submit-info would not only help improve bug handling,
but would also give the Gentoo Project useful feedback about its users.
Developers could require such a ticket to resume or even to start
analysing a bug.

It's a far cry from what Gentoo originally was supposed to be, I admit.
I am not even going to argue that this ticket system is necessary or
should be adopted by all developers once it has been implemented - it is
a means to an end, or perhaps several ends, none of which are required
to further develop Gentoo.


Kind regards,
     JeR
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Tobias Klausmann]

Hi! 

On Tue, 01 Aug 2006, Jeroen Roovers wrote:
> On Tue, 1 Aug 2006 10:21:53 +0200
> > Idea: should it be more obvious in emerge --info and ebuild
> > failure that an overlay is involved? If it's obvious enough,
> > I don't see a problem. Also, a command that lists all
> > installed packages that come from an overlay might be useful
> > (maybe even a sa part of --info).
> 
> emerge --info can easily be forged. I've seen people asking for
> help on #gentoo do it a few too many times (some even refuse to
> provide it), and have wasted precious minutes not just
> wondering what the error messages meant, but also whether I
> could trust the user.

I don't doubt your claim, yet I find it incredible. I'm
constantly amazed at how stupid some people are. Not to mention
how many idiotic assholes are out there.

> The only way to have people submit emerge --info properly and reliably
> would be to set up an online ticketing system - something like this:
> 
> 
> # emerge --submit-info
> 
> * sys-apps/portage generates emerge --info output and uploads it
> relatively tamper-proof to tickets.g.o, and
> 
> * returns a ticket to the user, a unique number that he or she can
> communicate to developers and active users through a URL like
> http://tickets.g.o/#ticket-number.
> 
> * --submit-info includes information about the emerge commandline that
> was run last and what category/package/version emerge was
> building/installing at the time.

I think this is a very good idea. Better than mine.

> Now, do I appear to sound mistrustful of Gentoo users? Perhaps.
> Perhaps, this --submit-info stuff reminds you of Product
> Activation routines used by closed source software vendors.
> Perhaps you think I am being paranoid. Maybe you think that
> FOSS should be a free-for-all exchange of meaningful
> information, which I would whole-heartedly agree with - the
> information would be meaningless if could not trust it.

I think it's critical how you sell this: don't say "this is
because we can not trust you" but "this is because it makes it
easier for you to send all relevant info". While it may seem
phone-home-ish, the contained info is clearly traceable and
everybody can see that there's nothing sensitive in there.

Feedback agents to which I can have the source are much less
suspicious than binary blobs that send gobs and gobs of binary
info to their home.

> It's a far cry from what Gentoo originally was supposed to be,
> I admit.  I am not even going to argue that this ticket system
> is necessary or should be adopted by all developers once it has
> been implemented - it is a means to an end, or perhaps several
> ends, none of which are required to further develop Gentoo.

Yet I think it's a good idea. Just don't misuse it as a tool to
spy on users. *Don't* turn it into something that pulls more info
than gentoo-stats (and then some).

Regards,
Tobias
-- 
You don't need eyes to see, you need vision.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Denis Dupeyron]

On 8/1/06, Jeroen Roovers <jer@gentoo.org> wrote:
> # emerge --submit-info
>
> * sys-apps/portage generates emerge --info output and uploads it
> relatively tamper-proof to tickets.g.o, and
>
> * returns a ticket to the user, a unique number that he or she can
> communicate to developers and active users through a URL like
> http://tickets.g.o/#ticket-number.
>
> * --submit-info includes information about the emerge commandline that
> was run last and what category/package/version emerge was
> building/installing at the time.

Like you, I'm not sure this is necessary, but I like it. I like it
even more when I think that the flags and other configuration options
that are in make.conf at the time you 'emerge --info' are not
necessarily the same as those you used when, maybe a long time ago,
you emerged the dependencies of the package that breaks. Let's imagine
we have :

# emerge --submit-info package-that-breaks

If that creates a compressed tarball of all (or selected relevant)
data in /var/db/pkg concerning all packages that package-that-breaks
depends on, I like it a lot. This will give more useful information
than 'emerge --info'. And I'm not only thinking of forged 'emerge
info', but also of those users and developers that play with flags
because they like it or have to, and then forget to revert to safe
flags. I'm sure there are many legitimate ways to make such mistakes.
You end up having some parts of your system built with stupid flags,
and you don't feel guilty about it because you don't even know (this
happened to me already).

So yes, I'd love to see something like this someday. And I'd love to
help implementing it if such a decision was taken. But the question
remains : it obviously looks useful, but do we need it ?

Denis.
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Denis Dupeyron <calchan@gentoo.org> schrieb:

Hi folks,

just a few thoughts:

> So yes, I'd love to see something like this someday. And I'd love to
> help implementing it if such a decision was taken. But the question
> remains : it obviously looks useful, but do we need it ?

I already suggested an bug-reporting tool, which automatically 
collects all the necessary data, several weeks ago. This tool is 
simply called by commandline and asks the users several questions.
Then it files an bug with some certain syntax and uploads necessary
information (emerge --info, pkg-db extracts, ...).

Maybe this also could take some load from the bug wranglers, because
based on the user's answers, the bugs could be formatted and assigned
to the right persons without manual interaction. 

I also like to have such an tool, and like to contribute.

So, now, let's start :)

Some points which (IMHO) have to be discussed:

* shall we directly access BGO ?
* what data should be sent ? 
* how to gather this data (directly look into /var/db/pkg) ?
* what questions should be asked ?
* should this tool create usual bugs or separate user-support bugs ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Simon Stelling]

Enrico Weigelt wrote:
> I already suggested an bug-reporting tool, which automatically 
> collects all the necessary data, several weeks ago. This tool is 
> simply called by commandline and asks the users several questions.
> Then it files an bug with some certain syntax and uploads necessary
> information (emerge --info, pkg-db extracts, ...).

That somehow looks like the guided file-a-new-bug form we had some time ago. 
Personally, I'd rather have it in bugzilla, because a shell tool takes the user 
away from bugzilla, and after all you have to search for existing bugs anyway, 
so you already are on bugzilla.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 Developer
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Jakub Moc]

[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]

Simon Stelling wrote:
> Enrico Weigelt wrote:
>> I already suggested an bug-reporting tool, which automatically
>> collects all the necessary data, several weeks ago. This tool is
>> simply called by commandline and asks the users several questions.
>> Then it files an bug with some certain syntax and uploads necessary
>> information (emerge --info, pkg-db extracts, ...).
> 
> That somehow looks like the guided file-a-new-bug form we had some time
> ago. 

It's still there, just not linked from homepage (and needs a few touches
here and there)

http://bugs.gentoo.org/enter_bug.cgi?format=guided
http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided


@jforman: Can you bring it back, people are filing bad bugs w/ missing
info over and over again. (It's been mentioned a couple of times in
Bug 115796 already).

Thanks.

-- 
Best regards,

 Jakub Moc
 mailto:jakub@gentoo.org
 GPG signature:
 http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E
 Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95  B30F 8717 D5FD CEBA 3D9E

 ... still no signature   ;)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] User support system

[Enrico Weigelt]

* Jakub Moc <jakub@gentoo.org> schrieb:

<snip>

> > That somehow looks like the guided file-a-new-bug form we had some time
> > ago. 
> 
> It's still there, just not linked from homepage (and needs a few touches
> here and there)
> 
> http://bugs.gentoo.org/enter_bug.cgi?format=guided
> http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided

hmm, looks like an good start, but for me doesn't go far enough. 
The user still has to type in too much manually.

I'd suggest an tool, where the user *first* gives the package name,
and the tool gathers any necessary information (version, useflags, 
make config, ...). Dependend on the package, this tool may ask specific
questions or gather specific information (ie. on web applications, 
we'd be interested in webserver, browser, certain network configs, ...). 

The usage should be as simple as possible for normal users, so they
have great interest in using it. For example, asking the user to 
look for similar bug is probably good for devs/maintainers, but
uncomfortable for plain users. But we shouldn't forget, that all
the plain users are (in their mass) also an important contributor.
(they find and report bugs, which probably never would be found
by the maintainers).


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Mike Bonar]

Enrico Weigelt wrote:
> * Jakub Moc <jakub@gentoo.org> schrieb:
>
> <snip>
>
>   
>>> That somehow looks like the guided file-a-new-bug form we had some time
>>> ago. 
>>>       
>> It's still there, just not linked from homepage (and needs a few touches
>> here and there)
>>
>> http://bugs.gentoo.org/enter_bug.cgi?format=guided
>> http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided
>>     
>
> hmm, looks like an good start, but for me doesn't go far enough. 
> The user still has to type in too much manually.
>
> I'd suggest an tool, where the user *first* gives the package name,
> and the tool gathers any necessary information (version, useflags, 
> make config, ...). Dependend on the package, this tool may ask specific
> questions or gather specific information (ie. on web applications, 
> we'd be interested in webserver, browser, certain network configs, ...). 
>
> The usage should be as simple as possible for normal users, so they
> have great interest in using it. For example, asking the user to 
> look for similar bug is probably good for devs/maintainers, but
> uncomfortable for plain users. But we shouldn't forget, that all
> the plain users are (in their mass) also an important contributor.
> (they find and report bugs, which probably never would be found
> by the maintainers).
>
>
> cu
>   
I think this is an excellent idea.  I wrote an automated trouble 
ticketing system years ago for the mainframe and it's an excellent way 
to get quality information into the system.  The one drawback was that 
we ended up having a lot more bugs entered into the system.  Once you 
have the shell it wouldn't be hard to hook it into batch processes and 
have emerge automatically send bug reports when it fails.  When this 
happens you end up with multiple, identical bug reports because users 
tend to re-create the error a few times before they head to the forums 
or bugzilla for help.  On the plus side it would be much easier to find 
duplicate bugs since the titles would be uniform. 

Glide
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Alec Warner]

> 
> I think this is an excellent idea.  I wrote an automated trouble 
> ticketing system years ago for the mainframe and it's an excellent way 
> to get quality information into the system.  The one drawback was that 
> we ended up having a lot more bugs entered into the system.  Once you 
> have the shell it wouldn't be hard to hook it into batch processes and 
> have emerge automatically send bug reports when it fails.  When this 
> happens you end up with multiple, identical bug reports because users 
> tend to re-create the error a few times before they head to the forums 
> or bugzilla for help.  On the plus side it would be much easier to find 
> duplicate bugs since the titles would be uniform.
> Glide

If people are automating I'd prefer they not post bugs directly on 
bugzilla.  When we do tinderboxing and whatnot we generally generate a 
standalone set of data to act on, as a human eye and processing can spot 
invalid problems as well as duplicates.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Enrico Weigelt]

* Mike Bonar <mike.bonar@shaw.ca> schrieb:

<snip>
> I think this is an excellent idea.  I wrote an automated trouble 
> ticketing system years ago for the mainframe and it's an excellent way 
> to get quality information into the system.  The one drawback was that 
> we ended up having a lot more bugs entered into the system.  Once you 
> have the shell it wouldn't be hard to hook it into batch processes and 
> have emerge automatically send bug reports when it fails.  

Those automatic reports should have some clear marking, so they can
be easily filtered.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Philipp Riegger]

On Aug 16, 2006, at 4:04 PM, Mike Bonar wrote:

> On the plus side it would be much easier to find duplicate bugs  
> since the titles would be uniform.

I think this is an interesting point. I'd like to have something like  
a specialised bug system for ebuilds, where you have to enter the  
package category, package name, package version and where the bug  
happens (configure, compile, test, install, execution). Then it would  
be much easier to look up for example all bugs concerning test errors  
or all bugs of glibc with compile errors. If a bug belongs to several  
categories, it should be able to post it in several categories. But  
at the moment there are some things you shouldn't have to search for  
because there are too many bugs with that name in the topic or  
somewhere else which have nothing to do with that specific package  
(unfortunately i cannot tell an example, but that happend to me more  
than once, i always filed a new bug then because i did not find  
anyting and sometimes t was a duplicate).

Philipp
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Alec Warner]

Philipp Riegger wrote:
> On Aug 16, 2006, at 4:04 PM, Mike Bonar wrote:
> 
>> On the plus side it would be much easier to find duplicate bugs since
>> the titles would be uniform.
> 
> I think this is an interesting point. I'd like to have something like a
> specialised bug system for ebuilds, where you have to enter the package
> category, package name, package version and where the bug happens
> (configure, compile, test, install, execution). Then it would be much
> easier to look up for example all bugs concerning test errors or all
> bugs of glibc with compile errors. If a bug belongs to several
> categories, it should be able to post it in several categories. But at
> the moment there are some things you shouldn't have to search for
> because there are too many bugs with that name in the topic or somewhere
> else which have nothing to do with that specific package (unfortunately
> i cannot tell an example, but that happend to me more than once, i
> always filed a new bug then because i did not find anyting and sometimes
> t was a duplicate).
> 
> Philipp
> --gentoo-dev@gentoo.org mailing list

Everyone has good ideas, no one has a good implementation.

aka, implement it :P
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system

[Philipp Riegger]

On Aug 23, 2006, at 3:54 PM, Alec Warner wrote:

>>> On the plus side it would be much easier to find duplicate bugs  
>>> since
>>> the titles would be uniform.
>>
>> I think this is an interesting point. I'd like to have something  
>> like a
>> specialised bug system for ebuilds, where you have to enter the  
>> package
>> category, package name, package version and where the bug happens
>> (configure, compile, test, install, execution).
<snip />
>
> Everyone has good ideas, no one has a good implementation.
>
> aka, implement it :P

I'm not that familiar with bugzilla. The easiest way could be to haev  
just another field like the email field for caterory/packagename (or  
with specific version if it is not a general bug) and another one for  
the ebuild phase in which the bug occured. I don't know how flexible  
bugzilla is with such modifications. Maybe some infra people could  
comment on this?

Philipp
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Jeffrey Forman]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

On Wed, 2006-08-16 at 13:29 +0200, Jakub Moc wrote:
> Simon Stelling wrote:
> > Enrico Weigelt wrote:
> >> I already suggested an bug-reporting tool, which automatically
> >> collects all the necessary data, several weeks ago. This tool is
> >> simply called by commandline and asks the users several questions.
> >> Then it files an bug with some certain syntax and uploads necessary
> >> information (emerge --info, pkg-db extracts, ...).
> > 
> > That somehow looks like the guided file-a-new-bug form we had some time
> > ago. 
> 
> It's still there, just not linked from homepage (and needs a few touches
> here and there)
> 
> http://bugs.gentoo.org/enter_bug.cgi?format=guided
> http://bugs.gentoo.org/enter_bug.cgi?product=Gentoo%20Linux&format=guided
> 
> 
> @jforman: Can you bring it back, people are filing bad bugs w/ missing
> info over and over again. (It's been mentioned a couple of times in
> Bug 115796 already).
Done

-- 
--------------
Jeffrey Forman
Gentoo Infrastructure
Gentoo Release Engineering
Bugs.Gentoo.org Administrator
--------------

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Simon Stelling <blubb@gentoo.org> schrieb:

Hi,

> Enrico Weigelt wrote:
> >I already suggested an bug-reporting tool, which automatically 
> >collects all the necessary data, several weeks ago. This tool is 
> >simply called by commandline and asks the users several questions.
> >Then it files an bug with some certain syntax and uploads necessary
> >information (emerge --info, pkg-db extracts, ...).
> 
> That somehow looks like the guided file-a-new-bug form we 
> had some time ago. 

I personally don't know this one, but this is what I intend 
(but instead via an commandline).

> Personally, I'd rather have it in bugzilla, because a shell tool 
> takes the user away from bugzilla, and after all you have to search 
> for existing bugs anyway, so you already are on bugzilla.

hmm, right, this would reduce preasure from reporting people for 
looking for duplicate bugs. But I'm not sure if this is bad:

* Do we have any reliable knowledge whether people actually do it ?
* Is it maybe a good idea to have certain bugs duplicate, so we can
  see whats more important (many bugs -> greater problem ?)
* Are all the bugs, currently considered as duplicate (by users
  intenting to file one) really duplicate ?
* Is the additional information more valuable than the probably
  additional work of linking together duplicate bugs ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Alastair Tse]

On Wed, 2006-08-16 at 13:18 +0200, Simon Stelling wrote:
> Enrico Weigelt wrote:
> > I already suggested an bug-reporting tool, which automatically 
> > collects all the necessary data, several weeks ago. This tool is 
> > simply called by commandline and asks the users several questions.
> > Then it files an bug with some certain syntax and uploads necessary
> > information (emerge --info, pkg-db extracts, ...).
> 
> That somehow looks like the guided file-a-new-bug form we had some time ago. 
> Personally, I'd rather have it in bugzilla, because a shell tool takes the user 
> away from bugzilla, and after all you have to search for existing bugs anyway, 
> so you already are on bugzilla.

Somehow I believe that most people will encounter bugs when on the
command line, so being able to search/post in bugzilla from the command
line is a pretty natural extension. 

Using PyBugz as an example, typing this after an "emerge plptools" fails
is much easier than opening firefox, typing bugs.gentoo.org, finding the
search page and typing the package name in the search box in:

bugz search plptools 

PyBugz actually has a 'bugz post' option that I've only used a couple of
times, but it actually prompts the user to submit their emerge --info.

Cheers,

Alastair

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Alastair Tse <liquidx@gentoo.org> schrieb:

<snip>

> Somehow I believe that most people will encounter bugs when on the
> command line, so being able to search/post in bugzilla from the command
> line is a pretty natural extension. 

ACK. The query could be done based on the answers from the user.
The more formalized and finely granulated these questions are, the
greater the chance for detecting duplicates. If certain projects/herds
can pull in their own questioning and information gathering, we can 
gain much better report quality. 
(ie. mplayer could include `mplayer -vo help`).

<snip>

> Using PyBugz as an example, typing this after an "emerge plptools" fails
> is much easier than opening firefox, typing bugs.gentoo.org, finding the
> search page and typing the package name in the search box in:
> 
> bugz search plptools 

ACK. Would be a great help.
But just posting bugs via command line is not enough. The tool
has to gather and ask for the right information (maybe dependent
on the package) and post it all together in an well-defined syntax.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 2202 bytes --]

You should look for existing tools which could be enhanced before
suggesting a new one. `bugz post` (from www-client/pybugz) allows you
to submit a new bug report from the command line. Why don't you go and
patch that to do all of the automated things you want it to do and then
come back and show us?

-Thomas

On Wed, 16 Aug 2006 12:52:03 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Denis Dupeyron <calchan@gentoo.org> schrieb:
> 
> Hi folks,
> 
> just a few thoughts:
> 
> > So yes, I'd love to see something like this someday. And I'd love to
> > help implementing it if such a decision was taken. But the question
> > remains : it obviously looks useful, but do we need it ?
> 
> I already suggested an bug-reporting tool, which automatically 
> collects all the necessary data, several weeks ago. This tool is 
> simply called by commandline and asks the users several questions.
> Then it files an bug with some certain syntax and uploads necessary
> information (emerge --info, pkg-db extracts, ...).
> 
> Maybe this also could take some load from the bug wranglers, because
> based on the user's answers, the bugs could be formatted and assigned
> to the right persons without manual interaction. 
> 
> I also like to have such an tool, and like to contribute.
> 
> So, now, let's start :)
> 
> Some points which (IMHO) have to be discussed:
> 
> * shall we directly access BGO ?
> * what data should be sent ? 
> * how to gather this data (directly look into /var/db/pkg) ?
> * what questions should be asked ?
> * should this tool create usual bugs or separate user-support bugs ?
> 
> 
> cu
> -- 
> ---------------------------------------------------------------------
>  Enrico Weigelt    ==   metux IT service - http://www.metux.de/
> ---------------------------------------------------------------------
>  Please visit the OpenSource QM Taskforce:
>  	http://wiki.metux.de/public/OpenSource_QM_Taskforce
>  Patches / Fixes for a lot dozens of packages in dozens of versions:
> 	http://patches.metux.de/
> ---------------------------------------------------------------------
> -- 
> gentoo-dev@gentoo.org mailing list
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Thomas Cort <tcort@gentoo.org> schrieb:
> You should look for existing tools which could be enhanced before
> suggesting a new one. `bugz post` (from www-client/pybugz) allows you
> to submit a new bug report from the command line. Why don't you go and
> patch that to do all of the automated things you want it to do and then
> come back and show us?

I personally dislike python, and I'm not skilled enough in this 
language. So I'm not the right one for coding @ pybugz.
But I'm working on my own tool, written in java. It's not very 
good yet (currently can only file new bugs), but it's from ground up 
independent from the actual tracker software (drivers for virtually
any issue tracker could be plugged in). If anyone likes to have a 
look at it, please drop a note to me.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Jean-François Gagnon Laporte]

On 8/16/06, Enrico Weigelt <weigelt@metux.de> wrote:
>
> I personally dislike python, and I'm not skilled enough in this
> language. So I'm not the right one for coding @ pybugz.
> But I'm working on my own tool, written in java. It's not very
> good yet (currently can only file new bugs), but it's from ground up
> independent from the actual tracker software (drivers for virtually
> any issue tracker could be plugged in). If anyone likes to have a
> look at it, please drop a note to me.
>

You know that java is not available on all arch that Gentoo supports
right ? Well, except  if you make it run on GCJ but it will seriously
limit the scope of your tool IMO. Not that's it a bad idea per se but
maybe think of another programming language to build your program.

Regards,

Jean-François

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Jean-François Gagnon Laporte <kioshen@gmail.com> schrieb:

<snip>

> You know that java is not available on all arch that Gentoo 
> supports right ? 

Which one ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Stephen P. Becker]

Enrico Weigelt wrote:
> * Jean-Fran�ois Gagnon Laporte <kioshen@gmail.com> schrieb:
> 
> <snip>
> 
>> You know that java is not available on all arch that Gentoo 
>> supports right ? 
> 
> Which one ?

See tcort's reply.  No java available on alpha, arm, hppa, m68k, mips,
sh, or sparc.  Seven strikes and you are out twice over...

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Stephen P. Becker <geoman@gentoo.org> schrieb:
> Enrico Weigelt wrote:
> > * Jean-Fran???ois Gagnon Laporte <kioshen@gmail.com> schrieb:
> > 
> > <snip>
> > 
> >> You know that java is not available on all arch that Gentoo 
> >> supports right ? 
> > 
> > Which one ?
> 
> See tcort's reply. 

Okay, now got his posting :) 

> No java available on alpha, arm, hppa, m68k, mips,
> sh, or sparc.  Seven strikes and you are out twice over...

hmm, AFAIK kaffe should support those platforms (didn't ever 
worked on them). But (as I just said), kaffe ebuild was broken 
some time ago, didn't check it for a while yet ... 

Well, I don't see the current lack of an proper java runtime
on certain platforms an real blocker for some additional tool.
Java generally is designed for a very wide range of platforms
and architectures. If some major archs are missing an proper
java implementation, then it's a bug, which sooner or later
will be fixed. 


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Stephen P. Becker]

> Well, I don't see the current lack of an proper java runtime
> on certain platforms an real blocker for some additional tool.

Uhh...I'm not even sure what I can say in response to such an asinine
statement.


> Java generally is designed for a very wide range of platforms
> and architectures. If some major archs are missing an proper
> java implementation, then it's a bug, which sooner or later
> will be fixed. 

Reading that almost made me spit water all over my keyboard...

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Ciaran McCreesh]

On Wed, 16 Aug 2006 21:29:40 +0200 Enrico Weigelt <weigelt@metux.de>
wrote:
| > No java available on alpha, arm, hppa, m68k, mips,
| > sh, or sparc.  Seven strikes and you are out twice over...
| 
| hmm, AFAIK kaffe should support those platforms (didn't ever 
| worked on them).

Nnnnnope.

| Well, I don't see the current lack of an proper java runtime
| on certain platforms an real blocker for some additional tool.

It's a blocker if it's a tool you're going to be pushing out to users.
Have a google for "Guidelines / policy for gentoo hosted projects".

| Java generally is designed for a very wide range of platforms
| and architectures.

Riiiiiight.

| If some major archs are missing an proper java implementation, then
| it's a bug, which sooner or later will be fixed. 

Riiiiiiiiiiiiiiiiiiiight.

You really don't have the slightest clue what you're talking about, do
you?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Duncan]

Enrico Weigelt <weigelt@metux.de> posted
20060816192939.GC552@nibiru.local, excerpted below, on  Wed, 16 Aug 2006
21:29:40 +0200:

> Java generally is designed for a very wide range of platforms
> and architectures. If some major archs are missing an proper
> java implementation, then it's a bug, which sooner or later
> will be fixed.

You ever seen the term "slaveryware"?  You have now.  One of the problems
with proprietary slaveryware is that support on a platform is subject to
the whim of the one controlling the code.  If a platform doesn't have
enough users for the code's master to bother, you are out of luck.  Java
is a good example.  I'm on amd64, where Java porting was well behind most
of the popular freedomware apps, because it had to wait for its master to
do it, while all popular freedomware had already been ported by users on
the platform, something they of course couldn't do with Java, as it's
slaveryware that the master hadn't deigned to port yet.

The freedomware implementations try, and there are decent jvms, but
without freedomware implementations of the classes, they aren't anywhere
close to complete, and with the standards for those continuing to mature
and everyone else having to wait on the standards to implement, they will
naturally always be behind.  Given the incompleteness of the solution, it
really doesn't make sense to worry to much about porting even the
freedomware versions to all available platforms.

Well, that may eventually change, as Sun is now saying it expects to start
freeing Java this year, and finish by the end of next year.  They've been
making noises about GPL3 as well, so while the license hasn't been
announced, that's possible, and would fit the timing.  Time will tell, I
suppose.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] If I may interject...

[Mike Lundy]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Wednesday 16 August 2006 14:49, Duncan wrote:
> You ever seen the term "slaveryware"?  You have now.

[This preface is directed at everyone who might respond to this, not just 
Duncan. I strive to be logical about this, and as un-inflammatory as 
possible. If you are going to respond, please make the same effort; I'm ok 
with being the latest person to start a discussion; I'm not ok with being the 
latest person to start a flamewar. So, with that said...]

I told a friend that there were some in the community who called proprietary 
software slaveryware. His response? "Holy shit!" If that term spreads, we can 
forget about convincing otherwise logical people that free software is the 
Right Way. There are two problems with it:

1) It's incorrect. There is nothing at this point in time that causes you to 
be enslaved by proprietary software. There are stories of speculative 
fiction, such as "Right to Read" and other, better written stories; those 
stories are just that- fiction. Microsoft does not beat you or chain you to 
their operating system. Sun does not whip you to use java. Members of the 
wider computer community may, through their own adoption, but Sun has nothing 
to do with it. You must convince members of your community to stay away from 
proprietary software. This leads me to the second error.

2) It's intentionally offensive. The end goal of the free software movement, 
as I understand it, is to convince everyone that freedom in software is 
something to strive for. Some people do not immediately see the light of 
this, and must be convinced through logical means. Convincing people to see 
the benefits of free software is difficult enough. Stealing a cliche- can you 
imagine explaining to your mother about slaveryware? If you use that term, 
you then have to convince people that that term is accurate. The discussion 
will be about the slaveryware /word/ instead of the free software /idea/. 
That is counterproductive, and will likely cause you to be dismissed as a 
extremist (though, hopefully not by your mother). Intentionally offending the 
very people we need to convince does not help us at all.

So please, for the good of the community, stop using it. Don't stop with the 
message, just cease using a term that would crystallize people against us if 
it spread. Thanks.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Re: If I may interject...

[Duncan]

Mike Lundy <novas007@gmx.net> posted 200608161801.43378.novas007@gmx.net,
excerpted below, on  Wed, 16 Aug 2006 18:01:37 -0700:

Mike Lundy <novas007@gmx.net> posted 200608161801.43378.novas007@gmx.net,
excerpted below, on  Wed, 16 Aug 2006 18:01:37 -0700:

> I strive to be logical about this, and as un-inflammatory as 
> possible. If you are going to respond, please make the same effort[.]

Likewise.  I consider flamewars a waste of time, but healthy debate a
chance to learn something.
 
> I told a friend that there were some in the community who called
> proprietary software slaveryware. His response? "Holy shit!" If that
> term spreads, we can forget about convincing otherwise logical people
> that free software is the Right Way. There are two problems with it:
> 
> 1) It's incorrect. There is nothing at this point in time that causes
> you to be enslaved by proprietary software.

Tell that to the many that can't leave it, due to "just one app",
photoshop, games, MS Office, Outlook/Exchange, Quickbooks accounting,
whatever. They are as enslaved to their "poison of choice", to combine
metaphors, as the druggie, as dependant on their master's whims as a slave.
As RMS says, every non-free program has a master, use the program, and you
are making him /your/ master.  A human with another human master is
called... a slave.  Note that some slavery can have been voluntary at some
point.  That's indentured servitude, but it's considered a form of
slavery.  When one can't leave, as these people can't, well, slavery it
becomes, whether it was originally voluntary or not.
 
> 2) It's intentionally offensive.

Intentionally accurate, IMO.  Intentionally thought provoking as well, but
the nomenclature is IMO 100% accurate.  Note that repeated "IMO".  Others
are of course free to have their own opinion and call it what they want.
That's their opinion and they are entitled to it.  I'll continue to choose
a label that matches my opinion thereof.  "Slaveryware" is what I call it
because that's a very concise term defining my opinion of it.  What you
call it is your choice, "the best thing since sliced bread", if you want. 
That doesn't mean I have to agree with you, nor that I expect you to agree
with me.  It's simply defining how each of us feels about it.

> Can you imagine explaining to your mother about slaveryware?

Actually, yes.  My family is reasonably aware of my feelings on the matter
and why I hold them.  I've described my journey from proprietaryware in
terms of a defector leaving the only land he ever knew, family, friends,
way of life, sacrificing it all because of a belief in freedom.  Just as a
defector, I know I could never go back unless there's a regime change.
Just as a defector, I look back on that old life as pretty much a different
person in a different time.  I still have friends in the old country, but
I recognize they must make their own choice, take their own risks in their
own time.  Some may eventually choose to do so, and I'll be here to
welcome them and help them get settled in their new land.  Others may
never choose to do it.  I still consider them friends, yearning for them
to choose freedom too, but there is now a difference separating us, as
long as they haven't yet done so.  My folks know and understand my
feelings on it, tho they don't share them.  As the defector, I recognize
there are some that may agree to one extent or another, but simply find
they are too old to pull up roots and move, now.  I understand this is
where my folks are, and am as comfortable with it as the defector
could/would be, because in a very real sense, that's really what I am.

As I said in my first post, I truly believe this stuff.  Some label me a
radical as a result.  I'm comfortable with that, because from my
perspective it puts me in some pretty fine company in terms of many others
who have been called radical because they refused to compromise on what
they considered freedom.  However, it wouldn't be freedom at all if I were
to force the same beliefs on others, so I don't.  I refuse to compromise
in terms of my own beliefs and definitions, but define them only in terms
of my own life.  Unfortunately (IMO), too often people try to force others
into their own belief set.  In turn, they expect I'm doing the same.  No,
I'm not.  They can deal with it as they see fit, but I demand and
positively assert my right and ability to do the same.



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: If I may interject...

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Thursday 17 August 2006 05:20, Duncan wrote:
> excerpted below, on  Wed, 16 Aug 2006 18:01:37 -0700:
> > I told a friend that there were some in the community who called
> > proprietary software slaveryware. His response? "Holy shit!" If that
> > term spreads, we can forget about convincing otherwise logical people
> > that free software is the Right Way. There are two problems with it:
> >
> > 1) It's incorrect. There is nothing at this point in time that causes
> > you to be enslaved by proprietary software.
>
> Tell that to the many that can't leave it, due to "just one app",
> <snip>

Lundy's point was that nutjobs hurt the free software movement

if you want to further a movement, use your head and employ logic, dont employ 
stupid terms
-mike

[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]

Re: [gentoo-dev] If I may interject...

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 2491 bytes --]

On Thursday 17 August 2006 03:01, Mike Lundy wrote:
> I told a friend that there were some in the community who called
> proprietary software slaveryware. His response? "Holy shit!" If that term
> spreads, we can forget about convincing otherwise logical people that free
> software is the Right Way. There are two problems with it:

I can't help to respond here.
>
> 1) It's incorrect. There is nothing at this point in time that causes you
> to be enslaved by proprietary software. There are stories of speculative
> fiction, such as "Right to Read" and other, better written stories; those
> stories are just that- fiction. Microsoft does not beat you or chain you to
> their operating system. Sun does not whip you to use java. Members of the
> wider computer community may, through their own adoption, but Sun has
> nothing to do with it. You must convince members of your community to stay
> away from proprietary software. This leads me to the second error.

Actually, it is more subtle. Microsoft does not force you to use windows. One 
uses windows because of office. One uses microsoft office not because of 
microsoft, but because *the whole world* uses microsoft office. It is called 
network effects and is the cause of the microsoft monopoly. The slavery part 
is that we are basically at the mercy of the owner of the monopoly. (You know 
the main competitor of windows XP? It's the earlier releases, same goes for 
office)

> 2) It's intentionally offensive. The end goal of the free software
> movement, as I understand it, is to convince everyone that freedom in
> software is something to strive for. Some people do not immediately see the
> light of this, and must be convinced through logical means. Convincing
> people to see the benefits of free software is difficult enough. Stealing a
> cliche- can you imagine explaining to your mother about slaveryware? If you
> use that term, you then have to convince people that that term is accurate.
> The discussion will be about the slaveryware /word/ instead of the free
> software /idea/. That is counterproductive, and will likely cause you to be
> dismissed as a extremist (though, hopefully not by your mother).
> Intentionally offending the very people we need to convince does not help
> us at all.

While it is accurate, I agree with you that it is indeed offensive.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] If I may interject...

[Samuel Baldwin]

[-- Attachment #1: Type: text/plain, Size: 3027 bytes --]

Quoth the subject: "If I may interject".

The term "slaveryware" is a little extreme, but not out of reality.
Microsoft does take steps to make themselves the *only* operating system out
there (heck, they are even putting Windows on Macintosh!). They do not
physically harm you if you switch Operating Systems, but they make it as
hard for you as you can. For instance, the moment Windows XP sees ANYTHING
else in the MBR of it's current HDD, it shuts down, and will not work until
you replace the MBR with it's own code. This is obviously to make it harder
for Linux users to share a HDD with Windows. As far as NTFS, they are
keeping that code to themselves (last I checked). Why? So other people have
a much more difficult time reading and writing NTFS from another OS (Linux).
Another big hook to keep you on Microsoft, is DirectX. Most of the big games
are DirectX, and will not run on anything but DirectX. (I know, UT, DOOM,
and Quake are for OpenGL). These keeps all gamers nailed down into Windows
(Cedega/Wine help, but my experience has been less than satisfactory. Only
Starcraft works well under Cedega for me, but that's another story). I'm a
gamer, I know a lot of gamers, and guess what? We all have a windows OS.
Only a few other people I know run Linux, but even so, we still using
Windows for gaming. If windows would release the numbers on DirectX,
everyone that I know (at least, the gamers), would be running linux (as they
are all interested, but don't want to dual-boot). There are a few other
examples, but I think you all get the point.

In short, Microsoft tries to pull you into using their products over a 3rd
party product, even if the latter is much better. Half of this is greed,
since you have to pay for most Microsoft software. If you *have* to use this
certain kind of DVD burning app on Vista, since that's the only one
Microsoft will support (or else the computer will lock, on purpose, or
something tricky like that), then Vista users are forced to pay Microsoft to
get that application if they want to burn DVDs. Apple employs similar
strategies, but that's another thread (which I'd be glad to have a
discussion about, email me off gentoo lists.)

As far as flamewars, they do nothing but take up time, anger, and email.
However, not every argument is a flamewar. A flame war is the typical "KDE
vs. GNOME, which is better". This has no basis in reality, as "better" is a
subjective term. Perhaps someone likes the look better for KDE. You don't
argue taste. A real argument would be "Which has better support for... CD
burning applications". Or "Which runs faster at a certain system
specification." Or even "Which has a wider choice of customization (with
every "aspect" having equal value to the next)". A good, logical argument is
a very good thing, since all parties generally leave enlightened, usually
bringing out the truth and destroying the falsehoods.

-- 
Samuel (shardz)

Noha+Shardz Productions: nsproductions.co.nr

Registered Linux User #410639

amarok.kde.org
usmc.mil

[-- Attachment #2: Type: text/html, Size: 3553 bytes --]

Re: [gentoo-dev] If I may interject...

[Jean-François Gagnon Laporte]

Oh please stop the FUD. Move this slaverythingie out of gentoo-dev. I
know I'm feeding the trolls but this has to stop.

On 8/17/06, Samuel Baldwin <shardz4217@gmail.com> wrote:
>
> Quoth the subject: "If I may interject".
>
> The term "slaveryware" is a little extreme, but not out of reality.
> Microsoft does take steps to make themselves the *only* operating system out
> there
Well it's a company and there are very good at using a network effect
strategy. Nobody is forcing you to use Windows but many people forces
you to have pixel perfect fidelity of DOC or XLS documents. Fortunatly
this is beginning to change.

> (heck, they are even putting Windows on Macintosh!).
Repeat after me : Boot camp is produced by Apple. Apple is using a
network effect style strategy just like microsoft to convince you to
buy Apple hardware (remember that Apple is an hardware company first
and foremost). If they can also make you run Mac OS X well goodie.

> They do not
> physically harm you if you switch Operating Systems, but they make it as
> hard for you as you can. For instance, the moment Windows XP sees ANYTHING
> else in the MBR of it's current HDD, it shuts down, and will not work until
> you replace the MBR with it's own code. This is obviously to make it harder
> for Linux users to share a HDD with Windows.
errr what !? I've been dual-booting or more for years with lilo or
grub directly on the MBR without any issues whatsoever nor side
effects affecting Windows.

> As far as NTFS, they are
> keeping that code to themselves (last I checked). Why? So other people have
> a much more difficult time reading and writing NTFS from another OS (Linux).
Do a google search on ntfs-3g and fuse. They are not keeping the code
to themselves, they are just licensing their code to the people that
can pay the fees. Recently, they even wanted to collect patent fees
for FAT but fortunatly it was agreed that FAT was common knowledge now
and it was too late.

> Another big hook to keep you on Microsoft, is DirectX. Most of the big games
> are DirectX, and will not run on anything but DirectX. (I know, UT, DOOM,
> and Quake are for OpenGL). These keeps all gamers nailed down into Windows
> (Cedega/Wine help, but my experience has been less than satisfactory. Only
> Starcraft works well under Cedega for me, but that's another story). I'm a
> gamer, I know a lot of gamers, and guess what? We all have a windows OS.
> Only a few other people I know run Linux, but even so, we still using
> Windows for gaming. If windows would release the numbers on DirectX,
> everyone that I know (at least, the gamers), would be running linux (as they
> are all interested, but don't want to dual-boot). There are a few other
> examples, but I think you all get the point.
OpenGL was the platform of choice for gaming developpement just a few
years ago. Until the decision board fragmented, conflict of interest
arised and bogged down the developpement of it's API. During that
time, Microsoft released their first shot at a universal API and it
was god awful but they kept at it until it was usable and even better
that OpenGL. Since "everybody" runs Windows, publishers and game
developpers alike follow the money for good reasons and the market
began to shift to Direct X. See network effect. They're using the same
strategy for the Xbox / Xbox 360 / XNA as we speak.

>
> In short, Microsoft tries to pull you into using their products over a 3rd
> party product, even if the latter is much better. Half of this is greed,
> since you have to pay for most Microsoft software. If you *have* to use this
> certain kind of DVD burning app on Vista, since that's the only one
> Microsoft will support (or else the computer will lock, on purpose, or
> something tricky like that), then Vista users are forced to pay Microsoft to
> get that application if they want to burn DVDs. Apple employs similar
> strategies, but that's another thread (which I'd be glad to have a
> discussion about, email me off gentoo lists.)
I use Firefox, Thunderbird, OpenOffice.org, Nero fex without any issue
instead of IE, OE, Office and whatever they have in place for bult-in
burning thank you very much. However, grandma just don't know any
better (not mine thought ;)). We just need to let them know they are
alternative and if possible provide training and coaching.

As for Apple, they produce excellent intergrated first party software
but the third party ecosystem is alive and kicking rear ends but
that's another story like you said.

>
> As far as flamewars, they do nothing but take up time, anger, and email.
> However, not every argument is a flamewar. A flame war is the typical "KDE
> vs. GNOME, which is better". This has no basis in reality, as "better" is a
> subjective term. Perhaps someone likes the look better for KDE. You don't
> argue taste. A real argument would be "Which has better support for... CD
> burning applications". Or "Which runs faster at a certain system
> specification." Or even "Which has a wider choice of customization (with
> every "aspect" having equal value to the next)". A good, logical argument is
> a very good thing, since all parties generally leave enlightened, usually
> bringing out the truth and destroying the falsehoods.
>

Unfortunatly there are other things like subjects that are completly
off-topic to a proper mailing list. Now please stop the FUD, we should
know better than use tactics like this to promote free software.

> --
> Samuel (shardz)

Kind regards,

Jean-François

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] [OT] If I may interject...

[Alec Warner]

Feel free to discuss with each other privately, but this has nothing to
do with gentoo development.

Thanks,

Alec Warner
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Duncan <1i5t5.duncan@cox.net> schrieb:

<snip>

> You ever seen the term "slaveryware"?  You have now.  

We are still talking about the java *language* ?
I aggree that we shouldn't be bound to some certain proprietary 
software. But the java language is not software, it is couple of 
abstract concept for actually writing software. 

There are lot's of java environments out there. So if you code 
someting in java, you don't need to use Sun JDK. You need an 
java environment which conforms to the standard (or at least
the subset you're actually using). 

My personal reference is kaffe. I'm now using this for years,
and it works great for me. AFAIK my java code is standard conform
(but rarely tested on other JREs).


I won't comment anything more on the "slaveryware" issue.
Its simply offtopic.


*If* the kaffe port is currently broken, then let's fix it. 


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Ciaran McCreesh]

On Thu, 17 Aug 2006 16:37:50 +0200 Enrico Weigelt <weigelt@metux.de>
wrote:
| *If* the kaffe port is currently broken, then let's fix it. 

Off you go then.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 666 bytes --]

On Thursday 17 August 2006 16:37, Enrico Weigelt wrote:
> * Duncan <1i5t5.duncan@cox.net> schrieb:
>
> <snip>
>
> > You ever seen the term "slaveryware"?  You have now.
>
> We are still talking about the java *language* ?
> I aggree that we shouldn't be bound to some certain proprietary
> software. But the java language is not software, it is couple of
> abstract concept for actually writing software.

You forget the main part of a language is the library. Basically there is not 
yet a good complete open java standard library available.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[James Potts]

hmmm....doesn't the GNU ClassPath implement enough of Java's runtimes
to handle a command-line app like this (the app needs, basically, to
be able to read files, communicate via the http protocol, print to
stdout, and accept input from stdin)?  And doesn't Kaffe use the GNU
ClassPath?  And if this is the case, couldn't GCJ be used in the place
of Kaffe to build this app on platforms that aren't supported by Kaffe
(or on all platforms, if that is desired)?

Just some thoughts...

--Arek


On 8/17/06, Paul de Vrieze <pauldv@gentoo.org> wrote:
> On Thursday 17 August 2006 16:37, Enrico Weigelt wrote:
> > * Duncan <1i5t5.duncan@cox.net> schrieb:
> >
> > <snip>
> >
> > > You ever seen the term "slaveryware"?  You have now.
> >
> > We are still talking about the java *language* ?
> > I aggree that we shouldn't be bound to some certain proprietary
> > software. But the java language is not software, it is couple of
> > abstract concept for actually writing software.
>
> You forget the main part of a language is the library. Basically there is not
> yet a good complete open java standard library available.
>
> Paul
>
> --
> Paul de Vrieze
> Gentoo Developer
> Mail: pauldv@gentoo.org
> Homepage: http://www.devrieze.net
>
>
>
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Ciaran McCreesh]

On Thu, 17 Aug 2006 14:42:52 -0500 "James Potts" <arek75@gmail.com>
wrote:
| hmmm....doesn't the GNU ClassPath implement enough of Java's runtimes
| to handle a command-line app like this (the app needs, basically, to
| be able to read files, communicate via the http protocol, print to
| stdout, and accept input from stdin)?  And doesn't Kaffe use the GNU
| ClassPath?  And if this is the case, couldn't GCJ be used in the place
| of Kaffe to build this app on platforms that aren't supported by Kaffe
| (or on all platforms, if that is desired)?

What makes you think gcj works?

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Mike Cvet]

On Thu, 2006-08-17 at 21:05 +0100, Ciaran McCreesh wrote:
> On Thu, 17 Aug 2006 14:42:52 -0500 "James Potts" <arek75@gmail.com>
> wrote:
> | hmmm....doesn't the GNU ClassPath implement enough of Java's runtimes
> | to handle a command-line app like this (the app needs, basically, to
> | be able to read files, communicate via the http protocol, print to
> | stdout, and accept input from stdin)?  And doesn't Kaffe use the GNU
> | ClassPath?  And if this is the case, couldn't GCJ be used in the place
> | of Kaffe to build this app on platforms that aren't supported by Kaffe
> | (or on all platforms, if that is desired)?
> 
> What makes you think gcj works?
> 

What makes you think it doesn't?

-Mike

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Ciaran McCreesh]

On Thu, 17 Aug 2006 22:01:48 -0400 Mike Cvet <mcvet@i2ce.com> wrote:
| On Thu, 2006-08-17 at 21:05 +0100, Ciaran McCreesh wrote:
| > On Thu, 17 Aug 2006 14:42:52 -0500 "James Potts" <arek75@gmail.com>
| > wrote:
| > | hmmm....doesn't the GNU ClassPath implement enough of Java's
| > | runtimes to handle a command-line app like this (the app needs,
| > | basically, to be able to read files, communicate via the http
| > | protocol, print to stdout, and accept input from stdin)?  And
| > | doesn't Kaffe use the GNU ClassPath?  And if this is the case,
| > | couldn't GCJ be used in the place of Kaffe to build this app on
| > | platforms that aren't supported by Kaffe (or on all platforms, if
| > | that is desired)?
| > 
| > What makes you think gcj works?
| 
| What makes you think it doesn't?

Practical experience on several of the platforms in question.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Stephen P. Becker]

Mike Cvet wrote:
> On Thu, 2006-08-17 at 21:05 +0100, Ciaran McCreesh wrote:
>> On Thu, 17 Aug 2006 14:42:52 -0500 "James Potts" <arek75@gmail.com>
>> wrote:
>> | hmmm....doesn't the GNU ClassPath implement enough of Java's runtimes
>> | to handle a command-line app like this (the app needs, basically, to
>> | be able to read files, communicate via the http protocol, print to
>> | stdout, and accept input from stdin)?  And doesn't Kaffe use the GNU
>> | ClassPath?  And if this is the case, couldn't GCJ be used in the place
>> | of Kaffe to build this app on platforms that aren't supported by Kaffe
>> | (or on all platforms, if that is desired)?
>>
>> What makes you think gcj works?
>>
> 
> What makes you think it doesn't?

For one example, it won't even build on mips (although it is possible 
some recent binutils changes has finally fixed that).

-Steve
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: User support system [WAS: Sunrise contemplations]

[Carsten Lohrke]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

On Thursday 17 August 2006 21:42, James Potts wrote:
> hmmm....doesn't the GNU ClassPath implement enough of Java's runtimes
> to handle a command-line app like this

When it is at 100% 1.4 compatibility (and that does not mean nearly as bug 
free, stable, fast, etc. as Sun's Java is), the latter will be at 1.6 and the 
apps follow. Just forget about Java, when it comes to software that needs to 
be available on multiple architectures. Period.


Carsten

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Thomas Cort]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Wed, 16 Aug 2006 18:11:24 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> I'm working on my own tool, written in java.

That's great. Have you or are you going to setup a project page
somewhere (maybe sourceforge.net)? You should be aware that java isn't
available on every platform that Gentoo supports and isn't Free
software.

virtual/jre

      | a a a h i m m p p p s s s x x
      | l m r p a 6 i p p p 3 h p 8 8
      | p d m p 6 8 p c c c 9   a 6 6
      | h 6   a 4 k s   6 - 0   r   -
      | a 4             4 m     c   f
      |                   a         b
      |                   c         s
      |                   o         d
      |                   s
------+------------------------------
1.3   |               ~           +
1.4.1 |   +                       +
1.4.2 |   +     +     + +   ~     +
1.5.0 |   ~     ~     ~ ~   ~     ~ ~

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Thomas Cort <tcort@gentoo.org> schrieb:
> On Wed, 16 Aug 2006 18:11:24 +0200
> Enrico Weigelt <weigelt@metux.de> wrote:
> 
> > I'm working on my own tool, written in java.
> 
> That's great. Have you or are you going to setup a project page
> somewhere (maybe sourceforge.net)? 

Not yet. Would you like to do that job ? :)

> You should be aware that java isn't available on every platform 
> that Gentoo supports and isn't Free software.

Aehm, java is an language. How can an language be unfree ?

AFAIK there are opensource JVMs which should run on almost all
platforms, ie. kaffe. Okay, last time I checked kaffe ebuild, 
it was broken. But it's quite some time ago ...


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Ciaran McCreesh]

On Wed, 16 Aug 2006 21:10:16 +0200 Enrico Weigelt <weigelt@metux.de>
wrote:
| AFAIK there are opensource JVMs which should run on almost all
| platforms, ie. kaffe.

And yet again, you demonstrate that you know Jack.

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] User support system [WAS: Sunrise contemplations]

[Marius Mauch]

[-- Attachment #1: Type: text/plain, Size: 1307 bytes --]

On Wed, 16 Aug 2006 18:11:24 +0200
Enrico Weigelt <weigelt@metux.de> wrote:

> * Thomas Cort <tcort@gentoo.org> schrieb:
> > You should look for existing tools which could be enhanced before
> > suggesting a new one. `bugz post` (from www-client/pybugz) allows
> > you to submit a new bug report from the command line. Why don't you
> > go and patch that to do all of the automated things you want it to
> > do and then come back and show us?
> 
> I personally dislike python, and I'm not skilled enough in this 
> language. So I'm not the right one for coding @ pybugz.
> But I'm working on my own tool, written in java. It's not very 
> good yet (currently can only file new bugs), but it's from ground up 
> independent from the actual tracker software (drivers for virtually
> any issue tracker could be plugged in). If anyone likes to have a 
> look at it, please drop a note to me.

Well, if you want this to be a default tool on Gentoo then java is not
really an option (possible options are C, C++, bash, perl or python
where bash and python are the preferred options).

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-dev] Portage Subtrees [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Tobias Klausmann <klausman@schwarzvogel.de> schrieb:

hi,

(I'm trying to splitt off sevaral sub-topics to get them 
more clear ...)

> I initially provided an ebuild for a package I maintain. I also
> provide a new ebuild for every new version. For this, proxy
> maintainership is the thing to do, IMO. 

hmm, I'm just thinking about splitting the tree into separate
(larger) parts, actually: move out certain subtrees to an overlay.

For example: KDE. 
Many people/systems won't ever use it (ie. have no X at all).
Others are very interested in it.

If we had this whole subtree in an overlay, it would make the main 
tree much, much smaller, so easier to maintain and save load from 
the mirrors.

But this only works good, if its actually an *subtree*, and *not* 
overriding any packages from the main tree. Otherwise we soon get 
ugly conflicts and evrything goes to hell.

The same could happen for other parts of the tree, ie. web servers.
Maybe this splitting could be done on similar boundaries as some
distros (or commercial OS vendors) have their different "editions".
So maybe "Gentoo KDesktop edition" would be Gentoo base plus
Xorg+KDE overlays ;-)

Of course this has to be done *very* careful, but IMHO it can
help a lot.



... just my 0.02 EUR


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage Subtrees [WAS: Sunrise contemplations]

[Martin Rud Ehmsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrico Weigelt wrote:
> hmm, I'm just thinking about splitting the tree into separate
> (larger) parts, actually: move out certain subtrees to an overlay.
> 
> For example: KDE. 
> Many people/systems won't ever use it (ie. have no X at all).
> Others are very interested in it.
> 
> If we had this whole subtree in an overlay, it would make the main 
> tree much, much smaller, so easier to maintain and save load from 
> the mirrors.

I don't see how this is going to make anything easier to maintain.
I maintain a separate part (different from KDE) of the tree and I simply
just avoid doing "cd kde-*" when I'm doing stuff in the tree (I simply
just forget it is there) :-)
In the rare case that my actions require that I actually look at kde
stuff, then it would be a pain in the ass if I had to get it from
somewhere else, and not have it right at hand.

The above of course only holds if the tree is structured in a good way,
which I think it is (to a large degree, one can always find special cases).

And an argument along the lines of "the tree is too large to download"
does not apply either. If one cannot sync the tree over his/hers
internet connection, then one can clearly not download gcc either :-)


Martin R. Ehmsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE4wQloCiIG96jYfYRAh4iAKDVA9HYS1oSDj8hgvH9kvQBMbBbpACdFIAH
2ypo9/R5xGLzC6D1dIMjM4Q=
=ROAN
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage Subtrees [WAS: Sunrise contemplations]

[Enrico Weigelt]

* Martin Rud Ehmsen <ehmsen@gentoo.org> schrieb:

Hi,

> I don't see how this is going to make anything easier to maintain.

Well, it's not the overlay, but the clean subtree'ing what does
the trick. If you look at the whole dependency graph, this subtree
is an really independent part, just if it was an big-fat package.
No one outside the subtree (or at least from the main tree) will 
ever depend on it. That's the primary condition.

<snip>

> I maintain a separate part (different from KDE) of the tree and I simply
> just avoid doing "cd kde-*" when I'm doing stuff in the tree (I simply
> just forget it is there) :-)
> In the rare case that my actions require that I actually look at kde
> stuff, then it would be a pain in the ass if I had to get it from
> somewhere else, and not have it right at hand.

In which cases do you have to look at KDE stuff ?
Would you say, your part is actually an subtree (upon my definition) ?

<snip>

> And an argument along the lines of "the tree is too large to download"
> does not apply either. If one cannot sync the tree over his/hers
> internet connection, then one can clearly not download gcc either :-)

The tree is really huge today. And it seems to grow each day.
Each sync requires a lot of resources (traffic is minimal w/ rsync,
but costing server and client load). And the tree requires a lot of 
space on the system. For example, I've got an notebook w/ an small
HDD (which is partially consumed by an win32 laying around ...).
On this box I already ran into serious space trouble - syncing the
whole tree (while requiring just a few packages) and building larger
stuff, failed due out of space. Okay, I simply could cut off some
dirs (via rsync ignore option), but this implies quite some danger
that I miss something I need. With clean subtree'ing, those things
would be clear.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage Subtrees [WAS: Sunrise contemplations]

[Martin Rud Ehmsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrico Weigelt wrote:
> * Martin Rud Ehmsen <ehmsen@gentoo.org> schrieb:
>> I don't see how this is going to make anything easier to maintain.
> 
> Well, it's not the overlay, but the clean subtree'ing what does
> the trick. If you look at the whole dependency graph, this subtree
> is an really independent part, just if it was an big-fat package.
> No one outside the subtree (or at least from the main tree) will 
> ever depend on it. That's the primary condition.

That has nothing to do with my statement that it does not make anything
easier to maintain. Your statement is that it does, please prove that.
(btw. with your definition of a substree you either end up with the
whole tree or require to duplicate something).

> In which cases do you have to look at KDE stuff ?

As I said, in rare case. But trust me I have to do it from time to time.

> Would you say, your part is actually an subtree (upon my definition) ?

Probably not and I don't care. As soon as you have proved that your
thing works and that it does make things easier, then I'll care. :-)

> stuff, failed due out of space. Okay, I simply could cut off some
> dirs (via rsync ignore option), but this implies quite some danger
> that I miss something I need.

And in that lies the problem with any approach that tries to cut things
from the tree (you can cut leafs from the graph, but they clearly have
nothing in common... in most cases).

Martin R. Ehmsen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE44YHoCiIG96jYfYRAh+HAJ94npitjR8HzAsAamxotW/opzJkNwCglS/l
5NvEo3WI9Mu5VbnP/kQAdxU=
=MMdI
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Portage Subtrees [WAS: Sunrise contemplations]

[Alec Warner]

> hmm, I'm just thinking about splitting the tree into separate
> (larger) parts, actually: move out certain subtrees to an overlay.
> 
> For example: KDE. 
> Many people/systems won't ever use it (ie. have no X at all).
> Others are very interested in it.
> 
> If we had this whole subtree in an overlay, it would make the main 
> tree much, much smaller, so easier to maintain and save load from 
> the mirrors.
> 
> But this only works good, if its actually an *subtree*, and *not* 
> overriding any packages from the main tree. Otherwise we soon get 
> ugly conflicts and evrything goes to hell.

There are developers that are interested in this; however I don't think 
it's a place that the majority of Gentoo is willing to go to (as those 
developers have already noted ;) ).
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Enrico Weigelt]

* Tobias Klausmann <klausman@schwarzvogel.de> schrieb:

<snip>

> People who use Sunrise as an overlay and then come whining to bgo
> about their failed ebuild can be told. 

ACK. Sunrise and main Gentoo should have strictly separate 
Bugzillas (or at least separate products).

BTW: my suggested bug reporting tool could take the right one
automatically.

<snip>

> Idea: should it be more obvious in emerge --info and ebuild
> failure that an overlay is involved? 

IMHO, Yes. It should print out the URLs or names of all overlays
this package (or its deepter dependencies) are affected by.

BTW: is this information also recorded in /var/db/pkg ?


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
---------------------------------------------------------------------
 Please visit the OpenSource QM Taskforce:
 	http://wiki.metux.de/public/OpenSource_QM_Taskforce
 Patches / Fixes for a lot dozens of packages in dozens of versions:
	http://patches.metux.de/
---------------------------------------------------------------------
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 8456 bytes --]

On Mon, 31 Jul 2006 19:25:20 +0200
foser <foser@gentoo.org> wrote:

> [...]
> 1. Stale ebuilds are often stale for a reason, there is obviously not
> enough interest to add and maintain them. Not just on the developer
> side, but also on the user side. If someone really cared enough
> he/she would go trough the process of becoming a dev.

I think most users would see becoming a dev as a long-term commitment.
We certainly want that to be the case - we don't want people becoming a
dev just to bump a package that they want in a particular moment just
to then disappear.

The situation for such stale ebuilds is that there may be no active
devs who are interested - even if there are many users who are.

Sunrise does provide a place where users can work with the Sunrise
project to get what they want into the overlay, perhaps ultimately
into the tree. These users can contribute for the period they want to,
then forget about it, leaving it to the Sunrise developers follow it
up.  Such follow-up could be:

1) Maintain the ebuild in the sunrise overlay
2) Take the package on themselves, and integrate it into the main tree
3) Find another dev willing to take the package on (e.g. by asking the
herd alias), hand it over for maintenance in the main tree.
4) Drop it.

Sunrise can also help gauge how much user interest there is in a
package.

> [...]
> Sunrise just lowers the step to get these often mediocre ebuilds,
> people can get them right now, just not as easy.

I hope the intention is that Sunrise would be improving these mediocre
ebuilds to the point where they would be acceptable in the tree, as
far as technical quality is concerned.

> 2. [...] Therefore I do not believe that QA for a tree that is as
> extensive as Sunrise done by a few 'official' developers amounts to
> much real world quality.

I would expect that over time, the Sunrise developers will learn more
and more how to write quality ebuilds (as hopefully do we all).  Since
they'll be working with a diverse set of stuff, they could become better
than most devs at this.  Remember that since they have custody of the
stuff in the Sunrise overlay, they will be hit with whatever issues
arise from their work.

> 3. Although I agree Sunrise may lower the step to becoming a dev, I
> doubt it will have a serious positive impact on our developer base
> and as such there is no reason to support Sunrise officially. I think
> the people attracted to Sunrise development are the ones that fall in
> the category 'want to be there, but don't really have the
> time/skills'.

That would certainly be true for many.  There may also be people who
would be happier with the proving ground that Sunrise provides,
gaining confidence before attempting to become a dev.

> Those people will not evolve to real developers; they
> either will stick it out in Sunrise for a short while or keep to a
> very small subset of it. My prediction is that Sunrise will see a
> high turnover of 'developers', either because they are there for one
> specific package (probably fresh and included in the main tree when
> mature) or find out they lack the time to really invest in learning
> the full extent of ebuilding. Also 'junior' devs on Sunrise might not
> take that extra step towards devhood because they got the influence
> they want, as such we might lose out on devs that never develop
> beyond Sunrise contributors.

I'd be wary of encouraging people who don't want to go further than
bunging something into Sunrise becoming devs.  If they're not prepared
to maintain their stuff in Sunrise, then they don't really want to be a
dev (which is largely about maintenance).

> As a developer I would not really think
> of Sunrise developers any different than someone coming 'fresh' to
> Gentoo developing.

What it does give you is a track record you can look through - in much
the same way you might have watched what someone did on bugzilla or
IRC.  Indeed I'd suggest that the history in Sunrise SVN would be
useful to indicate whether someone is learning how to write ebuilds
properly, or just continues to make the same errors.

> I would still require them to work on real bugs
> for a good while to see their intentions/devotion over time before I
> would even consider submitting them for real developership. In that
> sense Sunrise would only lengthen the time a wannabe dev has to spend
> in the no-mans land between active user and official developer.

I don't think anyone is suggesting that all future devs prove
themselves in Sunrise first, so I don't see that it lengthens the
time a wannabe dev has to spend, since they can always take the
approach we currently use and avoid Sunrise altogether.

I expect Sunrise would hope that contributors hang around to do their
own maintenance in the Sunrise overlay, in which case they'll get to
understand what maintenance means, how much effort is involved and
thereby understand better the commitment expected of them should they
decide to go for dev-ship.

> In conclusion these 3 points come together here : being a dev is not
> about adding new ebuilds to the tree, it is about maintaining what is
> already there. Dealing with bugs and users.

100% with you there.  Anyone can knock up an ebuild - it takes effort
to maintain it, and that's the lions share of the work of most devs.

> That aspect of Sunrise is
> not at all tackled in its goals. What are the longterm prospects of
> ebuilds in the Sunrise tree ?

Is this not in their documentation?  From the project name, I would
expect they hope that stuff either rises fully (i.e. to end up in
the tree with proper maintainership) or would wither and die depending
on how much effort is put in by those who want the package.

> That is what QA is about, providing a
> stable base to work on. I do not think that devs who mainly add
> ebuilds and new packages to the tree are good devs, the real job is
> maintenance and bughandling. In that sense Sunrise might be giving
> the wrong impression to wannabe devs.
> 
> * The rise of project Sunrise
> 
> Now for the second big point concerning Sunrise : how it came into
> being.

This was certainly handled very badly.  However I think that's history
now, and there's not much to be gained from going back over it.

> [...]
> Anyway, the project after the initial announcement got a 'temporarily
> removed' status from gentoo.org . The problem here in my opinion is
> not so much that the people who support the project needed to defend
> it, but that people who are more conscious about the project need to
> prove it is wrong. This had to happen in a mere 2 months where the
> project has had hardly any impact. If you want to properly evaluate
> such an extensive project it needs to be given much more time. The
> project should prove itself before it should be allowed to 'join'
> Gentoo, not the other way around. I have seen no tangible benefits
> from Sunrise so far, aside from the fact that developers have left
> over it and the developer community is seriously divided these days.
> As such Sunrise has been one big mistake, the possible benefits at
> this point in time do not outweigh the havoc it has caused.

Beyond the mailing list wars (I won't call them flamewars because I
think most combatants are sincere with their concerns), I don't think
there has been any significant detrimental effect - for the same
reason; i.e. it's only been around for a couple of months so hasn't had
time to produce any of the problems that some people are worried will
occur.

> * The implications of sunrise
> 
> What will Sunrise mean to the general developer ?
> [...]
> In short, from my experience Sunrise will only result in more work for
> the general developer with little benefits. This may not happen often,
> but every single time is one time too much. This is can be really
> demotivating, which is probably the worst thing about it.

I think as long as Sunrise steers clear of core system packages,
essentially focusing on "leaf" packages, the sorts of problem you
encountered with BMG can be avoided.  Certainly I would expect Sunrise
not to be providing alternate versions of stuff already in the tree,
and not to be modifying eclasses that exist in the tree - this sort of
change is for managed dev overlays.

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Sunrise contemplations

[foser]

On Tue, 2006-08-01 at 16:05 +0200, Kevin F. Quinn wrote:
> > 2. [...] Therefore I do not believe that QA for a tree that is as
> > extensive as Sunrise done by a few 'official' developers amounts to
> > much real world quality.
> 
> I would expect that over time, the Sunrise developers will learn more
> and more how to write quality ebuilds (as hopefully do we all).  Since
> they'll be working with a diverse set of stuff, they could become better
> than most devs at this.  Remember that since they have custody of the
> stuff in the Sunrise overlay, they will be hit with whatever issues
> arise from their work.

I expect the developers involved to be able to write quality ebuilds
right now, otherwise they shouldn't be developers. However, I don't
expect them to write quality ebuilds for everything in the tree, there
are a lot of packages that need specific knowledge to make a correct
ebuild. That is why we got the herd system, that is why we have a couple
of hundred ebuilders who all have their own specific parts of the tree
to take care of.

> What it does give you is a track record you can look through - in much
> the same way you might have watched what someone did on bugzilla or
> IRC.  Indeed I'd suggest that the history in Sunrise SVN would be
> useful to indicate whether someone is learning how to write ebuilds
> properly, or just continues to make the same errors.

Ebuilding is such a small part of the job I wouldn't seriously take it
into account, to me much more important is the bughandling skills of a
potential developer. Is he/she able to distill the right information
from a report, ask for the right additional info and come to a practical
and neat solution ?

- Marinus

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Thierry Carrez]

foser wrote:

> I checked back on the initial announcement, where it Sunrise was made
> public as an official Gentoo project without any prior discussion. The
> announcement actually stated 'This is an announcement - No flamewars
> allowed'. I guess the creators were already aware of the feelings of
> some other developers on this issue and decided to just go ahead instead
> of going through the proper channels (GLEP?) and do things as they
> wished. As we all know this can be very effective, but this particular
> time one of the largest and longest ongoing 'discussions' in Gentoo's
> history ensued.
> If you know it's flamewar material, why do you go ahead
> so bluntly with your project ? Why not go trough the proper channels and
> discuss it beforehand in a public place ?

That's just the way to do it.

Excerpt from the metastructure model, chosen by the majority of devs
last year (and not my model):

http://www.gentoo.org/proj/en/glep/glep-0039.html
=================================================
A project is a group of developers working towards a goal (or a set of
goals).

* A project exists if it has a web page at www.g.o/proj/en/whatever that
is maintained. ("Maintained" means that the information on the page is
factually correct and not out-of-date.) If the webpage isn't maintained,
it is presumed dead.

* It may have one or many leads, and the leads are selected by the
members of the project. This selection must occur at least once every 12
months, and may occur at any time.

* It may have zero or more sub-projects. Sub-projects are just projects
that provide some additional structure, and their web pages are in the
project's space.

* Not everything (or everyone) needs a project.

* Projects need not be long-term.

* Projects may well conflict with other projects. That's okay.

* Any dev may create a new project just by creating a new page (or, more
realistically, directory and page) in gentoo/xml/htdocs/proj/en.
=================================================

So you can create projects by creating a directory in
gentoo/xml/htdocs/proj/en, you don't have to announce it (but it's
polite to do so), and it may well conflict with other projects, that's okay.

You can't blame them for following the right rule. You can blame the
rule, though.

-- 
Koon
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Ciaran McCreesh]

On Wed, 02 Aug 2006 12:00:56 +0200 Thierry Carrez <koon@gentoo.org>
wrote:
| So you can create projects by creating a directory in
| gentoo/xml/htdocs/proj/en, you don't have to announce it (but it's
| polite to do so), and it may well conflict with other projects,
| that's okay.
| 
| You can't blame them for following the right rule. You can blame the
| rule, though.

You're forgetting the other rule about GLEPs being required for changes
that impact lots of people...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Ciaran McCreesh]

On Wed, 02 Aug 2006 07:07:31 -0700 Donnie Berkholz
<dberkholz@gentoo.org> wrote:
| One could argue that since the metastructure policy was approved more 
| recently, anything in it that contradicts previous rules takes 
| precedence. "Freedom to make new projects anytime" beats "must use
| GLEP for significant new feature."

The metastructure policy doesn't override anything it doesn't
explicitly say it overrides...

-- 
Ciaran McCreesh
Mail            : ciaran dot mccreesh at blueyonder.co.uk


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Sunrise contemplations

[Wernfried Haas]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

On Wed, Aug 02, 2006 at 03:55:44PM +0100, Ciaran McCreesh wrote:
> On Wed, 02 Aug 2006 07:07:31 -0700 Donnie Berkholz
> <dberkholz@gentoo.org> wrote:
> | One could argue that since the metastructure policy was approved more 
> | recently, anything in it that contradicts previous rules takes 
> | precedence. "Freedom to make new projects anytime" beats "must use
> | GLEP for significant new feature."
> 
> The metastructure policy doesn't override anything it doesn't
> explicitly say it overrides...

I guess this project may be a grey area considering if a GLEP is
neccessary or not, but then the decision was made by the council based
on the input of the developer community, which seems to be pretty
close to the GLEP process. Not everything can and will ever be covered
by some policy. There already are some examples where making up
policies to cover up single incidents went terribly wrong anyway.

cheers,
	Wernfried

-- 
Wernfried Haas (amne) - amne at gentoo dot org
Gentoo Forums: http://forums.gentoo.org
IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org

[-- Attachment #2: Type: application/pgp-signature, Size: 191 bytes --]

[gentoo-dev] metastructure model (was Re: Sunrise contemplations)

[Kevin F. Quinn]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On Wed, 02 Aug 2006 12:00:56 +0200
Thierry Carrez <koon@gentoo.org> wrote:

> Excerpt from the metastructure model, chosen by the majority of devs
> last year (and not my model):
> [...]
> * It may have one or many leads, and the leads are selected by the
> members of the project. This selection must occur at least once every
> 12 months, and may occur at any time.
> [...]

While we're on the subject of the metastructure model, could we
consider changing this rule?  It's a little strict, and I suspect it's
honoured more in the breach than otherwise (by which I mean some,
perhaps many, projects don't bother to hold a selection process every 12
months). The 12 month rule makes perfect sense for the council and
foundation trustees but it's over the top as a rule for all
projects.

I would suggest something along the lines of, "selection of
leadership of a project can occur at any time, but can be forced should
a majority of the team feel a new selection is necessary", perhaps
with a rider allowing projects to setup stricter rules if they feel the
need.  I'm assuming (since I haven't checked) that project membership
requires agreement of the project (i.e. people can't just join a
project without the existing project members' agreement).

The idea being that if the current leadership want to step down they
can do so and selection occurs within the project by default.  At the
other extreme, if a lead becomes a pita for everyone else on the
project, the rest of the project can oust the lead by majority
decision (hopefully a rare occurrence).

-- 
Kevin F. Quinn

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] metastructure model (was Re: Sunrise contemplations)

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 2110 bytes --]

Kevin F. Quinn wrote:
> On Wed, 02 Aug 2006 12:00:56 +0200
> Thierry Carrez <koon@gentoo.org> wrote:
> 
>> Excerpt from the metastructure model, chosen by the majority of devs
>> last year (and not my model):
>> [...]
>> * It may have one or many leads, and the leads are selected by the
>> members of the project. This selection must occur at least once every
>> 12 months, and may occur at any time.
>> [...]
> 
> While we're on the subject of the metastructure model, could we
> consider changing this rule?  It's a little strict, and I suspect it's
> honoured more in the breach than otherwise (by which I mean some,
> perhaps many, projects don't bother to hold a selection process every 12
> months). The 12 month rule makes perfect sense for the council and
> foundation trustees but it's over the top as a rule for all
> projects.
> 
> I would suggest something along the lines of, "selection of
> leadership of a project can occur at any time, but can be forced should
> a majority of the team feel a new selection is necessary", perhaps
> with a rider allowing projects to setup stricter rules if they feel the
> need.  I'm assuming (since I haven't checked) that project membership
> requires agreement of the project (i.e. people can't just join a
> project without the existing project members' agreement).
> 
> The idea being that if the current leadership want to step down they
> can do so and selection occurs within the project by default.  At the
> other extreme, if a lead becomes a pita for everyone else on the
> project, the rest of the project can oust the lead by majority
> decision (hopefully a rare occurrence).

One nice thing about the 12-month model is that it's harder to get on
bad terms with a lead that you'd rather wasn't the lead anymore. It's
less of a feeling of conspiring to oust them and more of a feeling of
"Well, they didn't win the election this time around."

However, it's easy to avoid the election if nobody else accepts a
nomination, as happened in the desktop project. That saves all the hassle.

Thanks,
Donnie


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-dev] Sunrise contemplations

[foser]

On Wed, 2006-08-02 at 12:00 +0200, Thierry Carrez wrote:
> So you can create projects by creating a directory in
> gentoo/xml/htdocs/proj/en, you don't have to announce it (but it's
> polite to do so), and it may well conflict with other projects, that's okay.
> 
> You can't blame them for following the right rule. You can blame the
> rule, though.

I deliberately added '(GLEP?)' with question mark because I know
projects in general do not fit the GLEP structure. However, in this case
the project has potentially the kind of impact on the tree and other
developers that discussing it beforehand would've been the right thing
to do. The way the announcement was written makes me think the
developers involved in the project were well aware of this.
It seems to me creating a project is now officially a loophole to do as
you please under the umbrella of Gentoo.

- Marinus

-- 
gentoo-dev@gentoo.org mailing list