[gentoo-dev] apache and ~arch

[gentoo-dev] apache and ~arch

[Grant Goodyear]

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

Yes, I was one of the many people who emerged the new apache ebuild
without paying sufficient attention to the mailing list post announcing
the dramatic changes.  *Shrug*  It took me a day or so to get things
fixed, but that was my own fault, and I have no complaints about the
new config.  

On the other hand, I do have a concern about the frequent posts I've
seen from our apache devs along the lines of "They [who had broken their
systems] obviousely didn't care, [sic] that ~arch is for testing. That of
course implies, that not everything will succeed as expected."
[http://trapni-akane.org/blog/index.php/trapni/2005/03/12/apache_and_the_enduser]
The serious breakage for people occurred because the apache devs
released into ~arch the new apache ebuild before a number of rather
important apache-module ebuilds had been rewritten to use the new
apache config.  Now, I think we've all done things like that (forgotten
a dependency, or something that uses the current package as a
dependency, or missed an obscure USE flag) by accident, and that's why
we have an ~arch tree.  The ~arch tree, at least in my understanding,
is for testing ebuilds, and it's not surprising that sometimes the
e-build has an error in it.  However, I don't believe that ~arch should
be used for ebuilds that one _knows_ have broken functionality.  For
such cases we have package.mask.

So, what should one do about a package that, in and of itself, is fully
functional, but related packages have not yet been updated and package
maintainers cannot be urged to move faster to fix the packages?  Well, nagging
on bugs is usually the first step, followed by nagging on -dev so that
people know that there is a problem.  If that doesn't work, the 
traditional method is to patch the related ebuilds oneself, add the
patched ebuilds to package.mask in a nice big block along w/ the
principal package, and start asking people to test.  That way, once it
appears that the bugs are reasonably worked out the whole block can be
unmasked at once, minimizing pain for our users who "can't read".
Moreover, once this step is done it is perfectly reasonable to post a
bug and a message to -dev saying "New foo system seems to be working,
and we plan to unmask all at once in 30 days unless any maintainers of
these packages [provide list] explicitly tells us not to do so."

Might this approach take a long time and involve a lot of frustration?
Yes, of course it might.  I understand that in this case the non-masked
apache ebuild was lagging further and further behind upstream, and that
the frustration for the apache devs was particularly acute.  However, I
think it's safe to say that our users would rather have older versions
with everything working, and the easy ability to use package.unmask if
the latest-and-greatest is needed, than to have the latest-and-greatest
in a semi-broken state.

My thoughts, please feel free to disagree with me.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] apache and ~arch

[kang]

Grant Goodyear wrote:
<snip>

It's clear to me that _known broken_ things should never go in ~arch, 
but hardmasked instead.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache and ~arch

[Michael Stewart]

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

Grant Goodyear wrote:
> The serious breakage for people occurred because the apache devs
> released into ~arch the new apache ebuild before a number of rather
> important apache-module ebuilds had been rewritten to use the new
> apache config.  Now, I think we've all done things like that (forgotten
> a dependency, or something that uses the current package as a
> dependency, or missed an obscure USE flag) by accident, and that's why
> we have an ~arch tree.  The ~arch tree, at least in my understanding,
> is for testing ebuilds, and it's not surprising that sometimes the
> e-build has an error in it.  However, I don't believe that ~arch should
> be used for ebuilds that one _knows_ have broken functionality.  For
> such cases we have package.mask.

In defense of the Apache team, and myself as I am leading the unmasking
of Apache and it's modules....

I believe the specific situation you are referring to is mod_php. We did
patch it and have it hard masked, and wanted the php herd's stamp of
approval before we unmasked it. All of us that are working on this are
rather new developers (I myself have only been a dev since December),
and didn't want to break someone else's package, especially one as
complex as PHP. So we left it hard-masked while unmasking ours, and
referenced users to the already open bug about mod_php and also pointed
users at the hard-masked revision of mod_php that worked for us. I agree
it could have been handled better, but what we did seemed like enough at
the time. The packages are in ~arch, and we never intended them to go to
stable without all other expected packages there as well.

