[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Fri, 19 Apr 2013 09:16:32 +0000 (UTC)
"Ben de Groot (yngwin)" <yngwin@gentoo.org> wrote:

> Index: package.mask
> ===================================================================
> RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
> retrieving revision 1.14667
> retrieving revision 1.14668
> diff -u -r1.14667 -r1.14668
> --- package.mask	19 Apr 2013 06:20:50 -0000	1.14667
> +++ package.mask	19 Apr 2013 09:16:32 -0000	1.14668
[...]
> @@ -133,6 +133,7 @@
>  # Non-maintainer ebuild with experimental multilib features
>  # masked for further testing
>  =media-libs/freetype-2.4.11-r2
> +=media-libs/fontconfig-2.10.2-r1
>  

Is there any real reason behind this mask I may have missed ? Because
so far, it is only breaking the deptree:
 dependency.bad                14
   x11-libs/libXft/libXft-2.3.1-r1.ebuild: DEPEND:
   ~amd64(default/linux/amd64/13.0)
   ['media-libs/freetype[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]',
   'media-libs/fontconfig[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]']



Alexis.

PS: btw, some hunks are weird in your commit, a locale issue ?

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Jeroen Roovers]

On Fri, 19 Apr 2013 15:30:43 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> Is there any real reason behind this mask I may have missed ? Because
> so far, it is only breaking the deptree:
>  dependency.bad                14
>    x11-libs/libXft/libXft-2.3.1-r1.ebuild: DEPEND:
>    ~amd64(default/linux/amd64/13.0)
>    ['media-libs/freetype[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]',
>    'media-libs/fontconfig[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]']

https://bugs.gentoo.org/show_bug.cgi?id=466546


     jer

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 19 April 2013 21:30, Alexis Ballier <aballier@gentoo.org> wrote:

> On Fri, 19 Apr 2013 09:16:32 +0000 (UTC)
> "Ben de Groot (yngwin)" <yngwin@gentoo.org> wrote:
>
> > Index: package.mask
> > ===================================================================
> > RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
> > retrieving revision 1.14667
> > retrieving revision 1.14668
> > diff -u -r1.14667 -r1.14668
> > --- package.mask      19 Apr 2013 06:20:50 -0000      1.14667
> > +++ package.mask      19 Apr 2013 09:16:32 -0000      1.14668
> [...]
> > @@ -133,6 +133,7 @@
> >  # Non-maintainer ebuild with experimental multilib features
> >  # masked for further testing
> >  =media-libs/freetype-2.4.11-r2
> > +=media-libs/fontconfig-2.10.2-r1
> >
>
> Is there any real reason behind this mask I may have missed ?


This ebuild, with multilib features, was committed without my consent,
while I am the de facto maintainer of freetype and fontconfig (other devs
in fonts herd are inactive). I don't want to deal with bug reports because
of this.

And I'd rather see this developed in an overlay instead, as I have said
before. We also need more consensus on this multilib approach before I am
happy to support this.



> Because
> so far, it is only breaking the deptree:
>  dependency.bad                14
>    x11-libs/libXft/libXft-2.3.1-r1.ebuild: DEPEND:
>    ~amd64(default/linux/amd64/13.0)
>    ['media-libs/freetype[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]',
>    'media-libs/fontconfig[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?]']
>
>
> Alexis.
>
> PS: btw, some hunks are weird in your commit, a locale issue ?
>

No, just a line in my vimrc that removes trailing whitespace.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Denis Dupeyron]

I'm hoping this kind of immature and abrasive behaviours will not
propagate (notice the plural here). Yes, when you see a package being
actively maintained by somebody else you should absolutely not touch
it without talking to that person or team first. This is probably the
single most important rule in Gentoo and I would like to thank Ben for
reminding us of it. But nobody owns anything in Gentoo. As a developer
you're not king of the hill but servant of the users. The only way to
make yourself more relevant is by doing a better job, not by barking
at the others to protect your territory. By the way folks, a better
job also involves communication and behaviour which is what we all
generally suck at.

Denis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Sun, Apr 21, 2013 at 10:11 AM, Denis Dupeyron <calchan@gentoo.org> wrote:
> But nobody owns anything in Gentoo. As a developer
> you're not king of the hill but servant of the users. The only way to
> make yourself more relevant is by doing a better job, not by barking
> at the others to protect your territory.

I think that has to be qualified.

If you're developing a package, and somebody else wants to add new
functionality/features/etc, and is willing to put in the time to
support them, then yes, it isn't your territory, and they can
co-maintain.

However, if somebody just commits something to your package, and it
causes you headaches, and they aren't committing to long-term
maintenance of the package, then yes, you can revert, etc.

The bottom line is that package maintenance is a long-term commitment.
 You can't modify an ebuild and walk away, in general.  Oh, sure, if
you're just renaming a dependency or something there is room for
exceptions.  However, you don't change how a package works without
cooperating with the maintainer, or becoming one yourself.

The alternative is a Gentoo where packages that are working just fine
get abandoned because somebody messes with them, and then the
maintainer isn't allowed to maintain them the way they like and so
they find something better to do with their time, leaving nobody
maintaining the package.

I don't know the specifics of this case so nobody should take this as
finger-pointing unless it is your conscience doing the pointing.
Maintainers don't "own" packages, but it is in everybody's interest to
keep maintainers happy.  Any dev can step up and co-maintain any
package, but they have to be in it for the long term.  If you don't
like how somebody else is maintaining their package, and you're not
willing to assume responsibility for it long term, then just consider
yourself an end-user, and pretend you don't have commit rights.  The
only exceptions to this apply to projects like council, QA, etc, and
those should represent even larger long-term commitments (and for the
most part these bodies use more discretion anyway).

Rich

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Chí-Thanh Christopher Nguyễn]

Denis Dupeyron schrieb:
> I'm hoping this kind of immature and abrasive behaviours will not
> propagate (notice the plural here). Yes, when you see a package being
> actively maintained by somebody else you should absolutely not touch
> it without talking to that person or team first.

I fail to see any wrong behavior here. A bug report was created and a review
of the changes was requested. The first reaction came after several weeks
after the bug filing, and the first objection almost two months after the
change was applied.
https://bugs.gentoo.org/show_bug.cgi?id=455074

Then the maintainer came and masked his package, which I see nothing wrong
with either. Except for the violation of visibility requirements only in this
particular case.

> By the way folks, a better
> job also involves communication and behaviour which is what we all
> generally suck at.

When someone asks about changing a package which someone else maintains, I
always suggest reporting a bug about it. Do you think that is generally ok,
or not the proper way to communicate?


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Denis Dupeyron]

On Sun, Apr 21, 2013 at 8:23 AM, Rich Freeman <rich0@gentoo.org> wrote:
> However, if somebody just commits something to your package, and it
> causes you headaches, and they aren't committing to long-term
> maintenance of the package, then yes, you can revert, etc.

That's where you're wrong. You can revert if necessary *after* you've
talked to the person. Either he's wrong or you're wrong, but most
likely you are both wrong to argue about it. By the way, the real fix
for headaches is ibuprofene and then some rest, not reverting commits.

Denis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Denis Dupeyron]

On Sun, Apr 21, 2013 at 8:38 AM, Chí-Thanh Christopher Nguyễn
<chithanh@gentoo.org> wrote:
> When someone asks about changing a package which someone else maintains, I
> always suggest reporting a bug about it. Do you think that is generally ok,
> or not the proper way to communicate?

Exactly. Bugzilla is not a communication tool, it's a process
management tool. The process in question is dealing with bugs. Don't
substitute filing a bug for communication. The main reason people end
up having these abrasive behaviours is they don't communicate
properly. If they did they'd find out they are actually very much
alike and agree on most things. Communication is (in order of
effectivity) in-person meeting, phone, irc, email. If you're not using
any of these tools you're not communicating effectively and you can't
expect things to go smoothly.

