FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 06-07-2011, 10:24 PM
Mike Frysinger
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On Tuesday, June 07, 2011 18:08:17 Matt Turner wrote:
> There _was_ a policy before, but it was unclear about documenting
> version removals and arguably didn't require it, so after a few
> developers (you've been often mentioned as one of them) refused to
> document version removals in the changelog, even after prompting on
> gentoo-dev@ the council fixed the policy.

i'm aware of the history. it still doesnt validate the logic cited earlier.

> Of course the policy doesn't exist simply because you disagree with
> others, the policy exists (and was instituted/clarified) because you
> wouldn't do something that most developers and users find useful and
> thought was already policy, even after being asked.
>
> Why does this have to be such a struggle. It's pretty clear that the
> policy is going to be changed again to fix the oversight of silly
> situations like I mentioned previously, but there's a near unanimous
> agreement that documenting version removals _is_ useful. So, please,
> just start doing it. It's really not a lot of work. I'm sure something
> more can be done to make this more automated, but until then please
> just fucking do it and let's stop all this silliness.

seems we gauge things differently as i dont think it's that black & white,
although it probably is further in your white than in my black. further, i
dont believe people actually get useful information out of this, they just
think they do (perception vs reality). when an actual bug arises, the
information contained in the ChangeLog doesnt assist in the bug triage/fixing.
depgraph broken -> file removed -> reason is irrelevant to the user.
maintainer of the package causing the depgraph breakage gets a bug in bugzilla
and they address it by either re-adding, or trimming more, or tweaking deps,
or something else. so if someone wants a fuzzy security blanket, they can
look to autogeneration and then it's no longer my problem.
-mike
 
Old 06-07-2011, 11:41 PM
Dale
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

Mike Frysinger wrote:


seems we gauge things differently as i dont think it's that black& white,
although it probably is further in your white than in my black. further, i
dont believe people actually get useful information out of this, they just
think they do (perception vs reality). when an actual bug arises, the
information contained in the ChangeLog doesnt assist in the bug triage/fixing.
depgraph broken -> file removed -> reason is irrelevant to the user.
maintainer of the package causing the depgraph breakage gets a bug in bugzilla
and they address it by either re-adding, or trimming more, or tweaking deps,
or something else. so if someone wants a fuzzy security blanket, they can
look to autogeneration and then it's no longer my problem.
-mike



Mike and others as it applies,

I have a question or two. I don't care if you, or others, reply to this
with a answer, just think on it. A policy, rule if you will, has been
decided on by the council. This after MUCH discussion on this list and
the council hearing both sides of the argument. You, apparently on your
own or with a few others, have decided to ignore the policy or rule.


What would you think if someone else ignores another rule that affects
you, negatively of course? What would you do? What do you think should
be done to the person ignoring the rule? Should that person be allowed
to do so with no consequences at all? Just everyone do as they wish
regardless of the rules. What affect would that have on Gentoo as a
whole? Do you really want to see this happen after all the mess Gentoo
has been through in the past?


Think on that for a bit. Give it a day or so or better yet, sleep on it.

Again, I don't care for you to answer or reply. Just think.

Dale

:-) :-)
 
Old 06-08-2011, 03:08 AM
Mike Frysinger
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On Tuesday, June 07, 2011 19:41:20 Dale wrote:
> I have a question or two. I don't care if you, or others, reply to this
> with a answer, just think on it. A policy, rule if you will, has been
> decided on by the council. This after MUCH discussion on this list and
> the council hearing both sides of the argument. You, apparently on your
> own or with a few others, have decided to ignore the policy or rule.

umm, no, ive done no such thing. try again.
-mike
 
Old 06-08-2011, 03:44 AM
Michał Górny
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On Tue, 7 Jun 2011 17:45:03 -0400
Mike Frysinger <vapier@gentoo.org> wrote:

> On Tuesday, June 07, 2011 17:36:59 Ciaran McCreesh wrote:
> > On Tue, 7 Jun 2011 17:35:11 -0400 Mike Frysinger wrote:
> > > > And yes, it should be automated. I agree. Doesn't change the
> > > > current situation.
> > >
> > > of course it does. it makes the current situation irrelevant.
> >
> > Does this mean we should shortly be expecting to see you do the
> > work to migrate the tree to Git and to automate ChangeLog
> > generation?
>
> the tree has already been migrated. automatic ChangeLog generation
> is trivial to implement, and many many projects already have scripts
> to do it.

Including portage's egencache which can generate ChangeLogs from git.
Just a side note.

--
Best regards,
Michał Górny
 
Old 06-08-2011, 03:45 AM
Dale
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

Mike Frysinger wrote:

On Tuesday, June 07, 2011 19:41:20 Dale wrote:


I have a question or two. I don't care if you, or others, reply to this
with a answer, just think on it. A policy, rule if you will, has been
decided on by the council. This after MUCH discussion on this list and
the council hearing both sides of the argument. You, apparently on your
own or with a few others, have decided to ignore the policy or rule.


umm, no, ive done no such thing. try again.
-mike



Let me see if I understand this correctly. Most devs and some users
wants things put in the changelog. I don't know if it was you before
but in the past someone didn't want to put when versions are removed.
That person, whoever it was, said they were not going to do it because
it was silly or whatever. This was taken to the council and it was
decided that all changes had to be put in the changelog. Now in this
thread, about the same thing from my understanding. You said "waste of
time" and the policy is not "sane".


So, council says it has to be done. You say you won't. Tell me where I
missed the point here.


