Timo Korvola said: (by the date of Wed, 25 Jun 2008 14:10:03 +0300) > Scott Scriven <[EMAIL PROTECTED]> writes:
> > It would probably help with all the patch > > management, and make it easier for people to contribute. > > A problem with the wiki is that there is sort of a reasonable patch > size. Very small things like typos don't get fixed, because they are > not worth the hassle to set up a wiki page, and very big things don't > get fixed because the changes would be too big for a single patch. Wow, I'm very happy to see that sawfish development is gaining even more momentum. There are currently 17 patches waiting on the wiki. And I cannot do anything right now about this, because I need to prepare for incoming conferences (29.06-5.07 Venice and 13.07-20.07 Montreal) which is quite a hard work in fact. I'm skilled at working with SVN and 'patch -lp1 < ...', but I have no time to learn bzr or git. But FOR SURE I'm not going to hold you back. Maybe, just maybe, my role here to "revive" sawfish is done, and now when the development gets more momentum, someone else should take the "maintainer" stick from me? Just volunteer, and I will do everything needed to provide you with all access rights that currently I have. Then you will be free to set up a bzr or git repository for sawfish, and mark it as an official repository. Personally, to avoid potential problems with 'organizing and managing' of development, I just want to say, that in my view the current model works well - for me (perhaps *only* for me). - formatting problems on patch pages, are solved by applying patch using -l flag (--ignore-whitespace) - adding a new patch (be it a single liner, or 2000-liner) is still as simple as clicking the button "Create patch page". Even if sometimes is feels a bit awkward to do so, due to not-normal patch length. For me it's simple, because when I have time to make release I just browse all submitted patches, consult with the mailing list, and finally apply a patch. A process quite simple and transparent. The bonus side for me, is that it does not require bzr or git skills. Currently people who want to contribute to sawfish only need to know how to create a patch, and how to edit a wiki webpage. If we are going to switch to bzr or git, such person would need to know how to work with them. That's an extra step, which may deter potential contributors. Therefore if I am to stay as the guy who makes releases by applying patches, I would prefer to stay with the current method, because it just works for me, and doesn't require extra learning of other tools. But I really don't want to hold the sawfish development. It's just my personal time constraints, that make it difficult to cope, if it gets bigger or complicated. A single place (currently a wiki) to view all patches waiting in queue is very convenient. There is another solution also, someone of you will set up a git or bzr repository, we will mark it as the official one (and deprecate that one on gnome server). Then patches could be committed there into branches, and the wiki patch page would not include a diff for it, only the explanation and voting. Instead of a diff, there would be an instruction on how to pull from repository a version of sawfish with that patch included. And finally, there would be and instruction (for me) on some other wiki page, how to merge those patches, so that I would not need spend time learning that. But then... are you sure that you still need me? :) perhaps we should do some voting here about the sawfish future? - vote no 1. remain status quo - vote no 2. someone (Scott ? ;) volunteers to maintain using bzr - vote no 3. someone (Timo ? ;) volunteers to maintain using git any other options? :) -- Janek Kozicki |