Some have suggested that we move backwards into hard-mask. I disagree 
with this. When we moved from hard-mask to ~arch, we did so to get a 
wider testing audience. We have run into a few glitches here and there, 
but that is the point of ~arch, to work all the glitches out before 
moving to stable. The major breakage that most users came across was the 
unexpected non-working of mod_php. And now mod_php revision that works 
with the new apache revision is no longer in hard-mask. Moving back to 
hard-mask at this point in time would only cause more headaches then 
pushing forward to get everything working together. Arguments for either 
side are welcome however.


-- 
Michael Stewart                                     vericgar@gentoo.org
Gentoo Developer                        http://dev.gentoo.org/~vericgar

GnuPG Key ID 0x08614788 available on http://pgp.mit.edu
--


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

Re: [gentoo-dev] apache and ~arch

[Ciaran McCreesh]

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

On Sun, 13 Mar 2005 11:24:41 -0600 Grant Goodyear <g2boojum@gentoo.org>
wrote:
| However, I don't believe that ~arch should be used for ebuilds
| that one _knows_ have broken functionality.  For such cases we
| have package.mask.

Indeed. It's in the developer docs and it's in the quiz. And yet...

http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
> I can understand that breaking the system isn't a very good idea and
> people will complain, but this does not count for the testing branch.

*sigh* Er, no. If you *know* it's broken, don't stick it in ~arch. If
it has no known issues, but hasn't been widely tested, then ~arch is
fine, but not if it's completely h0rked.

For how long have these people been developers and who were their
mentors? I'm starting to think that this wasn't a simple mistake --
rather, that it's a complete misunderstanding of what the different
KEYWORDS levels mean...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] apache and ~arch

[Christian Parpart]

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

On Monday 14 March 2005 3:43 pm, Ciaran McCreesh wrote:
> On Sun, 13 Mar 2005 11:24:41 -0600 Grant Goodyear <g2boojum@gentoo.org>
> wrote:
> | However, I don't believe that ~arch should be used for ebuilds
> | that one _knows_ have broken functionality.  For such cases we
> | have package.mask.
>
> Indeed. It's in the developer docs and it's in the quiz. And yet...
>
> http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering

He still does great work. So, please don't stick on words written down in hot 
times.

> > I can understand that breaking the system isn't a very good idea and
> > people will complain, but this does not count for the testing branch.
>
> *sigh* Er, no. If you *know* it's broken, don't stick it in ~arch. If
> it has no known issues, but hasn't been widely tested, then ~arch is
> fine, but not if it's completely h0rked.

FYI, mod_php wasn't "completely borked". It's just not been unmasked at the 
same time as the others went out of the hardmask state.

> For how long have these people been developers and who were their
> mentors? I'm starting to think that this wasn't a simple mistake --
> rather, that it's a complete misunderstanding of what the different
> KEYWORDS levels mean...

I - in my case - have learned my lessons from this - who cares.

Regards,
Christian Parpart.

-- 
Netiquette: http://www.ietf.org/rfc/rfc1855.txt
 16:27:26 up 136 days,  8:57,  1 user,  load average: 0.12, 0.21, 0.24

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

Re: [gentoo-dev] apache and ~arch

[Grant Goodyear]

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

Michael Stewart wrote: [Mon Mar 14 2005, 03:23:38AM CST]
> I believe the specific situation you are referring to is mod_php. We did
> patch it and have it hard masked, and wanted the php herd's stamp of
> approval before we unmasked it. All of us that are working on this are
> rather new developers (I myself have only been a dev since December),
> and didn't want to break someone else's package, especially one as
> complex as PHP. So we left it hard-masked while unmasking ours, and
> referenced users to the already open bug about mod_php and also pointed
> users at the hard-masked revision of mod_php that worked for us. I agree
> it could have been handled better, but what we did seemed like enough at
> the time. The packages are in ~arch, and we never intended them to go to
> stable without all other expected packages there as well.