Denis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Sun, 21 Apr 2013 20:53:28 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 19 April 2013 21:30, Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Fri, 19 Apr 2013 09:16:32 +0000 (UTC)
> > "Ben de Groot (yngwin)" <yngwin@gentoo.org> wrote:
> >
> > > Index: package.mask
> > > ===================================================================
> > > RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
> > > retrieving revision 1.14667
> > > retrieving revision 1.14668
> > > diff -u -r1.14667 -r1.14668
> > > --- package.mask      19 Apr 2013 06:20:50 -0000      1.14667
> > > +++ package.mask      19 Apr 2013 09:16:32 -0000      1.14668
> > [...]
> > > @@ -133,6 +133,7 @@
> > >  # Non-maintainer ebuild with experimental multilib features
> > >  # masked for further testing
> > >  =media-libs/freetype-2.4.11-r2
> > > +=media-libs/fontconfig-2.10.2-r1
> > >
> >
> > Is there any real reason behind this mask I may have missed ?
> 
> 
> This ebuild, with multilib features, was committed without my consent,
> while I am the de facto maintainer of freetype and fontconfig (other
> devs in fonts herd are inactive). I don't want to deal with bug
> reports because of this.

Fair enough, but there is a lack of coordination there (who started the
mess is irrelevant), leaving as only choices: unmask ft/fc or mask a
good part of the multilib x11 stuff. The current situation is broken.

I suppose you talked with Michal about this and couldn't reach an
agreement, like him joining the fonts herd, or at least the mail alias
to monitor ft/fc bugs.

If you want I can join the fonts herd also, I already have a foot in
there for some small packages used within texlive anyway.

> And I'd rather see this developed in an overlay instead, as I have
> said before. We also need more consensus on this multilib approach
> before I am happy to support this.

I believe we reached consensus last time. Also, I believe we are at the
step "it is mature enough to give it a wide ~arch testing"; otherwise
we may just repeat multilib-portage history and have it in an overlay
for several years to never give it wide adoption in the end.

[...]

Alexis.

[OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Sun, 21 Apr 2013 20:53:28 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> >
> > PS: btw, some hunks are weird in your commit, a locale issue ?
> >
> 
> No, just a line in my vimrc that removes trailing whitespace.
> 

You should probably disable it or remove trailing whitespaces in a
separate commit though. Having functional changes mixed with
whitespace/cosmetics in a single commit makes it hard to read
and understand.

[This is really a nitpick, no need to have a debate, it's only a
suggestion ;)]

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Chí-Thanh Christopher Nguyễn]

Denis Dupeyron schrieb:
>> When someone asks about changing a package which someone else maintains, I
>> always suggest reporting a bug about it. Do you think that is generally ok,
>> or not the proper way to communicate?
> 
> Exactly. Bugzilla is not a communication tool, 

> Communication is (in order of
> effectivity) in-person meeting, phone, irc, email.

But all comments in bugs are sent to the maintainer via email, at least in
default settings. So in my opinion, the communication aspect of email is also
included in bugzilla.

> If you're not using
> any of these tools you're not communicating effectively and you can't
> expect things to go smoothly.

I think that over direct email, bugzilla has the advantage of being visible
in the public record. And in contrast to mailing lists, only interested
parties will receive the messages.

But if you think that is not the case, we can ask council to clarify whether
a change announced in bugzilla counts as proper communication with the
maintainer.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Sun, 21 Apr 2013 17:07:41 +0200
Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org> wrote:

> Denis Dupeyron schrieb:
> >> When someone asks about changing a package which someone else
> >> maintains, I always suggest reporting a bug about it. Do you think
> >> that is generally ok, or not the proper way to communicate?
> > 
> > Exactly. Bugzilla is not a communication tool, 
> 
> > Communication is (in order of
> > effectivity) in-person meeting, phone, irc, email.
> 
> But all comments in bugs are sent to the maintainer via email, at
> least in default settings. So in my opinion, the communication aspect
> of email is also included in bugzilla.
> 
> > If you're not using
> > any of these tools you're not communicating effectively and you
> > can't expect things to go smoothly.
> 
> I think that over direct email, bugzilla has the advantage of being
> visible in the public record. And in contrast to mailing lists, only
> interested parties will receive the messages.
> 
> But if you think that is not the case, we can ask council to clarify
> whether a change announced in bugzilla counts as proper communication
> with the maintainer.

It's probably something in between: proper communication is when the
other party has received and understood your message. It can fail in
every of the above mentioned methods for a wide variety of reasons ;)
(eg: poorly explained, not listening, not willing to listen, being
drunk, gmail ate my email, etc.)

Alexis.

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Tom Wijsman]

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

On Sun, 21 Apr 2013 17:05:49 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 21 Apr 2013 20:53:28 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> > >
> > > PS: btw, some hunks are weird in your commit, a locale issue ?
> > >
> > 
> > No, just a line in my vimrc that removes trailing whitespace.
> > 
> 
> You should probably disable it or remove trailing whitespaces in a
> separate commit though. Having functional changes mixed with
> whitespace/cosmetics in a single commit makes it hard to read
> and understand.

You should just convert the commit diff to not include space changes.

> [This is really a nitpick, no need to have a debate, it's only a
> suggestion ;)]

[There are two sides to a debate; so, the nitpick goes both ways. ;)]

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Sun, 21 Apr 2013 17:32:26 +0200
Tom Wijsman <TomWij@gentoo.org> wrote:

> On Sun, 21 Apr 2013 17:05:49 +0200
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 21 Apr 2013 20:53:28 +0800
> > Ben de Groot <yngwin@gentoo.org> wrote:
> > > >
> > > > PS: btw, some hunks are weird in your commit, a locale issue ?
> > > >
> > > 
> > > No, just a line in my vimrc that removes trailing whitespace.
> > > 
> > 
> > You should probably disable it or remove trailing whitespaces in a
> > separate commit though. Having functional changes mixed with
> > whitespace/cosmetics in a single commit makes it hard to read
> > and understand.
> 
> You should just convert the commit diff to not include space changes.

How? Sometimes space changes matter a lot...

Alexis.

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> > > No, just a line in my vimrc that removes trailing whitespace.
> > 
> > You should probably disable it or remove trailing whitespaces in a
> > separate commit though.

I agree strongly with this.


> > Having functional changes mixed with whitespace/cosmetics in a
> > single commit makes it hard to read and understand.
> 
> You should just convert the commit diff to not include space changes.

Tom, I don't understand what you mean here? Who should do the convert
and why?

In the ideal case, there should never be any whitespace changes in a
repository history. But we programmers frequently prove ourselves
unable to accomplish anything ideal, and whitespace is no exception.

Writing good code takes experience and awareness, and many if not
most are just interested in banging out something that works.

Since we have to live with whitespace changes, because someone
put broken whitespace into the repo before we got here, we should
at least make an effort to minimize the impact, and the best way is
to make them a separate commit.

That also helps significantly when using some of the nontrivial
functionality in Git, and while it could be argued that portage
isn't using Git yet it is anyway not a bad idea to get into habits
which support the most efficient and powerful use of Git for when
portage has migrated.

And of course the same applies to all repositories - so the good
habits mean immediate advantages in other repos where Git is already
being used.

Specifically, interactive rebase on its own or combined with
bisecting become a lot easier and quicker with clean commits.

I know people who are amazing in many ways but who fail to recgonize
those benefits. I'm not yet sure why that is and I fear that they
have some cognitive bias against Git. Try not to be that person,
because it doesn't help anyone. If something becomes easier by using
a particular process or workflow, then I think that's a good reason
to do it.


//Peter

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Tom Wijsman]

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

On Sun, 21 Apr 2013 18:00:42 +0200
Peter Stuge <peter@stuge.se> wrote:

