public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Unstable branch proposal - second round
@ 2002-03-16 19:46 George Shapovalov
  2002-03-16 20:59 ` George Shapovalov
  2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
  0 siblings, 2 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-16 19:46 UTC (permalink / raw
  To: Gentoo Dev

Hi All.

I just looked again through the recent thread and here are some thoughts I 
would like to throw out.
The thread did not see that much of activity and I thought that timing was 
not right - during the feature freeze right before 1.0 release. Then I gave 
it a second thought and here are a few things I would like to bring here. I 
will try to summarise the previous discussion and then propose some stuff 
which if accepted will require a minor addition to existing functionality and 
may even go in the tree before release (or to 1.x version).

Now to the issue.
Technically I would not call the proposed  an "unstable branch". The core 
which is a portage system and supporting infrastructure is going to stay the 
same, there has been no call to fork that as far as I can tell (and I am not 
about to do that either). The call was for producing new ebuild submission 
system.
At present gentoo definitely allows submission of new ebuilds - you just have 
to go to bugs.gentoo.org and submit an ebuild as described in manual, then it 
gets reviewed by core developer and goes into /usr/portage/incoming/ and 
later gets incorporated into the portage tree. 
While a very sound submission protocol it is not very scalable if  ebuild 
submissions are expected to grow significantly. In such case a decentralised 
submission/review schema is desired.

One proposed way of doing this was to setup a self-managed "mirror", which 
should accept all packages from developers but keep them local. New 
submissions will get reviewed by community and later manually incorporated 
into the main tree by core developers. 
While this allows better exposure of new submissions it does not prevent the 
bottleneck - core developers will be just as occupied. Than self-managed 
sound like a way to start a big mess unless somebody is going to spend a lot 
of time actively maintaining thing, compiling lists of a "worthy", "confirmed 
by majority", etc.. ebuilds. And actively pushing them to the core group. 
Also having to worry about separate system incarnation looks like a 
possibility to start a fork where you might avoid doing so. After all these 
systems will have different requirements.

Another possibility is to use the same infrastructure, but add new 
specificator to the package name, which will mark it as "unstable". Allow 
unstable ebuilds to appear in the main tree but these will be installed (and 
reported) only if you use special flag (for example --allow-unstable) with 
emerge (ebuild as a low-level utility I guess should just do whatever you ask 
it to). After all this is similar to what people do now with not yet 
incorporated ebuilds.
Users of unstable ebuilds can and are requested to report on 
usability/stability of an ebuild by setting some flag in the package dir or 
somewhere in the database, which should be counted when user rsyncs again. 
Certain policy can be set, so that for example packages accumulating enough 
voices should automatically be granted for example "confirmed" status. There 
might be additional layer of (even manual) check through which the package 
should go to get "approved" status (and the removal of specificator form 
ebuild name).
I am apparently thinking in favour of this one as it seems things can be 
setup more cleanly this way (avoiding any reason for possible forking) while 
allowing everybody to have easier access to all functionality. Users can  
choose to stick with "approved" packages if stability is of most concern, 
"confirmed" if some more functionality is desired or even "unstable" to 
access all packages (and of course anybody anytime can force-install any 
package). To provide this functionality emerge can check make.conf for 
-allow-status flag for example. The tree can even be synchronised on user 
machine according to set stability level.
The main benefit of setting up something along these lines is that newly 
submitted ebuilds get much broader attention. Especially recalling numerous 
calls for setting up the list of new ebuild submissions so that newcomers can 
start to actively contribute to the system, while allowing "core" people to 
concentrate on essential stuff.

George


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-03-16 19:46 [gentoo-dev] Unstable branch proposal - second round George Shapovalov
@ 2002-03-16 20:59 ` George Shapovalov
  2002-03-17  0:52   ` [gentoo-dev] multiple pkg state levels, was: Unstable branch proposal George Shapovalov
  2002-04-16 21:29   ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
  2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
  1 sibling, 2 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-16 20:59 UTC (permalink / raw
  To: gentoo-dev

Hi again

I would like to somewhat clarify my previous submission. 
So the new ebuild submission and processing procedure can be as follows:

1. new ebuild gets submitted through bugs.gentoo.org as it is now (no change)
change starts:
2. it immediately gets incorporated into the main portage tree with the 
"unstable" status (robot).
3. ebuild voting statistics are kept on bugs.gentoo.org, attached to ebuild 
submission topic. Voters have to be registered with bugs.gentoo.org as they 
are now.
4. When ebuild accumulates enough unique votes is gets "confirmed" status
Meanwhile updates and patches to ebuild are submitted as usual but whoever 
cares to correct/update it via existing mechanism.
5. if ebuild reaches second threshold of "approval wanted" votes or is of 
special interest for core group it gets reviewed and manually assigned 
"approved" status and is maintained by the core group. 
Or there can be additional layer, where ebuild just gets an approval and then 
when it gets core maintaince it gets "core" status.

Comments
It can seem like a lot of new activity for bugs.gentoo.org. However half of 
that functionality is already implemented and activity is taking place. The 
other half is happening and requires manual interaction. Ebiuld submissions 
are soaring so that some rework of bugs.gentoo.org will probably be necessary 
anyway. This looks like a way to simplify life fore core developers and 
everybody else. (When ebuilds start to be posted to mailing list instead of 
accepted procedure is the time to start thinking about the procedure I think).


George



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-04-16 21:29   ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
@ 2002-03-16 22:09     ` Brent Cook
  2002-03-17  0:26       ` Daniel Mettler
  2002-04-16 22:08       ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
  2002-03-19 13:05     ` [gentoo-dev] Usb mouse issues with 2.4.17-r5 Michael M Nazaroff
  1 sibling, 2 replies; 25+ messages in thread