Again, I certainly understand that one makes mistakes.  My e-mail was
not intended to castigate the new apache devs, but instead to point out
an error, explain my rationale, and subtly suggest that you not do
something similar in the future.  Reading your response, and especially
hollow's blog posting, however, it seems that I also should have more
firmly pointed out a misconception: ~arch in Gentoo is supposed to be
as fully functional as the Gentoo devs can make it.  Saying that "we
never intended them to go to stable without all other expected packages
there as well" means that point was missed; for situations where you
want to release before all packages are ready we have package.mask.
The rationale is fairly simple: ~arch is for testing ebuilds,
essentially for finding non-trivial errors (especially errors in
interactions between packages), and that's awfully hard to do if not
all packages are available.

> Some have suggested that we move backwards into hard-mask. I disagree 
> with this. When we moved from hard-mask to ~arch, we did so to get a 
> wider testing audience. We have run into a few glitches here and there, 
> but that is the point of ~arch, to work all the glitches out before 
> moving to stable. The major breakage that most users came across was the 
> unexpected non-working of mod_php. And now mod_php revision that works 
> with the new apache revision is no longer in hard-mask. Moving back to 
> hard-mask at this point in time would only cause more headaches then 
> pushing forward to get everything working together. Arguments for either 
> side are welcome however.

Now that the shiny new mod_php ebuild is available, I tend to agree
that masking the new stuff would be a mistake.  Indeed, masking any
package that has already been released is almost always a disaster if
the new release was incompatible with the old release.  That's
precisely why one has to be so careful not to unmask packages before
they're ready.

Finally, let me say that I'm quite grateful that you folks are
maintaining apache.  It's an important package, and not a simple one,
and I appreciate all of the work that went into the new config.  You
folks did good work, and along the way made a moderately big mistake.
It happens.  Just fix it (it looks like it mostly is, now),  please
don't do it again, and we'll all move on.

-g2boojum-
-- 
Grant Goodyear	
Gentoo Developer
g2boojum@gentoo.org
http://www.gentoo.org/~g2boojum
GPG Fingerprint: D706 9802 1663 DEF5 81B0  9573 A6DC 7152 E0F6 5B76

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

Re: [gentoo-dev] apache and ~arch

[Jochen Maes]

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


| For how long have these people been developers and who were their
| mentors? I'm starting to think that this wasn't a simple mistake --
|
This is a mistake, i know it's a stupid mistake perhaps but it is a
mistake. Don't start insinuating other things.

As Grant said, we all make mistakes, so fix them and learn from it.
move on :-)

greetings

- --
"Defer no time, delays have dangerous ends"

Jochen Maes                    
Gentoo Linux                      
http://dev.gentoo.org/~sejo/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFCNcKDMXMsRNMHhmARAk54AJ9X7PnJlVjLA9DxEBVPfrOdTEe9YwCfd0J2
2kZ9t2gmYCm/bezrOMoDhxU=
=DaYD
-----END PGP SIGNATURE-----

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache and ~arch

[Marius Mauch]

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

On Mon, 14 Mar 2005 17:57:39 +0100
Jochen Maes <sejo@gentoo.org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> | For how long have these people been developers and who were their
> | mentors? I'm starting to think that this wasn't a simple mistake --
> |
> This is a mistake, i know it's a stupid mistake perhaps but it is a
> mistake. Don't start insinuating other things.
> 
> As Grant said, we all make mistakes, so fix them and learn from it.
> move on :-)

http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
"... and users using testing may not complain if things break."

That's the real problem.

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.

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

Re: [gentoo-dev] apache and ~arch

[Ciaran McCreesh]

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

On Mon, 14 Mar 2005 17:57:39 +0100 Jochen Maes <sejo@gentoo.org> wrote:
| | For how long have these people been developers and who were their
| | mentors? I'm starting to think that this wasn't a simple mistake --
| |
| This is a mistake, i know it's a stupid mistake perhaps but it is a
| mistake. Don't start insinuating other things.

Sure, the original unmasking was a mistake. The followups from some of
these developers claiming that it wasn't a mistake or that it wasn't
their fault is what worries me...

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] apache and ~arch

[Sven Vermeulen]

Marius Mauch wrote:
> http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
> "... and users using testing may not complain if things break."
> 
> That's the real problem.