> > You should just convert the commit diff to not include space
> > changes.
> 
> Tom, I don't understand what you mean here? Who should do the convert
> and why?

It's a human error for both ends, it can thus be done on both sides.

> Writing good code takes experience and awareness, and many if not
> most are just interested in banging out something that works.

Good code ideally is tested.

> ... minimize the impact, and the best way is to ...

Depends on whose impact you minimize, s/best/alternative/.

> Specifically, interactive rebase on its own or combined with
> bisecting become a lot easier and quicker with clean commits.

Rebasing is overkill in the Portage tree and not needed; as for bisect,
it makes it worse because you introduce extra commits to bisect.

> Try not to be that person, because it doesn't help anyone.

I'm not rooting either side, I just hate the noise that occurs when
neither side takes an effort to fix it. I can tell from a private mail
from one of the persons that at least one side is interested, I'm not
so sure about the other side; but well, better than an endless debate.

> If something becomes easier by using a particular process or
> workflow, then I think that's a good reason to do it.

And that's why I responded, I won't respond any further to this thread.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge]

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

Tom Wijsman wrote:
> > > You should just convert the commit diff to not include space
> > > changes.
> > 
> > Tom, I don't understand what you mean here? Who should do the convert
> > and why?
> 
> It's a human error for both ends, it can thus be done on both sides.

Hm, I'm not sure I follow.

When a commit is created there's only one human involved; the person
creating the commit. We should all try to avoid whitespace changes in
all commits.

Are you arguing that because people who happen to read commits and
source code can provide options to hide whitespace changes in commits
and/or use indent to always reformat source there is no point in
avoiding whitespace changes (by getting formatting right the first
time) and being strict about code style?


> > Writing good code takes experience and awareness, and many if not
> > most are just interested in banging out something that works.
> 
> Good code ideally is tested.

I see testing as orthogonal to writing code.

The two can complement each other very nicely, but code can be good
without testing, and testing does not reliably turn otherwise
bad code into good. But testing can certainly preempt lots of both
simple and advanced issues, like for example, broken whitespace.


> > ... minimize the impact, and the best way is to ...
> 
> Depends on whose impact you minimize, s/best/alternative/.

I refer to the impact of whitespace changes (noise) in the repository
on anyone and everyone who interacts with the repository in some way
beyond usage.


> > Specifically, interactive rebase on its own or combined with
> > bisecting become a lot easier and quicker with clean commits.
> 
> Rebasing is overkill in the Portage tree

I don't think this can be said with certanity. Git allows new things
which might lead to a situation where rebasing simply makes sense.


> and not needed;

I don't know about that at all.


> as for bisect, it makes it worse because you introduce extra
> commits to bisect.

The extra commit may mean one extra test cycle, but if tests are
automated that doesn't matter much. The benefit is that the *other*
commit can much more easily be moved around, as I wrote, rebasing
combined with bisecting.


In any case, I guess you aren't arguing that because some more
advanced uses of Git are perhaps not immediately useful there is no
point in clean code style?


> > Try not to be that person, because it doesn't help anyone.
> 
> I'm not rooting either side,

Understood - I want to clarify that I did not get the impression that
you were, the "Try not to be that person" was a very broad request to
everyone listening.


> I just hate the noise that occurs when neither side takes an effort
> to fix it.

Consider that commits in version control systems are immutable, so
it's not really possible to "fix" things there.

I think the only real fix is to avoid that whitespace errors are
committed in the first place.


//Peter

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Michał Górny]

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

On Sun, 21 Apr 2013 17:05:49 +0200
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 21 Apr 2013 20:53:28 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> > >
> > > PS: btw, some hunks are weird in your commit, a locale issue ?
> > >
> > 
> > No, just a line in my vimrc that removes trailing whitespace.
> 
> You should probably disable it or remove trailing whitespaces in a
> separate commit though. Having functional changes mixed with
> whitespace/cosmetics in a single commit makes it hard to read
> and understand.

While I'm usually strongly for that, I would just like to point out
that we're using CVS and 'repoman commit', and these two together make
committing a really painful and time-consuming experience. I can see
the benefit of avoiding a second commit just to fix whitespace.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 21 April 2013 22:38, Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org>wrote:

> Denis Dupeyron schrieb:
> > I'm hoping this kind of immature and abrasive behaviours will not
> > propagate (notice the plural here). Yes, when you see a package being
> > actively maintained by somebody else you should absolutely not touch
> > it without talking to that person or team first.
>
> I fail to see any wrong behavior here. A bug report was created and a
> review
> of the changes was requested. The first reaction came after several weeks
> after the bug filing, and the first objection almost two months after the
> change was applied.
> https://bugs.gentoo.org/show_bug.cgi?id=455074
>

You are missing an important part of the story.
See https://bugs.gentoo.org/show_bug.cgi?id=455070 where we discuss
the same issue for freetype. (Yes I should have been explicit for fontconfig
too, my bad.)

I initially reacted within hours, saying that his proposal was in my eyes
not ready yet. I assumed I was clear enough in my refusal, but
apparently Michał didn't understand it that way. He then contacted
the herd a few weeks later, when I was on holiday, and got Luca's permission
to commit, not taking into account he hadn't touched those packages in
many years.

After I found out, I was a bit pissed off about it, but I was too busy with
work to deal with it (and thought it wise to cool down a bit before taking
action). I then saw bug reports about the freetype multilib ebuild revision
flooding in, and was satisfied after it got masked.

But then it got unmasked again (I assume by Michał), and when I found
some time to take a closer look again at freetype and fontconfig, I decided
to mask those versions, as I still don't think they are ready (especially
for
ebuilds that might go stable soon).



>
> Then the maintainer came and masked his package, which I see nothing wrong
> with either. Except for the violation of visibility requirements only in
> this
> particular case.
>
>
I understand this is a bit of a mess, and I'm sorry for my part in it, but
I'm
not part of the x11 herd, so I would rather leave it up to you to decide
how
you want to handle this.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 21 April 2013 22:59, Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 21 Apr 2013 20:53:28 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
> > On 19 April 2013 21:30, Alexis Ballier <aballier@gentoo.org> wrote:
> >
> > > On Fri, 19 Apr 2013 09:16:32 +0000 (UTC)
> > > "Ben de Groot (yngwin)" <yngwin@gentoo.org> wrote:
> > >
> > > > Index: package.mask
> > > > ===================================================================
> > > > RCS file: /var/cvsroot/gentoo-x86/profiles/package.mask,v
> > > > retrieving revision 1.14667
> > > > retrieving revision 1.14668
> > > > diff -u -r1.14667 -r1.14668
> > > > --- package.mask      19 Apr 2013 06:20:50 -0000      1.14667
> > > > +++ package.mask      19 Apr 2013 09:16:32 -0000      1.14668
> > > [...]
> > > > @@ -133,6 +133,7 @@
> > > >  # Non-maintainer ebuild with experimental multilib features
> > > >  # masked for further testing
> > > >  =media-libs/freetype-2.4.11-r2
> > > > +=media-libs/fontconfig-2.10.2-r1
> > > >
> > >
> > > Is there any real reason behind this mask I may have missed ?
> >
> >
> > This ebuild, with multilib features, was committed without my consent,
> > while I am the de facto maintainer of freetype and fontconfig (other
> > devs in fonts herd are inactive). I don't want to deal with bug
> > reports because of this.
>
> Fair enough, but there is a lack of coordination there (who started the
> mess is irrelevant), leaving as only choices: unmask ft/fc or mask a
> good part of the multilib x11 stuff. The current situation is broken.
>

I agree it is broken. I'm trying to do my part for the packages I maintain.
In my opinion all the recent multilib stuff should be masked, but I don't
maintain those other (x11) packages. So you may want to handle it in
a different way.