Thanks for the reply but I think this is going to be headed back up the
food chain again. It appears that either rules mean nothing or they
have to be enforced on everyone. The rule makers need to decide this.
I suspect the reason this thread has gotten quiet is because it has
already been discussed off this list about what is coming next. Just me
reading tea leaves here.


My advice, follow the rules or get the rules changed. Don't break them
tho. It doesn't matter to me if you take that advice or not. Just saying.


Dale

:-) :-)
 
Old 06-08-2011, 09:27 AM
Patrick Lauer
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

@council: We need to discuss ways to improve the current policy. See below.

On 06/07/11 23:09, Mike Frysinger wrote:
> On Tuesday, June 07, 2011 16:47:29 Dane Smith wrote:
>> To be perfectly blunt, no small part of what caused this current fiasco
>> was this exact attitude. I don't like the current policy either, it's
>> far too wide. However, if you go back and look at why it even *got* to
>> council, it was because you (and others), decided that they weren't
>> going to give any regard to the requests of some of their fellow devs
>> about ChangeLogging removals.
It was not only that, and the situation escalated as people tried to
lawyer around instead of doing something productive like writing a perl
script to wrap the "nonsense" so they can ignore it.

Result was an unambiguous policy so that no lawyering happens and all
ChangeLogs make sense.

>
> how is this relevant at all ? i dont find value in these entries, other
> people do. my attitude towards how worthless they are has 0 bearing on the
> policy towards creating it.

So you say that you want to follow the rules but accidentally forgot it?

Since it has caused so much trouble I'd like to see it discussed and
improved by the council. I disagreed with the initial strict wording,
and I think the fallout has shown that we need to find a common ground
so that no one feels he has to ignore the rules.

> if you want useless information, then automate it. there's no reason at all
> to not do so. i prefer to keep useful information in the changelogs of
> packages i maintain without cluttering up with noise.
> -mike

Here's the problem. Useful depends a lot on the context.
Sometimes I only care about a new addition. Sometimes I care about when
and how a patch was introduced. Sometimes I care about removals because
some monkey has broken things for me.

In all cases I want one resource to look at, viewcvs is a horrible and
slow interface. So it does make sense to keep changelogs filled with
information - maybe automation is needed, I don't have a strong opinion
either way. But don't make me do more work because you are lazy, that
never ends well.

--
Patrick Lauer http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
 
Old 06-08-2011, 09:28 AM
Dirkjan Ochtman
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On Wed, Jun 8, 2011 at 11:27, Patrick Lauer <patrick@gentoo.org> wrote:
> In all cases I want one resource to look at, viewcvs is a horrible and
> slow interface. So it does make sense to keep changelogs filled with
> information - maybe automation is needed, I don't have a strong opinion
> either way. But don't make me do more work because you are lazy, that
> never ends well.

IMO we should just make repoman commit update the ChangeLog.

Cheers,

Dirkjan
 
Old 06-08-2011, 09:43 AM
Michał Górny
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On Wed, 8 Jun 2011 11:28:47 +0200
Dirkjan Ochtman <djc@gentoo.org> wrote:

> On Wed, Jun 8, 2011 at 11:27, Patrick Lauer <patrick@gentoo.org>
> wrote:
> > In all cases I want one resource to look at, viewcvs is a horrible
> > and slow interface. So it does make sense to keep changelogs filled
> > with information - maybe automation is needed, I don't have a
> > strong opinion either way. But don't make me do more work because
> > you are lazy, that never ends well.
>
> IMO we should just make repoman commit update the ChangeLog.

What if we wanted to remove ChangeLogs then for autogeneration? Will we
require all devs to quickly update their portage versions?

--
Best regards,
Michał Górny
 
Old 06-08-2011, 09:45 AM
Samuli Suominen
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On 06/08/2011 12:28 PM, Dirkjan Ochtman wrote:
> On Wed, Jun 8, 2011 at 11:27, Patrick Lauer <patrick@gentoo.org> wrote:
>> In all cases I want one resource to look at, viewcvs is a horrible and
>> slow interface. So it does make sense to keep changelogs filled with
>> information - maybe automation is needed, I don't have a strong opinion
>> either way. But don't make me do more work because you are lazy, that
>> never ends well.
>
> IMO we should just make repoman commit update the ChangeLog.

Then repoman commit should have a flag to leave out removals from
ChangeLog entries so unlazy people can still leave the cruft out from them.

Ref. http://bugs.gentoo.org/show_bug.cgi?id=365373
 
Old 06-08-2011, 09:50 AM
Patrick Lauer
 
Default gentoo-x86 commit in app-arch/bzip2: bzip2-1.0.5-r1.ebuild

On 06/08/11 11:43, Michał Górny wrote:
> On Wed, 8 Jun 2011 11:28:47 +0200
> Dirkjan Ochtman <djc@gentoo.org> wrote:
>
>> On Wed, Jun 8, 2011 at 11:27, Patrick Lauer <patrick@gentoo.org>
>> wrote:
>>> In all cases I want one resource to look at, viewcvs is a horrible
>>> and slow interface. So it does make sense to keep changelogs filled
>>> with information - maybe automation is needed, I don't have a
>>> strong opinion either way. But don't make me do more work because
>>> you are lazy, that never ends well.
>>
>> IMO we should just make repoman commit update the ChangeLog.
>
> What if we wanted to remove ChangeLogs then for autogeneration? Will we
> require all devs to quickly update their portage versions?
>

Just make committing the ChangeLog fatal on the server side

There are enough ways to get it done ...

--
Patrick Lauer http://service.gentooexperimental.org

Gentoo Council Member and Evangelist
Part of Gentoo Benchmarks, Forensics, PostgreSQL, KDE herds
 

Thread Tools




All times are GMT. The time now is 01:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org