From: Brent Cook @ 2002-03-16 22:09 UTC (permalink / raw
  To: gentoo-dev

> The beauty of this?  Those familiar with Freshmeat barely have to learn a
> new interface and the whole Freshmeat site has *got* to be open source
> available somewhere to make this a fast start towards this sort of vision.
>

Do you essentially mean http://www.freshports.org/ with comments?



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-03-16 22:09     ` Brent Cook
@ 2002-03-17  0:26       ` Daniel Mettler
  2002-04-17  0:33         ` Michael Lang
  2002-04-16 22:08       ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
  1 sibling, 1 reply; 25+ messages in thread
From: Daniel Mettler @ 2002-03-17  0:26 UTC (permalink / raw
  To: gentoo-dev

On Saturday 16 March 2002 23:09, Brent Cook wrote:
> Do you essentially mean http://www.freshports.org/ with
> comments?

that's cool, but imho there should be some way to leverage 
bugs.gentoo.org by integrating both. i think it would be an 
overkill having a separate "ebuild repository", it should rather 
be kept central.

probably a simple link like

http://bugs.gentoo.org/buglist.cgi?component=Ebuilds

(add your date constraints)

would be sufficient if we just agreed on a standardized way how 
ebuild submissions (and error reports) have to be made. this 
could be done by "forcing" a formatted summary field. e.g. for 
ebuild submissions:

${P} ${DESCRIPTION}

this would be suitable for most users (as gentoo mainly targets 
developers/professionals and as the ebuild names are usually 
self-explanatory). disclaimer: i do not know whether forcing 
field formats is possible with bugzilla. a voting feature 
would be nice too.

rgds

dan

-- 
      ...::: Daniel Mettler | http://www.numlock.ch :::....



^ permalink raw reply	[flat|nested] 25+ messages in thread

* [gentoo-dev] multiple pkg state levels, was: Unstable branch proposal
  2002-03-16 20:59 ` George Shapovalov
@ 2002-03-17  0:52   ` George Shapovalov
  2002-04-16 21:29   ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
  1 sibling, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-17  0:52 UTC (permalink / raw
  To: gentoo-dev

Hi All again!

Further refinement.

Proposed package state levels:
1. "new" - new package submitted, no peer review yet.
2. "unstable" - package got over the threshold of negative votes
3. "confirmed" - positive votes threshold reached
4.  "approved" - package was checked and approved by core group (after being 
confirmed)
5. "core" - package is maintained via core group (all patches must go through 
them).  Portage and supporting packages come to mind for example.
"core-new" may be usefull, see below.

It might be desirable to have "new-version" level, specifically for new 
ebuild versions, they might need special processing. However right now I 
cannot come up with the reasons why just marking them as "new" won't work.

As specified above these pkg-state levels may be treated  as new 
"minor-minor" number after ebuild revision number. It makes sense to 
incorporate this into ebuild name right before .ebuild part.

In this way the package flow is as follows: new ebuild gets a "new" status 
until it gets enough peer-review and is considered "confirmed" and may be 
later even "stable". In this way many distribution stability levels are 
possible from more_strict_then_debian_stable to 
more_extreme_then_Mandrake_beta_or_RH_x.0.
You are also not forced to believe just anybody. It may be usefull to assign 
"new" status even to the new "core" ebuilds (well, probably "core-new" will 
be better), which upon confirmation would get "core" status directly (they 
have been reviewed already). Thus you are getting not only level 
assumed_to_be_stable_because_I_personally_tested_it_on_whatever_was_available 
but you can also have level 
extensively_tested_by_many_people_on_many_architectures_to_be_stable.

In addition I want to note, that gentoo is a true meta-distribution, so it 
might be desirable to create more categories along these lines to represent 
this. For example there might be "secure-core" level treated analogously to 
"core" with different core group responsible for it. 

It will also allow to solve such situation as there is with new kernel for 
example. Now it has to be masked out, so that 2.4.17-r5 is used by default. 
This does not look elegant and is just plain wrong on a large scale. There is 
nothing right-out wrong with new kernel. It is not as efficient as an old 
one, but it contains some new features which some people might want to use 
(not that much for this one, but there were such situations quite a few times 
with kernel versions).  It would be better for it get out in the open and end 
up in "unstable" with the comment attached or even some special category for 
example "ambiguous" :-).

Some reflection.
Having thought about this issue for some time I start considering this to be 
the next necessary step for gentoo as it gains momentum. 
Few important things for distribution are:
1. good scalable core - fine here.
2. appropriate (and competent in some circumstances) user base - excellent 
here.
3. ease of participation in development via bug reports/submissions - good 
here.
4. easy access for EVERYBODY to new submissions for peer review - not good 
here. And this is the issue I try to bring up with this proposal. 

Key point here is pushing as much responsibility down the chain as possible. 
Many people will be willing to live with "confirmed" level thus reviewing new 
submissions and speeding up ebuild handling process. 
Present situation with gentoo ebuilds somewhat mirrors kernel 
patch-submission situation. Linus is crying out to make people to assume as 
much responsibility down the chain as possible and not try to push ALL 
patches through him directly. (I am not referencing his switch to BitKeeper, 
this is just a technical thing which will increase his personal throughput 
approx 2x, while 10x larger throughput is necessary for the whole arbitration 
and 100x is desirable if kernel is to continue to grow as it does now).

Ok, It's been a few long submissions today, so I will just shut up now and 
try to limit myself to listening and answering questions only :-).


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-04-16 22:08       ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
@ 2002-03-17  1:04         ` George Shapovalov
  0 siblings, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-17  1:04 UTC (permalink / raw
  To: gentoo-dev

Well, the main idea I try to put up here is to expose new ebuilds as much as 
possible by pushing ALL submissions to the portage tree for people who want 
to see what's up on the table, while maintaining only the stable core access 
for people who only need thoroughly tested stuff. 
If something can be easily setup to simplify ebuild submission process this 
is fine and in fact does not change much the idea. bugs.gentoo.org is pretty 
simple IMHO, and majority of users are developers, while as far as I can tell 
linux newcomers are not uncommon to gentoo either.
Please see my new post for clarification. In short I feel that it is 
necessary to introduce multiple ebuild-state levels to better represent the 
"real-world life of a package", which will also help end-users to follow the 
stock and contribute to what he feels necessary even just voting for package 
he wants to see.

George

On Tuesday 16 April 2002 15:08, you wrote:
> Yeah, pretty much.  However, Freshports looks more developer centrix than
> end-user
> centric as Freshmeat appears to me.
>
> I think it is important to keep the end user who's going to be trying to
> make intelligent decisions about which ebuilds to download as your central
> audience.
>
> At 04:09 PM 3/16/2002 -0600, you wrote:
> > > The beauty of this?  Those familiar with Freshmeat barely have to learn
> > > a new interface and the whole Freshmeat site has *got* to be open
> > > source available somewhere to make this a fast start towards this sort
> > > of vision.
> >
> >Do you essentially mean http://www.freshports.org/ with comments?
> >
> >_______________________________________________
> >gentoo-dev mailing list
> >gentoo-dev@gentoo.org
> >http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
> President
> www.cybrains.net
>
> "All things should be as simple as possible, but no simpler" -- Albert
> Einstein
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-04-17  0:33         ` Michael Lang
@ 2002-03-17  1:13           ` George Shapovalov
  2002-03-17 19:53           ` [gentoo-dev] separate catalog for my ebuilds Giulio Eulisse
  1 sibling, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-17  1:13 UTC (permalink / raw
  To: gentoo-dev

Got this message after I answered previous :-).
It looks like the proposal will address the issue you are concerned with. If 
user selects to see unstable (confirmed or even all) packages he will 
download all these ebuild on the next rsync and then will be able to use 
gentool or gentoolkit on local copy!

George

On Tuesday 16 April 2002 17:33, you wrote:
> hmmm...I never intended to imply that the ebuild repository and bugs
> wouldn't be integrated....only that the avg joe downloader wouldn't be
> forced to learn a developer tool and that the ebuild repository would
> automatically push issues into the bugs database.
>
> To take this step up another notch, when bugs are fixed for a particular
> package, the issues surrounding the bug are suppressed to just a link
> called "past bugs" but when a bug is actively open, then the issues for
> that bug are displayed prominently for the end user so he can quickly
> determine if the package is going to meet his needs.
>
> This is something that would be most important to me as a new Linux
> user...I'm trying to find
> good quality packages and I know little about their background, but if I
> can read comments about them and see that there are bug issues at the
> moment, I can choose to move on to another package or attempt to work
> around the known bug issues.
>
> Michael
>
> At 01:26 AM 3/17/2002 +0100, you wrote:
> >On Saturday 16 March 2002 23:09, Brent Cook wrote:
> > > Do you essentially mean http://www.freshports.org/ with
> > > comments?
> >
> >that's cool, but imho there should be some way to leverage
> >bugs.gentoo.org by integrating both. i think it would be an
> >overkill having a separate "ebuild repository", it should rather
> >be kept central.
> >
> >probably a simple link like
> >
> >http://bugs.gentoo.org/buglist.cgi?component=Ebuilds
> >
> >(add your date constraints)
> >
> >would be sufficient if we just agreed on a standardized way how
> >ebuild submissions (and error reports) have to be made. this
> >could be done by "forcing" a formatted summary field. e.g. for
> >ebuild submissions:
> >
> >${P} ${DESCRIPTION}
> >
> >this would be suitable for most users (as gentoo mainly targets
> >developers/professionals and as the ebuild names are usually
> >self-explanatory). disclaimer: i do not know whether forcing
> >field formats is possible with bugzilla. a voting feature
> >would be nice too.
> >
> >rgds
> >
> >dan
> >
> >--
> >       ...::: Daniel Mettler | http://www.numlock.ch :::....
> >
> >_______________________________________________
> >gentoo-dev mailing list
> >gentoo-dev@gentoo.org
> >http://lists.gentoo.org/mailman/listinfo/gentoo-dev
>
> President
> www.cybrains.net
>
> "All things should be as simple as possible, but no simpler" -- Albert
> Einstein
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev


^ permalink raw reply	[flat|nested] 25+ messages in thread

* [gentoo-dev] separate catalog for my ebuilds...
  2002-04-17  0:33         ` Michael Lang
  2002-03-17  1:13           ` George Shapovalov
@ 2002-03-17 19:53           ` Giulio Eulisse
  2002-03-17 21:40             ` Chad M. Huneycutt
  1 sibling, 1 reply; 25+ messages in thread
From: Giulio Eulisse @ 2002-03-17 19:53 UTC (permalink / raw
  To: gentoo-dev

I'd like to keep my ebuilds under one single,separated, catalog
directory, as they are still in development. I created a "mycat" dir in
/usr/portage and added it to the known catalogs, but I keep having all
my ebuilds masked out. 
 
-- 
Ciao,
Giulio



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] separate catalog for my ebuilds...
  2002-03-17 19:53           ` [gentoo-dev] separate catalog for my ebuilds Giulio Eulisse
@ 2002-03-17 21:40             ` Chad M. Huneycutt
  0 siblings, 0 replies; 25+ messages in thread
From: Chad M. Huneycutt @ 2002-03-17 21:40 UTC (permalink / raw
  To: gentoo-dev

Giulio Eulisse wrote:
> I'd like to keep my ebuilds under one single,separated, catalog
> directory, as they are still in development. I created a "mycat" dir in
> /usr/portage and added it to the known catalogs, but I keep having all
> my ebuilds masked out. 

Portage keeps an internal list of categories, so you would need to update 
that in order for it to see your new category.  The file to edit is 
/usr/lib/portage/pym/portage.py . Search for categories and add yours there.

-- 
Chad Huneycutt                                try { Windows }
Ph.D. Student                                 catch ( Exception BSOD )
Georgia Tech College of Computing               { linux };
http://www.cc.gatech.edu/~chadh



^ permalink raw reply	[flat|nested] 25+ messages in thread

* [gentoo-dev] Usb mouse issues with 2.4.17-r5
  2002-04-16 21:29   ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
  2002-03-16 22:09     ` Brent Cook
@ 2002-03-19 13:05     ` Michael M Nazaroff
  2002-03-20  8:11       ` Stefan Jones
  1 sibling, 1 reply; 25+ messages in thread
From: Michael M Nazaroff @ 2002-03-19 13:05 UTC (permalink / raw
  To: gentoo-dev

I seem to be having troubles with the 2.4.17-r5 kernel.  It works fine
except my usbmouse doesn't work under it..  It times out, I did try to
enable Long timeout for slow responding devices but that didn't help.  I
tried having the drivers in the kernel and as modules.  I also
considered that maybe I had missed configured the kernel and went ahead
and copied .config from linux-2.4.17-r3 (where my mouse worked perfect).
I tried it that way with still no luck, anyways it was detecting it, but
was just timeing out.. but I figured that I should try all options
avalible just in case.=o) I also had the chance to try this on friends
computer with 2.4.17-r5 kernel with the same results.  Our hardware does
differ, I have a logitech optical mouse and soyo motherboard, he has
microsoft intellimouse and tyan motherboard. The mouse refused to work
there as well,so it doesn't seem to be my system only.  I just switched
back to the 2.4.17-r3 kernel and it works fine again... I'm not sure
what the diffirence is between r3 and r5 but figured someone might be
interested in this problem.

Michael Nazaroff aka "Naz"



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Usb mouse issues with 2.4.17-r5
  2002-03-19 13:05     ` [gentoo-dev] Usb mouse issues with 2.4.17-r5 Michael M Nazaroff
@ 2002-03-20  8:11       ` Stefan Jones
  0 siblings, 0 replies; 25+ messages in thread
From: Stefan Jones @ 2002-03-20  8:11 UTC (permalink / raw
  To: gentoo-dev

I am also having problems with a USB driver for an
ADSL modem, Speed Touch USB. It works find for
2.4.19-pre3-ac1-preempt
and for 2.4.18 but for 2.4.17-r4/5 the drivers crashes
the kernel on startup. Its a badly written driver but
it should still work.
Normally the modem takes quite a while to initilise
(a few seconds).
My two pence ....
 --- Michael M Nazaroff <naz@themoonsofjupiter.net>
wrote: > I seem to be having troubles with the
2.4.17-r5
> kernel.  It works fine
> except my usbmouse doesn't work under it..  It times
> out, I did try to
> enable Long timeout for slow responding devices but
> that didn't help.  I
> tried having the drivers in the kernel and as
> modules.  

__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com


^ permalink raw reply	[flat|nested] 25+ messages in thread

* [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-16 19:46 [gentoo-dev] Unstable branch proposal - second round George Shapovalov
  2002-03-16 20:59 ` George Shapovalov
@ 2002-03-25 11:23 ` Troy Dack
  2002-03-25 14:57   ` Aaron Cohen
                     ` (2 more replies)
  1 sibling, 3 replies; 25+ messages in thread
From: Troy Dack @ 2002-03-25 11:23 UTC (permalink / raw
  To: gentoo-dev

( new post @ bottom, original left in for continuity ... )

On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:

> Hi All.
> 
> I just looked again through the recent thread and here are some thoughts I
> would like to throw out.
> The thread did not see that much of activity and I thought that timing was
> not right - during the feature freeze right before 1.0 release. Then I
> gave it a second thought and here are a few things I would like to bring
> here. I will try to summarise the previous discussion and then propose
> some stuff which if accepted will require a minor addition to existing
> functionality and may even go in the tree before release (or to 1.x
> version).
> 
> Now to the issue.
> Technically I would not call the proposed  an "unstable branch". The core
> which is a portage system and supporting infrastructure is going to stay
> the same, there has been no call to fork that as far as I can tell (and I
> am not about to do that either). The call was for producing new ebuild
> submission system.
> At present gentoo definitely allows submission of new ebuilds - you just
> have to go to bugs.gentoo.org and submit an ebuild as described in manual,
> then it gets reviewed by core developer and goes into
> /usr/portage/incoming/ and later gets incorporated into the portage tree.
> While a very sound submission protocol it is not very scalable if  ebuild
> submissions are expected to grow significantly. In such case a
> decentralised submission/review schema is desired.
> 
> One proposed way of doing this was to setup a self-managed "mirror", which
> should accept all packages from developers but keep them local. New
> submissions will get reviewed by community and later manually incorporated
> into the main tree by core developers.
> While this allows better exposure of new submissions it does not prevent
> the bottleneck - core developers will be just as occupied. Than
> self-managed sound like a way to start a big mess unless somebody is going
> to spend a lot of time actively maintaining thing, compiling lists of a
> "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing
> them to the core group. Also having to worry about separate system
> incarnation looks like a possibility to start a fork where you might avoid
> doing so. After all these systems will have different requirements.
> 
> Another possibility is to use the same infrastructure, but add new
> specificator to the package name, which will mark it as "unstable". Allow
> unstable ebuilds to appear in the main tree but these will be installed
> (and reported) only if you use special flag (for example --allow-unstable)
> with emerge (ebuild as a low-level utility I guess should just do whatever
> you ask it to). After all this is similar to what people do now with not
> yet incorporated ebuilds.
> Users of unstable ebuilds can and are requested to report on
> usability/stability of an ebuild by setting some flag in the package dir
> or somewhere in the database, which should be counted when user rsyncs
> again. Certain policy can be set, so that for example packages
> accumulating enough voices should automatically be granted for example
> "confirmed" status. There might be additional layer of (even manual) check
> through which the package should go to get "approved" status (and the
> removal of specificator form ebuild name).
> I am apparently thinking in favour of this one as it seems things can be
> setup more cleanly this way (avoiding any reason for possible forking)
> while allowing everybody to have easier access to all functionality. Users
> can choose to stick with "approved" packages if stability is of most
> concern, "confirmed" if some more functionality is desired or even
> "unstable" to access all packages (and of course anybody anytime can
> force-install any package). To provide this functionality emerge can check
> make.conf for -allow-status flag for example. The tree can even be
> synchronised on user machine according to set stability level.
> The main benefit of setting up something along these lines is that newly
> submitted ebuilds get much broader attention. Especially recalling
> numerous calls for setting up the list of new ebuild submissions so that
> newcomers can start to actively contribute to the system, while allowing
> "core" people to concentrate on essential stuff.
> 
> George

George,
        After reading the messages in this thread (particularly the last two 
posted by you) I'd like to say that I agree with you and to add a couple of 
thoughts of my own.

I like the idea of having ebuilds submitted via bugs.gentoo.org being made 
easily available to all gentoo users -- keeping one interface for 
submission is a good idea.

However instead of (as well as) your multiple package state levels how 
about this (this is all just hypthesis, I don't know if it is possible, I 
don't know enough about all the tools used):

Multiple cvs branches along the lines of this:

Testing Branch  - primarily for use by developers.
                - new ebuilds from bugs.gentoo.org come in here
                - If there is no activity on an ebuild (it's bug)
                  for 14 days it get's moved to Unstable

Unstable Branch - ebuilds that have made it out of testing and *should*
                  work for most users
                - flagged as Stable after 28 days of nil activity on the bug
                - need to be reviewd by gentoo dev team before getting into
                  Stable

Stable Branch   - ebuilds that have made it out of Unstable and are suitable
                  for general consupmtion.
                - the beginning of the "next" gentoo release branch

Release Branch  - ebuilds that are the *current* release of gentoo
                - no changes (except critical security and bug fixes) to
                  be made to this branch

My proposal to integrate this into the portage system and give users a 
means of selecting which branch they wish to rsync against.

eg:
root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
... updating /usr/portage/unstable from cvs.gentoo.org/unstable

or

root@gentoobox # emerge rsync
... updating /usr/portage/release from cvs.gentoo.org

ie: emerge defaults to using the release branch.

It may mean a slightly larger /usr/portage for some users (particularly 
devs), but I think it is needed to reduce the rash of -rX ebuilds that are 
coming out as the developers _react_ to all the problems that are occuring.

This will also allow new users to install a version of gentoo that will 
actually work first go.  Then as they get comfortable with the system they 
can start to experiment, first with Stable ebuilds and then move on to 
Unstable and become part of the development process.

Just my $0.02, either way I'm still going to continue to use gentoo, it is 
by far the best way to learn about and use linux going.

-- 
        Troy Dack
        http://linuxserver.tkdack.com

"...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
the Ugly)."  (By Matt Welsh)



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
@ 2002-03-25 14:57   ` Aaron Cohen
  2002-03-28  3:22     ` Aaron Cohen
  2002-03-26  3:36   ` George Shapovalov
  2002-03-29 23:40   ` Chris Johnson
  2 siblings, 1 reply; 25+ messages in thread
From: Aaron Cohen @ 2002-03-25 14:57 UTC (permalink / raw
  To: gentoo-dev

Great, we will be a Debian Want a be!
On Mon, 2002-03-25 at 06:23, Troy Dack wrote:
> ( new post @ bottom, original left in for continuity ... )
> 
> On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
> 
> > Hi All.
> > 
> > I just looked again through the recent thread and here are some thoughts I
> > would like to throw out.
> > The thread did not see that much of activity and I thought that timing was
> > not right - during the feature freeze right before 1.0 release. Then I
> > gave it a second thought and here are a few things I would like to bring
> > here. I will try to summarise the previous discussion and then propose
> > some stuff which if accepted will require a minor addition to existing
> > functionality and may even go in the tree before release (or to 1.x
> > version).
> > 
> > Now to the issue.
> > Technically I would not call the proposed  an "unstable branch". The core
> > which is a portage system and supporting infrastructure is going to stay
> > the same, there has been no call to fork that as far as I can tell (and I
> > am not about to do that either). The call was for producing new ebuild
> > submission system.
> > At present gentoo definitely allows submission of new ebuilds - you just
> > have to go to bugs.gentoo.org and submit an ebuild as described in manual,
> > then it gets reviewed by core developer and goes into
> > /usr/portage/incoming/ and later gets incorporated into the portage tree.
> > While a very sound submission protocol it is not very scalable if  ebuild
> > submissions are expected to grow significantly. In such case a
> > decentralised submission/review schema is desired.
> > 
> > One proposed way of doing this was to setup a self-managed "mirror", which
> > should accept all packages from developers but keep them local. New
> > submissions will get reviewed by community and later manually incorporated
> > into the main tree by core developers.
> > While this allows better exposure of new submissions it does not prevent
> > the bottleneck - core developers will be just as occupied. Than
> > self-managed sound like a way to start a big mess unless somebody is going
> > to spend a lot of time actively maintaining thing, compiling lists of a
> > "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing
> > them to the core group. Also having to worry about separate system
> > incarnation looks like a possibility to start a fork where you might avoid
> > doing so. After all these systems will have different requirements.
> > 
> > Another possibility is to use the same infrastructure, but add new
> > specificator to the package name, which will mark it as "unstable". Allow
> > unstable ebuilds to appear in the main tree but these will be installed
> > (and reported) only if you use special flag (for example --allow-unstable)
> > with emerge (ebuild as a low-level utility I guess should just do whatever
> > you ask it to). After all this is similar to what people do now with not
> > yet incorporated ebuilds.
> > Users of unstable ebuilds can and are requested to report on
> > usability/stability of an ebuild by setting some flag in the package dir
> > or somewhere in the database, which should be counted when user rsyncs
> > again. Certain policy can be set, so that for example packages
> > accumulating enough voices should automatically be granted for example
> > "confirmed" status. There might be additional layer of (even manual) check
> > through which the package should go to get "approved" status (and the
> > removal of specificator form ebuild name).
> > I am apparently thinking in favour of this one as it seems things can be
> > setup more cleanly this way (avoiding any reason for possible forking)
> > while allowing everybody to have easier access to all functionality. Users
> > can choose to stick with "approved" packages if stability is of most
> > concern, "confirmed" if some more functionality is desired or even
> > "unstable" to access all packages (and of course anybody anytime can
> > force-install any package). To provide this functionality emerge can check
> > make.conf for -allow-status flag for example. The tree can even be
> > synchronised on user machine according to set stability level.
> > The main benefit of setting up something along these lines is that newly
> > submitted ebuilds get much broader attention. Especially recalling
> > numerous calls for setting up the list of new ebuild submissions so that
> > newcomers can start to actively contribute to the system, while allowing
> > "core" people to concentrate on essential stuff.
> > 
> > George
> 
> George,
>         After reading the messages in this thread (particularly the last two 
> posted by you) I'd like to say that I agree with you and to add a couple of 
> thoughts of my own.
> 
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made 
> easily available to all gentoo users -- keeping one interface for 
> submission is a good idea.
> 
> However instead of (as well as) your multiple package state levels how 
> about this (this is all just hypthesis, I don't know if it is possible, I 
> don't know enough about all the tools used):
> 
> Multiple cvs branches along the lines of this:
> 
> Testing Branch  - primarily for use by developers.
>                 - new ebuilds from bugs.gentoo.org come in here
>                 - If there is no activity on an ebuild (it's bug)
>                   for 14 days it get's moved to Unstable
> 
> Unstable Branch - ebuilds that have made it out of testing and *should*
>                   work for most users
>                 - flagged as Stable after 28 days of nil activity on the bug
>                 - need to be reviewd by gentoo dev team before getting into
>                   Stable
> 
> Stable Branch   - ebuilds that have made it out of Unstable and are suitable
>                   for general consupmtion.
>                 - the beginning of the "next" gentoo release branch
> 
> Release Branch  - ebuilds that are the *current* release of gentoo
>                 - no changes (except critical security and bug fixes) to
>                   be made to this branch
> 
> My proposal to integrate this into the portage system and give users a 
> means of selecting which branch they wish to rsync against.
> 
> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
> 
> or
> 
> root@gentoobox # emerge rsync
> ... updating /usr/portage/release from cvs.gentoo.org
> 
> ie: emerge defaults to using the release branch.
> 
> It may mean a slightly larger /usr/portage for some users (particularly 
> devs), but I think it is needed to reduce the rash of -rX ebuilds that are 
> coming out as the developers _react_ to all the problems that are occuring.
> 
> This will also allow new users to install a version of gentoo that will 
> actually work first go.  Then as they get comfortable with the system they 
> can start to experiment, first with Stable ebuilds and then move on to 
> Unstable and become part of the development process.
> 
> Just my $0.02, either way I'm still going to continue to use gentoo, it is 
> by far the best way to learn about and use linux going.
> 
> -- 
>         Troy Dack
>         http://linuxserver.tkdack.com
> 
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> the Ugly)."  (By Matt Welsh)
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
  2002-03-25 14:57   ` Aaron Cohen
@ 2002-03-26  3:36   ` George Shapovalov
  2002-03-29 23:40   ` Chris Johnson
  2 siblings, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-26  3:36 UTC (permalink / raw
  To: gentoo-dev

Hi Troy

Some new activity on this thread, cool!
If I understand correctly your proposal you talk about supporting different 
ebuild stabiliyt/status levels by means of creating new branches for every 
stability level. 
This seems semantically very similar to my proposal (including use of shell 
variables). There are some technical discripances though which I would 
like to address here. 
I shell say that I am working now on writing a detailed proposal of multiple 
ebuild stability levels (and immediate submission visibilty). I will try to 
finish it and submit the link to this maillist as soon as possible.


> George,
>         After reading the messages in this thread (particularly the last
> two posted by you) I'd like to say that I agree with you and to add a
> couple of thoughts of my own.
>
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made
> easily available to all gentoo users -- keeping one interface for
> submission is a good idea.
>
> However instead of (as well as) your multiple package state levels how
> about this (this is all just hypthesis, I don't know if it is possible, I
> don't know enough about all the tools used):
>
> Multiple cvs branches along the lines of this:
As I said semantically  it seems very similar. Technically though, how 
exactly will this be represented in user (synced) portage tree? Will user 
have portage, portage-testing, portage-unstable, etc? I am afraid it will 
create more confusion especially if you take into account the need to update 
existing ebuilds. What about the package in the stable tree which was updated 
and new ebuild should get a "testing" status? If you want to keep things 
semantically consistent and secure you will end up with pieces of package in 
different trees. Is this then really different from additional suffix in 
ebuild name? I designed this change to ebuild name in order to be consistent 
with present ebuild processing scheme. It seems that it should require less 
modification to portage tools this way and it should keep the whole process 
as much as possible automated, not only on the user but also on maintainer 
side. I would guess that maintainers of the server will be unhappy about 
having to support additional trees. 


>
> Testing Branch  - primarily for use by developers.
>                 - new ebuilds from bugs.gentoo.org come in here
>                 - If there is no activity on an ebuild (it's bug)
>                   for 14 days it get's moved to Unstable
I personally would be quite opposed to automatic promotion on my system.  I 
think it should require some user intervention, such as votes for 
intermediate stability level and core group revision before it gets marked as 
stable.  This way you can get whatever stability you want for you setup.
I will post the link to all the details as soon as I'll get enough time to 
finish it, I promise :-).

> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
Nice idea. I actually thought about inclusion of such flags into 
/etc/make.conf (and all other related files). It should definitely be 
possible to set this in command line as well.

It is good to know that people think along the same lines generally WRT this 
issue.

George


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-25 14:57   ` Aaron Cohen
@ 2002-03-28  3:22     ` Aaron Cohen
  2002-03-28  6:52       ` George Shapovalov
  0 siblings, 1 reply; 25+ messages in thread
From: Aaron Cohen @ 2002-03-28  3:22 UTC (permalink / raw
  To: gentoo-dev

It sounds like a good idea!
On Mon, 2002-03-25 at 09:57, Aaron Cohen wrote:
> Great, we will be a Debian Want a be!
> On Mon, 2002-03-25 at 06:23, Troy Dack wrote:
> > ( new post @ bottom, original left in for continuity ... )
> > 
> > On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
> > 
> > > Hi All.
> > > 
> > > I just looked again through the recent thread and here are some thoughts I
> > > would like to throw out.
> > > The thread did not see that much of activity and I thought that timing was
> > > not right - during the feature freeze right before 1.0 release. Then I
> > > gave it a second thought and here are a few things I would like to bring
> > > here. I will try to summarise the previous discussion and then propose
> > > some stuff which if accepted will require a minor addition to existing
> > > functionality and may even go in the tree before release (or to 1.x
> > > version).
> > > 
> > > Now to the issue.
> > > Technically I would not call the proposed  an "unstable branch". The core
> > > which is a portage system and supporting infrastructure is going to stay
> > > the same, there has been no call to fork that as far as I can tell (and I
> > > am not about to do that either). The call was for producing new ebuild
> > > submission system.
> > > At present gentoo definitely allows submission of new ebuilds - you just
> > > have to go to bugs.gentoo.org and submit an ebuild as described in manual,
> > > then it gets reviewed by core developer and goes into
> > > /usr/portage/incoming/ and later gets incorporated into the portage tree.
> > > While a very sound submission protocol it is not very scalable if  ebuild
> > > submissions are expected to grow significantly. In such case a
> > > decentralised submission/review schema is desired.
> > > 
> > > One proposed way of doing this was to setup a self-managed "mirror", which
> > > should accept all packages from developers but keep them local. New
> > > submissions will get reviewed by community and later manually incorporated
> > > into the main tree by core developers.
> > > While this allows better exposure of new submissions it does not prevent
> > > the bottleneck - core developers will be just as occupied. Than
> > > self-managed sound like a way to start a big mess unless somebody is going
> > > to spend a lot of time actively maintaining thing, compiling lists of a
> > > "worthy", "confirmed by majority", etc.. ebuilds. And actively pushing
> > > them to the core group. Also having to worry about separate system
> > > incarnation looks like a possibility to start a fork where you might avoid
> > > doing so. After all these systems will have different requirements.
> > > 
> > > Another possibility is to use the same infrastructure, but add new
> > > specificator to the package name, which will mark it as "unstable". Allow
> > > unstable ebuilds to appear in the main tree but these will be installed
> > > (and reported) only if you use special flag (for example --allow-unstable)
> > > with emerge (ebuild as a low-level utility I guess should just do whatever
> > > you ask it to). After all this is similar to what people do now with not
> > > yet incorporated ebuilds.
> > > Users of unstable ebuilds can and are requested to report on
> > > usability/stability of an ebuild by setting some flag in the package dir
> > > or somewhere in the database, which should be counted when user rsyncs
> > > again. Certain policy can be set, so that for example packages
> > > accumulating enough voices should automatically be granted for example
> > > "confirmed" status. There might be additional layer of (even manual) check
> > > through which the package should go to get "approved" status (and the
> > > removal of specificator form ebuild name).
> > > I am apparently thinking in favour of this one as it seems things can be
> > > setup more cleanly this way (avoiding any reason for possible forking)
> > > while allowing everybody to have easier access to all functionality. Users
> > > can choose to stick with "approved" packages if stability is of most
> > > concern, "confirmed" if some more functionality is desired or even
> > > "unstable" to access all packages (and of course anybody anytime can
> > > force-install any package). To provide this functionality emerge can check
> > > make.conf for -allow-status flag for example. The tree can even be
> > > synchronised on user machine according to set stability level.
> > > The main benefit of setting up something along these lines is that newly
> > > submitted ebuilds get much broader attention. Especially recalling
> > > numerous calls for setting up the list of new ebuild submissions so that
> > > newcomers can start to actively contribute to the system, while allowing
> > > "core" people to concentrate on essential stuff.
> > > 
> > > George
> > 
> > George,
> >         After reading the messages in this thread (particularly the last two 
> > posted by you) I'd like to say that I agree with you and to add a couple of 
> > thoughts of my own.
> > 
> > I like the idea of having ebuilds submitted via bugs.gentoo.org being made 
> > easily available to all gentoo users -- keeping one interface for 
> > submission is a good idea.
> > 
> > However instead of (as well as) your multiple package state levels how 
> > about this (this is all just hypthesis, I don't know if it is possible, I 
> > don't know enough about all the tools used):
> > 
> > Multiple cvs branches along the lines of this:
> > 
> > Testing Branch  - primarily for use by developers.
> >                 - new ebuilds from bugs.gentoo.org come in here
> >                 - If there is no activity on an ebuild (it's bug)
> >                   for 14 days it get's moved to Unstable
> > 
> > Unstable Branch - ebuilds that have made it out of testing and *should*
> >                   work for most users
> >                 - flagged as Stable after 28 days of nil activity on the bug
> >                 - need to be reviewd by gentoo dev team before getting into
> >                   Stable
> > 
> > Stable Branch   - ebuilds that have made it out of Unstable and are suitable
> >                   for general consupmtion.
> >                 - the beginning of the "next" gentoo release branch
> > 
> > Release Branch  - ebuilds that are the *current* release of gentoo
> >                 - no changes (except critical security and bug fixes) to
> >                   be made to this branch
> > 
> > My proposal to integrate this into the portage system and give users a 
> > means of selecting which branch they wish to rsync against.
> > 
> > eg:
> > root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> > ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
> > 
> > or
> > 
> > root@gentoobox # emerge rsync
> > ... updating /usr/portage/release from cvs.gentoo.org
> > 
> > ie: emerge defaults to using the release branch.
> > 
> > It may mean a slightly larger /usr/portage for some users (particularly 
> > devs), but I think it is needed to reduce the rash of -rX ebuilds that are 
> > coming out as the developers _react_ to all the problems that are occuring.
> > 
> > This will also allow new users to install a version of gentoo that will 
> > actually work first go.  Then as they get comfortable with the system they 
> > can start to experiment, first with Stable ebuilds and then move on to 
> > Unstable and become part of the development process.
> > 
> > Just my $0.02, either way I'm still going to continue to use gentoo, it is 
> > by far the best way to learn about and use linux going.
> > 
> > -- 
> >         Troy Dack
> >         http://linuxserver.tkdack.com
> > 
> > "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> > the Ugly)."  (By Matt Welsh)
> > 
> > _______________________________________________
> > gentoo-dev mailing list
> > gentoo-dev@gentoo.org
> > http://lists.gentoo.org/mailman/listinfo/gentoo-dev
> 
> 
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-28  3:22     ` Aaron Cohen
@ 2002-03-28  6:52       ` George Shapovalov
  2002-03-29 13:10         ` Chris Johnson
  0 siblings, 1 reply; 25+ messages in thread
From: George Shapovalov @ 2002-03-28  6:52 UTC (permalink / raw
  To: gentoo-dev

Thanks!

you might be willing then to read my detailed description :-), link to which 
I just posted on mailing list:
http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html

George

On Wednesday 27 March 2002 19:22, you wrote:
> It sounds like a good idea!
>


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-28  6:52       ` George Shapovalov
@ 2002-03-29 13:10         ` Chris Johnson
  2002-03-30 11:04           ` George Shapovalov
  0 siblings, 1 reply; 25+ messages in thread
From: Chris Johnson @ 2002-03-29 13:10 UTC (permalink / raw
  To: gentoo-dev

George and all, 

I'd like to modify/simplify this proposal somewhat. George's proposal is
complementary and more comprehensive, but I try to cut it down to what I
think is the minimally sufficient system. I explain further at this
link: 

Background/motivation:
http://relentless.org:8000/gentoo/

Short proposal plus forum: 
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581 
Enjoy, and I'm open for comments! 

Chris

On Thu, 2002-03-28 at 00:52, George Shapovalov wrote:
> Thanks!
> 
> you might be willing then to read my detailed description :-), link to which 
> I just posted on mailing list:
> http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
> 
> George
> 
> On Wednesday 27 March 2002 19:22, you wrote:
> > It sounds like a good idea!
> >
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@gentoo.org
> http://lists.gentoo.org/mailman/listinfo/gentoo-dev




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
  2002-03-25 14:57   ` Aaron Cohen
  2002-03-26  3:36   ` George Shapovalov
@ 2002-03-29 23:40   ` Chris Johnson
  2002-03-30  6:02     ` Troy Dack
  2 siblings, 1 reply; 25+ messages in thread
From: Chris Johnson @ 2002-03-29 23:40 UTC (permalink / raw
  To: gentoo-dev

What I don't like about this, and catching Aaron Cohen's tone perhaps in
his follow-up email ("Great, we will be a Debian Want a be!"), is the
complexity of a set of cvs branches, stability levels, etc. 

It's what has made a mess of debian from the perspective of having
mature packages float to the top and become available in a timely
manner. See, if I run debian, I have to make all sorts of decisions
about what stability level, which tree, which mirrors, etc. I want to
connect to. With the quality of ebuilds and the ease of the gentoo
system, we can have much lower complexity and higher quality. 

I vote strongly against any cvs branches of the portage tree--that's why
we currently have the -rx designations, anyway! Leverage that and the
organic nature of the community (i.e., see my proposal at 
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581 )
to get a simple, effective system. 

Please, avoid the duplication of effort that all the branches of debian
represent!

Chris



On Mon, 2002-03-25 at 05:23, Troy Dack wrote:
> ( new post @ bottom, original left in for continuity ... )
> 
> On Sun, 17 Mar 2002 06:46, George Shapovalov thought that we needed this:
> 
> > Hi All.
> > 
> > I just looked again through the recent thread and here are some thoughts I

<snip>

> > newcomers can start to actively contribute to the system, while allowing
> > "core" people to concentrate on essential stuff.
> > 
> > George
> 
> George,
>         After reading the messages in this thread (particularly the last two 
> posted by you) I'd like to say that I agree with you and to add a couple of 
> thoughts of my own.
> 
> I like the idea of having ebuilds submitted via bugs.gentoo.org being made 
> easily available to all gentoo users -- keeping one interface for 
> submission is a good idea.
> 
> However instead of (as well as) your multiple package state levels how 
> about this (this is all just hypthesis, I don't know if it is possible, I 
> don't know enough about all the tools used):
> 
> Multiple cvs branches along the lines of this:
> 
> Testing Branch  - primarily for use by developers.
>                 - new ebuilds from bugs.gentoo.org come in here
>                 - If there is no activity on an ebuild (it's bug)
>                   for 14 days it get's moved to Unstable
> 
> Unstable Branch - ebuilds that have made it out of testing and *should*
>                   work for most users
>                 - flagged as Stable after 28 days of nil activity on the bug
>                 - need to be reviewd by gentoo dev team before getting into
>                   Stable
> 
> Stable Branch   - ebuilds that have made it out of Unstable and are suitable
>                   for general consupmtion.
>                 - the beginning of the "next" gentoo release branch
> 
> Release Branch  - ebuilds that are the *current* release of gentoo
>                 - no changes (except critical security and bug fixes) to
>                   be made to this branch
> 
> My proposal to integrate this into the portage system and give users a 
> means of selecting which branch they wish to rsync against.
> 
> eg:
> root@gentoobox # GENTOOBRANCH="UNSTABLE" emerge rsync
> ... updating /usr/portage/unstable from cvs.gentoo.org/unstable
> 
> or
> 
> root@gentoobox # emerge rsync
> ... updating /usr/portage/release from cvs.gentoo.org
> 
> ie: emerge defaults to using the release branch.
> 
> It may mean a slightly larger /usr/portage for some users (particularly 
> devs), but I think it is needed to reduce the rash of -rX ebuilds that are 
> coming out as the developers _react_ to all the problems that are occuring.
> 
> This will also allow new users to install a version of gentoo that will 
> actually work first go.  Then as they get comfortable with the system they 
> can start to experiment, first with Stable ebuilds and then move on to 
> Unstable and become part of the development process.
> 
> Just my $0.02, either way I'm still going to continue to use gentoo, it is 
> by far the best way to learn about and use linux going.
> 
> -- 
>         Troy Dack
>         http://linuxserver.tkdack.com
> 
> "...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and
> the Ugly)."  (By Matt Welsh)
> 




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-29 23:40   ` Chris Johnson
@ 2002-03-30  6:02     ` Troy Dack
  2002-03-30  8:57       ` George Shapovalov
  2002-03-30  9:03       ` Chris Johnson
  0 siblings, 2 replies; 25+ messages in thread
From: Troy Dack @ 2002-03-30  6:02 UTC (permalink / raw
  To: gentoo-dev

On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together 
and come up with:

> What I don't like about this, and catching Aaron Cohen's tone perhaps in
> his follow-up email ("Great, we will be a Debian Want a be!"), is the
> complexity of a set of cvs branches, stability levels, etc.
> 
> It's what has made a mess of debian from the perspective of having
> mature packages float to the top and become available in a timely
> manner. See, if I run debian, I have to make all sorts of decisions
> about what stability level, which tree, which mirrors, etc. I want to
> connect to. With the quality of ebuilds and the ease of the gentoo
> system, we can have much lower complexity and higher quality.
> 
> I vote strongly against any cvs branches of the portage tree--that's why
> we currently have the -rx designations, anyway! Leverage that and the
> organic nature of the community (i.e., see my proposal at
> 
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
> ) to get a simple, effective system.
> 
> Please, avoid the duplication of effort that all the branches of debian
> represent!
> 
> Chris

Fair enough... I realise that the -rx designations are there, however I 
have had -rx .ebuilds fail on numerous occassions because there was simply 
not enough testing before the ebuild was submitted to CVS.

This is fine if you already have a package installed ... simply file a bug, 
or slap the ebuild maintainer on IRC and in a few hours (a day or two at 
most) the ebuild is fixed and away you go.

The problem comes when a new user is trying to build their system and they 
get all these errors.  We don't want to discourage newcomers by having a 
tree of ebuilds that is not 100% stable for their first installation.

That was my main reason for suggesting seperate CVS branch(es).

I agree that Gentoo is not targeted at the "I've never seen linux before 
and thought I'd give it a go" type of user (that's what RH & MDK do), but I 
don't think we should make new users jump through too many hoops simply 
because an ebuild maintainer has hastily submitted an ebuild -- 
particularly for core packages (baselayout is one that comes to mind).


Perhaps a comprimise ....

A stable/install CVS branch that is only used during the initial 
bootstrap/build process and afterwards portage defaults to using the 
regular CVS tree?

Still it is a refreshing way to get my linux "fix"!

--
        Troy Dack
        http://linuxserver.tkdack.com

The onset and the waning of love make themselves felt in the uneasiness
experienced at being alone together.
                -- Jean de la Bruyere



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-30  6:02     ` Troy Dack
@ 2002-03-30  8:57       ` George Shapovalov
  2002-03-30  9:03       ` Chris Johnson
  1 sibling, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-30  8:57 UTC (permalink / raw
  To: gentoo-dev

Please see below.

On Friday 29 March 2002 22:02, you wrote:
> On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together
> > I vote strongly against any cvs branches of the portage tree--that's why
> > we currently have the -rx designations, anyway! Leverage that and the
> > organic nature of the community (i.e., see my proposal at
>
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=65
>81
>
> > ) to get a simple, effective system.
> >
> > Please, avoid the duplication of effort that all the branches of debian
> > represent!
> >
> > Chris
>
[snip]
> The problem comes when a new user is trying to build their system and they
> get all these errors.  We don't want to discourage newcomers by having a
> tree of ebuilds that is not 100% stable for their first installation.
>
> That was my main reason for suggesting seperate CVS branch(es).
[snip]

> Perhaps a compromise ....
>
> A stable/install CVS branch that is only used during the initial
> bootstrap/build process and afterwards portage defaults to using the
> regular CVS tree?
  With multiple stability levels you will get the same effect by setting 
Stability_Level = approved
rsync_Stability_Level = Stability_Level
and withoud a need for a separate CVS branch!
New users will get a stable system and when later they learn enough about 
linux and gentoo in particular they will know what these flags mean and will 
start exploring ... :-).
(here I refer to the flags I introduced in my writeup at:
www.its.caltech.edu/~georges/gentoo/epsp/proposal.html )
   Chris proposed somewhat different definition of stability levels. While 
overall structure is different the "stable" ebuilds will correspond to just 
such level. (please visit:
http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581
for his submissions where he brings up some important aspects. Chris: I am 
going to reply in the forum soon).

Side note:
I am not sure if we should use forum which Chis set up or continue in the 
list. First allows nice concise place for discussion, second gives better 
exposure. In fact there is an alternative - we can use bugs.gentoo.org and I 
am going to enter this proposal there (not only my writeup but whatever will 
accumulate by then)  either when 1.0 comes out (and freeze is over) or in 
about a week or two, whichever is shorter. However this has the same problem 
of low exposure, on the other hand it grabs attention of core group, so right 
now I like that the best. 
If only there was a discussion area setup under gentoo.org (which would not 
require a bugzilla account. I have no problem with that but it scares off 
many people. For the "discussion" situation it is not really necessary 
anyway).

George


^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-30  6:02     ` Troy Dack
  2002-03-30  8:57       ` George Shapovalov
@ 2002-03-30  9:03       ` Chris Johnson
  1 sibling, 0 replies; 25+ messages in thread
From: Chris Johnson @ 2002-03-30  9:03 UTC (permalink / raw
  To: gentoo-dev

<special note to new readers> 

I wonder if anyone else on this list cares to give input. (Hint:
maintainers who really know what this is all about, drobbins, etc.). 

</special note>

On Sat, 2002-03-30 at 00:02, Troy Dack wrote:
> On Sat, 30 Mar 2002 10:40, Chris Johnson got a bunch of monkeys together 
> and come up with:
> 
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=6581

<snip>

> Fair enough... I realise that the -rx designations are there, however I 
> have had -rx .ebuilds fail on numerous occassions because there was simply 
> not enough testing before the ebuild was submitted to CVS.
> 
> This is fine if you already have a package installed ... simply file a bug, 
> or slap the ebuild maintainer on IRC and in a few hours (a day or two at 
> most) the ebuild is fixed and away you go.
> 

See, this whole "waiting on the maintainer" bit is what my proposal
avoids. In general, the idea is whenever *someone* gets it to work
right, their ebuild rises up into cvs to be tested by anyone running in
"10 stable installs or less" mode, which will be a sizeable portion of
the group. (My already stated threshold is in this category, e.g. if I
saw a single successful install of OpenOffice, I'd try it!--already
have, unsuccessfully.)

> The problem comes when a new user is trying to build their system and they 
> get all these errors.  We don't want to discourage newcomers by having a 
> tree of ebuilds that is not 100% stable for their first installation.
 
In this case, the default will be to install in "more than {50|choose a
big number} successful installs" mode, i.e. very tested versions of each
package. Then, in the "Desktop guide" or other documents, it can be made
clear how to get the *latest* builds by changing one's make.conf to set
the "{10|20|50} successful installs or less" mode. 

> That was my main reason for suggesting seperate CVS branch(es).

I'm trying to avoid branching, because that ultimately brings duplicated
effort and communication problems, not to mention contributes to the
slowness already alluded to (i.e "slap the maintainer on IRC to fix"
becomes "slap the maintainer on IRC to test it and bump it to
'stable'"). 

On George's scale of terms, I'm arguing for an _active system, passive
users_ as much as possible. I don't enjoy spending my whole day
bothering 50 maintainers to fix their packages, esp. when it's *easier*
to fix them myself. It's just that I'm frustrated when I make a fix--and
it goes nowhere, helps no one, and then I have to slog through web pages
to submit a bug that gets looked at a week later... yawn. 

> I agree that Gentoo is not targeted at the "I've never seen linux before 
> and thought I'd give it a go" type of user (that's what RH & MDK do), but I 
> don't think we should make new users jump through too many hoops simply 
> because an ebuild maintainer has hastily submitted an ebuild -- 
> particularly for core packages (baselayout is one that comes to mind).

Agreed. Baselayout/bootstrap + core systems are "maintained"; the rest
are "free float".  Besides, if what I'm saying could be implemented,
then ebuilds with high success rates tend to stick in cvs, and ones that
are not successful in the field get demoted and replaced. Automatically.

> Perhaps a comprimise ....
> 
> A stable/install CVS branch that is only used during the initial 
> bootstrap/build process and afterwards portage defaults to using the 
> regular CVS tree?

Why a need for seperate trees: only allow the "freefloat" system to
affect non-core packages, and when doing an install only use packages
that have ratings of "100 successful installs or greater|'STABLE'
blessing".  This seems to solve the problem. 

> Still it is a refreshing way to get my linux "fix"!
> 
> --
>         Troy Dack
>         http://linuxserver.tkdack.com
> 

Me too!  Thanks for your response and participation! How can we measure
if this conversation will be fruitfull? 

Chris




^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Re: Unstable branch proposal - second round
  2002-03-29 13:10         ` Chris Johnson
@ 2002-03-30 11:04           ` George Shapovalov
  0 siblings, 0 replies; 25+ messages in thread
From: George Shapovalov @ 2002-03-30 11:04 UTC (permalink / raw
  To: gentoo-dev

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

Chris

I cannot post to the forum, all I get in responce is this:

Request Error The server has encountered an internal server error. The error 
has been logged and will be investigated by our system programmers. 
AOLserver/3.3.1+ad13 on http://relentless.org:8000

Therefore I attach my posting here.

PS
Don't you think we should change the topic name? I am afraid this "unstable 
branch" stuff scares @gentoo.org people off :-).
    If you agree please reply off my posting under "distributed ebuild 
processing" or start the new thread.

George


On Friday 29 March 2002 05:10, you wrote:
> George and all,
>
> I'd like to modify/simplify this proposal somewhat. George's proposal is
> complementary and more comprehensive, but I try to cut it down to what I
> think is the minimally sufficient system. I explain further at this
> link:
>
> Background/motivation:
> http://relentless.org:8000/gentoo/
>
> Short proposal plus forum:
> http://relentless.org:8000/gentoo/forum/message?message_id=6584&forum_id=65
>81 Enjoy, and I'm open for comments!
>
> Chris
>
> On Thu, 2002-03-28 at 00:52, George Shapovalov wrote:
> > Thanks!
> >
> > you might be willing then to read my detailed description :-), link to
> > which I just posted on mailing list:
> > http://www.its.caltech.edu/~georges/gentoo/epsp/proposal.html
> >
> > George
> >
> > On Wednesday 27 March 2002 19:22, you wrote:
> > > It sounds like a good idea!

[-- Attachment #2: Chris_forum-1.txt --]
[-- Type: text/plain, Size: 6604 bytes --]

Chris: Thanks for contribution!

First I would like to go over conceptual stuff. I totally agree, that unobscured ebuild flow is central to the success and scalability of the distribution. Your points on what are you looking for in the user feedback (namely reports of what worked and what did not) are very essential. This is a kind of input I was looking for. 

I see now that we are attacking the problem from different sides, you jump right at what you as user would like to see and I was thinking in terms of how to introduce distributed ebuild processing with minimal effort and maximum security. I must say that I generally prefer evolution over revolution :-).

Now to the technical stuff:

 I see that we think about packages in a different way. I opted for every change to any ebuild be specifically visible: every update by original author or anybody willing to contribute goes as a new -rX ebuild. These ebuilds are rated according to voting system. Effectively this is a CVS realisation, however since the needs are quite specific it has to be modified. I think that addresses your concerns to some extent - every attempt is available and successfull ones are better visible. 

I created this design on a presumption (which I did not realise at the time but now see its influence) that as a successful project which finally left tight hacker community for a large world, gentoo has have three categories of users: 1.regular users 2.developers 3.core developers With a popular distribution 1st category will outnumber others (and at some point greatly) and thus provide sufficient testing. It may be essential to have silent votes submitted or it may be better to require users to take an action to submit the vote. We can never know beforehand. That's why I did not just push for a specific voting system but instead tried to quickly compile a few possibilities. I am sure in the end we will settle on initial realisation (probably something mixing both possibilities), as well as I am sure that we will have to readjust it later :-). 

BTW, I am going to rewrite my chapter devoted to voting systems. Right now it is not much more than a few paragraphs of raw thoughts. I also have an idea about developer ratings to complement votes for ebuilds (and make overall voting mechanism more efficient). I will write this down sometime over this coming week. 

Promotion threshold levels: I strongly feel against setting them in stone, whatever stability level structure we will end up with. It WILL have to be readjusted as a userbase will grow.

On a related note. As system grows the more decentralized it gets. However this does not happen in a big crash-event normally. Usually it goes through stages, like benevolent dictatorship -> core group in charge -> delegation of partial processing rights to outsiders -> core group as coordinating center... and for successfull project the transitions are normally pretty smooth. Therefore in my design I try to accomodate all the needs. 

1. We have to provide possibility to keep resultant distribution stable. Therefore I consider my stability levels and requirement for user confirmation of ALL ebuilds essential. I will update this section in the main file (proposal.html) as well. 2. It seems that your stability levels are pretty similar to mine and even overlap somewhere:

 2.1 I think tere is misconception in your text: your "Stable" ebuilds correspond not just to core in mine structure but to core and approved comined. The distinction on my side is purely functional, they both are stable, while core require more specific core developer intervention: they cannot be commited automatically, instead they go through core group. 

Approved CAN be commited automatically, they are accessible, only they reach approved status upon core developer blessing. This is more related to security levels of distribution then to ebuild acessibility.

All other ebuilds do not require core groupintervention al att. Well, technically none require. If ebuild does not get core developer attention it can still reach confirmed status. With many users setting their Stability_Level = confirmed you will effectively get decentralized distribution without central control on majority of packages. No "manual certification" as you mentioned it required. Only on core packages.

 2.2 However there is an additional feature you want represented more specifically, that is to see all successfull and all failed attempts. I do not want to go into voting specifisity at this point. Lets try to keep design modular from the very beginning. So, what about such scenario: All the limitations I imposed in "Server perspective chapter" will require that every modification to any ebuild shell go as a new -r(X+1) ebuild. If original ebuild fails it gets "unstable" and author or interested users are forced to repair it. And all their modifications will stay in the tree - visible. The success of implementation is visible as its aggregate vote. Unsuccessfull are visible if you opt for it (rsync_Stability_Level flag).

The best thing - this info is available locally. nd you do not need to use special tools for it - avoids unnecessary database branching.

Well, actually it may be desirable to have all this data stored remotely. It is possible to do it both ways and write tools that do both. It is possible to keep one database per LAN and sync it to some central depository. As system grows single central depository will become a single point of failure and distributed system similar to DNS or FreeNet can be used (this is already Mega level, when we surpass RedHat, Mandrake and RedFlag combined :-)). Infinite configurability is possible, and this is why I think that with proper care gentoo can become THE unifying (but not limiting) base. All it takes is to follow evolution.

Now back to evolution and design. While we have to strive to keep the system secure and choose the best implementation corresponding to presennt user base (what defines how much centralized it should be kept at the moment) we should not forget the ultimate goal: infinite scalability, evolution is a distributed process. On the other hand while we strive to reach infinite scalability we should not forget issues at hand: keep it secure sequre and appropriate. Ok, I feel like I start to sound political here, thats a sign to stop and put some time in the actual desing :-), and may be start thinking about implementation?

PS I will submit rewised proposal to bugs.gentoo.org in about a week. I think to provide links to both proposals and to this forum. What do you think?

^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-03-16 20:59 ` George Shapovalov
  2002-03-17  0:52   ` [gentoo-dev] multiple pkg state levels, was: Unstable branch proposal George Shapovalov
@ 2002-04-16 21:29   ` Michael Lang
  2002-03-16 22:09     ` Brent Cook
  2002-03-19 13:05     ` [gentoo-dev] Usb mouse issues with 2.4.17-r5 Michael M Nazaroff
  1 sibling, 2 replies; 25+ messages in thread
From: Michael Lang @ 2002-04-16 21:29 UTC (permalink / raw
  To: gentoo-dev

I like this decentralized idea as it lets the users help drive the ebuild 
tree without core developers being involved in every single 
decision.  However, I think it is flawed in trying to push users to the 
bugzilla interface as this forces the user to learn yet another interface 
with dealing with Gentoo ebuilds.  Why not borrow Freshmeat's design for 
searching, displaying and drilling down to the various packages available 
in the portage tree.

As you just pointed out, a lot of information is getting lost because your 
average Joe isn't hanging out in bugzilla.  However, if you had a comment 
style section such as Freshmeat has, then bugs and issues could also go 
here and we could let users "vote" on how their installs went as well as 
report problems right there on the package's description and ranking page 
along with all the other fun stuff Freshmeat rolls into their site.

I don't know how difficult this next suggestion would be, but it would be 
great if the user had an "Emerge" link as opposed to Freshmeat's tarball, 
rpm, binaries, src links, and that kicked off the emerge...if emerge 
failed, the error gets cookied back to the browser and user gets presented 
with a short submission form asking him to describe what went wrong.  This 
form is then sent to bugzilla upon user hitting submit.  Of course, if the 
build goes successfully, then a success submission form is offered and user 
is allowed to comment, rank, etc. and submit.

If users are going to be allowed to write ebuilds and submit them to the 
tree, then perhaps the bug submission is routed to the original ebuild 
submitter and he has a set number of days to respond.  If he doesn't 
respond within that time period, then the bug gets routed to a core developer.

The beauty of this?  Those familiar with Freshmeat barely have to learn a 
new interface and the whole Freshmeat site has *got* to be open source 
available somewhere to make this a fast start towards this sort of vision.

At 12:59 PM 3/16/2002 -0800, you wrote:
>Hi again
>
>I would like to somewhat clarify my previous submission.
>So the new ebuild submission and processing procedure can be as follows:
>
>1. new ebuild gets submitted through bugs.gentoo.org as it is now (no change)
>change starts:
>2. it immediately gets incorporated into the main portage tree with the
>"unstable" status (robot).
>3. ebuild voting statistics are kept on bugs.gentoo.org, attached to ebuild
>submission topic. Voters have to be registered with bugs.gentoo.org as they
>are now.
>4. When ebuild accumulates enough unique votes is gets "confirmed" status
>Meanwhile updates and patches to ebuild are submitted as usual but whoever
>cares to correct/update it via existing mechanism.
>5. if ebuild reaches second threshold of "approval wanted" votes or is of
>special interest for core group it gets reviewed and manually assigned
>"approved" status and is maintained by the core group.
>Or there can be additional layer, where ebuild just gets an approval and then
>when it gets core maintaince it gets "core" status.
>
>Comments
>It can seem like a lot of new activity for bugs.gentoo.org. However half of
>that functionality is already implemented and activity is taking place. The
>other half is happening and requires manual interaction. Ebiuld submissions
>are soaring so that some rework of bugs.gentoo.org will probably be necessary
>anyway. This looks like a way to simplify life fore core developers and
>everybody else. (When ebuilds start to be posted to mailing list instead of
>accepted procedure is the time to start thinking about the procedure I think).
>
>
>George
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@gentoo.org
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev

President
www.cybrains.net

"All things should be as simple as possible, but no simpler" -- Albert Einstein



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-03-16 22:09     ` Brent Cook
  2002-03-17  0:26       ` Daniel Mettler
@ 2002-04-16 22:08       ` Michael Lang
  2002-03-17  1:04         ` George Shapovalov
  1 sibling, 1 reply; 25+ messages in thread
From: Michael Lang @ 2002-04-16 22:08 UTC (permalink / raw
  To: gentoo-dev

Yeah, pretty much.  However, Freshports looks more developer centrix than 
end-user
centric as Freshmeat appears to me.

I think it is important to keep the end user who's going to be trying to 
make intelligent decisions about which ebuilds to download as your central 
audience.

At 04:09 PM 3/16/2002 -0600, you wrote:
> > The beauty of this?  Those familiar with Freshmeat barely have to learn a
> > new interface and the whole Freshmeat site has *got* to be open source
> > available somewhere to make this a fast start towards this sort of vision.
> >
>
>Do you essentially mean http://www.freshports.org/ with comments?
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@gentoo.org
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev

President
www.cybrains.net

"All things should be as simple as possible, but no simpler" -- Albert Einstein



^ permalink raw reply	[flat|nested] 25+ messages in thread

* Re: [gentoo-dev] Unstable branch proposal - second round
  2002-03-17  0:26       ` Daniel Mettler
@ 2002-04-17  0:33         ` Michael Lang
  2002-03-17  1:13           ` George Shapovalov
  2002-03-17 19:53           ` [gentoo-dev] separate catalog for my ebuilds Giulio Eulisse
  0 siblings, 2 replies; 25+ messages in thread
From: Michael Lang @ 2002-04-17  0:33 UTC (permalink / raw
  To: gentoo-dev

hmmm...I never intended to imply that the ebuild repository and bugs 
wouldn't be integrated....only that the avg joe downloader wouldn't be 
forced to learn a developer tool and that the ebuild repository would 
automatically push issues into the bugs database.

To take this step up another notch, when bugs are fixed for a particular 
package, the issues surrounding the bug are suppressed to just a link 
called "past bugs" but when a bug is actively open, then the issues for 
that bug are displayed prominently for the end user so he can quickly 
determine if the package is going to meet his needs.

This is something that would be most important to me as a new Linux 
user...I'm trying to find
good quality packages and I know little about their background, but if I 
can read comments about them and see that there are bug issues at the 
moment, I can choose to move on to another package or attempt to work 
around the known bug issues.

Michael
At 01:26 AM 3/17/2002 +0100, you wrote:
>On Saturday 16 March 2002 23:09, Brent Cook wrote:
> > Do you essentially mean http://www.freshports.org/ with
> > comments?
>
>that's cool, but imho there should be some way to leverage
>bugs.gentoo.org by integrating both. i think it would be an
>overkill having a separate "ebuild repository", it should rather
>be kept central.
>
>probably a simple link like
>
>http://bugs.gentoo.org/buglist.cgi?component=Ebuilds
>
>(add your date constraints)
>
>would be sufficient if we just agreed on a standardized way how
>ebuild submissions (and error reports) have to be made. this
>could be done by "forcing" a formatted summary field. e.g. for
>ebuild submissions:
>
>${P} ${DESCRIPTION}
>
>this would be suitable for most users (as gentoo mainly targets
>developers/professionals and as the ebuild names are usually
>self-explanatory). disclaimer: i do not know whether forcing
>field formats is possible with bugzilla. a voting feature
>would be nice too.
>
>rgds
>
>dan
>
>--
>       ...::: Daniel Mettler | http://www.numlock.ch :::....
>
>_______________________________________________
>gentoo-dev mailing list
>gentoo-dev@gentoo.org
>http://lists.gentoo.org/mailman/listinfo/gentoo-dev

President
www.cybrains.net

"All things should be as simple as possible, but no simpler" -- Albert Einstein



^ permalink raw reply	[flat|nested] 25+ messages in thread

end of thread, other threads:[~2002-03-30 11:11 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-03-16 19:46 [gentoo-dev] Unstable branch proposal - second round George Shapovalov
2002-03-16 20:59 ` George Shapovalov
2002-03-17  0:52   ` [gentoo-dev] multiple pkg state levels, was: Unstable branch proposal George Shapovalov
2002-04-16 21:29   ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
2002-03-16 22:09     ` Brent Cook
2002-03-17  0:26       ` Daniel Mettler
2002-04-17  0:33         ` Michael Lang
2002-03-17  1:13           ` George Shapovalov
2002-03-17 19:53           ` [gentoo-dev] separate catalog for my ebuilds Giulio Eulisse
2002-03-17 21:40             ` Chad M. Huneycutt
2002-04-16 22:08       ` [gentoo-dev] Unstable branch proposal - second round Michael Lang
2002-03-17  1:04         ` George Shapovalov
2002-03-19 13:05     ` [gentoo-dev] Usb mouse issues with 2.4.17-r5 Michael M Nazaroff
2002-03-20  8:11       ` Stefan Jones
2002-03-25 11:23 ` [gentoo-dev] Re: Unstable branch proposal - second round Troy Dack
2002-03-25 14:57   ` Aaron Cohen
2002-03-28  3:22     ` Aaron Cohen
2002-03-28  6:52       ` George Shapovalov
2002-03-29 13:10         ` Chris Johnson
2002-03-30 11:04           ` George Shapovalov
2002-03-26  3:36   ` George Shapovalov
2002-03-29 23:40   ` Chris Johnson
2002-03-30  6:02     ` Troy Dack
2002-03-30  8:57       ` George Shapovalov
2002-03-30  9:03       ` Chris Johnson

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox