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 03-04-2009, 06:32 AM
Caleb Cushing
 
Default Regen2 ( was QA Overlay Layout support )

I'd like to start with, I'm not trying to stir up trouble but since
questions were asked i'll answer them.

> If you think neither should exist why do you have an opinion about this at all?

I merged the java-overlay into regen2 a couple of weeks ago. as of
right now I've no plans to support java-experimental.

I'm fine with overlays so long as working ebuilds spend no more than a
few weeks in them. I have my own development branch and half the stuff
that's in there that isn't in the main tree doesn't work. Things like
perl 5.10 have been rotting in an overlay for a year. Funtoo ( under
my direction ) and Regen2 have had it ~arch for over a month now. We
found one bug post release thus far. I filed a bug on xorg-server
1.6.0 not being in tree. It was resolved fixed (in overlay) (which
another bug clearly states it has amd64 build issues). since when has
(in overlay) been an acceptable solution to a missing package? I said
it before, the reason I like gentoo* distro's is I don't have to find
the repository to get the latest package, that's just a pain, in
ubuntu, in opensuse, in fedora... etc. But no more... officially
supported huge overlays have ruined this.

on the topic of sunrise, I approve of sunrise to a degree. I like the
non-reviewed half, but once they're reviewed they should be put in
tree. Isn't it true that some of those packages never get maintainers?

> What makes you think that overlays aren't for developers, aspiring developers
> and interested users where they are working on stuff?

users don't know how to hack. the very definition of user says that,
imo. There are developers, admins, and users. admins don't want
overlays, they are supposed to be unstable. users can't hack, so what
do they care. the problem is, an overlay has become a repo, I'm not
sure that it was originally intended for that.

> It is desirable IMO that
> all such people can easily be given full access to muck around and learn.

this does not mean officially supported overlays. You obviously won't
commit just anything to an officially supported overlay which suggests
that you don't allow 'mucking around'.

> Further, overlays are good places to put ebuilds for software that is more
> experimental than what's expected for ~arch. That includes live ebuilds. In the
> end, overlays have a (far) lower level of guaranteed quality than the main tree,
> for their ebuilds

because ~arch is supposed to work? take open bug on wine-1.1.16 it
doesn't build on amd64 and yet it's ~amd64. how about that nam ebuild
that has invalid bash that I mentioned? that's some quality work
there. The point is the tree is no better or worse than the overlays
in many cases.

> might even argue that Funtoo is one big overlay. When your own ability to
> contribute directly depends on an overlay, then why are you arguing against
> other people's overlays?

perhaps this is the real problem gentoo's primary way to accept user
contributions is via overlays. I disagree with the calling of Funtoo
as one big overlay, it's a replacement tree, and it provides
everything needed within that tree, as does regen2. overlays however
rely on an external tree, and now you've been discussing making them
rely on other overlays.

> Please point me to the people willing and having the time to maintain
> those >100 new ebuilds in the main tree.

given all the problems with the in tree ebuilds that aren't properly
maintained, I see no difference.

Regen2, is attempting to fix these problems, and more. I do try to get
my fixes back upstream here, but more often than not the bug
languishes. I don't think Gentoo is bad, but I do think it's taken a
wrong turn. But I suppose that these things are problems are simply my
opinion.

I've probably already offended a large share of people on this list,
now lets see if I can offend a few more by soliciting.

I consider Regen2 ready for use, but pre-release since I have yet to
roll ISO's and tarballs. Anyone who wants to help is welcome, be you
current, former or aspiring developer. More info at http://regen2.org

I will not discuss regen2 further on this list as I feel this is not
really the place, but I was asked. I am willing to discuss overlays
further, but I'm not sure I really have more to say. I suppose the
last thing would be back in the day I got everything from the tree, if
I wanted, needed something else I downloaded an individual ebuild, and
put it in /my/ local overlay. I didn't download a bunch of incomplete
mini-trees using a tool.
--
Caleb Cushing

http://xenoterracide.blogspot.com
 
Old 03-04-2009, 09:46 AM
Peter Alfredsen
 
Default Regen2 ( was QA Overlay Layout support )

On Wed, 4 Mar 2009 02:32:13 -0500
Caleb Cushing <xenoterracide@gmail.com> wrote:

> I'd like to start with, I'm not trying to stir up trouble but since
> questions were asked i'll answer them.
>
> > If you think neither should exist why do you have an opinion about
> > this at all?
>
> I merged the java-overlay into regen2 a couple of weeks ago. as of
> right now I've no plans to support java-experimental.

Then don't. Really.

> I filed a bug on xorg-server
> 1.6.0 not being in tree. It was resolved fixed (in overlay) (which
> another bug clearly states it has amd64 build issues). since when has
> (in overlay) been an acceptable solution to a missing package?


That's pretty much at developer discretion. Please note that we have to
have an actual working distribution, which means that sometimes we use
overlays to make basic QA checks against installed packages (Does it
build? Does it work?). That said, I try to not close bugs before
they've been resolved in-tree precisely because of the reaction that
provoked on bug 260582. I personally like to have my bugs reflect the
state of the tree.

Bugzilla is a tool for developers to track progress, not for
third-party distributions to track progress. You've forked the tree.
That's fine. The license allows that. But it doesn't obligate us to
adapt our tools to fit your purpose. Bugzilla is a strictly
technical tool, so comments on bugs should be kept free of ad hominem
remarks. From all parties.

Your behavior on bug 260582 was clearly unacceptable. You
seem to think that we owe you something. Please re-examine your
premises. Donnie already told you he was working on it. Our job is not
to support your distribution. It is to make the best distro for
ourselves. In the case of xorg-server, that means getting something
into the tree that works. A masked ebuild will in this case be more
bother than it's worth because the mask would have to encompass a
bunch of other packages. Which leads me on to the next paragraph...

> I said it before, the reason I like gentoo* distro's is I don't have
> to find the repository to get the latest package, that's just a pain,
> in ubuntu, in opensuse, in fedora... etc. But no more... officially
> supported huge overlays have ruined this.

Please contact me on IRC. I'll mentor you. It shouldn't be painful for
someone as knowledgeable as you. That way you get to fix most problems
yourself. If you prefer someone else to mentor you, we can probably
arrange that too.

> on the topic of sunrise, I approve of sunrise to a degree. I like the
> non-reviewed half, but once they're reviewed they should be put in
> tree. Isn't it true that some of those packages never get maintainers?

They need maintainers to be maintained in-tree. Sorry, but that's the
deal.

> users don't know how to hack. the very definition of user says that,
> imo. There are developers, admins, and users. admins don't want
> overlays, they are supposed to be unstable. users can't hack, so what
> do they care. the problem is, an overlay has become a repo, I'm not
> sure that it was originally intended for that.

It wasn't. And if an admin has a problem with overlays he can become a
developer. *hint*

There are too many possible packages for the number of developers we
have in Gentoo. But that'll always be the case, probably, no matter how
many developers you pour in. If you have specific grievances, the
recruitment process is the obvious remedy since you seem to have the
time, the ability and the will to adress them.

> this does not mean officially supported overlays. You obviously won't
> commit just anything to an officially supported overlay which suggests
> that you don't allow 'mucking around'.

The only thing in Gentoo that's 'officially supported' is the tree.

> > Further, overlays are good places to put ebuilds for software that
> > is more experimental than what's expected for ~arch. That includes
> > live ebuilds. In the end, overlays have a (far) lower level of
> > guaranteed quality than the main tree, for their ebuilds
>
> because ~arch is supposed to work? take open bug on wine-1.1.16 it
> doesn't build on amd64 and yet it's ~amd64.

QA fail, amd64 keyword dropped.

> how about that nam ebuild
> that has invalid bash that I mentioned? that's some quality work
> there. The point is the tree is no better or worse than the overlays
> in many cases.

In many cases that's true, but on average, the QA of the tree is much
better than overlays.

> perhaps this is the real problem gentoo's primary way to accept user
> contributions is via overlays. I disagree with the calling of Funtoo
> as one big overlay, it's a replacement tree, and it provides
> everything needed within that tree, as does regen2.