> I suppose you talked with Michal about this and couldn't reach an
> agreement, like him joining the fonts herd, or at least the mail alias
> to monitor ft/fc bugs.
>
> If you want I can join the fonts herd also, I already have a foot in
> there for some small packages used within texlive anyway.
>

We could certainly use a hand in fonts herd. Most members have
left or are on extended non-active status. It's just lu_zero (and I am
not sure how active he is wrt fonts packages, but it certainly doesn't
cover freetype and fontconfig) and me.

> And I'd rather see this developed in an overlay instead, as I have
> > said before. We also need more consensus on this multilib approach
> > before I am happy to support this.
>
> I believe we reached consensus last time. Also, I believe we are at the
> step "it is mature enough to give it a wide ~arch testing"; otherwise
> we may just repeat multilib-portage history and have it in an overlay
> for several years to never give it wide adoption in the end.
>

Maybe I missed something, but I haven't seen anything like that.
Can you point me to those discussions?

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 21 April 2013 23:05, Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 21 Apr 2013 20:53:28 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
> > >
> > > PS: btw, some hunks are weird in your commit, a locale issue ?
> > >
> >
> > No, just a line in my vimrc that removes trailing whitespace.
> >
>
> You should probably disable it or remove trailing whitespaces in a
> separate commit though. Having functional changes mixed with
> whitespace/cosmetics in a single commit makes it hard to read
> and understand.
>
> [This is really a nitpick, no need to have a debate, it's only a
> suggestion ;)]
>
> Alexis.
>

I don't see the problem. Also, in this case I see only one extra hunk.
But once we have proper tools (like git) we can revisit this.
I don't think there is currently any guideline in devmanual that
recommends not mixing functional changes with cosmetics.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 21 April 2013 22:11, Denis Dupeyron <calchan@gentoo.org> wrote:

> I'm hoping this kind of immature and abrasive behaviours will not
> propagate (notice the plural here).
>

I'm not sure exactly which behaviours you're calling immature and abrasive,
but it seems to me you're overreacting again. Please stay out if this.
-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [OT/NIT] Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Mon, 22 Apr 2013 20:00:38 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 21 April 2013 23:05, Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > On Sun, 21 Apr 2013 20:53:28 +0800
> > Ben de Groot <yngwin@gentoo.org> wrote:
> > > >
> > > > PS: btw, some hunks are weird in your commit, a locale issue ?
> > > >
> > >
> > > No, just a line in my vimrc that removes trailing whitespace.
> > >
> >
> > You should probably disable it or remove trailing whitespaces in a
> > separate commit though. Having functional changes mixed with
> > whitespace/cosmetics in a single commit makes it hard to read
> > and understand.
> >
> > [This is really a nitpick, no need to have a debate, it's only a
> > suggestion ;)]
> >
> > Alexis.
> >
> 
> I don't see the problem.

"Having functional changes mixed with whitespace/cosmetics in a single
 commit makes it hard to read and understand."

> Also, in this case I see only one extra hunk.
> But once we have proper tools (like git) we can revisit this.

I don't see how git helps. You'll have to commit twice then push, vs
commit twice with cvs.

> I don't think there is currently any guideline in devmanual that
> recommends not mixing functional changes with cosmetics.

I was pretty sure there was one but can't find it anymore. Anyway, I
don't think there needs to be any rule for this, it is common sense.

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alexis Ballier]

On Mon, 22 Apr 2013 19:56:49 +0800
Ben de Groot <yngwin@gentoo.org> wrote:
> I agree it is broken. I'm trying to do my part for the packages I
> maintain. In my opinion all the recent multilib stuff should be
> masked, but I don't maintain those other (x11) packages. So you may
> want to handle it in a different way.

Part of what one is supposed to check prior to changing the visibility
of a package is that it doesn't break the deptree ;)


> > I suppose you talked with Michal about this and couldn't reach an
> > agreement, like him joining the fonts herd, or at least the mail
> > alias to monitor ft/fc bugs.
> >
> > If you want I can join the fonts herd also, I already have a foot in
> > there for some small packages used within texlive anyway.
> >
> 
> We could certainly use a hand in fonts herd. Most members have
> left or are on extended non-active status. It's just lu_zero (and I am
> not sure how active he is wrt fonts packages, but it certainly doesn't
> cover freetype and fontconfig) and me.

Ok; added myself to the mail alias at least.


> > And I'd rather see this developed in an overlay instead, as I have
> > > said before. We also need more consensus on this multilib approach
> > > before I am happy to support this.
> >
> > I believe we reached consensus last time. Also, I believe we are at
> > the step "it is mature enough to give it a wide ~arch testing";
> > otherwise we may just repeat multilib-portage history and have it
> > in an overlay for several years to never give it wide adoption in
> > the end.
> >
> 
> Maybe I missed something, but I haven't seen anything like that.
> Can you point me to those discussions?

[gentoo-dev] [PATCHES] multilib-build: public API for header wrapping
[gentoo-dev] [PATCH] Support wrapping headers for multilib ABIs.
[gentoo-dev] [PATCHES] Header wrapping support for multilib


These 3 came after discussing that multilib-portage does it, that it is
needed for multilib, and thus should be done by an eclass based system.

[gentoo-dev] [RFC] multilib-build.eclass and restricting unsupported
ABIs

and maybe others, but on this last thread tommy clearly said that he
was ok with the approach (under some conditions); I don't know what
else you need as consensus :)

Alexis.

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Michał Górny]

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

On Mon, 22 Apr 2013 19:43:22 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> On 21 April 2013 22:38, Chí-Thanh Christopher Nguyễn <chithanh@gentoo.org>wrote:
> 
> > Denis Dupeyron schrieb:
> > > I'm hoping this kind of immature and abrasive behaviours will not
> > > propagate (notice the plural here). Yes, when you see a package being
> > > actively maintained by somebody else you should absolutely not touch
> > > it without talking to that person or team first.
> >
> > I fail to see any wrong behavior here. A bug report was created and a
> > review
> > of the changes was requested. The first reaction came after several weeks
> > after the bug filing, and the first objection almost two months after the
> > change was applied.
> > https://bugs.gentoo.org/show_bug.cgi?id=455074
> >
> 
> You are missing an important part of the story.
> See https://bugs.gentoo.org/show_bug.cgi?id=455070 where we discuss
> the same issue for freetype. (Yes I should have been explicit for fontconfig
> too, my bad.)
> 
> I initially reacted within hours, saying that his proposal was in my eyes
> not ready yet. I assumed I was clear enough in my refusal, but
> apparently Michał didn't understand it that way. He then contacted
> the herd a few weeks later, when I was on holiday, and got Luca's permission
> to commit, not taking into account he hadn't touched those packages in
> many years.

Just to be clear -- I misunderstood you indeed. I thought you mean that
you would agree if the idea is discussed and the discussion results in
a general agreement on proceeding with the solution.

> After I found out, I was a bit pissed off about it, but I was too busy with
> work to deal with it (and thought it wise to cool down a bit before taking
> action). I then saw bug reports about the freetype multilib ebuild revision
> flooding in, and was satisfied after it got masked.

Those bugs weren't relevant to the final version of the ebuild which
you have masked. The only actual bug left open was the one which I
forgot to close after fixing it instantly after it was opened.

So please don't say that I don't take responsibility for my changes.

-- 
Best regards,
Michał Górny

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

[gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Duncan]

Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:

> "Having functional changes mixed with whitespace/cosmetics in a single
>  commit makes it hard to read and understand."
> 
>> Also, in this case I see only one extra hunk.
>> But once we have proper tools (like git) we can revisit this.
> 
> I don't see how git helps. You'll have to commit twice then push, vs
> commit twice with cvs.

But git commits are quite lightweight, while as someone already pointed 
out, cvs commits, if done properly with repoman, are anything but.

So at least in the sense that it'll be less hassle, two git commits 
followed by a push should be much easier than two repoman and cvs commits.

