Mailing List Archive

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/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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/

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

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