We Need Git. It would really ease the workflow of accepting user
contributions if users could just set up their own overlay and sent me
an email asking to merge their changesets.

> overlays however
> rely on an external tree, and now you've been discussing making them
> rely on other overlays.

Personally, I think that any itch that's scratch-worthy is commendable
but I would personally abstain from the rather elaborate java overlay
setup. Not because it doesn't work, it does to a degree, but because it
keeps potential developers away from Gentoo, instead playing in
sandboxes. And because it's a pain in the neck to keep track of
packages that aren't being used.

> Regen2, is attempting to fix these problems, and more. I do try to get
> my fixes back upstream here, but more often than not the bug
> languishes. I don't think Gentoo is bad, but I do think it's taken a
> wrong turn. But I suppose that these things are problems are simply my
> opinion.

We need to get you recruited. Why haven't you pushed us more? You could
have made thousands of commits already, fixing a substantial amount of
the problems you've raised. I know the perl herd is always in need of
new devs. This isn't a quick fix. You'll have to work with people and
that can sometimes be frustrating. But you'll get to be part of the
development process and you'll get to work with the things you care
about.

> I've probably already offended a large share of people on this list,
> now lets see if I can offend a few more by soliciting.

If people can't take a bit of honest criticism, we've become too
thin-skinned.

/loki_val
 
Old 03-04-2009, 12:59 PM
Thomas Anderson
 
Default Regen2 ( was QA Overlay Layout support )

On Wed, Mar 04, 2009 at 02:32:13AM -0500, Caleb Cushing wrote:
> > Further, overlays are good places to put ebuilds for software that is more
> > experimental than what's expected for ~arch. That includes live ebuilds. In the
> > end, overlays have a (far) lower level of guaranteed quality than the main tree,
> > for their ebuilds
>
> because ~arch is supposed to work? take open bug on wine-1.1.16 it
> doesn't build on amd64 and yet it's ~amd64. how about that nam ebuild
> that has invalid bash that I mentioned? that's some quality work
> there. The point is the tree is no better or worse than the overlays
> in many cases.

Heh, that's the problem with ~arch. ~amd64 keywords aren't added for
every new version; keywords are carried over from the previous version.
Having to test each new version of a package before it receiving a
keyword puts far too much stress on the arch teams(who are struggling
under the current workload, a lot of >75 stable request bugs). What
happens is the keyword gets carried over from the previous version. So
if a developer screws up, the arch teams really have no idea because 1)
we don't get assigned any bug with our keyword in it. 2) We don't run
~arch.

--
---------
Thomas Anderson
Gentoo Developer
/////////
Areas of responsibility:
AMD64, Secretary to the Gentoo Council
---------
 
Old 03-04-2009, 10:17 PM
Caleb Cushing
 
Default Regen2 ( was QA Overlay Layout support )

> Bugzilla is a tool for developers to track progress, not for
> third-party distributions to track progress. You've forked the tree.
> That's fine. The license allows that. But it doesn't obligate us to
> adapt our tools to fit your purpose.

I've done lots of version bump bugs over the years. my reasons for
doing so may have changed. But the general process has not. Does it
matter if I've forked? doesn't the package still need an update?

> Your behavior on bug 260582 was clearly unacceptable. You
> seem to think that we owe you something. Please re-examine your
> premises. Donnie already told you he was working on it. Our job is not
> to support your distribution. It is to make the best distro for
> ourselves. In the case of xorg-server, that means getting something
> into the tree that works. A masked ebuild will in this case be more
> bother than it's worth because the mask would have to encompass a
> bunch of other packages. Which leads me on to the next paragraph...

this and all the cases given are examples, and perhaps my behavior was
unacceptable. But I think the response to my bug was too. No gentoo
doesn't owe me or regen2, a thing. It might, however, owe users
something. I agree on committing ebuilds that work, that doesn't mean
I don't have the right to open a bug and watch for progress reports.

> In many cases that's true, but on average, the QA of the tree is much
> better than overlays.

