Re: [gentoo-dev] [[e-mail]: [Bug 322157] [mail-filter/procmail] new ebuild + autocreate maildirs]

[Enrico Weigelt]

* Nirbheek Chauhan <nirbheek@g.o> schrieb:

> > Thats not even necessary. They just should use the infrastructure,
> > as described in my paper. So everyone can easily set up automatic
> > notifications, cherry-pick, etc, etc.
>
> Why should we?

To make tracking and applying other's changes much easier.
Currently it's quite work intensive to do so.

If - hypothetically - everyone work within an git repo, using a 
normalized naming/versioning scheme, it is trivial to set some
little tracking system, informing package maintainers if something
happens (new upstream, new patches from distro XYZ, etc). And
we can inspect that easily, take patches, etc, etc, using 
standard git tools.

> I am *yet* to see a single reason for us to change how we work
> other than "please use this since I've been putting a lot of
> effort into it".

I have no intention to urge you to use my approach, I'm just
offering you my works, nothing more.

> >> On a technical level, it's got serious security, trust, and
> >> redundancy problems.
> >
> > Git makes that very easy ;-p
> >
>
> No, it does not. The security problems come because you are the single
> point of failure.

Which SPOF ? 

man 1 git-cone ;-p

> The trust problems come because we have no reason to trust you.

You dont have to trust me. Just let me point out some possible 
leak points (if I missed some, feel free to add them ...):

a) repository manipulation (directly changing objects): will 
   be found out by git-gc.

b) injecting changed upstream: you can easily compare my UPSTREAM.*
   tags against the real upstream's tarballs or vcs tags. 
   
   BTW: as long as not all upstreams sign their releases, our trust 
   relies just relies on their server's integrity (and the connection
   to them).
   
c) manipulated tags: someone, perhaps myself overwrites other's tags 
   use signed tags, and check the signatures (easily doable by a 
   little shell script
 
d) some vendor (possibly myself) adds crappy changes: you'll most
   likely have a look at the changes before cherry-picking them.

> The redundancy problems come because if your hosting goes
> down or you lose interest, we're left high and dry.

That wouldn't affect your clones. You simply won't get anything
new from my site anymore.

> > If we're doing a good job (my generic fixes instead of distro-
> > specfic dirty hacks) about 99% can be shared ;-p
> >
>
> I'd advise you to take a look at the sort of patching Ubuntu/Debian
> does, and then revisit that figure. You'll find it more along the
> lines of 30%.

I never claimed that Ubuntu does clean and generic fixes. 

BTW: Gentoo tends to have similar problems, just look at the zlib ebuild:


>> # trust exit status of the compiler rather than stderr #55434
>> # -if test "`(...) 2>&1`" = ""; then
>> # +if (...) 2>/dev/null; then
>> sed -i 's|\<test "`\([^"]*\) 2>&1`" = ""|\1 2>/dev/null|' configure || die
>> sed -i -e '/ldconfig/d' Makefile* || die
					
> >> A practical solution to the problem of patch sharing is to
> >> have a website with a search interface for upstream source
> >> tarballs, which can display all the patches that various
> >> distros apply, as well as a download link for the patchsets
> >> (hotlinked to the distro files where possible).
> >
> > Too complicated, and actually would not help me a single bit.
>
> Help *you*? I thought this was about helping the distros.

Yes, I first want to solve my daily business problems, but in a way
that other folks can benefit from my works.

> >> Distro packagers are much more comfortable with downloading
> >> patchsets from a foreign source than complete tarballs.
> >
> > man git-format-patch ;-p
> >
>
> So why don't you submit that to bugzilla?

Yet too complicated/work intensive to do this for each individual
distro. It would be a completely different issue, if there was
some robot interface for that.

On the other hand, if you pull from my repo, you can easily hack
up a little bot, which tells you when something happens (or 
even send you patches).

> > Meanwhile I dont need it anymore, since I gave up maintaining
> > plaintext patches in favour of git. And that makes my daily works
> > _much_ easier.
> >
>
> You don't need to maintain **anything** manually if you code the
> website properly. That's the whole point. You get major benefits with
> minimal long-term work which can be done by a single person in their
> free time.

First, I have to build that website and maintain it over a long time.
Then I'll have to do a lot of advertisement work to get people to
actually push their patches there.

On the other hand, the git-based infrastructure is already there,
people can use it right now. And it gives my exactly what I need.
So I prefer spending my time in advocating this one.

> This job is easily automated to simply aggregate links to patches
> which all the distros manually publish themselves.

It's not that simple. Many distros don't even do proper patches, 
instead wildly copy over or directly sed certain sourcesfiles,
or even (like Debian) use their own broken tarballs.
(the worst srcpkg I've ever seen is Debian's mysql-5.0.32 ...)

And even *if* we assume, that everyone's just doing patches, we
still need to transform the everbody's strange (often not even
linear) versioning schemes. One of OSS-QMs primary goals is to
use a strictly normalized/canonical naming/versioning scheme in 
the primay source repository.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  [phone]  email: weigelt@×××××.de
 mobile: [phone]  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------