-- 
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] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ryan Hill]

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

On Mon, 22 Apr 2013 19:56:49 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

> > I suppose you talked with Michal about this and couldn't reach an
> > agreement, like him joining the fonts herd, or at least the mail alias
> > to monitor ft/fc bugs.
> >
> > If you want I can join the fonts herd also, I already have a foot in
> > there for some small packages used within texlive anyway.
> >
> 
> We could certainly use a hand in fonts herd. Most members have
> left or are on extended non-active status. It's just lu_zero (and I am
> not sure how active he is wrt fonts packages, but it certainly doesn't
> cover freetype and fontconfig) and me.

As the previous maintainer of these packages, I think they should be maintained
by the x11 team as well as fonts.  Fonts has been dead for a while and freetype
at least needs a dedicated maintainer.

No offense to lu_zero, but he has a habit of popping in, applying some
non-upstreamed patch to a critical project, and then disappearing again.

On the other hand, you applied infinality, so you're not on my favorite people
list either.  :P


-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 23 April 2013 01:13, Michał Górny <mgorny@gentoo.org> wrote:

> On Mon, 22 Apr 2013 19:43:22 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
> > On 21 April 2013 22:38, Chí-Thanh Christopher Nguyễn <
> chithanh@gentoo.org>wrote:
> >
> > > Denis Dupeyron schrieb:
> > > > I'm hoping this kind of immature and abrasive behaviours will not
> > > > propagate (notice the plural here). Yes, when you see a package being
> > > > actively maintained by somebody else you should absolutely not touch
> > > > it without talking to that person or team first.
> > >
> > > I fail to see any wrong behavior here. A bug report was created and a
> > > review
> > > of the changes was requested. The first reaction came after several
> weeks
> > > after the bug filing, and the first objection almost two months after
> the
> > > change was applied.
> > > https://bugs.gentoo.org/show_bug.cgi?id=455074
> > >
> >
> > You are missing an important part of the story.
> > See https://bugs.gentoo.org/show_bug.cgi?id=455070 where we discuss
> > the same issue for freetype. (Yes I should have been explicit for
> fontconfig
> > too, my bad.)
> >
> > I initially reacted within hours, saying that his proposal was in my eyes
> > not ready yet. I assumed I was clear enough in my refusal, but
> > apparently Michał didn't understand it that way. He then contacted
> > the herd a few weeks later, when I was on holiday, and got Luca's
> permission
> > to commit, not taking into account he hadn't touched those packages in
> > many years.
>
> Just to be clear -- I misunderstood you indeed.


I know, and it's water under the bridge. We're people and we make mistakes
sometimes. Let's move on.


> I thought you mean that
> you would agree if the idea is discussed and the discussion results in
> a general agreement on proceeding with the solution.


That and ample testing. I think it has been going all a bit too quick, with
the eclass(es) in flux, and so on. I'm still not convinced it's mature
enough
at this point, which is why I believe this should still be masked.

As to the discussion, I see only a few people speaking up, but obviously
you cannot be blamed for the silent majority.

But it's starting to look more and more like I'm the only one objecting
at this point. So maybe I should stop being cautious (or even cranky)
and let you guys go ahead and do your work. I do need someone to
co-maintain freetype and fontconfig then, as I am personally still not
happy with these changes and the maintenance burden they create.


> > After I found out, I was a bit pissed off about it, but I was too busy
> with
> > work to deal with it (and thought it wise to cool down a bit before
> taking
> > action). I then saw bug reports about the freetype multilib ebuild
> revision
> > flooding in, and was satisfied after it got masked.
>
> Those bugs weren't relevant to the final version of the ebuild which
> you have masked. The only actual bug left open was the one which I
> forgot to close after fixing it instantly after it was opened.
>
> So please don't say that I don't take responsibility for my changes.


I'm not saying that at all. You respond quickly. I can only commend you
on that.

But I do have doubts about long term maintainance. I know you are
more than willing to do your part, but it's simply beyond any one
person to (co-)maintain half the tree.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ben de Groot]

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

On 23 April 2013 11:58, Ryan Hill <dirtyepic@gentoo.org> wrote:

> On Mon, 22 Apr 2013 19:56:49 +0800
> Ben de Groot <yngwin@gentoo.org> wrote:
>
> > > I suppose you talked with Michal about this and couldn't reach an
> > > agreement, like him joining the fonts herd, or at least the mail alias
> > > to monitor ft/fc bugs.
> > >
> > > If you want I can join the fonts herd also, I already have a foot in
> > > there for some small packages used within texlive anyway.
> > >
> >
> > We could certainly use a hand in fonts herd. Most members have
> > left or are on extended non-active status. It's just lu_zero (and I am
> > not sure how active he is wrt fonts packages, but it certainly doesn't
> > cover freetype and fontconfig) and me.
>
> As the previous maintainer of these packages, I think they should be
> maintained
> by the x11 team as well as fonts.  Fonts has been dead for a while and
> freetype
> at least needs a dedicated maintainer.
>

Fonts herd isn't dead, but most of the member have dispersed. Matsuu and
pva are
inactive, and lu_zero is busy with other things it seems. So that leaves
me. I've
always had an interest in fonts, so I'm happy to do this, but I don't have
the time
to properly maintain all packages belonging to the herd. So help is more
than
welcome.


> No offense to lu_zero, but he has a habit of popping in, applying some
> non-upstreamed patch to a critical project, and then disappearing again.
>
> On the other hand, you applied infinality, so you're not on my favorite
> people
> list either.  :P


We'll need to agree to disagree then. Anyway, no one was taking care of
freetype
and fontconfig at the time I picked up maintenance. So there you have it.

I would be happy to have someone join the fonts team and co-maintain
freetype and fontconfig. I just want to make sure infinality will remain
available to our users.

-- 
Cheers,

Ben | yngwin
Gentoo developer
Gentoo Qt project lead, Gentoo Wiki admin

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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Jeroen Roovers]

On Mon, 22 Apr 2013 22:46:14 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
> > I don't see how git helps. You'll have to commit twice then push, vs
> > commit twice with cvs.
> 
> But git commits are quite lightweight, while as someone already
> pointed out, cvs commits, if done properly with repoman, are anything
> but.

Er, you can't be seriously suggesting we will drop repoman checks with
the migration to git? I don't see how that would benefit anyone.


      jer

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <jer@gentoo.org> wrote:
> Er, you can't be seriously suggesting we will drop repoman checks with
> the migration to git? I don't see how that would benefit anyone.
>

Interesting point.  One thing to keep in mind with git is that commits
don't affect the "central repository."  Pushes are what impacts the
repository.

If I spend six months working on a bunch of coordinated package
changes, nobody will see a thing until I push those commits and 500
ebuilds all change atomically (not that I'm suggesting that lack of
communication is to be encouraged).  A repoman check on a commit may
not reflect its impact six months later when it actually hits the main
tree.

The right time to run repoman is probably right before doing a push,
regardless of when any git commits were made.  That isn't to say that
it can't be run sooner.

So, splitting something up into multiple commits can be very
lightweight, if repoman is only run before the push.  This might
create a need to be able to run repoman on more than one package
directory, but on less than the entire tree (otherwise you'll end up
having to do another pull/rebase before you push anyway).

Rich

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Matt Turner]

On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <jer@gentoo.org> wrote:
>> Er, you can't be seriously suggesting we will drop repoman checks with
>> the migration to git? I don't see how that would benefit anyone.
>>
>
> Interesting point.  One thing to keep in mind with git is that commits
> don't affect the "central repository."  Pushes are what impacts the
> repository.
>
> If I spend six months working on a bunch of coordinated package
> changes, nobody will see a thing until I push those commits and 500
> ebuilds all change atomically (not that I'm suggesting that lack of
> communication is to be encouraged).  A repoman check on a commit may
> not reflect its impact six months later when it actually hits the main
> tree.