I couldn't say... I suppose I agree yes on most overlays, but a few
are supposed to be more 'exceptional'. the biggest problem is the bugs
that result between ebuilds in the tree and those of overlays. like
one I filed on virtual/perl-Mime-Base64. or like how inkscape won't
build against 5.10, except with patches already in bugzilla, but both
cases seemed to be one of 'perl 5.10 isn't in the tree so we won't
fix' I think they should put it in before 5.10 is in the tree. put
that's just me.

> We Need Git. It would really ease the workflow of accepting user
> contributions if users could just set up their own overlay and sent me
> an email asking to merge their changesets.

git's great. but I've actually found 'merging' changesets to be a bad
idea from people. It can lead to some really sloppy commits, and
merging is a less stringent review than cherry-picking patches.

> You could
> have made thousands of commits already, fixing a substantial amount of
> the problems you've raised.

thousands seem like a high number. I think I've been pushing an
average one 1 patch per day since january to the tree (my tree).
*laughing* I'm still the #1 contributor of git patches to funtoo.

> This isn't a quick fix.

> You'll have to work with people and
> that can sometimes be frustrating.

I already have to 'work' with these people, the difference would be
what? how much respect I get? in gentoo land having @gentoo.org seems
to mean something... if you don't have that, you seem to
auto-magically get less respect, than you would if you did have it.

> But you'll get to be part of the
> development process and you'll get to work with the things you care
> about.

you mean I'll be part of 'a' development process and work on some of
the things I care about. Obviously stepping on other developers toes
seems to be a taboo.
--
Caleb Cushing

http://xenoterracide.blogspot.com
 
Old 03-04-2009, 10:19 PM
Caleb Cushing
 
Default Regen2 ( was QA Overlay Layout support )

On Wed, Mar 4, 2009 at 8:59 AM, Thomas Anderson <gentoofan23@gentoo.org> wrote:
> eh, that's the problem with ~arch. ~amd64 keywords aren't added for
> every new version; keywords are carried over from the previous version.
> Having to test each new version of a package before it receiving a
> keyword puts far too much stress on the arch teams

I'm not talking about testing before... I was talking about removing
it after. I understand that not everything can always be tested
before. But when it's found to be broken, there shouldn't have been an
argument about the kewords removal in lieu of a proper fix.
--
Caleb Cushing

http://xenoterracide.blogspot.com
 
Old 03-05-2009, 12:11 AM
"Jorge Manuel B. S. Vicetto"
 
Default Regen2 ( was QA Overlay Layout support )

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

Caleb Cushing wrote:
> I'd like to start with, I'm not trying to stir up trouble but since
> questions were asked i'll answer them.
>
>> If you think neither should exist why do you have an opinion about this at all?
>
> I merged the java-overlay into regen2 a couple of weeks ago. as of
> right now I've no plans to support java-experimental.
>
> I'm fine with overlays so long as working ebuilds spend no more than a
> few weeks in them. I have my own development branch and half the stuff
> that's in there that isn't in the main tree doesn't work. Things like
> perl 5.10 have been rotting in an overlay for a year. Funtoo ( under
> my direction ) and Regen2 have had it ~arch for over a month now. We
> found one bug post release thus far. I filed a bug on xorg-server
> 1.6.0 not being in tree. It was resolved fixed (in overlay) (which
> another bug clearly states it has amd64 build issues). since when has
> (in overlay) been an acceptable solution to a missing package? I said
> it before, the reason I like gentoo* distro's is I don't have to find
> the repository to get the latest package, that's just a pain, in
> ubuntu, in opensuse, in fedora... etc. But no more... officially
> supported huge overlays have ruined this.

The single tree model is not the only one, nor necessarily the best one.
I understand your concern, but as ciaranm argued in another thread, the
issues many people seem to have with overlays are caused by the current
level of support by Portage. What we need is better support for multiple
repositories, not to drop them.
As it has been discussed before, multiple repositories could even foster
the development in Gentoo, instead of halting it down - as quite a few
people seem to be affraid of. If we can have some repositories focusing
in certain areas or relaxing access rules to a few repos, some devs
might get more focused and some packages might find new maintainers and
or their way into "mainline" Gentoo.
One issue that has been raised is about having testing ebuilds in
overlays instead of the tree. In a few cases, we have ebuilds in
overlays, not because of the lack of QA of the ebuilds, but because of
the experimental nature of the packages or because of the difficulty in
making packages comply to Gentoo rules. One example of a package that
was never in the tree, but instead on an overlay was XGL. It was never
considered to be stable enough to get into the tree. KDE-4 work started
in overlays and was kept there until 4.0 because it was more flexible to
work in the overlay than it would have been to do it in the tree. By the
way, KDE-4 is a good example of how work in overlays can help the tree -
what we had for 4.0 and have now in the tree was mostly done by people
that weren't Gentoo devs. Work in these overlays has lead to an
injection of many new devs.

