[Kolab-devel] Submitting Patches
Richard Bos
radoeka at xs4all.nl
Sat Dec 10 15:49:01 CET 2005
Op zaterdag 10 december 2005 13:02, schreef Bernhard Reiter:
> I must say that this statement leaves me confused.
> As written in my mail send a few minutes ago,
> getting the overview and the relation of patches together
> helps to make it easier to apply them in general.
>
> In order to help this, I have created a issue topic "patch",
> so we can search for all patches that are not handeled yet,
> more easily.
> I have tried to mark your and Marcus patches.
> So as far as I can see issue1010 and issue1021 are left.
Sounds good :) issue1010 is finished. There are things that can be
improved, but that go in another issue. One improvement that I would like to
see is to have execute permissions on the krh/bootstrap script. That should
be done on the server I assume.
> > As you have noticed already, after the initial patch I added other
> > changes, and I'll do the same for the patch that I'll attach to the
> > to be created issue. As such the patch becomes bigger and bigger and
> > more difficult to check.... I prefer small patches, picked up, checked
> > and committed quickly.
>
> Technically there are two ways to avoid a patch getting bigger:
> * make a patch depending on the first one, because you have made
> a copy on each patch creation
> * use a branch and non-branch tags, so patches ca always be
> generated and be the same, and keep on adding on top of this.
As the cvs commit rate is low I only want to provide 1 patch. So it is not a
technical reason, the patch keeps growing...
> > Opening issue's for each and every patch is cumbersome and
> > discouraging...! I understand that it works and it is easy to discuss the
> > patch, but it is not really enjoyable to do a patch 3 times in my free
> > time....
>
> Actually opening an issue makes sure the patch is not forgotten
> and (as written in my other email), one issue per feature can have
> several patches and we can talk about the relations of these.
It's a method, I have to admit. Perhaps put it in an FAQ ;) Make sure
someone is pointed to FAQ to create an issue as soon as an patch is provided
via email.
> > Anyway Marcus and me will continue as we don't want to leave an
> > incomplete build system behind. Hopefully, you'll include the to be
> > submitted patch and the patch to perl-kolab in the next beta (openpkg
> > 2.5).
>
> We have not done a beta for 2.1 yet because of your patches
> and Bernhard H. and I were thinking about another snapshot next week.
I'll already open 1 additional issue for the perl-kolab autoconfiscation
patch. As soon as the patch is available we'll attach it. It should be
available this weekend.
> > This patch and
> > the one to perl-kolab finished the autoconfiscation foundation, after
> > that it is only building upon the foundation....
>
> This comment is an example why I want a better overview,
> it is hard to find out about which patches those comments are,
> my hope was that issue numbers and comment in there makes this more
> transparent.
Okay.
--
Richard Bos
Without a home the journey is endless
More information about the devel
mailing list