... if you're squashing 6 months of work into a single commit before pushing.

I don't think we want to do that, do we? Maybe bisecting isn't
particularly interesting for the portage tree.

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Matt Turner]

On Tue, Apr 23, 2013 at 11:00 AM, Jeroen Roovers <jer@gentoo.org> wrote:
> On Mon, 22 Apr 2013 22:46:14 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
>> > I don't see how git helps. You'll have to commit twice then push, vs
>> > commit twice with cvs.
>>
>> But git commits are quite lightweight, while as someone already
>> pointed out, cvs commits, if done properly with repoman, are anything
>> but.
>
> Er, you can't be seriously suggesting we will drop repoman checks with
> the migration to git? I don't see how that would benefit anyone.

I didn't interpret it that way. cvs commits are just kind of
expensive, even without repoman doing checks.

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <mattst88@gentoo.org> wrote:
> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers <jer@gentoo.org> wrote:
>>> Er, you can't be seriously suggesting we will drop repoman checks with
>>> the migration to git? I don't see how that would benefit anyone.
>>>
>>
>> Interesting point.  One thing to keep in mind with git is that commits
>> don't affect the "central repository."  Pushes are what impacts the
>> repository.
>>
>> If I spend six months working on a bunch of coordinated package
>> changes, nobody will see a thing until I push those commits and 500
>> ebuilds all change atomically (not that I'm suggesting that lack of
>> communication is to be encouraged).  A repoman check on a commit may
>> not reflect its impact six months later when it actually hits the main
>> tree.
>
> ... if you're squashing 6 months of work into a single commit before pushing.
>
> I don't think we want to do that, do we? Maybe bisecting isn't
> particularly interesting for the portage tree.

I never said that I was squashing 6 months of work into a single
commit, only that I was pushing 6 months worth of commits in a single
operation.

Any repoman checks done at the time of each commit are essentially
worthless.  Consider this example:

1.  Create app-misc/foo-1.2 which depends on app-misc/bar.  Repoman
checks this and it is fine.
2.  Do 500 other commits.
3.  Push it all to the tree six months later.
4.  Get bug report that app-misc/bar was renamed two months back.

Repoman is about checking changes to the main repository.  What
matters isn't how the change you made impacts your clone of the
repository, but how that change impacts the main repository when it
eventually makes its way back.

Unless your workflow is to pull, commit, and push with no intervening
commits by other contributors, the repoman check needs to be done
before the push, not the commit.

Rich

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Matt Turner]

On Tue, Apr 23, 2013 at 12:11 PM, Rich Freeman <rich0@gentoo.org> wrote:
> Any repoman checks done at the time of each commit are essentially
> worthless.  Consider this example:

Unless you're bisecting a change that was in those 6 months of
commits. You could introduce a problem in one commit and fix it in the
next and have intermediate breakage.

But, like I said, maybe bisection isn't useful for the portage tree.

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/04/13 03:11 PM, Rich Freeman wrote:
> On Tue, Apr 23, 2013 at 2:37 PM, Matt Turner <mattst88@gentoo.org>
> wrote:
>> On Tue, Apr 23, 2013 at 11:20 AM, Rich Freeman <rich0@gentoo.org>
>> wrote:
>>> On Tue, Apr 23, 2013 at 2:00 PM, Jeroen Roovers
>>> <jer@gentoo.org> wrote:
>>>> Er, you can't be seriously suggesting we will drop repoman
>>>> checks with the migration to git? I don't see how that would
>>>> benefit anyone.
>>>> 
>>> 
>>> Interesting point.  One thing to keep in mind with git is that
>>> commits don't affect the "central repository."  Pushes are what
>>> impacts the repository.
>>> 
>>> If I spend six months working on a bunch of coordinated
>>> package changes, nobody will see a thing until I push those
>>> commits and 500 ebuilds all change atomically (not that I'm
>>> suggesting that lack of communication is to be encouraged).  A
>>> repoman check on a commit may not reflect its impact six months
>>> later when it actually hits the main tree.
>> 
>> ... if you're squashing 6 months of work into a single commit
>> before pushing.
>> 
>> I don't think we want to do that, do we? Maybe bisecting isn't 
>> particularly interesting for the portage tree.
> 
> I never said that I was squashing 6 months of work into a single 
> commit, only that I was pushing 6 months worth of commits in a
> single operation.
> 
> Any repoman checks done at the time of each commit are essentially 
> worthless.  Consider this example:
> 
> 1.  Create app-misc/foo-1.2 which depends on app-misc/bar.
> Repoman checks this and it is fine. 2.  Do 500 other commits. 3.
> Push it all to the tree six months later. 4.  Get bug report that
> app-misc/bar was renamed two months back.
> 
> Repoman is about checking changes to the main repository.  What 
> matters isn't how the change you made impacts your clone of the 
> repository, but how that change impacts the main repository when
> it eventually makes its way back.
> 
> Unless your workflow is to pull, commit, and push with no
> intervening commits by other contributors, the repoman check needs
> to be done before the push, not the commit.
> 
> Rich
> 


This makes a lot of sense to me too -- repoman checks that are
absolutely -needed- are those run at push time, specifically when
pushing to master.  'git commit' time doesn't have an equivalent in
cvs, but to me the checks that should be done at this time would be
covered by the 'repoman -d full' checks we're already supposed to do,
and I don't think those need to be enforced.

Alternatively, we could enforce repoman checks on any commit or push
operation in master, and leave branches to their own devices.  Of
course, I haven't seen (or looked for, tbh) how tree development will
be implemented/suggested to be done in git so I've no idea what role
branches might play..




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

iF4EAREIAAYFAlF24C0ACgkQ2ugaI38ACPASUQD/VqYe+f28wPGByWjcCicWiF5e
84vjyyrMxS3IF1qLeisA/jzfePn7pID8RsUqLYUtdSF+xo6dZDhLJgQARelS4yMx
=bywE
-----END PGP SIGNATURE-----

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Michał Górny]

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

On Mon, 22 Apr 2013 22:46:14 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
> 
> > "Having functional changes mixed with whitespace/cosmetics in a single
> >  commit makes it hard to read and understand."
> > 
> >> Also, in this case I see only one extra hunk.
> >> But once we have proper tools (like git) we can revisit this.
> > 
> > I don't see how git helps. You'll have to commit twice then push, vs
> > commit twice with cvs.
> 
> But git commits are quite lightweight, while as someone already pointed 
> out, cvs commits, if done properly with repoman, are anything but.
> 
> So at least in the sense that it'll be less hassle, two git commits 
> followed by a push should be much easier than two repoman and cvs commits.

Just to make it clear -- there are four CVS commits. Ebuild commit
followed by GPG-signed Manifest commit. Hopefully the developer has
persistent SSH connections set up.

-- 
Best regards,
Michał Górny

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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Tue, Apr 23, 2013 at 3:25 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> Alternatively, we could enforce repoman checks on any commit or push
> operation in master, and leave branches to their own devices.  Of
> course, I haven't seen (or looked for, tbh) how tree development will
> be implemented/suggested to be done in git so I've no idea what role
> branches might play..

Keep in mind that the following are all roughly equivalent in the world of git:
1.  The master branch on anything other than the copy of the
repository hosted by infra.
2.  Some other named branch anywhere.
3.  An overlay.

Just because you're committing to master doesn't mean that anybody
will ever see it.

As far as how things will go - this seems very much TBD.  There have
been various random thoughts on this list, and in IRC discussions.

My two cents:

1.  For most routine work, just do it all in master, rebasing commits,
so that in the end it looks just like the current CVS (well, assuming
CVS had cross-file atomic commits).

2.  For big projects, do the work in an overlay first.  Then for
staging purposes consider a short-term branch in the main repository
with frequent rebasing during any QA checks, then do one big
fast-forward-merge at the end.  That lets you do big atomic tree-wide
changes without blocking commits, and having the final merge in a
single commit (think KDE stabilization, big eclass changes, etc).

