[gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

Hi all,

I think it's worth to discuss the `behaviour of removing ebuilds from  
the tree`.

In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets  
updated
the older ebuild gets removed in the same turn. In my opinion, it is  
better to
keep the older ebuild around for a while since if there are some bugs  
in the
newer ebuild, users are able to downgrade easily.

My suggestion is to set up a guidline similar like it exists for  
marking the ebuilds as
stable (4 weeks).

Probably, a time period for removing ebuilds would be nice to have, I  
think
2 weeks would be reasonable if there aren't any known bugs of the  
newer ebuild.
Of course, if the newer ebuild has bugs, which do not exist in the  
older ebuild
the older ebuild should still be kept to let the user be able to  
choose, which version
they want.

What do you think?

Cheers,

Cecilia

PS: other topics to be discussed `Not to modify ebuilds which are  
already in the tree... even if masked` what do you think?
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: guidline to set a timeline of removal of ebuild from stable tree

[Christian Faulhammer]

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

cilly <cilly@cilly.mine.nu>:
> What do you think?

 I agree with that.

> PS: other topics to be discussed `Not to modify ebuilds which are  
> already in the tree... even if masked` what do you think?

 Explain please.

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] Re: guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 11:49 AM, Christian Faulhammer wrote:

>> PS: other topics to be discussed `Not to modify ebuilds which are
>> already in the tree... even if masked` what do you think?
>
>  Explain please.

I will start a new topic on that.

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Luca Barbato]

cilly wrote:
> Hi all,
> 
> I think it's worth to discuss the `behaviour of removing ebuilds from
> the tree`.

Currently it's up to the developer, some people are more conservative,
some prefer to get rid of certain stuff asap.

You should differentiate between ~ and stable ones btw...
> 
> In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets updated
> the older ebuild gets removed in the same turn.

This happens only when:

- there are security concerns
- the old ebuild was there till ages and the new one had been in ~ since
ages.

> In my opinion, it is better to keep the older ebuild around for a while since
> if there are some bugs in the newer ebuild, users are able to downgrade easily.

that's is quite up to the specific applications IMHO.

> What do you think?

I'd leave it up to the developer, nothing is lost in gentoo and fetching
from the attic isn't exactly difficult. Still probably having a note to
make people aware of that could be useful since the problem you pointed
doesn't require any more work to be solved.

> PS: other topics to be discussed `Not to modify ebuilds which are
> already in the tree... even if masked` what do you think?

I probably understood what you mean and well, no, I don't think is a
good idea.

lu - that prefers less rules and more people aware.


-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 11:59:28AM +0200, Luca Barbato wrote:
> lu - that prefers less rules and more people aware.

Couldn't agree more.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 11:40:26AM +0200, cilly wrote:
>  In my opinion, ebuilds are removed too soon, i.e. if an ebuild gets
>  updated the older ebuild gets removed in the same turn. In my
>  opinion, it is better to keep the older ebuild around for a while
>  since if there are some bugs in the newer ebuild, users are able to
>  downgrade easily.
> 
>  My suggestion is to set up a guidline similar like it exists for
>  marking the ebuilds as stable (4 weeks).
> 
>  Probably, a time period for removing ebuilds would be nice to have, I
>  think 2 weeks would be reasonable if there aren't any known bugs of
>  the newer ebuild.  Of course, if the newer ebuild has bugs, which do
>  not exist in the older ebuild the older ebuild should still be kept
>  to let the user be able to choose, which version they want.
> 
>  What do you think?

I think that setting arbitrary guidelines that try to rule every
situation is just *plain* wrong.

Some of the packages I maintain are better removed when a new
maintenance version is released. And I plan to keep it that way :)

As usual, deep known of the package you are removing and common sense is
way better than guidelines 'to rule them all'.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote:

> I think that setting arbitrary guidelines that try to rule every
> situation is just *plain* wrong.
>
> Some of the packages I maintain are better removed when a new
> maintenance version is released. And I plan to keep it that way :)
>
> As usual, deep known of the package you are removing and common  
> sense is
> way better than guidelines 'to rule them all'.

I see myself very often upgrading and encountering a bug which  
requires me to
downgrade. But a downgrade isn't easily possible since the last  
stable ebuild has
already been replaced by the newer and buggy one. The bug must not be  
in the
ebuild itself, sometimes a version-upgrade (upstream) brings new  
features and
new bugs. Sometimes it is nearly impossible for a package maintainer  
to get an
overview of possible bugs, may be upstream bugs, or typos.

Related to these issues, I really recommend to add timeline like it  
exists for adding
to stable tree.

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 12:14:37PM +0200, cilly wrote:
>  On Jun 12, 2007, at 12:01 PM, Fernando J. Pereda wrote:
> 
> > I think that setting arbitrary guidelines that try to rule every
> > situation is just *plain* wrong.
> >
> > Some of the packages I maintain are better removed when a new
> > maintenance version is released. And I plan to keep it that way :)
> >
> > As usual, deep known of the package you are removing and common sense is
> > way better than guidelines 'to rule them all'.
> 
>  I see myself very often upgrading and encountering a bug which
>  requires me to downgrade. But a downgrade isn't easily possible since
>  the last stable ebuild has already been replaced by the newer and
>  buggy one. The bug must not be in the ebuild itself, sometimes a
>  version-upgrade (upstream) brings new features and new bugs.
>  Sometimes it is nearly impossible for a package maintainer to get an
>  overview of possible bugs, may be upstream bugs, or typos.

Well, if maintainers can't properly follow upstream development they
should probably seek help in their maintenance job.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:21 PM, Fernando J. Pereda wrote:

> Well, if maintainers can't properly follow upstream development they
> should probably seek help in their maintenance job.

Hi Fernando,

well, I wouldn't bring up this discussion if there aren't any  
problems. I `think` a reminder to all devs about managing ebuilds,  
i.e. with the following link:

http://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html

would be a solution. What do you think?

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Marijn Schouten (hkBst)]

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

cilly wrote:
> well, I wouldn't bring up this discussion if there aren't any problems.

Hi Cecilia,

perhaps you could go into some more specifics of these problems?
Which packages were removed and were they stable, testing or masked at the
time of removal? What problems did the removal cause?

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbngop/VmCx0OL2wRAkfoAKCyuL8a8n4o3iZB1sH3qrHWWWlKlQCgwTl+
XDGLe9penKS9ymmxcrAyobU=
=nGUG
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:40 PM, Marijn Schouten (hkBst) wrote:

> Hi Cecilia,
>
> perhaps you could go into some more specifics of these problems?
> Which packages were removed and were they stable, testing or masked  
> at the
> time of removal? What problems did the removal cause?
>
> Marijn

Hi Marijn,

please, understand that I do not want to `blame` any developer,  
unless it is discussed here with a final solution. Since I am not a  
gentoo-dev, some of the devs `may not understand` my concerns and  
probably `feel offended`.

Cheers,

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Marijn Schouten (hkBst)]

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

cilly wrote:
> please, understand that I do not want to `blame` any developer, unless
> it is discussed here with a final solution. Since I am not a gentoo-dev,
> some of the devs `may not understand` my concerns and probably `feel
> offended`.

Hi Cecilia,

Nobody will feel offended by your bug report. I'm asking you to go into
specifics precisely because I want to better understand what the exact problem
is. Or you could start using lilypond and tell me all that is wrong with it (a
lot). When 2.10.26 comes out in probably a few days I'll be removing all other
 testing versions, except 2.11.26, because they have problems with the newest
fontforge. I hope 2.10.26 will be good enough to be stabled.

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbn7Yp/VmCx0OL2wRAjM2AJ0UdBKDsb+u0CVHvttKwAakqKvLgACfYer9
9J70SOJpZNkMNIkXe30OnRo=
=9nCO
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Richard Freeman]

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

Fernando J. Pereda wrote:
> Some of the packages I maintain are better removed when a new
> maintenance version is released. And I plan to keep it that way :)
> 

Can you clarify this?  What scenarios do you run into where it isn't 
good for stable users to have access to more than one version of the 
software?

One thing that I noticed is that in many cases there are multiple 
testing versions of a package available, and one stable version.  So, if 
you run unstable you can pick and choose, but if you're running stable 
(which in theory should be the target audience gentoo aims for) then you 
get your choice of only one.

I tend to think that unless something unusual is going on that old 
packages should be kept around for a while (a few weeks at least).  The 
same should apply to packages in testing as well.  Actually, that could 
be a whole separate topic.  There have been many times that I've had to 
upgrade to a package in testing to get some needed feature, but then it 
gets deleted in favor of some other package in testing - and the stable 
package sits at its current version for ages.  Unless a package in 
testing has a reasonably serious problem of some kind it would seem to 
make more sense to me to have ebuilds not removed until they've been 
stabilized and then obsoleted.  An exception would be revision bumps - 
no sense stabilizing an ebuild revision that has a simple bugfix 
available without an upstream version change.

Others have pointed out that inflexible rules aren't always the answer. 
  I'd agree in general, but there should be guidelines.  Maybe certain 
packages shouldn't have multiple stable versions to choose from.  But 
when "certain packages" becomes 80% of them then I'd wonder if there 
really is a good reason for this...

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 06:36:31AM -0400, Richard Freeman wrote:
>  Fernando J. Pereda wrote:
> > Some of the packages I maintain are better removed when a new
> > maintenance version is released. And I plan to keep it that way :)
> 
>  Can you clarify this?  What scenarios do you run into where it isn't good 
>  for stable users to have access to more than one version of the software?

Known to be buggy versions.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:

> Known to be buggy versions.

Of course, there are bugs in every version. Sometimes a user must be  
able to choose which bug is more problematic, i.e. the bug in the  
newer ebuild which makes the package unusable for them or the older  
bug which has a security issue the users are aware of but not  
present, i.e. prevented by firewall. A timeline of two weeks would  
allow the user to easily downgrade and if necessary put the ebuild in  
overlay.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:53 PM, cilly wrote:

> Of course, there are bugs in every version. Sometimes a user must  
> be able to choose which bug is more problematic, i.e. the bug in  
> the newer ebuild which makes the package unusable for them or the  
> older bug which has a security issue the users are aware of but not  
> present, i.e. prevented by firewall. A timeline of two weeks would  
> allow the user to easily downgrade and if necessary put the ebuild  
> in overlay.

Additional:

Sometimes the chance for the users to place the ebuild comfortably  
into overlay is simply taken, since the ebuild has been removed and  
doesn't exist after a sync anymore.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Luca Barbato]

cilly wrote:
> Sometimes the chance for the users to place the ebuild comfortably into
> overlay is simply taken, since the ebuild has been removed and doesn't
> exist after a sync anymore.

any ebuild from day 0 till now lives in the cvs, you can fetch it from
the cvs attic anytime, I'm afraid this information isn't exactly well
known =/

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 1:27 PM, Luca Barbato wrote:

> any ebuild from day 0 till now lives in the cvs, you can fetch it from
> the cvs attic anytime, I'm afraid this information isn't exactly well
> known =/

I am aware of it, but this means much more "frickle"-time (forget  
frickle if you don't know it :).
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Christoph Mende]

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

On Tue, 12 Jun 2007 12:59:42 +0200
cilly <cilly@cilly.mine.nu> wrote:

> On Jun 12, 2007, at 12:53 PM, cilly wrote:
> Additional:
> 
> Sometimes the chance for the users to place the ebuild comfortably  
> into overlay is simply taken, since the ebuild has been removed and  
> doesn't exist after a sync anymore.
It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
and hit "Show X dead files" in the dir of the ebuild you want ;)

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 1:29 PM, Christoph Mende wrote:

> It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
> and hit "Show X dead files" in the dir of the ebuild you want ;)

so you misunderstood comfortably :)
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Robert Buchholz]

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


Am 12.06.2007 um 13:29 schrieb Christoph Mende:

> On Tue, 12 Jun 2007 12:59:42 +0200
> cilly <cilly@cilly.mine.nu> wrote:
>
>> On Jun 12, 2007, at 12:53 PM, cilly wrote:
>> Additional:
>>
>> Sometimes the chance for the users to place the ebuild comfortably
>> into overlay is simply taken, since the ebuild has been removed and
>> doesn't exist after a sync anymore.
> It's not, CVS keeps every ebuild around, just go to sources.gentoo.org
> and hit "Show X dead files" in the dir of the ebuild you want ;)

The problem is rather that the patches are gone from the distfiles
mirror after two weeks. The sources often stay upstream, but could
also be gone.

Is there an archive for these files I missed?

Robert

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFGcACzyZx3L/ph1soRAutQAKCMQ2f6nCzoXgATbIPTO6sbTv32ugCeP+JP
tqC13Sfmy1t30jU6aCWgZug=
=A832
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Brian Harring]

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

On Wed, Jun 13, 2007 at 04:35:31PM +0200, Robert Buchholz wrote:
> The problem is rather that the patches are gone from the distfiles
> mirror after two weeks. The sources often stay upstream, but could
> also be gone.
> 
> Is there an archive for these files I missed?

That archive ('purgatory' being the name used for it) isn't publically 
accessible; had suggested it in the past, but infra folks didn't 
think it would be needed.

Few issues if it were opened up;

1) it's not a true vcs, just a directory.  Meaning 

1.a) it's collapsing down the trees history of distfile names; if 
ebuild x refs 'patch', gets removed, 'patch' goes into purgatory.  If 
ebuild y refs 'patch', which is a different file, then gets removed, 
ebuild ys' version of 'patch' is whats is now in purgatory (last used 
basically).

1.b) skimped a bit in the description above; 'patch' gets removed from 
purgatory when ebuild 'y' is added to the tree- the chksums will 
differ, thus it throws out the copy that no longer is relevant to it's 
job (maintaining the mirror image).


2) if implemented, likely to be a single box- meaning stuff shouldn't 
rely on it as an upstream URI, they should mirror it themselves.

3) mirror maintenance, if an ebuild is added to the tree that uses 
that specific distfile name, as hinted at in 1.b, the file is removed 
from purgatory- this *includes* if the chksums match.  Basically, if 
the file is needed on the mirror image, it copies it over and wipes 
the purgatory copy of it (intention is to keep space usage down).
This obviously would break any ebuilds daftly ignoring #2, and using 
the purgatory host as an upstream URI.


Personally, I think at least for devs, having access to purgatory 
would be a good thing.  Folks seem to have learned over the last few 
years, but dealt with a lot of requests where a dev screwed up and 
needed to pull a file out of purgatory.  Perhaps they've gotten wiser 
since, dunno.  Either way, if trying to pull a file out of 
purgatory, bug your friendly infra monkey, or zmedico if you need a 
specific file out- they ought to have access.

For effectively random anonymous, http/ftp, not sure about 
that.  Think some form of access is needed, don't think it should 
really be usable as an upstream host.

~harring

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

[gentoo-dev] Re: guidline to set a timeline of removal of ebuild from stable tree

[Duncan]

cilly <cilly@cilly.mine.nu> posted
4FA373CA-773E-4390-BD91-70F87510D6D9@cilly.mine.nu, excerpted below, on 
Tue, 12 Jun 2007 12:59:42 +0200:

> On Jun 12, 2007, at 12:53 PM, cilly wrote:
> 
>> Of course, there are bugs in every version. Sometimes a user must be
>> able to choose which bug is more problematic, i.e. the bug in the newer
>> ebuild which makes the package unusable for them or the older bug which
>> has a security issue the users are aware of but not present, i.e.
>> prevented by firewall. A timeline of two weeks would allow the user to
>> easily downgrade and if necessary put the ebuild in overlay.
> 
> Additional:
> 
> Sometimes the chance for the users to place the ebuild comfortably into
> overlay is simply taken, since the ebuild has been removed and doesn't
> exist after a sync anymore.

Keeping this short since the user list would be more appropriate for this 
sort of thing, but I've not seen it mentioned in the thread yet.

That's one of several reasons I find FEATURES=buildpkg so useful.  It is 
IMO the most under-publicized great feature of portage. =8^)  Really.  
Read about it, then try it for awhile, and if you don't agree, look in 
the forums or ask on users for some hints on the troubleshooting and 
rescue methods it makes possible or much easier.  (Specific hint for this 
thread, the ebuild is tacked onto the end of the tar.bz2-ed compressed 
package.  That's been useful to me a couple times.)

If people only knew some of the great features portage already has, the 
wouldn't keep asking for them. =8^)  Features=buildpkg is one such 
feature.

-- 
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: guidline to set a timeline of removal of ebuild from stable tree

[banym tuxaner]

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

Hi,

my opinion is to make the sync machanism more intelligent in this way.
I don't want to have a tree with 2 stable versions or old versions of
ebuilds.
My idea is to let the actual(old) installed ebuild version untouched so you
are able to downgrade after an update, and you are although able to
downgrade to you old stabe version if it is older than just the last version
of the ebuild.

In this way you don't have the problem in the official tree because
everybody is able to downgrade to his old version no matter how old.

so but just an idea

banym

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Fernando J. Pereda]

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

On Tue, Jun 12, 2007 at 12:53:16PM +0200, cilly wrote:
>  On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
> 
> > Known to be buggy versions.
> 
>  Of course, there are bugs in every version. Sometimes a user must be able to 
>  choose which bug is more problematic, i.e. the bug in the newer ebuild which 
>  makes the package unusable for them or the older bug which has a security 
>  issue the users are aware of but not present, i.e. prevented by firewall. A 
>  timeline of two weeks would allow the user to easily downgrade and if 
>  necessary put the ebuild in overlay.

If the user thinks he knows better than me which version he wants to
use, there is the code. I'll still keep in Gentoo's tree whatever *I*
feel it is best for every gentoo user.

- ferdy

-- 
Fernando J. Pereda Garcimartín
20BB BDC3 761A 4781 E6ED  ED0B 0A48 5B0C 60BD 28D4

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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 1:03 PM, Fernando J. Pereda wrote:

> If the user thinks he knows better than me which version he wants to
> use, there is the code. I'll still keep in Gentoo's tree whatever *I*
> feel it is best for every gentoo user.

Fernando, I do not complain against you, may be if everyone would act  
as you I / we / some won't have problems at all.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Luis Francisco Araujo]

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

cilly wrote:
> On Jun 12, 2007, at 12:46 PM, Fernando J. Pereda wrote:
> 
>> Known to be buggy versions.
> 
> Of course, there are bugs in every version. Sometimes a user must be
> able to choose which bug is more problematic, i.e. the bug in the newer
> ebuild which makes the package unusable for them or the older bug which
> has a security issue the users are aware of but not present, i.e.
> prevented by firewall. A timeline of two weeks would allow the user to
> easily downgrade and if necessary put the ebuild in overlay.

Hello,

We (developers) won't immediately remove old packages versions if there
is no a good reason for it, at least in my case.

One of the main motivation for fast removal are security concerns, they
sometimes happen and they don't even get into our bugzilla database ,
but the maintainer of the package is aware of it from upstream reports,
so these might be "unknown" problems for our users.

Best recommendation is that you trust the package maintainer and report
bugs in the new packages if you find them.

Regards,

- --

Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)

iD8DBQFGbsQ8aTNpke9pJcURAugPAJ9MuOmIFMzNNAx7DqKCm/ZuxLj5mACfcOf/
W3oxNo4aXWZLGlT9D5HblQ4=
=GLS5
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Luca Barbato]

Richard Freeman wrote:
> Can you clarify this?  What scenarios do you run into where it isn't
> good for stable users to have access to more than one version of the
> software?

- Security issues.

- "Downgrade to hell" scenarios

- Other colorful issues that may happen from time to time.

> 
> One thing that I noticed is that in many cases there are multiple
> testing versions of a package available, and one stable version.  So, if
> you run unstable you can pick and choose, but if you're running stable
> (which in theory should be the target audience gentoo aims for) then you
> get your choice of only one.

The stable one is supposed to be the best available, the ~ ones are
supposed to be "in flux"

> 
> I tend to think that unless something unusual is going on that old
> packages should be kept around for a while (a few weeks at least).

Happens more than often =)

> Others have pointed out that inflexible rules aren't always the answer.
>  I'd agree in general, but there should be guidelines.  Maybe certain
> packages shouldn't have multiple stable versions to choose from.  But
> when "certain packages" becomes 80% of them then I'd wonder if there
> really is a good reason for this...

Keep in mind that the trade off is :

- our time
- our sanity
- what provide to our used
- the quality of what we provide to out users.

We all try our best to not burn out while serving you the best we could
think.

lu

-- 

Luca Barbato

Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote:

> Keep in mind that the trade off is :
>
> - our time
> - our sanity
> - what provide to our used
> - the quality of what we provide to out users.
>
> We all try our best to not burn out while serving you the best we  
> could
> think.

Does it make such a difference if ebuilds are kept for a few weeks?
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Petteri Räty]

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

cilly kirjoitti:
> On Jun 12, 2007, at 12:48 PM, Luca Barbato wrote:
> 
>> Keep in mind that the trade off is :
>>
>> - our time
>> - our sanity
>> - what provide to our used
>> - the quality of what we provide to out users.
>>
>> We all try our best to not burn out while serving you the best we could
>> think.
> 
> Does it make such a difference if ebuilds are kept for a few weeks?

Nope and they should usually be kept but we can't make a hard rule
because there are cases where the old ebuilds don't work any more. If
you find that a broken version slipped the cracks of the arch teams and
made it to stable with the old version removed, file a bug to
bugs.gentoo.org and hopefully the maintainer learns from his/her mistake
of removing it too soon. If the maintainer keeps on doing the same
thing, then you can try to escalate things to qa/devrel. If you are
using ~arch, then encountering some broken stuff is fully expected, just
file a bug and the maintainer is expected to react in a timely manner.

Regards,
Petteri


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

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 1:21 PM, Petteri Räty wrote:

> Nope and they should usually be kept but we can't make a hard rule
> because there are cases where the old ebuilds don't work any more. If
> you find that a broken version slipped the cracks of the arch teams  
> and
> made it to stable with the old version removed, file a bug to
> bugs.gentoo.org and hopefully the maintainer learns from his/her  
> mistake
> of removing it too soon. If the maintainer keeps on doing the same
> thing, then you can try to escalate things to qa/devrel. If you are
> using ~arch, then encountering some broken stuff is fully expected,  
> just
> file a bug and the maintainer is expected to react in a timely manner.

I agree, if an ebuild is broken then it should be removed since it  
doesn't work at all. But rather than exchanging the broken ebuild  
with a version bump it is sometimes more advisable to repair the  
broken ebuild and increase the integer of -rx instead of replacing  
the broken ebuild with a masked one. Very often bugs are filed after  
a package has been unmasked and so it is  better to have a working  
older ebuild.

Of course, this is just a case scenario which may happen. To prevent  
such rare cases is in mind of every user. Well, I still think, leave  
it up to the users and give them time to choose between ebuilds and  
move them to overlay, instead of forcing them to query the source for  
dead packages.--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Marijn Schouten (hkBst)]

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

Richard Freeman wrote:
> One thing that I noticed is that in many cases there are multiple
> testing versions of a package available, and one stable version.  So, if
> you run unstable you can pick and choose, but if you're running stable
> (which in theory should be the target audience gentoo aims for) then you
> get your choice of only one.

I think this is a consequence of the strict rules for stabling packages and
removing stable packages.

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGbny9p/VmCx0OL2wRAp29AJ9V3Nvok7ol9QQCRSj62FP03dEl6wCaA5Df
mm/NURPVPSwcHcBeA3fKOnE=
=Mvgs
-----END PGP SIGNATURE-----
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: guidline to set a timeline of removal of ebuild from stable tree

[Christian Faulhammer]

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

Richard Freeman <rich@thefreemanclan.net>:

> One thing that I noticed is that in many cases there are multiple 
> testing versions of a package available, and one stable version.  So,
> if you run unstable you can pick and choose, but if you're running
> stable (which in theory should be the target audience gentoo aims
> for) then you get your choice of only one.

 That is not by purpose.  Most people clean-up a package when
stabilisation round has been done.  So I must say clarify my first
statement: I think it is a good idea to have old stable versions in the
tree, but that should be the choice of the dev in the end without
strict rules.

V-Li

-- 
http://www.gentoo.org/
http://www.faulhammer.org/
http://www.gnupg.org/

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

Re: [gentoo-dev] Re: guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 1:25 PM, Christian Faulhammer wrote:

>  That is not by purpose.  Most people clean-up a package when
> stabilisation round has been done.  So I must say clarify my first
> statement: I think it is a good idea to have old stable versions in  
> the
> tree, but that should be the choice of the dev in the end without
> strict rules.

So what do we do with `the may be 5%` *) of packages this behaviour  
is not working?

*) imaginary number
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[Marius Mauch]

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

Btw, both of your issues could probably be solved by bug 126059 without
adding new rules or new work for ebuild devs.

-- 
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 --]

Re: [gentoo-dev] guidline to set a timeline of removal of ebuild from stable tree

[cilly]

On Jun 12, 2007, at 2:55 PM, Marius Mauch wrote:

> Btw, both of your issues could probably be solved by bug 126059  
> without
> adding new rules or new work for ebuild devs.

Thanks a lot for this, I totally agree.
-- 
gentoo-dev@gentoo.org mailing list