...

> users don't know how to hack. the very definition of user says that,
> imo. There are developers, admins, and users. admins don't want
> overlays, they are supposed to be unstable. users can't hack, so what
> do they care. the problem is, an overlay has become a repo, I'm not
> sure that it was originally intended for that.

Fortunately, Gentoo users are not like some other distributions users.
I've seen many Gentoo users working in ebuilds and quite a few working
with devs to improve the Gentoo tree.
Most admins don't like unstable packages. Unfortunately quite a few of
them have to support new (testing) packages whether they like them or not.

...

>> Further, overlays are good places to put ebuilds for software that is more
>> experimental than what's expected for ~arch. That includes live ebuilds. In the
>> end, overlays have a (far) lower level of guaranteed quality than the main tree,
>> for their ebuilds
>
> because ~arch is supposed to work? take open bug on wine-1.1.16 it
> doesn't build on amd64 and yet it's ~amd64. how about that nam ebuild
> that has invalid bash that I mentioned? that's some quality work
> there. The point is the tree is no better or worse than the overlays
> in many cases.

If anything, I've been hearing lately complaints about the testing
branch having become the new stable branch, not that it's terribly broken.

...

> I've probably already offended a large share of people on this list,
> now lets see if I can offend a few more by soliciting.

I think you'll find a reasonable "tolerance level" in this ml about
technical issues and development models.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmvJroACgkQcAWygvVEyAJtEwCfYNY1EuJ4/ZEKOGBtKDX7VtOm
mtYAniAof1AWL5GMVtpbpZ1g6LCKf7GS
=i3Gl
-----END PGP SIGNATURE-----
 
Old 03-05-2009, 09:57 AM
"Marijn Schouten (hkBst)"
 
Default Regen2 ( was QA Overlay Layout support )

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

Caleb Cushing wrote:
>> Bugzilla is a tool for developers to track progress, not for
>> third-party distributions to track progress. You've forked the tree.
>> That's fine. The license allows that. But it doesn't obligate us to
>> adapt our tools to fit your purpose.
>
> I've done lots of version bump bugs over the years. my reasons for
> doing so may have changed. But the general process has not. Does it
> matter if I've forked? doesn't the package still need an update?

I think a lot (most?) of us agree that bugs shouldn't be closed until fixes hit
the main tree. But it indeed does not matter that you've forked, so you
shouldn't even have brought it up on the bug report. Bugs aren't a good way to
keep in touch with developers, that's what irc is for.

>> Your behavior on bug 260582 was clearly unacceptable. You
>> seem to think that we owe you something. Please re-examine your
>> premises. Donnie already told you he was working on it. Our job is not
>> to support your distribution. It is to make the best distro for
>> ourselves. In the case of xorg-server, that means getting something
>> into the tree that works. A masked ebuild will in this case be more
>> bother than it's worth because the mask would have to encompass a
>> bunch of other packages. Which leads me on to the next paragraph...
>
> this and all the cases given are examples, and perhaps my behavior was
> unacceptable. But I think the response to my bug was too. No gentoo
> doesn't owe me or regen2, a thing. It might, however, owe users
> something. I agree on committing ebuilds that work, that doesn't mean
> I don't have the right to open a bug and watch for progress reports.

No, you don't have that right. It's just how it usually works and how it should
work IMO, but that doesn't entitle you to it.