They *should* complain, constructively, on a bugreport, stating the 
issue and how they could resolve it. If people wouldn't be allowed to 
reply to ~arch bugs, then why do we have ~arch?

-- 
  ^__^   And Larry saw that it was Good.
  (oo)                                      Sven Vermeulen
  (__)   http://www.gentoo.org              Documentation & PR
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] apache and ~arch

[Ciaran McCreesh]

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

On Tue, 15 Mar 2005 10:08:42 +0100 Sven Vermeulen <swift@gentoo.org>
wrote:
| Marius Mauch wrote:
| > http://planet.gentoo.org/developers/hollow/2005/03/14/apache_dithering
| > "... and users using testing may not complain if things break."
| > 
| > That's the real problem.
| 
| They *should* complain, constructively, on a bugreport, stating the 
| issue and how they could resolve it. If people wouldn't be allowed to 
| reply to ~arch bugs, then why do we have ~arch?

We have ~arch for things that aren't well tested but aren't believed to
be broken. So, some midpoint is needed on the ~arch being broken thing.
On the one hand, it's not suitable for running on production kit, so
complaints about things which aren't known to be broken being added to
~arch aren't particularly viable. On the other hand, constructive useful
bug reports about breakages in ~arch that the maintainer doesn't know
about *are* useful, since they'll let the maintainer know that the
package isn't ready to go stable.

Probably easiest to think of ~arch as meaning "candidate for arch after
more testing".

-- 
Ciaran McCreesh : Gentoo Developer (Vim, Fluxbox, shell tools)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


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

Re: [gentoo-dev] apache and ~arch

[Paul de Vrieze]

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

On Sunday 13 March 2005 18:24, Grant Goodyear wrote:
> Yes, I was one of the many people who emerged the new apache ebuild
> without paying sufficient attention to the mailing list post announcing
> the dramatic changes.  *Shrug*  It took me a day or so to get things
> fixed, but that was my own fault, and I have no complaints about the
> new config.

<cut>

> So, what should one do about a package that, in and of itself, is fully
> functional, but related packages have not yet been updated and package
> maintainers cannot be urged to move faster to fix the packages?  Well,
> nagging on bugs is usually the first step, followed by nagging on -dev
> so that people know that there is a problem.  If that doesn't work, the
> traditional method is to patch the related ebuilds oneself, add the
> patched ebuilds to package.mask in a nice big block along w/ the
> principal package, and start asking people to test.  That way, once it
> appears that the bugs are reasonably worked out the whole block can be
> unmasked at once, minimizing pain for our users who "can't read".
> Moreover, once this step is done it is perfectly reasonable to post a
> bug and a message to -dev saying "New foo system seems to be working,
> and we plan to unmask all at once in 30 days unless any maintainers of
> these packages [provide list] explicitly tells us not to do so."
>
It's actually worse. I had a new testing version of subversion in package 
mask, but it did not get unmasked with apache. Neither did I get notified 
(except by the general announcement) that the new apache stuff would be 
unmasked. I caught it in a couple of hours, but am wary of what happens 
when the new apache is marked stable as that would introduce similar 
problems.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

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

Re: [gentoo-dev] apache and ~arch

[Aaron Walker]

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

Paul de Vrieze wrote:
> 
> It's actually worse. I had a new testing version of subversion in package 
> mask, but it did not get unmasked with apache. Neither did I get notified 
> (except by the general announcement) that the new apache stuff would be 
> unmasked. I caught it in a couple of hours, but am wary of what happens 
> when the new apache is marked stable as that would introduce similar 
> problems.

Yeah those were nice segfaults.

- --
Pundure's Roole-a:
	Nefer oopee a bux yuoo deedn't cluse-a.
Bork Bork Bork!

Aaron Walker <ka0ttic@gentoo.org>
[ BSD | cron | forensics | shell-tools | commonbox | netmon | vim | web-apps ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCQCyXC3poscuANHARAlT2AKDDtZSfugd/eo8Uj530ifPv++rrUQCfVabd
23AYwKkFMm/WnRR/1sGSoAU=
=EgD6
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list