[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: [patch] Re: GUI consistency
From:       Marc Mutz <mutz () kde ! org>
Date:       2002-09-01 10:28:31
[Download RAW message or body]

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

[ Sorry to take PM to the list; hadn't you mentioned your wanting to 
commit, I would've had no point in doing so. ]

Earlier on, Don Sanders wrote in thread "Independent commands diff":
> I don't regard the missing menu items as being a bug, so I guess the 
> right thing to do is to wait until 3.1 is released. Hopefully this 
> will be on schedule in a month and a half.
> 
> This will mean that I'll probably have quite some conflicts to resolve 
> before I can commit.

On Sunday 01 September 2002 08:57, Don Sanders wrote:
> On Friday 30 August 2002 21:22, Marc Mutz wrote:
<snip>
> > So what? It does for everyone who has non-trivial patches applied
> > locally.
>
> cvs conflicts are a problem because they introduce the possibility
> that I'll make an error when resolving them and add more work for me.

Yes, that's how it works.

> I mean it wouldn't make sense to reformat all the tabbing in files
> to make then consistent when I have a large patch outstanding.

I agree here. But Carsten's patch is not about cleaning indention.

> It also doesn't make sense for me to with hold my cleanup when other
> cleanups are being committed.

It's not a cleanup. It's introducing _a whole new interface_. Tested 
only by yourself. _After_ the first beta is out. _While_ we're in 
feature freeze.

> Once the cryptPlugList changes are made I'll commit my cleanup with
> the new features #if out.

So you revised your opinion quoted above, based solely on the fact that 
_you_ now seem to have more work merging.
CVS is _not_ a dumping ground for unfinished patches.
If you feel merging is getting over your head, open a 
kmail_commands_branch and commit there.

> > We are in a feature_freeze_, not in a feature_race_.
> > When will you all understand this?
>
> I guess I understood it when I submitted my patch with the new
> features enumerated in an #if.
<snip>

No, you obviously did not. Else, you wouldn't try to force a 
(technically, not lines of code) intrusive patch in *for your 
convenience* while everybody else holds back much lighter patches (I'm 
thinking about folder tree DnD and mainling list management here, e.g.) 
and duely add it to the 3.2 feature list.

But _you_ are of course special. _You_ don't need to abide the rules.
Not.

Marc

- -- 
If free-software authors lose the right to disclaim all warranties and
find themselves getting sued over the performance of the programs
they've written, they'll stop contributing free software to the world.
 -- Bruce Perens: Open Sources: Voices from the Open Source Revolution
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ceve3oWD+L2/6DgRAidKAJ4x2AbHIoZciNw/OZhITvAOybEoQACfUBAa
dOXLUs2NuAZCc0YLRvDdvjg=
=Yn7j
-----END PGP SIGNATURE-----

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail
[prev in list] [next in list] [prev in thread] [next in thread]