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.
--
[EMAIL PROTECTED] mailing list
On Jun 12, 2007, at 2:14 PM, Carsten Lohrke wrote:
Could you please stop spamming the list with your one sentence
replies!
Waiting a day and then sending a single subsuming reply to the most
important
arguments suffices completely. The mailing list is not a chat channel.
Carsten
Hi list,
On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:
P.S.: I think you are fighting against windmills here. Most devs are
happy with the current policy, and even I see no urgent point from
your
arguments.
So this will require users to file a bugreport, but I for myself am
burned out
On Jun 12, 2007, at 2:05 PM, Christian Faulhammer wrote:
You have the cvs diff abilites and we have a header that says which
CVS revision one is having.
Well, who are bugreporters? I'd say a lot of users report bugs who
don't use CVS at all. And they even don't know about the different
CV
On Jun 12, 2007, at 1:56 PM, Christoph Mende wrote:
It seems a bit that you didn't fully understand that case. That
package
fails to install for 10% but works flawlessly for the other 90%. Those
10% will get the fix even without a version bump, the other 90% don't,
but that's ok, they don't ne
On Jun 12, 2007, at 1:56 PM, Christian Faulhammer wrote:
P.S.: I think you are fighting against windmills here. Most devs are
happy with the current policy, and even I see no urgent point from
your
arguments.
yeah, I already figured out...
--
[EMAIL PROTECTED] mailing list
On Jun 12, 2007, at 1:50 PM, Vlastimil Babka wrote:
I don't agree for hard-masked packages. Sometimes they are hard-masked
because of being under development, and are changed several times
until
unmasked (think about new KDE versions etc). Revbumping with each
change
and then finally unmask
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
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 vers
On Jun 12, 2007, at 12:55 PM, Marius Mauch wrote:
Hi Marius,
Not realistic. Think about it:
- upstream location for a package changes, so old SRC_URI stops
working. If we don't update the existing ebuild people can't use it
anymore, if we bump it to a new revision existing users "have to"
perfo
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 :)
--
[EMAIL PROTECTED] mailing list
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 i
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 w
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
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
b
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 diffe
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,
ple
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 d
On Jun 12, 2007, at 12:20 PM, Petteri Räty wrote:
http://devmanual.gentoo.org/general-concepts/ebuild-revisions/
index.html
This is the current policy. So far it has worked quite well for me
at least.
Okay, does this include ~ packages? And what about hard masked ones?--
[EMAIL PROTECTED]
On Jun 12, 2007, at 12:21 PM, Luca Barbato wrote:
There is already a guideline about it it basically says :
"Every changes that just fix an issue for a certain deals of users
(e.g.
optional dep version bump, different use handling, anything that
makes
the program not build just in that pa
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, d
Hi all,
I think it is worth to discuss about `Do not modify ebuilds which are
already in the tree... even if masked.`
Sometimes ebuilds which are already in the portage tree are modified
without changing the
version-number, i.e. ebuild-r1 is in the portage tree and the ebuild-
r1 gets chan
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
--
[EMAIL PROTECTED] mailing list
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 sinc
24 matches
Mail list logo