>> In many cases that's true, but on average, the QA of the tree is much
>> better than overlays.
>
> I couldn't say... I suppose I agree yes on most overlays, but a few
> are supposed to be more 'exceptional'. the biggest problem is the bugs
> that result between ebuilds in the tree and those of overlays. like
> one I filed on virtual/perl-Mime-Base64. or like how inkscape won't
> build against 5.10, except with patches already in bugzilla, but both
> cases seemed to be one of 'perl 5.10 isn't in the tree so we won't
> fix' I think they should put it in before 5.10 is in the tree. put
> that's just me.

And they probably will, but as perl-5.10 isn't in the tree, there is no rush.
Either way, it's the perl team's decision to go with the patch in bugzilla or
some other option and when they do it, whether they make that decision
consciously or are forced into it due to real life time-constraints.

>> We Need Git. It would really ease the workflow of accepting user
>> contributions if users could just set up their own overlay and sent me
>> an email asking to merge their changesets.
>
> git's great. but I've actually found 'merging' changesets to be a bad
> idea from people. It can lead to some really sloppy commits, and
> merging is a less stringent review than cherry-picking patches.

I've found that git's patches aren't really what we want in the case of bumping.
For bug reports we usually ask for a patch against the last ebuild in the tree.
Is there perhaps a way to make git do that automatically?

>> You could
>> have made thousands of commits already, fixing a substantial amount of
>> the problems you've raised.
>
> thousands seem like a high number. I think I've been pushing an
> average one 1 patch per day since january to the tree (my tree).
> *laughing* I'm still the #1 contributor of git patches to funtoo.

It's great that people are doing their own thing, but to get it into OUR tree it
will need to be comitted to OUR tree by someone who has access to OUR tree.
Patches are great, but commits are better.

>> This isn't a quick fix.
>
>> You'll have to work with people and
>> that can sometimes be frustrating.
>
> I already have to 'work' with these people, the difference would be
> what? how much respect I get? in gentoo land having @gentoo.org seems
> to mean something... if you don't have that, you seem to
> auto-magically get less respect, than you would if you did have it.

Your demands because of your feelings of entitlement are what are costing you
respect.

>> But you'll get to be part of the
>> development process and you'll get to work with the things you care
>> about.
>
> you mean I'll be part of 'a' development process and work on some of
> the things I care about. Obviously stepping on other developers toes
> seems to be a taboo.

Yes, it's extremely frowned upon to step on another developers toes; Gentoo is
not a one-man show. Would you like ME to stomp all over your tree? Didn't think so.

Just so we're clear. I really hope you change your attitude and take Peter
Alfredsen (loki_val) up on his generous offer.

Marijn

- --
Sarcasm puts the iron in irony, cynicism the steel.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmvsBoACgkQp/VmCx0OL2xGYQCfTcCXKZ7QOui0Btgkpj9AYBNt
8lMAnRbnWBP5i7tAzFRy68PWjrKPvij8
=n+6Y
-----END PGP SIGNATURE-----
 
Old 03-05-2009, 06:15 PM
Alistair Bush
 
Default Regen2 ( was QA Overlay Layout support )

Caleb Cushing wrote:

I'd like to start with, I'm not trying to stir up trouble but since
questions were asked i'll answer them.


If you think neither should exist why do you have an opinion about this at all?


I merged the java-overlay into regen2 a couple of weeks ago. as of
right now I've no plans to support java-experimental.



Please don't. Until less than a month ago, it was a qa nightmare ( even
java-overlay was). Im sure both overlays probably still have
unresolvable dependencies. And yes they are an example of piss poor qa
standards. Even now im sure there is stuff in java-overlay that is be
just plain broken. I would hate to think about what java-experimental
is like.
 
Old 03-06-2009, 10:09 AM
Caleb Cushing
 
Default Regen2 ( was QA Overlay Layout support )

> I've found that git's patches aren't really what we want in the case of bumping.
> *For bug reports we usually ask for a patch against the last ebuild in the tree.
> Is there perhaps a way to make git do that automatically?

well, git has copy detection, you can tell if a file is merely a copy
of the previous (if git format-patch is done right) you can also just
do a diff on it? you could probably put it in a hook. or write a
script... or numerous other ways. once the work is done, getting any
amount of varying diffs is easy.