We already have overlays, so I'm not sure we want to end up with lots
of long-term branches in the main portage repository.

All of this is of course talking about the portage tree.  More
traditional software development projects like portage (the software),
eudev, etc should of course use more traditional use of git.

Rich

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Jeroen Roovers]

On Tue, 23 Apr 2013 21:31:10 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Just to make it clear -- there are four CVS commits. Ebuild commit
> followed by GPG-signed Manifest commit. Hopefully the developer has
> persistent SSH connections set up.

AFAIK setting these up still isn't properly documented. I once read
about it in a post somewhere by robbat2 and have been using this ever
since, and I also recall suggesting using persistent SSH connections
without finding a trace of evidence of their use in developer
documentation.


     jer

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Tom Wijsman]

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

On Mon, 22 Apr 2013 22:46:14 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
> 
> > "Having functional changes mixed with whitespace/cosmetics in a
> > single commit makes it hard to read and understand."
> > 
> >> Also, in this case I see only one extra hunk.
> >> But once we have proper tools (like git) we can revisit this.
> > 
> > I don't see how git helps. You'll have to commit twice then push, vs
> > commit twice with cvs.
> 
> But git commits are quite lightweight, while as someone already
> pointed out, cvs commits, if done properly with repoman, are anything
> but.
> 
> So at least in the sense that it'll be less hassle, two git commits 
> followed by a push should be much easier than two repoman and cvs
> commits.
> 

Maybe the question is rather why `repoman` takes 15 seconds on a quite
fast system in a package folder that contains 2 ebuilds and 1 metadata.

See the call graph for repoman at http://i.imgur.com/OQTUBdR.png.

A third of the time, ~5 seconds, are spent on 60,000 - 70,000 calls to
the function that is listed in the bottom; but the ebuilds barely
list any dependencies. Why are there so much calls to this?

A third of the time, ~5 seconds, are spent on visibility; if we look at
the `emerge -puDN @world` call graph (http://i.imgur.com/A93CdNR.png)
we also see visibility checks taking a prominent enough place. If this
is part is really needed, we may look at how we can improve this and at
the same time improvement the dependency calculation and repoman times.

Last third of the time, ~5 seconds, are spent on regular expressions
and mostly configuration; why is configuration so invasive here?

My thoughts are that we may be able to shave ten seconds of this time.

-- 
With kind regards,

Tom Wijsman (TomWij)
Gentoo Developer

E-mail address  : TomWij@gentoo.org
GPG Public Key  : 6D34E57D
GPG Fingerprint : C165 AF18 AB4C 400B C3D2  ABF0 95B2 1FCD 6D34 E57D

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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Zac Medico]

On 04/23/2013 01:27 PM, Tom Wijsman wrote:
> Maybe the question is rather why `repoman` takes 15 seconds on a quite
> fast system in a package folder that contains 2 ebuilds and 1 metadata.
> 
> See the call graph for repoman at http://i.imgur.com/OQTUBdR.png.
> 
> A third of the time, ~5 seconds, are spent on 60,000 - 70,000 calls to
> the function that is listed in the bottom; but the ebuilds barely
> list any dependencies. Why are there so much calls to this?

There's lots of redundant repetition involved in repoman's iteration
over the profiles listed in profiles.desc. It may be possible to
optimize away the redundancy by taking advantage of all the things that
each of the profiles have in common.
-- 
Thanks,
Zac

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Duncan]

Ben de Groot posted on Wed, 24 Apr 2013 00:24:13 +0800 as excerpted:

> I just want to make sure infinality will remain
> available to our users.

To save others wondering WTF infinality is the google I had to do...

http://www.infinality.net/blog/infinality-freetype-patches/

https://wiki.archlinux.org/index.php/Font_Configuration#Infinality

-- 
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] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Duncan]

Jeroen Roovers posted on Tue, 23 Apr 2013 20:00:53 +0200 as excerpted:

> On Mon, 22 Apr 2013 22:46:14 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> 
>> Alexis Ballier posted on Mon, 22 Apr 2013 15:40:33 +0200 as excerpted:
>> > I don't see how git helps. You'll have to commit twice then push, vs
>> > commit twice with cvs.
>> 
>> But git commits are quite lightweight, while as someone already pointed
>> out, cvs commits, if done properly with repoman, are anything but.
> 
> Er, you can't be seriously suggesting we will drop repoman checks with
> the migration to git? I don't see how that would benefit anyone.

Rich and others have already covered it, but since it was my post you 
replied to with the question, I'll confirm, what they said was what I had 
in mind...

Just because you're doing a git commit doesn't mean you're doing a push 
to the main infra-hosted tree.  Individual git commits are as I said, 
(very) light weight, making even a five-minute "autosave" commit process 
entirely feasible on the local working branch.  (Presumably, if one were 
to do that, a rebase would be done condensing all those auto-saves into a 
single atomic commit at the next higher branch level... branches too 
being /very/ lightweight with git, thus enabling an auto-save branch, a 
session-save branch, an atomic-commit branch..., with each of these 
possible for each of a dozen different individual projects a dev might be 
undertaking in parallel... no problem from a git perspective!)

But repoman has little to do with them since all it cares about is that 
the rules are followed when the changes get pushed to the tree.  Commit/
branch all you want locally, then run repoman on the "upstreaming" branch 
before the push to infra (or to a public overlay or whatever, if an 
overlay is being used as an intermediate step).

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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge]

Jeroen Roovers wrote:
> Er, you can't be seriously suggesting we will drop repoman checks
> with the migration to git? I don't see how that would benefit anyone.

I would argue that repoman and/or corresponding checks should be run
by a CI system hooked up to the Gerrit instance that developers push to.

Anything else is IMO waste of developers' time and minds.


//Peter

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge]

Peter Stuge wrote:
> Jeroen Roovers wrote:
> > Er, you can't be seriously suggesting we will drop repoman checks
> > with the migration to git? I don't see how that would benefit anyone.
> 
> I would argue that repoman and/or corresponding checks should be run
> by a CI system hooked up to the Gerrit instance that developers push to.
> 
> Anything else is IMO waste of developers' time and minds.

Sorry, I meant to write: "Anything less"


//Peter

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Michael Mol]

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

On 04/24/2013 07:21 AM, Peter Stuge wrote:
> Jeroen Roovers wrote:
>> Er, you can't be seriously suggesting we will drop repoman checks
>> with the migration to git? I don't see how that would benefit anyone.
> 
> I would argue that repoman and/or corresponding checks should be run
> by a CI system hooked up to the Gerrit instance that developers push to.
> 
> Anything else is IMO waste of developers' time and minds.

I was thinking something similar, actually, except you'd need something
like this:

1. dev pushes to Gerrit
2. Gerrit does processing
3. Gerrit pushes to tree, if tests pass.

It would necessitate needing a separate mechanism to be able to undo
changes to tree that broke things Gerrit missed, or it would necessitate
"undo" steps being pushed through Gerrit. Both have their disadvantages.

It might also result in only being able to push one changeset at a time,
due to this scenario:

1. Dev A pulls from tree
2. Dev A merges those changes with his local copy of tree
3. Dev A pushes to Gerrit
4. Gerrit begins tests on changeset A
5. Dev B pulls from tree (or perhaps he pulled earlier)
6. Gerrit is still testing changeset A
7. Dev B merges those changes with his local copy of tree
8. Gerrit finishes testing, pushes to tree
9. Dev B pushes to Gerrit
10. Gerrit runs tests on changeset B
11. Gerrit finishes tests, pushes to tree
13. Gerrit's push to tree fails, since tree with changeset A isn't in
changeset B's ancestry.

