Manuel A. Fernandez Montecelo <[email protected]> wrote: > If for example it's decided that we shouldn't touch the current > repository for the time being, then maybe it's better to clone it > elsewhere and fix stuff without more delay, and then it would be > pulled by dburrows when he becomes available again. I think that this > way of doing things would be less intrusive (+1) and would allow us > and maybe other interested people to tweak and learn about the code > without causing trouble to the real repository (+1), but with the > effect that we would not be able to release directly and thus still > not making easier the process of triaging bugs, etc.
There is currently a clone on gitorious that hosted a QT development branch. However, given my suggestion below, I think we can unintrusively work on the alioth repo. Either way, I agree that it is best to begin such efforts soon. > On Saturday 31 Dec 2011 09:45:20 Christian PERRIER wrote: >> I think it would be nice to have you guys able to commit in the >> repository but I can't do this now as I'm not admin for the project. > > Good. Is it OK for you, D. Hartwig? Yes, and this is preferable to creating a mirror somewhere. In support of this, especially if D. Burrows is not involved at this point, I propose to follow a strict policy for commits: 1. Master and debian branches for simple bug fixes and maintainence only. 2. Separate branch for each fix which requires extensive changes, to be peer-reviewed and merged only as appropriate. (Small changes can stay on the BTS for review). Branch names like: bug-341434-alt-configs 3. Feature branches : wip-multiarch Especially 2 and 3 are easier to work with than either a series of large patches on the BTS or such branches being in a mirrored repository somewhere. I have no idea how we will go in recruiting peers to review the work... Are there many interested developers following this list? To give an idea of the immediate changes I would push: There are some two dozen bugs currently tagged `patch' which after evaluating I consider suitable for comitting to the master branch. Some others are not suitable at all (due to changes in the code or just poorly done patches) -- these I shall untag shortly -- while others could be committed to separate branches or just remain in the BTS (for really small fixes). There are various changes to the packaging requested (#263318, #445125, etc.). Most of these are minor changes suitable for the debian branch. Proper multiarch support is very important before Wheezy freeze, which is proposed to be only a few months away. Dpkg and apt support is becoming quite mature. This is really a topic for another day. I have two local WIP nearing completion which address over a dozen bugs relating to locking and command line arguments/exit status. The changes to the code are extensive and certainly would require review before being merged. > >> I'll focus on the l10n stuff in the upcoming days. I was indeed >> wondering whether I should do it..:-) > > I saw that you went ahead, great! Indeed this is quite useful. Thank you. There are many bugs with minor corrections to the strings (missing newlines, etc.) and docs (paragraphs in the wrong place, ...) which I think will be easier to fix after apply all outstanding translation updates. This way it is possible to fix the string and it's translations all at once, without worrying that the changes will be undone or lost in a translation update. Consider #652419 (some prompt strings miss trailing spaces, etc.) where the changes required are trivial and translations could be updated at the same time as the main strings. Is this considered something which is ok to do or should all updates to the translations be done by someone who knows the language in question? Either way, I think it best to apply all changes affecting translations sooner rather than later so that translators can do their work in one pass, rather than having to keep following a series of changes over the next several months. _______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
