Scott Scriven said: (by the date of Thu, 26 Jun 2008 07:55:24 -0600) > if I can make things easier I'd like to try. :)
that's great. See my other message about write access (in which I forgot to thank Timo for explaining git - thanks!). > As for the rest of this message, sorry it's so long. It's just > ideas for how to possibly make things easier. yeah, thank you for that. When gnome moves to bzr, your job will be to write a short wiki page about quick introduction to bzr - related to working with sawfish repo. > I'm actually pretty new to launchpad, but I like it so far. It's > kind of like sourceforge, except better. just a side note - launchpad is hosted by canonical - the people who made ubuntu. AFAIK the CMS used on launchpad is closed source, but maybe it has changed recently? > > ... having all patches listed in a single place. > > It seems to me like a good idea to extend this idea further. > There seem to be sawfish add-ons all over... could we merge > these into a "contrib" area in the sawfish repository, or > something similar? > > This would help keep things in one place, but it also would > probably make the write-access bottleneck worse. Very few people > can commit changes to the repository. that's an interesting idea. Except for the write access bottleneck, which can be solved by giving access to more people. If we wanted to stay strict we could give access rights to people to only certain subdirectories in the repo. But I'm not sure if it's worth the hassle, as we should approach each other with trust :) > > Currently people who want to contribute to sawfish only need to > > know how to create a patch, and how to edit a wiki webpage. > > That can remain the same, if desired. However, we could give > people more advanced options if they prefer. I'd rather post a > merge bundle than a simple patch, and it'd be nice to get > notifications of new changes instead of having to check. Yeah, however it evolves, I think that we should stay with patch voting system on the wiki. Just the patches will not be copy/pasted in the page, but instead a proper instruction to test it by downloading from the repo would be provided. People then would just run the shell commands listed on wiki to test it. I emphasise the "shell commands" because doing a copy/paste of shell instructions is much simpler than thinking about how to download the patch to test it. It saves a time for the tester, while the patch author doesn't spend too much time to write them. He obviously knows those commands - they're in his shell's history, just press the up arrow ;-) > BTW... I found out that there is some discussion elsewhere about > moving all of GNOME to bzr or git. Some of the launchpad team > are going to GUADEC (July 7-12) to discuss it, along with people > from Red Hat and Novell. > > I get the impression that the GNOME discussion isn't "if" but > "when" and "how". I know sawfish isn't really part of GNOME any > more, but as long as it's still hosted by GNOME's servers, it > would be good to pay attention. :) there was one thing which was disturbing for me about BZR. Unless explicitly instructed it kept insisting on downloading whole repository, all revisions. We wanted to move to BZR with YADE which is quite a big project. Downloading YADE with all its history took quite a long time, so finally that's why we decided to stay with SVN. But sawfish is small in size, so that shouldn't be a problem. However I'm curious how gnome team will cope with that. Waiting 15 minutes to download gnome desktop (with whole history)? If I was a dev there, it would be a no-go for me. But it was about a year ago... so maybe it changed now. -- Janek Kozicki |