Though you might be able to get around that by using git's email
features to email diffs, allowing Gerrit to pipeline them (unless one
diff set fails to apply after another has been applied, of course).




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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Wed, Apr 24, 2013 at 7:47 AM, Michael Mol <mikemol@gmail.com> wrote:
>
> 13. Gerrit's push to tree fails, since tree with changeset A isn't in
> changeset B's ancestry.
>

Honestly, this is a problem with any use of repoman with git unless
you let the server auto-merge trivial changes.  Cvs tracks commits at
the file level, and git does it at the repository level.  The chances
of somebody modifying the same files in the time it takes you to
stage, test, and commit a change in cvs are fairly low.  The chances
of somebody making any commit to the repository in the time it takes
you to rebase, do a repoman check, and push are much higher.

We might have to live with repoman being a manual process - then you'd
just pull/rebase-or-merge/push to get it to the tree and use your
brain to determine if it causes any problems (which does require
responsibility).

However, your specific example could be modified a bit to make it more robust:

1. Dev A pulls from tree
2. Dev A merges those changes with his local copy of tree
3. Dev A pushes to Gerrit
4. Gerrit begins tests on changeset A
5. Dev B pulls from tree (or perhaps he pulled earlier)
6. Gerrit is still testing changeset A
7. Dev B merges those changes with his local copy of tree
8. Gerrit finishes testing, pushes to tree
9. Dev B's push to Gerrit fails, since Gerrit's head isn't in B's ancestry.
10.  Dev B pulls, rebases, and re-pushes - possibly pulling directly
from Gerrit to reduce latency.

It still fails when you get high volumes, because the fundamental
issue is that it can only handle as many commits as Gerrit can test in
a given period of time, plus various latencies.

Rich

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Alex Xu]

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

Any reason why a pre-commit hook can't be used?

Assuming that `git push -f` is never used and that every committer uses
it, pre-commit is guaranteed to be executed on all commits that are
pushed to the remote.

pre-commit can check QA and even automate changelog, so instead of:

$ cvs update
$ cvs add foo
$ echangelog "fixed #xxxxxx in foo"
$ repoman commit

We have:

$ git pull
$ git add foo
$ echangelog "fixed #xxxxxx in foo"
$ git commit

To set up:

$ cat > .git/hooks/pre-commit << EOF
#!/bin/sh
repoman scan
EOF

Seems simple enough, as long as `repoman scan` runs quickly.


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

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Rich Freeman]

On Wed, Apr 24, 2013 at 4:04 PM, Alex Xu <alex_y_xu@yahoo.ca> wrote:
> Seems simple enough, as long as `repoman scan` runs quickly.
>

This is the key, because if a commit happens anywhere in your process,
your push will fail.

At first I thought you were suggesting a server-side hook.  This
essentially has the same problem, though.

Manually running repoman may be the cleanest solution.  By all means
people are welcome to use hooks if they're afraid they'll forget.
However, if you run repoman and it is fine, then you just need to
repeat pull/rebase, push until you get though.  Sure, there is a
slight risk something might get missed, but that risk is lower than it
is with cvs currently (since the git pull before your repoman check
updated the entire repository, and not just the current directory - I
doubt anybody does a cvs update on the whole repository before every
change as it is so much more expensive).

I think our policy should emphasize the what over the how.  The what
is we want commits that are free from stupid mistakes.  The how is
repoman.  We'll offer suggested workflows, and then it is up to the
committer to be responsible.

Rich

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Patrick Lauer]

On 04/24/2013 07:21 PM, Peter Stuge wrote:
> Jeroen Roovers wrote:
>> Er, you can't be seriously suggesting we will drop repoman checks
>> with the migration to git? I don't see how that would benefit anyone.
> 
> I would argue that repoman and/or corresponding checks should be run
> by a CI system hooked up to the Gerrit instance that developers push to.

So, let me get this straight ...

$now: Developer A makes a change to automake
$now+10min: Change is pushed to CI

...
...


$now + 2 weeks: Initial testrun done, 734 potential issues found
(and 2 weeks is a pretty generous optimistic estimate)


$now + 4 weeks: Triaging and 50% fixing done
$now + 8 weeks: Developer forgot about the issue while going on vacation

$now + 12 weeks: Developer B, unaware of the prior work, pushes the same
change again and waits 2 weeks too

etc. etc.
> 
> Anything else is IMO waste of developers' time and minds.

At least your idea is completely unrelated to reality and a waste of
developer's time and minds, but thanks for bringing up something
completely silly again.

Re: [gentoo-dev] Re: [OT/NIT] Re: Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Peter Stuge]

Michael Mol wrote:
> > I would argue that repoman and/or corresponding checks should be run
> > by a CI system hooked up to the Gerrit instance that developers push to.
> 
> I was thinking something similar, actually, except you'd need
> something like this:
> 
> 1. dev pushes to Gerrit
> 2. Gerrit does processing
> 3. Gerrit pushes to tree, if tests pass.

This is exactly how Gerrit works and indeed what I expect also Gentoo
to use. It's a very convenient workflow.


> It would necessitate needing a separate mechanism to be able to undo
> changes to tree that broke things Gerrit missed

Gerrit can be told to revert any changeset.


> It might also result in only being able to push one changeset at a
> time, due to this scenario:

The policy that Gerrit will use for adding commits in the output
repository is configurable.

One of the options is to require each commit to be a fast-forward.
This means that every single commit blocks all other commits, but
ensures that what is in the public repo is exactly what was tested.

I personally find that merge policy unworkable.

I tend to prefer cherry-pick, which means that commits pushed to
Gerrit can be included in the output repo in any order, and that
there is a risk for a merge conflict when Gerrit tries to pick the
commit. It also means that there is a risk of false test positives,
when the output repo has changed enough while the new commit was
being tested to cause the new commit to break something.

I personally find that merge policy the most practical, and
experience from a few projects shows that the number of actual
nontrivial problems is low if not zero.


> git's email features to email diffs

Nono, Gerrit does all of this already. Look into the documentation
and/or set up an installation to play around with.


Patrick Lauer wrote:
> > I would argue that repoman and/or corresponding checks should be run
> > by a CI system hooked up to the Gerrit instance that developers push to.
> 
> So, let me get this straight ...
> 
> $now: Developer A makes a change to automake
> $now+10min: Change is pushed to CI

What are the 10 minutes?


> $now + 2 weeks: Initial testrun done, 734 potential issues found
> (and 2 weeks is a pretty generous optimistic estimate)

I think you mean something else than I do with CI and testing.

It obviously doesn't make sense to build a whole lot of stuff per-commit.


> At least your idea is completely unrelated to reality and a waste of
> developer's time and minds, but thanks for bringing up something
> completely silly again.

You are behaving like an asshole. Please consider that what I
contribute might be useful for Gentoo, and that if you have a
different impression perhaps you have misunderstood something
and can politely ask me to clarify if I really intend what you
have interpreted. Thanks!


//Peter

[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in profiles: ChangeLog package.mask

[Ryan Hill]

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

On Wed, 24 Apr 2013 00:24:13 +0800
Ben de Groot <yngwin@gentoo.org> wrote:

>On 23 April 2013 11:58, Ryan Hill <dirtyepic@gentoo.org> wrote:

> > On the other hand, you applied infinality, so you're not on my favorite
> > people
> > list either.  :P

> We'll need to agree to disagree then. Anyway, no one was taking care of
> freetype
> and fontconfig at the time I picked up maintenance. So there you have it.
> 
> I would be happy to have someone join the fonts team and co-maintain
> freetype and fontconfig. I just want to make sure infinality will remain
> available to our users.

Sorry I realized it wasn't obvious I was joking.  Infinality is just my bugbear
of the month.  You're doing a fine job.


(to save Duncan some googling:  http://en.wiktionary.org/wiki/bugbear)
-- 
gcc-porting
toolchain, wxwidgets
@ gentoo.org

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