the problem with git right now, is all the things that gentoo does for
cvs and rsync. git doesn't need as much manifesting, it doesn't need
the cvs headers, or ChangeLog files, all this stuff just clutters
things with git. but this is a 'right now' problem, that I'm working
to solve, most of it leads right back to manifests.

> It's great that people are doing their own thing, but to get it into OUR tree it
> will need to be comitted to OUR tree by someone who has access to OUR tree.
> Patches are great, but commits are better.

yes but your commit process is made more complicated by your tools. I
for the most part require that the entire commit be ready to go.

> Your demands because of your feelings of entitlement are what are costing you
> respect.

why do people keep telling me what I feel? anyone else ever notice
feelings don't convey well over text.

> Yes, it's extremely frowned upon to step on another developers toes; Gentoo is
> not a one-man show. Would you like ME to stomp all over your tree? Didn't think so.

that depends on what you mean by 'stomp' if by stomp you mean fix
problems for users, stomp away. if by stomp you mean break stuff, then
no. I don't care if you change something I changed if it's better,
it's better.

> Just so we're clear. I really hope you change your attitude and take Peter
> Alfredsen (loki_val) up on his generous offer.

and my attitude is? what is it that you think I think?

I may take him up. but I'm also considering the possible conflict of
interest, as well as the additional time requirement. I hope you
understand. even if I do I have a commitment to what I've already
started.
--
Caleb Cushing

http://xenoterracide.blogspot.com
 
Old 03-06-2009, 11:12 AM
"Marijn Schouten (hkBst)"
 
Default Regen2 ( was QA Overlay Layout support )

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

Caleb Cushing wrote:
>> Your demands because of your feelings of entitlement are what are costing you
>> respect.
>
> why do people keep telling me what I feel? anyone else ever notice
> feelings don't convey well over text.

Well, you spoke of "owing users", and "the right to open a bug and watch for
progress reports" combined with this:

"right now you are the kind of person that thinks being a volunteer is a
privilege and not a responsibility. You think that because you don't get paid
that you don't have to do it. I assure you that if you look at most non foss
volunteer jobs you either have to do your job or quit. it is the same in open
source. perhaps I'm judging you wrongly." --
https://bugs.gentoo.org/show_bug.cgi?id=260582#c6

It seems like you want to tell us how to do our jobs. It seems like you think
you have the right to tell us what to do. Now, I'm happy to be wrong about those
views, but that's what it looks like to me.

>> Yes, it's extremely frowned upon to step on another developers toes; Gentoo is
>> not a one-man show. Would you like ME to stomp all over your tree? Didn't think so.
>
> that depends on what you mean by 'stomp' if by stomp you mean fix
> problems for users, stomp away. if by stomp you mean break stuff, then
> no. I don't care if you change something I changed if it's better,
> it's better.

The point is that you don't know whether someone else has a good judgement of
better. People that have been taking care of certain parts of the tree may just
know something you don't. This is why we encourage people to talk to maintainers
when they touch their packages but also encourage maintainers not to feel too
possessive.

>> Just so we're clear. I really hope you change your attitude and take Peter
>> Alfredsen (loki_val) up on his generous offer.
>
> and my attitude is? what is it that you think I think?

I've answered that above.

> I may take him up. but I'm also considering the possible conflict of
> interest, as well as the additional time requirement. I hope you
> understand. even if I do I have a commitment to what I've already
> started.

On your blog[1] you imply that if you decide to not, that you wouldn't be able
to "to talk to people to understand something". I just want to stress that this
is not so. Many of us are available on #gentoo-dev-help and this mailing list
for technical questions.

Marijn

[1]:http://xenoterracide.blogspot.com/2009/03/to-gentoo-dev-or-not-to-gentoo-dev.html

- --
Sarcasm puts the iron in irony, cynicism the steel.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmxEyEACgkQp/VmCx0OL2xG7QCgwCML2vEUSIO6LBeXSIYcApRT
J8sAnR7AgV4EeyiZnNLYQH0SsoKia0+s
=YNn/
-----END PGP SIGNATURE-----
 

Thread Tools




All times are GMT. The time now is 05:40 PM.

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