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

[Nirbheek Chauhan]

On Mon, Jul 12, 2010 at 8:14 AM, Enrico Weigelt <weigelt@×××××.de> wrote:
> * 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.
>

Ah, so you want us to use your git repos as patch managers? That
clears up a few things.

>> No, it does not. The security problems come because you are the single
>> point of failure.
>
> Which SPOF ?
>
> man 1 git-cone ;-p
>

So you don't want us to use your tarballs? That's a relief. If you'd
tell us on the bugs you opened that you want us to start using your
git repos, and add another layer of abstraction to our patch process,
say so! Then we can clearly say why we don't want to use them.

>> 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 ...):
>

[snip info about basic git working]
>   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).
>

Difference is that there are multiple upstreams while you are one, and
the larger upstreams (such as GNOME/KDE/FDO) have a professional
admins devoted to the security of their machines, while you're using a
free service on a public git website.

[snip proposal about us changing our workflow]

> d) some vendor (possibly myself) adds crappy changes: you'll most
>   likely have a look at the changes before cherry-picking them.
>

Makes sense. If we use your git repos for pulling patches we'll verify
them before applying them locally.

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

Of course, since now I understand that you don't want us to use your
tarballs, the hosting problem is a non-issue.

Oh wait, I just remembered. All the ebuilds that you submitted use
*your* tarballs.  And since you want us to use snapshot tarballs, the
same old problems of trust, security, redundancy come into play. If
you went away, all of them would break and we would need to go through
each and every ebuild, fix the SRC_URI to point back to upstream, and
apply the patches the way we do now.

Please decide if you want us to use your git repos as patch
aggregators or as snapshot tarball sources. Although, the question is
quite futile. The latter is completely unacceptable, and the former is
a major change in workflow and a dependency on you that few (if any)
will accept.

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

Why would they push their patches? You'd be an RSS reader. An
aggregator, You wouldn't need anyone to push anything.

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

Yes, in a sense you've already made the patch aggregation website.
Except you use git to store whatever patches you get manually from the
various sources. In essence, you've traded lots of short-term work for
extended work of manual patch aggregation and integration. Sure,
that's your choice, but that ensures that we will never make our
workflow dependent on your continued interest in the project.

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

*Shrug* you aggregate whatever is there in patch form. Refinements can
happen later. The same problem is also present in your current
approach, but that didn't stop you.

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

I'm reading this as: "I want everyone to change to my way of doing
things because it supposedly makes patch management easier". But since
you say that you're only offering a service, and we aren't compelled
to use it, I won't feel bad about firmly saying "No thanks. Most of us
see no net benefit in relation to the proposed change in workflow".

On the other hand, if you propose benefits w/o a change of workflow,
I'm sure many more people will be interested. Otherwise, all your
current efforts *will* go to waste. Infact, I've explained this twice
now[1], and you should really understand that people will not change
their workflow unless you give them a very good reason to do so.
"Possibly better patch management as long as I'm interested in it" is
not a valid reason (to say the least).


1. This means I won't try to explain it again.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team